Sunteți pe pagina 1din 212

FP7-SEC-2007-4.2.

01 Network enabled command and control system


ESS D2.1 State-of-the-Art Report ESS– 217951

ESS
Emergency Support System

Project Number: 217951 (IP)

Deliverable D2.1

Analysis Report of state-of-the-art technologies for crisis


discovery and management

Due date of deliverable M6


Actual submission date 15.01.2010
Organisation name of lead beneficiary for this deliverable IGSI
Dissemination Level PU
Start date of project 01 June 2009
Duration 48 months

Version History
Version Number Date Status Distribution
0.1 30.11.2009 First draft ESS consortium
1.0 07.12.2009 Final draft ESS consortium
1.0.1 15.12.2009 Final (reviews by partners ESS consortium for pub-
integrated) lic release

© ESS Consortium 2009 1


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

!"#$%&'(&)'*+%*+,&

DELIVERABLE D2.1 ............................................................................................................... 1!


ANALYSIS REPORT OF STATE-OF-THE-ART TECHNOLOGIES FOR CRISIS
DISCOVERY AND MANAGEMENT ........................................................................................ 1!
1! MANAGEMENT SUMMARY ............................................................................................. 7!
1.1! PURPOSE OF THIS DOCUMENT ....................................................................................... 7!
1.2! SUMMARY ..................................................................................................................... 7!
2! ABBREVIATIONS AND ACRONYMS............................................................................... 8!
3! TABLES ........................................................................................................................... 14!
4! FIGURES ......................................................................................................................... 15!
5! GENERAL ARCHITECTURE APPROACHES ................................................................ 18!
5.1! ARCHITECTURAL STYLES REST, SOA, GRID, P2P, AND EDA ...................................... 18!
5.2! REST, RESTFUL AND ROA ........................................................................................ 18!
5.3! SOA........................................................................................................................... 20!
5.4! DESIGN GUIDELINES FOR ESS .................................................................................... 20!
5.5! GRID COMPUTING ....................................................................................................... 21!
5.6! P2P............................................................................................................................ 22!
5.7! EDA AND CEP............................................................................................................ 23!
6! EVENT DRIVEN SPATIAL DATA INFRASTRUCTURE ................................................. 24!
6.1! INTRODUCTION............................................................................................................ 24!
6.2! RELATED TECHNOLOGIES ............................................................................................ 24!
6.2.1! Realizing Publish / Subscribe in ROA................................................................. 25!
6.2.2! Realizing Publish / Subscribe in SOA ................................................................. 25!
6.3! AVAILABLE SPECIFICATIONS ........................................................................................ 30!
6.3.1! Event Model ........................................................................................................ 30!
6.3.2! Event Pattern Markup Language ........................................................................ 31!
6.3.3! Web Notification Service..................................................................................... 32!
6.3.4! Sensor Alert / Event Service ............................................................................... 33!
6.4! CONCLUSIONS ............................................................................................................ 34!
7! OGC SENSOR WEB ENABLEMENT ............................................................................. 37!
7.1.1! Introduction ......................................................................................................... 37!
7.1.2! OGC SWE Sensor Model ................................................................................... 38!
7.1.3! SWE Enterprise Perspective............................................................................... 40!
7.1.4! SWE Services and Encodings ............................................................................ 41!
7.1.5! Sensor Planning Service..................................................................................... 52!
7.1.6! Sensor Alert Service ........................................................................................... 54!
7.1.7! Sensor Event Service ......................................................................................... 55!
7.1.8! Web Notification Service..................................................................................... 55!
8! OGC WEB SERVICES .................................................................................................... 56!
8.1! WEB MAP SERVICE (WMS) ......................................................................................... 56!
8.2! WEB COVERAGE SERVICE (WCS) ............................................................................... 58!
8.3! WEB FEATURE SERVICE (WFS)................................................................................... 58!
8.4! WEB PROCESSING SERVICE (WPS)............................................................................. 59!
8.5! CATALOGUE SERVICE FOR WEB (CSW)....................................................................... 59!
8.6! SDI SERVICE INTEGRATION ......................................................................................... 60!

2 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

8.7! CONCLUSIONS ............................................................................................................ 61!


9! EMERGENCY MANAGEMENT STANDARDS FROM OASIS ....................................... 63!
9.1! INTRODUCTION............................................................................................................ 63!
9.2! COMMON ALERTING PROTOCOL .................................................................................. 63!
9.3! EMERGENCY DATA EXCHANGE LANGUAGE .................................................................. 64!
9.3.1! Distribution Element (EDXL-DE)......................................................................... 64!
9.3.2! Resource Messaging (EDXL-RM)....................................................................... 66!
9.3.3! Hospital Availability Exchange (EDXL-HAVE) .................................................... 68!
9.4! CONCLUSIONS ............................................................................................................ 70!
10! MULTIMEDIA STREAMING DATA ............................................................................... 72!
10.1! INTRODUCTION.......................................................................................................... 72!
10.2! SESSION DESCRIPTION PROTOCOL ............................................................................ 73!
10.3! APPLICATION OF SDP IN EMERGENCY SYSTEMS ........................................................ 75!
10.4! CONCLUSIONS .......................................................................................................... 76!
11! TRAFFIC INFORMATION INTERFACES ..................................................................... 77!
11.1! SUPPLY OF TRAFFIC INFORMATION TO DRIVERS ......................................................... 78!
11.1.1! RDS-TMC ......................................................................................................... 78!
11.1.2! TPEG ................................................................................................................ 81!
11.1.3! Agora-C............................................................................................................. 84!
11.1.4! OpenLR............................................................................................................. 87!
11.2! INTERFACES FOR TRAFFIC CONTROL CENTRES .......................................................... 88!
11.2.1! UMTC................................................................................................................ 88!
11.2.2! NTCIP ............................................................................................................... 91!
11.2.3! Datex II.............................................................................................................. 93!
11.3! INTERFACES FOR TRAFFIC APPLICATIONS (B2B) ........................................................ 95!
11.3.1! KML................................................................................................................... 96!
11.3.2! WMS ................................................................................................................. 98!
12! TRAFFIC MEASUREMENTS METHODS ..................................................................... 99!
12.1! TRADITIONAL METHODS ............................................................................................. 99!
12.1.1! Journalistic and Human Reported Information.................................................. 99!
12.1.2! Traffic Measurement Technologies................................................................... 99!
12.2! FLOATING VEHICLE DATA ........................................................................................ 100!
12.3! COMMUNITY BASED SOLUTIONS ............................................................................... 101!
12.4! CONCLUSION .......................................................................................................... 101!
13! CELL BROADCAST SERVICE ................................................................................... 102!
13.1! DESCRIPTION .......................................................................................................... 102!
13.2! SCHEDULING OF INFORMATION TRANSPORT ............................................................. 105!
13.3! NODES OF CBS ARCHITECTURE .............................................................................. 106!
13.3.1! Cell broadcast entity ....................................................................................... 106!
13.3.2! Cell broadcast centre ...................................................................................... 106!
13.3.3! Base station controller .................................................................................... 107!
13.4! MODE OF OPERATION ............................................................................................. 107!
13.5! CONCLUSIONS ........................................................................................................ 108!
13.6! RELEVANT LINKS ..................................................................................................... 108!
14! SATELLITE TECHNOLOGIES .................................................................................... 110!
14.1! DESCRIPTION .......................................................................................................... 110!
14.1.1! Satellite HUB................................................................................................... 111!
14.1.2! Subscriber terminal ......................................................................................... 111!
14.1.3! Satellite Transmission Channel ...................................................................... 112!
14.1.4! ServicesTopologies......................................................................................... 112!

© ESS Consortium 2009 3


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

14.1.5! Critical Operation Conditions On Satellite Networks....................................... 112!


14.2! SATELLITE SERVICE PROVIDERS.............................................................................. 113!
14.2.1! ASTRA2Connect™ ......................................................................................... 113!
14.2.2! Tooway™ ........................................................................................................ 114!
14.3! CONCLUSIONS ........................................................................................................ 117!
14.3.1! Modulation parameters Adaptation ................................................................. 118!
14.3.2! Bandwidth Management Policy....................................................................... 118!
14.3.3! Satellite Signal Propagation Delay.................................................................. 118!
14.3.4! Satellite Antenna Pointing............................................................................... 119!
14.4! RELEVANT LINKS ..................................................................................................... 119!
15! HIPERLAN/2 ................................................................................................................ 120!
15.1! DESCRIPTION .......................................................................................................... 120!
15.2! COMMENTS FROM INVESTIGATOR ............................................................................ 121!
15.3! RELEVANT LINKS ..................................................................................................... 121!
16! SELF-ORGANIZED NETWORKS ............................................................................... 122!
16.1! DESCRIPTION .......................................................................................................... 122!
16.2! PROJECT MESA ..................................................................................................... 124!
16.3! AD HOC NETWORKS ................................................................................................ 124!
16.3.1! Wireless ad hoc networks ............................................................................... 124!
16.3.2! Mobile ad hoc networks .................................................................................. 125!
16.3.3! Mesh Networks ............................................................................................... 125!
16.3.4! Key implementation requirements .................................................................. 127!
16.4! CONCLUSIONS ........................................................................................................ 129!
16.5! RELEVANT LINKS ..................................................................................................... 130!
17! PEOPLE DETECTION AND LOCATION ASSESSMENT .......................................... 131!
17.1! LOCATING PEOPLE AT CRISIS ZONES ....................................................................... 131!
17.1.1! Cellular Location in Case of Proper Cellular Service ...................................... 131!
17.1.2! LBS Comprehensive Solution ......................................................................... 133!
17.1.3! Combination of Active and Passive Technology – A Comprehensive Location
Framework .................................................................................................................... 135!
17.1.4! Mediation Server............................................................................................. 136!
17.1.5! GMLC (Gateway Mobile Location Centre) ...................................................... 137!
17.2! CELLULAR LOCATION METHODS .............................................................................. 137!
17.2.1! Cell ID ............................................................................................................. 137!
17.2.2! Enhanced Cell ID (E-CID)............................................................................... 138!
17.2.3! Uplink Time Difference of Arrival (U-TDOA) ................................................... 139!
17.2.4! Assisted-GPS (A-GPS) ................................................................................... 140!
18! C4I SYSTEMS ............................................................................................................. 141!
18.1! IEEE 1512 ............................................................................................................. 141!
18.2! SHIFT .................................................................................................................... 142!
18.3! ITCM...................................................................................................................... 143!
18.3.1! Background..................................................................................................... 143!
18.3.2! Added Value ................................................................................................... 145!
18.3.3! Standardisation ............................................................................................... 145!
18.4! SHARED OPERATIONAL PICTURE EXCHANGE SERVICES (SOPES)............................ 146!
18.5! GLOBAL COMMAND AND CONTROL SYSTEM – JOINT (GCCS-J) ................................ 146!
18.6! TACTICAL SITUATION OBJECT .................................................................................. 148!
18.6.1! Description ...................................................................................................... 148!
18.6.2! Comments from Investigator........................................................................... 148!
18.6.3! Relevant Links ................................................................................................ 149!

4 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

19! VISUAL ANALYTICS .................................................................................................. 150!


19.1! GEOGRAPHIC ANALYSIS .......................................................................................... 151!
19.2! AN APPLICATION: ANALYSIS OF MOVEMENT IN GEOGRAPHICAL SPACE ..................... 151!
19.2.1! Analysis of movement of a single entity.......................................................... 152!
19.2.2! Analysis of movements of multiple unrelated entities ..................................... 155!
19.2.3! Analysis of movements of multiple related entities ......................................... 157!
19.3! ASSESSMENT FOR ESS........................................................................................... 159!
20! VISUALLY-DRIVEN OPTIMIZATION TOOL FOR EVACUATION SCHEDULING..... 160!
20.1! SHORT DESCRIPTION .............................................................................................. 160!
20.2! VISUAL ANALYTICS TOOLS ....................................................................................... 162!
20.2.1! The Data to be Examined ............................................................................... 162!
20.2.2! Dynamic Aggregation...................................................................................... 162!
20.2.3! Visualization and User Interaction .................................................................. 163!
20.2.4! Modification of a Schedule.............................................................................. 165!
20.3! CONCLUSIONS ........................................................................................................ 166!
20.4! MORE DETAILS ....................................................................................................... 167!
21! VISUAL ANALYTICS TOOLKIT.................................................................................. 168!
21.1! DESCRIPTION .......................................................................................................... 168!
21.2! COMMENTS FROM INVESTIGATOR ............................................................................ 168!
21.3! RELEVANT LINKS ..................................................................................................... 168!
22! 3D VISUALIZATION OF MASSIVE GEOGRAPHICAL DATASETS .......................... 169!
22.1! INTRODUCTION........................................................................................................ 169!
22.2! TOOLS .................................................................................................................... 170!
22.2.1! Google Earth................................................................................................... 170!
22.2.2! Microsoft Bing Maps, Virtual Earth or Yahoo! Maps ....................................... 171!
22.2.3! NASA World Wind........................................................................................... 172!
22.2.4! Terra Explorer ................................................................................................. 173!
22.2.5! OssimPlanet.................................................................................................... 173!
22.2.6! Luciad, PRESAGIS, RATMAN and ESRI ....................................................... 173!
22.2.7! Virtual Geo ...................................................................................................... 175!
22.2.8! 3D visualisation of geographic dataset systems for crisis management......... 176!
22.2.9! Summary......................................................................................................... 178!
22.3! RELEVANT LINKS ..................................................................................................... 179!
23! INFORMATION TECHNOLOGY IN FOREST FIRE MANAGEMENT ......................... 180!
23.1! FOREST FIRE EMERGENCY ...................................................................................... 180!
23.2! FIRE DANGER RATING ............................................................................................. 181!
23.3! FOREST FIRE DETECTION ........................................................................................ 182!
23.4! FIRE MODELLING..................................................................................................... 183!
23.5! ASSESSMENT FOR ESS........................................................................................... 185!
24! ITU ACTIVITIES FOR EMERGENCY MANAGEMENT............................................... 186!
24.1! OVERVIEW BY ITU SECRETARY GENERAL ................................................................ 186!
24.2! “SAVING LIVES”: GLOBAL FORUM ON THE ROLE OF TELECOMMUNICATIONS AND ICT IN
DISASTER MANAGEMENT ..................................................................................................... 186!
24.3! ITU’S ROLE IN EMERGENCY TELECOMMUNICATIONS .................................................. 190!
24.3.1! Radiocommunications (ITU-R)........................................................................ 190!
24.3.2! Standardization (ITU-T) .................................................................................. 191!
24.3.3! Development (ITU-D)...................................................................................... 191!
24.4! THE TAMPERE CONVENTION .................................................................................... 191!
24.5! ITU RESPONDS TO NATURAL DISASTERS .................................................................. 192!
24.5.1! Floods in Bangladesh ..................................................................................... 192!

© ESS Consortium 2009 5


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

24.5.2! Ugandan floods............................................................................................... 192!


24.5.3! Indian Ocean tsunami ..................................................................................... 193!
24.5.4! Study of emergency telecommunications in Bangladesh ............................... 193!
24.5.5! Pakistan earthquake ....................................................................................... 193!
24.5.6! Floods in Suriname ......................................................................................... 194!
24.5.7! Indonesian earthquake ................................................................................... 194!
24.5.8! Emergency vehicles for Sri Lanka .................................................................. 194!
24.5.9! Earthquake in Peru ......................................................................................... 194!
24.5.10! Better links in the Marshall Islands ............................................................... 195!
24.6! WORLD RADIOCOMMUNICATION CONFERENCE (WRC-07)........................................ 195!
24.7! COMPENDIUM OF ITU’S WORK IN EMERGENCY TELECOMMUNICATIONS ..................... 196!
24.8! ITU-T REC. X.1303 (COMMON ALERTING PROTOCOL) ............................................. 196!
25! RELATED PROJECTS ................................................................................................ 197!
25.1! HUMBOLDT .......................................................................................................... 197!
25.2! SANY..................................................................................................................... 197!
25.3! OSIRIS .................................................................................................................. 198!
25.4! OASIS ................................................................................................................... 198!
25.5! NIPI ....................................................................................................................... 198!
25.6! WISECOM............................................................................................................. 199!
26! CONCLUSIONS FOR ESS .......................................................................................... 202!
26.1! TRAFFIC MANAGEMENT ........................................................................................... 203!
26.2! CELL BROADCASTING .............................................................................................. 203!
26.3! NETWORKS ............................................................................................................. 204!
26.4! C4I......................................................................................................................... 204!
26.5! DATA VISUALIZATION ............................................................................................... 205!
26.6! PEOPLE LOCATION .................................................................................................. 205!
26.7! RELATED PROJECTS ............................................................................................... 206!
27! BIBLIOGRAPHY.......................................................................................................... 207!

6 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

- ."*"/%0%*+&1200"34&

-5- 6237',%&'(&+89,&:';20%*+&

The purpose of this document is to provide the results of the assessment work carried out in
the State-of-the-Art Analysis task (T2.1) within the work package (WP2). The document de-
scribes the results of a series of investigations on the “State of the Art” approaches, stand-
ards and enabling technologies with relevance for the emergency management system archi-
tecture and services to be developed within ESS.

-5< 1200"34&

This document is an edited collection of individual reports reflecting the ESS Partners’ view
on the state-of-the-art of relevant ESS components, technologies and best practises. The
reports contained here cover their respective topic from the viewpoint of relevance and
usability within ESS with emphasis on a number of aspects:
• ESS will focus on the integration of distributed sensors and simulation models into
single systems
• Concepts for the development of event models, the ESS architecture and the imple-
mentation of soft- and hardware components need to support a flexible, ad-hoc,
quickly deployable emergency management system. Functionality of the resulting
ESS will include:
o Multimedia integration in distributed heterogeneous systems is a key objective
o Localization of people and resources in crisis areas
o Road traffic management based on cell phone data and integration with exist-
ing traffic management systems
o Interfaces between C3I systems and emergency management systems and
alert systems and cell broadcasting technologies
To ensure the subsequent work of ESS accommodates the most recent trends and is well
aligned with global standardisation efforts, this report provides a broad overview on all rel-
evant topics and lists the relevant links to sources and references, should more detailed in-
formation be required.

© ESS Consortium 2009 7


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

< =##3%>9"+9'*,&"*:&=;3'*40,&
3D Three Dimensional

8PSK 8 Phase Shift Keying

ACM Adaptive Coding and Modulation

ADP Automated Data Processing

ADSL Asymmetric Digital Subscriber Line

AOA Angle Of Arrival

AP Access Point

ARP Address Resolution Protocol

BRAN Broadband Radio Access Networks

BSC Base Station Controller

BTS Base Transceiver Station

C2 Command and Control

C4I Command, Control, Communications, Computers, and Intelligence

C4I DTF C4I Domain Task Force (of the Object Management Group)

CB Cell Broadcast

CBC Cell Broadcast Centre

CBCH Cell Broadcast Channel

CBE Cell Broadcast Entities

CBS Cell Broadcast Service

CCM Constant Code and Modulation

CDL Call Detailed Log

CEP Complex Event Processing

CMI Crisis Management Initiative

CN Core Network

COP Common Operational Picture

COTS Commercial-off-The-Shelf

CPE Customer Premises Equipment

8 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

CR Cognitive Radio

CRO Crisis Response Management Operation

CSMA/CA Carrier Sense Multiple Access with Collision Avoidance

DCM Data Base Correlation method

DHCP Dynamic Host Configuration Protocol

DHT Distributed Hash Table

DISN Defence Information Systems Network

DMR Digital Mobile Radio

DNS Domain Name System

DOCSIS Data Over Cable Service Interface Specifications

DoD (US) Department of Defense

DTH Direct-To-Home

DVB Digital Video Broadcast

DVB-H Digital Video Broadcasting - Handhelds

DVB-RCS Digital Video Broadcast - Return Channel Satellite

DVB-S2 Digital Video Broadcasting - Satellite - Second Generation

E-CID Enhanced Cell ID

EDA Event Driven Architecture

ETSI European Telecommunications Standards Institute

FAP Fair Access Policy

FEC Forward Error Correction

FTP File Transfer Protocol

FUP Fair Use Policy

G/T Gain-over-Temperature

GCCS-J Global Command and Control System – Joint

GMLC Gateway Mobile Location Center

GMSK Gaussian Minimum Shift Keying

GOTS government-off-the-shelf

GPS Global Positioning System

© ESS Consortium 2009 9


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

GSM Global System for Mobile Communications

HTTP Hypertext Transfer Protocol

I3 Integrated Imagery and Intelligence

iCOP internet COP

ICSF Integrated C4I System Framework

IDU Indoor Unit

IEEE Institute of Electrical and Electronics Engineers

IFL Intra-Facility Link

IGMP Internet Group Management Protocol

IP Internet Protocol

ITCM Information Technology and Crisis Management

ITU International Telecommunication Union

JFC Joint Force Command

JOPES Joint Operation Planning and Execution System

Ku band Kurtz-under band

LAN Local Area Network

LBA Location Based Application

LBS Location Based Systems

LBS Location Based Service/System

LCS Location System

LEO Low Earth Orbit

LMU Location Measurement Unit

LNB Low Noise Block

LNC Low Noise Converter

MAC Media Access Control

MANET mobile (multihop) ad hoc network

MIMO multiple-input and multiple-output

MNE5 Multinational Experiment 5

MO Mobile Originated

10 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

MPC Mobile Positioning Center

MS Mobile Station

MT Mobile Terminal

MT Mobile Terminated

NAT Network Address Translation

NCES Net-Centric Enterprise Services

NECC Net-Enabled Command Capability

NLOS Non-line-of-sight

NMCC National Military Command Center

NOC Network Operation Centre

NXDN Common Air Interface technical protocol for mobile communications

O&M Observations and Measurements

ODU Outdoor Unit

OFDM Orthogonal frequency division multiplexing

OMG Object Management Group

OSI Open System Interconnection

P2P Peer to Peer

P2P Peer to Peer

PAMR Public Access Mobile Radio

PC Personal Computer

PDE Position Determination Entity

PLMN Public Land Mobile Network

PMO Program Management Office

PMR Professional (or Private) Mobile Radio

PPDR public protection and disaster relief

QoS Quality of Service

QPSK Quadrature phase-shift keying (QPSK)

RAN Radio Access Network

REST Representational State Transfer

© ESS Consortium 2009 11


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

RF Radio Frequency

RPC Remote Procedure Call

RR Radio Resource

RRC Radio Resource Control

RTT Round Trip Time

RTT Round Trip Time

SAS Sensor Alert Service

SDI Spatial Data Infrastructure

SDR Software Defined Radio

SECDEF United States Secretary of Defense

SES Sensor Event Service

SIP Session Initiation Protocol

SMLC Serving Mobile Location System

SMR Specialized Mobile Radio

SMS Short Message Service

SMSCB Short Message Service Cell Broadcast

SOA Service Oriented Architecture

SOPES Shared Operational Picture Exchange Services

SORTS Status of Resources and Training System

SOS Sensor Observation Service

SPS Sensor Planning Service

ST Subscriber Terminal

TA Time Advance

TCP Transmission Control Protocol

TDMA Time Division Multiple Access

TETRA Terrestrial Trunked Radio

TIA Telecommunications Industry Association

TSO Tactical Situation Object

U-TDOA Uplink Time Difference of Arrival

12 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

UAV Unmanned Aerial Vehicle

UDP User Datagram Protocol

UE User Element

UMTS Universal Mobile Telecommunications System

URI Uniform Resource Identifier

URL Uniform Resource Locator

URN Uniform Resource Name

VCM Variable Coding and Modulation

VCM Variable Coding and Modulation

VoIP Voice over IP

WADL Web Application Description Language

WCAN Campus WMN

WLAN Local WMN

WMAN Metropolitan WMN

WMN Wireless Mesh Network

WNS Web Notification Service

WPAN Personal WMN

WS-N Web Service Notification

© ESS Consortium 2009 13


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

? !"#$%,&
Table 1: Comparison of Service Oriented and Event Driven Architecture ....................................24!
Table 2: Comparison of SAS and SES filter functionality ...............................................................34!
Table 3: Fields used in the Session Description Protocol ..............................................................74!
Table 4: TMC Information and References .......................................................................................80!
Table 5: TPEG Information and References .....................................................................................84!
Table 6: AGORA-C Information and References ..............................................................................87!
Table 7: OpenLR Information and References .................................................................................88!
Table 8: UTMC Information and References .....................................................................................90!
Table 9: NTCIP Information and References ....................................................................................93!
Table 10: DATEX Information and References .................................................................................95!
Table 11: KML Information and References .....................................................................................98!
Table 12: WMS Information and References ....................................................................................98!
Table 13: Comparison of SMSBC and SMS ....................................................................................105!
Table 14: Tooway Uplink / Downlink Frequencies .........................................................................114!
Table 15: Feature comparison ASTRA2Connect and Tooway ......................................................117!
Table 16: IEEE 1512 Information and Reference ............................................................................142!
Table 17: SHIFT Information and References .................................................................................143!
Table 18: SOPES Information and References ...............................................................................146!
Table 19: GCCS-J Information and References..............................................................................147!
Table 20: Types of movement data and related analysis tasks ....................................................152!
Table 21: Factors influencing the notion of spatial proximity ......................................................157!
Table 22: References on Forest Fire Managemenet ......................................................................185!
Table 23: ITU Article on emergency telecommunications.............................................................190!
Table 24: Details on ITU–T’s work in emergency telecommunications .......................................191!

14 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

@ A9/23%,&

Figure 1: Client scalability of publish/subscribe system ................................................................27!


Figure 2: Client and publisher scalability of publish/subscribe system........................................27!
Figure 3: Event Service without topic filtering .................................................................................29!
Figure 4: Event Service with topic filtering.......................................................................................29!
Figure 5: The Event Model according to ...........................................................................................31!
Figure 6: Web Notification Service ....................................................................................................33!
Figure 7: Sensor Web: Aggregation of Sensor Networks ...............................................................37!
Figure 8: Model of a simple form of a Sensor ..................................................................................38!
Figure 9: Model of a complex form of a Sensor ...............................................................................39!
Figure 10: Model of a Sensor System ...............................................................................................39!
Figure 11: SWE Framework ................................................................................................................40!
Figure 12: TML Transducer System ..................................................................................................42!
Figure 13: SensorML Process Types ................................................................................................43!
Figure 14: SensorML Process Model ................................................................................................44!
Figure 15: SensorML System Definition ...........................................................................................45!
Figure 16: Observation Schema Dependencies ...............................................................................46!
Figure 17: The basic observation type..............................................................................................47!
Figure 18: SweCommon Simple Types .............................................................................................48!
Figure 19: SweCommon Aggregate Types .......................................................................................48!
Figure 20: SweCommon Encodings ..................................................................................................49!
Figure 21: SweCommon Service Model Package Dependencies ...................................................50!
Figure 22: SOS GetObservation operation definition ......................................................................51!
Figure 23: SPS interaction sequence ................................................................................................53!
Figure 24: SPS Package Dependencies ............................................................................................54!
Figure 25: Demonstration of the WMS GetMap operation...............................................................57!
Figure 26: Example of the components and their connections in the spatial data infrastructure.
......................................................................................................................................................61!
Figure 27: CAP 1.1 Information Model ..............................................................................................64!
Figure 28: Distribution Element (DE) Domain Model .......................................................................65!
Figure 29: EDXL-RM operations in support of resource discovery, ordering and deployment
requirements ...............................................................................................................................66!
Figure 30: EDXL Hospital Availability Exchange (HAVE) Element Structure ................................69!
Figure 31: Exemplary SDP session description...............................................................................74!
Figure 32: KML based level of service map......................................................................................97!
Figure 33: CBS structure inside GSM (2G) network ......................................................................103!
Figure 34: CBS inside UMTS (3G) network .....................................................................................103!

© ESS Consortium 2009 15


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 35: bi-directional satellite architecture................................................................................111!


Figure 36: IDU Concept.....................................................................................................................112!
Figure 37: Infrastructure/backbone WMNs .....................................................................................126!
Figure 38: Approximate Location Accuracy in GSM networks.....................................................132!
Figure 39: General LBS Connectivity in GSM.................................................................................132!
Figure 41: Passive/massive connectivity in GSM/UMTS ...............................................................134!
Figure 42: Active/selective connectivity in GSM/UMTS.................................................................135!
Figure 43: Active/passive LBS Solution..........................................................................................136!
Figure 44: GMLC messaging flow in UMTS ....................................................................................137!
Figure 45: Cell ID ...............................................................................................................................138!
Figure 46: Enhanced Cell ID based on single RTT/TA...................................................................138!
Figure 47: Enhanced Cell ID based on 3 RTTs ...............................................................................139!
Figure 48: U-TDOA principle ............................................................................................................139!
Figure 49: A-GPS principle ...............................................................................................................140!
Figure 50: The temporal histograms show the weekly (A) and daily (B) distributions of the
stops of the personal car with the duration of 3 hours or more ..........................................153!
Figure 51: Three different routes from work to home....................................................................154!
Figure 52: The frequency histogram of the trip durations. The coloured segments correspond
to the clusters of trips shown in Figure 51 ............................................................................154!
Figure 53:The graduated circles show the mean times spent in different places along the three
selected routes .........................................................................................................................154!
Figure 54:A map with mosaic diagrams..........................................................................................156!
Figure 55: An origin-destination matrix ..........................................................................................156!
Figure 56: Summarised representation of the major clusters of trajectories from the suburbs of
Milan towards the centre on Wednesday morning. Only the moves occurring in at least 10
trajectories are visible as a result of interactive filtering .....................................................157!
Figure 57: Visual representation of possible interactions between moving entities .................159!
Figure 58: summary view of the transportation progress.............................................................164!
Figure 59: A fragment of a map view...............................................................................................164!
Figure 60: map legend ......................................................................................................................164!
Figure 61:the source-destination matrix .........................................................................................165!
Figure 62:the Gantt chart; original appearance (no filtering) .......................................................165!
Figure 63: the Gantt chart after filtering by people category and time interval ..........................165!
Figure 64: Google Earth....................................................................................................................171!
Figure 65: Microsoft Bing Maps.......................................................................................................172!
Figure 66: NASA WorldWind ............................................................................................................172!
Figure 67: Skyline Terra Explorer ....................................................................................................173!
Figure 68: ESRI - 3D Analyst ............................................................................................................174!
Figure 69: Ratman .............................................................................................................................175!
Figure 70: CS Virtual Geo .................................................................................................................176!

16 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 71: Sensor Map......................................................................................................................177!


Figure 72: Geo Grid Framework.......................................................................................................177!
Figure 73: Virtual Alabama Views....................................................................................................178!
Figure 74: Annual forest fire fatalities (CRED EM-DAT Data base) ..............................................180!

© ESS Consortium 2009 17


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

B C%*%3"$&=3;89+%;+23%&=773'";8%,&

B5- =3;89+%;+23"$&1+4$%,&DE1!F&1G=F&C39:F&6<6F&"*:&EH=&

Currently five principle architectural styles constitute the discussion base in ESS:
• REST (Representational State Transfer),
• SOA (Service Oriented Architecture),
• Grid Computing,
• P2P (Peer to Peer), and
• EDA (Event Driven Architecture).
There is also a sixth architectural approach called ROA, the Resource Oriented Architecture.
However, ROA can be seen as a specific set of guidelines of an implementation of the REST
architecture and as such is addressed under the REST headline in the context of the ESS
discussion.
The following sections discuss the different styles individually to provide an overview on the
general principles underlying each architectural approach. Whilst each approach has its own
reason for existence and its own pros and cons for application scenarios, there is no strict
necessity to make a singular choice. Depending on use case requirements, there may be
good reasons to follow different principles and eventually merge different styles to some ex-
tent.
There are various examples of ongoing discussions in exactly this direction, such as Chap-
pell and Berry, who consider the next generation of SOA being Grid-enabled (Berry &
Chappell, 2007), or research by Schaeffer et al. to fusion SOA and Grid, respectively Cloud
Computing(Baranski, Schäffer, & Redweik, 2009). Galatopoullos et al. describe the integra-
tion of P2P and SOA in order to overcome pervasive service connectivity problems
(Galatopoullos, Kalofonos, & Manolakos, 2008). Similar approaches have been described by
Loureiro et al. (Loureiro, Bublitz, Barbosa, Perkusich, Almeida, & Ferreira, 2006) Benatallah
et al.(Benatallah, Sheng, & Dumas, 2003), or Mondéjar et al. (Mondejar, Garcia, Pairot, &
Gomez, 2006). All these ongoing activities clearly show that choosing an architecture ap-
proach is nothing that has to happen in a black and white world. Hence, each major architec-
tural style will be briefly described in the following section and complemented by a set of de-
sign guidelines for ESS.

B5< DE1!F&DE1!(2$&"*:&DG=&

The Representational State Transfer (REST) was first introduced by Fielding in


2000(Fielding, 2000). It represents a software architecture style or a set of design criteria
constituted by four main principles:

18 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

• First, REST uses resources. A resource can by anything that has identity and thus
can be referenced as an entity. Clients and servers exchange resource representa-
tions as part of their interactions.
• Second, every resource can be addressed, as it is uniquely identified using a uniform
syntax, e.g. an URI and exposed to clients.
• Third, REST is a stateless client-server protocol, in which all requests carry the perti-
nent session-oriented information.
• Fourth, REST uses a set of well-defined operations, which is a clear contrast to re-
mote procedure calls (RPC), where every resource can define an arbitrary set of op-
erations.
In addition to this puristic perspective, there is an ongoing discussion on what REST really is
- and even equally important is not. This started almost immediately with its introduction nine
years ago. REST has evolved since then, but the discussion is still alive, also because Field-
ing himself keeps arguing from different points of view. In addition, Fielding originally de-
scribed REST in his dissertation more as a way of judging architectures and not so much as
an architecture itself. Meanwhile, the term RESTful came up and is now used more often
than REST itself. RESTful defines the way an architecture can be designed. The “RESTful-
ness” of an architecture or an implementation can thus be judged on the criteria set forth by
Fielding.
In the context of Web service architectures, Richardson and Ruby differentiate three com-
mon architectural approaches in the context of the Internet(Richardson & Ruby, 2007):
• RESTful resource-oriented,
• RPC-style, and
• REST-RPC hybrid.
The first and second types are of high relevance to ESS, as they define two rather contrary
architectural styles. The latter, REST-RPC hybrid, is literally a mixture between the first two
and often used for RPC-style applications that have only been transferred to be RESTful half
way. This does not necessarily disqualify the style for ESS, but in order to build a unambigu-
ously defined architecture, its usage shall be considered very carefully.
Based on REST design principles, Richardson and Ruby design a concrete RESTful archi-
tecture called Resource Oriented Architecture (ROA) that implements RESTful Web ser-
vices. ROA has a number of overlaps with SOA, the Service Oriented Architecture, but treats
resources in a RESTful sense. Even though the focus of ROA is on resources, i.e. on infor-
mation rather than behaviour, ROA still supports the invocation of behaviour working on iden-
tified resources.
RESTful Web services can be described using WADL, the Web Application Description Lan-
guage. WADL is principally a XML grammar and vocabulary to describe RESTful Web Ser-
vices. Due to the often much more simplistic interfaces exposed by RESTful Web Services
(in contrast to Web services using SOAP), the usage of WADL is often unnecessary.

© ESS Consortium 2009 19


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

B5? 1G=&

There a number of different, and partly even contradicting, definitions of what a Service Ori-
ented Architecture (SOA) is. Instead of discussing the similarities and differences of those
definitions, ESS adopts the definition given by Srinivasan (Srinivasan & Treadwell, 2005):
“The term service-oriented architecture refers to a style of building reliable distributed sys-
tems that deliver functionality as services, with the additional emphasis on loose coupling
between interacting services.”
Though being usually implemented using Web Service technology in the context of the Inter-
net, SOA is not bound to any specific service technology. In fact, SOA and Web Services are
not mutually dependent. In the context of the Internet, SOAP, XML or key-value pairs over
HTTP POST and GET is used for client server communication. Services often described
using WSDL, Web Service Description Language, which principally allows dynamic binding
of arbitrary services at runtime.
An implementation of SOA usually follows a number of design principles and relies, in addi-
tion to the services as such, on a number of additional facilities (Vinoski, 2007),(Srinivasan &
Treadwell, 2005). As SOA implements the publish-find-bind pattern, service providers publish
their service capabilities and location at a registry that allows clients to discover and bind the
service at runtime. In addition, SOA requires service definition languages, which developers
use to define service contracts; and service platforms, which provide design-time and run-
time support for service creation, deployment, and execution. Services advertise details such
as their capabilities, interfaces, policies, and supported communications protocols. Imple-
mentation details such as programming language and hosting platform are not revealed.
SOA features loose coupling, which implies that communicating components minimize their
knowledge of each other. Required information for communication is discovered at runtime.
The benefits of this approach are:
• improved flexibility, as a service can be relocated easily as long as the registry gets
updated,
• better scalability, as services can be added or removed on demand,
• replaceability, as an underlying implementation can change as long as the service
interface is maintained, and
• higher fault tolerance, as clients can discover alternative services if a previously used
service becomes unavailable
One of the design principles of REST, the statelessness, is also an important feature of the
loose coupling implemented in SOA. When a state has to be preserved in a SOA implemen-
tation, this can be done at server or client side.

B5@ H%,9/*&C29:%$9*%,&('3&E11&

There are a number of design principles that can be derived from the recent ROA/SOA dis-
cussion that apply to scenarios relevant for ESS. Interestingly enough, some of those guide-
lines are rather independent of the applied architecture design:

20 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

• Loose coupling is desirable. This is particular true if independent parts of a system


evolve at the different rates. Loose coupling is supported by ROA and SOA either
way.
• Uniform interface constraints allow applications to be adapted to solution require-
ments more efficiently. In contrast to SOA-based services, where clients and services
always have two agreements or contracts, one for the interface and one for the data,
do ROA-based services only feature data contracts. This advantage becomes more
important with the number of clients developed for a specific service type. First, if cli-
ents don’t have build in knowledge about a specific interface, there is substantially
less coding required, and second, evolving the interface to adapt to new application
requirements becomes very expensive.
• Data formats shall be self-describing. Standards shall be developed and agreed upon
as a baseline for representation formats. In addition, the representation format shall
be specified within the message as such if possible.
• Unique identifiers facilitate usage of resources across networks or institutional boun-
daries. ROA features the design principle of unique addressability, whereas SOA de-
velopers are often free to choose service naming and identification.

B5B C39:&)'072+9*/&

“Grid computing is a form of distributed computing in which the use of disparate resources
such as compute nodes, storage, applications and data, often spread across different phys-
ical locations and administrative domains, is optimized through virtualization and collective
management.” (Srinivasan & Treadwell, 2005).
Grid Computing was massively supported in the 6th European Framework Programme, with
a total of over 250 Million Euros invested in research and infrastructure set up. Still, Grid
Computing has not become fully applicable in many domains. According to the Gartner
Group (http://www.gartner.com),
Grid Computing is “another technology [to watch]. [...] Grid computing is widely used in tradi-
tional ways, such as design and other research. But [...] the most interesting applications are
yet to come. Grid computing uses a mesh of computers to perform complex tasks, but is not
fully understood by all its potential users.”
Gartner Group’s viewpoint is also reflected in the ongoing deviation between academic and
industrial requirements and developments in Grid Computing. Scientists concentrate on col-
laboration and open flow of information, whereas industry has to work on environments that
are competitive and support security and business requirements as much as
possible(Altmann, Buyya, & Rana, 2009), (Kao, 2008), (Knights, 2007).
Keeping the aforementioned problems in mind, three different types of Grids can be distin-
guished:
• First, Grids based on clusters using homogenous components
• Second, Grids using heterogeneous components but remaining within close adminis-
trative boundaries

© ESS Consortium 2009 21


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

• Third, Enterprise Grids focussing on the integration of various Grid solutions applied
in a single enterprise.
As soon as the enterprise is no longer the last boundary, other aspects become highly rel-
evant, such as security, and accounting models (Foster, Kesselman, & Tuecke, 2001). From
an ESS viewpoint, it is questionable if pure Grid approaches will be applicable. In particular
as the power of the Grid lies on dynamic allocation of processing and storage capacities; two
aspects that probably play a minor role in emergency event management.
The Open Grid Service Architecture (OGSA) is one of the most widely used architectural
designs for Grid architectures. Initially published in 2003 by Foster et al. (Foster, Kesselman,
Nick, & Tuecke, 2003), it is now an official release of the Open Grid Forum (GGF,
http://www.gridforum.org). OGSA uses a multi-tier approach with an application tier on top
and the integrated resources at the bottom. The two Grid core tiers are represented (and
properly speaking implemented) by OGSA Platform Services and Open Grid Services Infra-
structure (OGSI). The former offers basic Grid services, such as authentication, access inter-
faces, registry services etc. The latter connects the different services with the resources of
the Grid. Thus, all resources can be addressed using Platform Services (often using Web
Services). Free or Open Source software implementations, such as e.g. Globus
(http://www.globus.org,(Foster, 2006)) foster an easy testing of Grid technologies in ESS
research and development.

B5I 6<6&

P2P networks support one very important feature of relevance in scenarios addressed in
ESS: they are immune against single-point-of-failure problems. Using peer to peer instead of
client-server communication changes the communication pattern from hierarchical to sym-
metrical. Other advantages of P2P networks are self-organization or dynamic adaptation to
changing topologies. On the downside, existing P2P networks are known for effects such as
unreliability, quality of service inconsistencies, trust and security problems.
Different flavours of P2P networks have been developed in the past. Simplest (and non-pure
P2P) architectures, such as Napster, still contain centralized databases storing data identifi-
ers and peer locations. Pure P2P approaches do without a centralized server. Instead, each
peer tries to connect to a known list of standard peers in a first bootstrapping step to connect
to the network. Once connected, diverse flooding mechanisms are used in order to learn
about other peers. Technologies such as unique identifiers, time to live numbers, super
peers and neighbourhood communication constraints help to avoid unnecessary network
traffic. Data is queried using dedicated query messages. IP address aggregations help to
optimize the data delivery on shortest paths. More advanced approaches use distributed
hash tables (DHT) that calculate node identifiers based on the IP address of each peer using
hash functions. The combination of distributed hash tables with finger tables allows efficient
search mechanisms with a runtime of O(log N). The system becomes more fault tolerant
against disappeared peers if additional protocols, such as stabilization protocols periodically
test and maintain the finger tables. The available bandwidth of a network is shared among all
peers. Split stream protocols help to optimize the download of big files. Those protocols split
the big file into smaller chunks. Tracker hosts coordinate the download process. Initially, all
segments are available at the seeder peer. Every peer that downloads the segments informs

22 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

other peers about the availability of the segment that it just downloaded using the host
tracker und continuous downloading segments from the seeder or other peers that already
have copies of the missing segments. The system takes the burden from the seeder to pro-
vide the entire big file at once and optimizes the download speed by using P2P networks
between the interested peers, the tracker, and the seeder.
Some typical known issues of existing P2P networks would most likely not apply to a poten-
tial ESS. In ESS, the peers probably do not show asymmetric upload and download speeds,
as it is common in Internet file sharing applications. Firewall and NAT traversals may be less
problematic if existing at all, because the ESS would use a dedicated P2P network in IP
overlay mode that needs to get shared within single organization only (cross-institutional
communication can get realized independently). On the other side, split stream protocols
have been tested shown their scalability and usability for Internet telephony and video trans-
mission, two aspects that are of high relevance to ESS as well.
ESS main interest in P2P technologies certainly deviates from the typical P2P applications,
such as file sharing in the Internet among thousands or millions of participants. P2P networks
provide a number of advantages that should be considered for adoption in the ESS architec-
ture.
There are a number of P2P systems available that could be used for testing purposes.
Among them is Sun Microsystems’ JXTA (CITE) one of the most interesting for ESS, as it is
now an Open Source project and thus qualifies for research and testing in ESS.

B5J EH=&"*:&)E6&

In contrast to Service Oriented Architectures, which work best if a workflow can be defined
upfront and doesn't change continuously, the Event Driven Architecture (EDA) takes into
account that many processes are in fact event driven. In 2003, the information technology
research and advisory company Gartner has analyzed that "the real world is mostly event
driven" and predicted that Event Driven Architectures will become more important in the near
future (Schulte, 2003).In combination with Complex Event Processing (CEP) systems, Gart-
ner talks of EDA CEP as SOA 2.0 or Advanced SOA (Computerwoche, 2006).
For ESS, EDA supports a very important feature that becomes relevant if heterogeneous
systems need to be integrated at runtime: EDA is particular useful if components supposed
to interact with each other do not share a joint technical basis (Keller, 2003) that allows ser-
vice calls. We will investigate event based systems with emphasize on spatial aspects further
below.

© ESS Consortium 2009 23


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

I E>%*+&H39>%*&17"+9"$&H"+"&K*(3",+32;+23%&

I5- K*+3':2;+9'*&

For almost a decade, Spatial Data Infrastructures (SDI) have been developed and deployed
throughout the world to facilitate standardized and interoperable exchange of geographic
information in and across organizations. So far, SDIs have been realized according to archi-
tectural principles of Service Oriented Architectures (SOA), though recently the adaptation of
Resource Oriented Architecture (ROA) principles sparked increasing interest in the geo-
graphical domain as well. Another architectural style, Event Driven Architectures (EDA), also
gained uptake – though primarily in enterprise systems in the financial domain. Chapter 5
describes these different styles of system architecture design in more detail.
Comparing SOA and EDA reveals that the two approaches are quite different (see 5.1).
Characteristic Traditional SOA EDA
Interaction Loosely Coupled Strongly Decoupled
Interaction Flow Control Synchronous Asynchronous
Communication Initiator Client Service
Main Messaging Patterns Request-Response Publish/Subscribe
Process Communication Models 1:1 1:1, 1:n, n:m
Primary Technical Goal Service Component Rapid Sense / Re-
Reuse sponse
Table 1: Comparison of Service Oriented and Event Driven Architecture

While traditional SOA is about the reuse of service components, EDA focuses on highly reac-
tive (business) processes and rapid sense and respond functionality – a feature that is of
high interest for ESS. However, the boundaries between the two design styles are fluent. For
example, many data infrastructures that are in place today, like SDIs, use both synchronous
and asynchronous request-response.
In this chapter we will concentrate on how traditional SDIs, following SOA design principles,
can be enhanced to leverage the advantages that EDA offers. Ultimately, the combination of
the two approaches will lead to the development of Event Driven Spatial Data Infrastructures
(ED-SDI).
In the following, we will first provide an overview of technologies that are relevant for realizing
an ED-SDI. Before concluding the chapter, we will provide an overview of specifications that
support EDA functionality.

I5< D%$"+%:&!%;8*'$'/9%,&

The Publish/Subscribe messaging pattern is a fundamental mechanism for enabling an


EDA/ED-SDI (Everding & Echterhoff, Event Processing in Sensor Webs, 2009). It allows cli-
ents to subscribe at a web service for automatically being notified when an event that is of

24 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

interest to the client is detected by that service. The pattern allows integration of various sub-
scription models (e.g. channel, type, filter or group based subscriptions) and introduces de-
coupling of the client and the entity that generates events in space, time and in program flow
(Faison, 2006).Various technologies exist to enable the publish/subscribe paradigm in a SOA
and ROA.

I5<5- D%"$9L9*/&62#$9,8&M&12#,;39#%&9*&DG=&

In a resource oriented system approach, web feed technology is used to realize functionality
that mimics the publish/subscribe pattern. The technology is based upon data formats like
Atom and protocols like AtomPub (Gregorio, 2007) that enable feed reader software to re-
trieve frequently updated information in a pull-based manner. The Atom model offers exten-
sion points in which additional content not foreseen by format designers can be added – like
GeoRSS for encoding location information (Reed, 2006).
One of the objectives of web feed technology is to enable clients to quickly grasp new infor-
mation from multiple sources without being forced to screen these sources themselves.
Feeds and feed readers usually provide only an abstract of the full news provided by a
source – thus clients can decide whether to retrieve the full news from the source or not.
A drawback of web feed technology is that it does not enable the notification of clients regis-
tered to a feed as soon as possible. Clients always need to access the feeds to get the most
recent information, which is undesirable when new information is published in varying inter-
vals. Work to overcome this problem has already started ((Saint-Andre, Hildebrand, &
Wyman, 2008), (Fitzpatrick, Slatkin, & Atkins, 2009)), though a final solution has not been
achieved yet.

I5<5< D%"$9L9*/&62#$9,8&M&12#,;39#%&9*&1G=&

In the area of Service Oriented Architecture standards developments, two organizations are
developing specifications with significant impact on web service development: OASIS (Orga-
nization for the Advancement of Structured Information Standards) and the World Wide Web
Consortium (W3C).
Two standards exist in the SOA world that both realize publish / subscribe though with differ-
ent level of functionality. WS-Eventing (Box, et al., 2006)realizes basic public subscribe func-
tionality and is now on its way to become final standards status at W3C. It is lacking topic
based filtering and broker functionality – features that WS-Notification, on the other hand,
provides (Graham, Hull, & Murray, 2006),(Chappell & Liu, 2006),(Vambenepe, Graham, &
Niblett, 2006).
Reliable and secure communication in a publish / subscribe scenario can be achieved when
including WS-ReliableMessaging (Davis, Karmarkar, Pilz, Winkler, & Yalcinalp, 2009)and
WS-Security1 into the system. This is doable in both WS-Eventing and WS-Notification.

1
Which in version 1.1 is in fact a large set of specifications, see http://www.oasis-
open.org/specs/index.php#wssv1.1

© ESS Consortium 2009 25


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

However, when scalability is concerned the situation is different. Here, having a well-defined
notification broker interface enables scaling of publish / subscribe services.

26 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

This is especially true when scalability with respect to consumers / clients is concerned. In
this case, load balancing can be performed at the broker provider site – see Figure 1.

Figure 1: Client scalability of publish/subscribe system

through load-balancing of broker services

The publish/subscribe service can dynamically add new broker instances inside of its system
that get all events from the broker that gets published data. These internal brokers can be
added or removed depending upon the number of currently subscribed consumers. Such
load balancing can certainly also be achieved if no standards based broker functionality was
in place. However, in that case the implementation of the broker service cannot be easily
changed which would result in vendor-lock-in.
Scaling a publish/subscribe system if the number of publishers increases is more difficult. In
this case, broker functionality only helps to a certain extent – see Figure 2.

Figure 2: Client and publisher scalability of publish/subscribe system

requires intelligent connection algorithm

© ESS Consortium 2009 27


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

The problem is that the publishers generate much more information than a single service can
handle. Therefore, notifications coming from publishers need to be distributed across distinct
brokers.
Clients will not want to subscribe to all of these brokers. Some subscriptions might require
that information generated from publishers connected to different brokers need to be aggre-
gated in one service. If the client cannot or does not want to accomplish this itself then the
system needs to provide that functionality. To handle this situation, an intelligent algorithm to
connect publisher-brokers to client-brokers is required. This could be an approach similar to
that of DNS where brokers are responsible for publishers in geographic regions. A broker
hierarchy would be established where a higher-level broker would aggregate information
from lower-level brokers. Clients or „Client-brokers“ can then connect to according brokers
on demand.
The combination of publish/subscribe systems with peer-to-peer technology (see chapter 5.6
- P2P) could also result in a solution to the publisher/client scalability issues identified in this
chapter.
Performance is another aspect that needs to be taken into account when filtering of notifica-
tions has to be performed for a subscription. Here, topic based filtering can significantly in-
crease the performance of an event service. The events generated by such a service can
often be categorized. For example, an event containing information about a fire outbreak
could be tagged with “alert for fire department GT-318”, “fire” or simply “news” while an event
containing a flood warning could be tagged with “alert for fire department GT-318”, “flood”,
“flood warning” or “news”. These categories represent notification topics. They function like
tags that have been assigned by the entity that created the event. All clients that are inter-
ested in notifications with certain tags can use topic based filtering to be notified only if those
events are generated by an event service. Without such a mechanism, clients could only
subset the event cloud generated by the event service via content based filters (see Figure
3). Executing content based filters is consuming a lot of the event service’s computing per-
formance, as each event needs to be parsed and the content filter of a subscription executed
against that event. The more subscriptions using content filters exist in a service, the longer it
takes the service to act upon a new event. This is true even if the service implementation
performs intelligent algorithms to detect that the filter criteria of two subscriptions target the
same set of events.

28 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 3: Event Service without topic filtering

subsetting of events only via content based filters

If topic based filtering is supported by an event service, the performance of event matching
can significantly improve (see Figure 4):

Figure 4: Event Service with topic filtering

subsetting of events by topic(s) and optional content based filters

Though a subscription may still have a content based filter, in this case it identifies a set of
topics from which it wants to receive events from. The event service can now assign sub-
scriptions to topics. Whenever a new event is detected, it is assigned to a certain number of
topics and then automatically sent to all subscriptions “listening” on these topics – optionally
also invoking a content based filter if declared for the subscription. This mechanism gains
increased performance when the amount of subscriptions is considerably greater than the
number of notification topics.

© ESS Consortium 2009 29


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

I5? =>"9$"#$%&17%;9(9;"+9'*,&

Some work that drives the establishment of ED-SDI has already been performed. Information
and service models have been created by standardization bodies like the Open Geospatial
Consortium (OGC) to support the functionality required to make SDIs event-driven. In this
chapter we provide an overview of the Event Model and the Event Pattern Markup Language
(EML). We also discuss the Web Notification Service (WNS) as well as Sensor Alert Service
(SAS) and Sensor Event Service (SES).

I5?5- E>%*+&.':%$&

Various definitions of what an “event” and what it is not exist today. This is due to the fact
that the notion of the term “event” can be different across application domains. The OGC did
a survey of various definitions to come up with a definition that identifies the core of what
really constitutes an event, is compatible with the OGC baseline, i.e. the OGC Reference
Model (OGC RM) and Abstract Specification (OGC AS) and is consistent with ISO TC 211
nomenclature. The definition is as follows (Everding & Echterhoff, OGC OWS-6 SWE Event
Architecture Engineering Report, 2009):
“An event is anything that happens or is contemplated as happening at an instant or over
an interval of time.”
This definition is quite simple and emphasizes the temporal aspect of an event. It also says
that both a happening in the real world like a car accident and happenings in software (or
otherwise contemplated) like the simulation of a chemical spill dispersion are events.
The notion of what an event is has been further elaborated with respect to the General Fea-
ture Model (GFM) defined in ISO 19103. This led to the creation of the Event Model, a GML
Application Schema according to ISO 19136 – see Error! Reference source not found.:

30 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 5: The Event Model according to

(Everding & Echterhoff, OGC OWS-6 SWE Event Architecture Engineering Report, 2009)

This model provides the foundation for the creation of specialized event types. Those spe-
cializations can be used in a given application domain but would in the best case be applic-
able across application domains.

I5?5< E>%*+&6"++%3*&."3N27&O"*/2"/%&

The handling of events is nothing new in IT industry; the initiation of actions upon an event
from a Graphical User Interface (GUI), like the push of a button, being a prominent example.
Events provide actionable information and programs that are able to recognize events can
respond immediately, rather than frequently looking for new events. The decoupling of soft-
ware components introduced through event processing is another valuable aspect (Everding
& Echterhoff, 2009).
Pushing a button and reacting to this event is an example of simple event processing. Event
Processing in general also includes the techniques of Event Stream Processing (ESP) and
Complex Event Processing (CEP). ESP is concerned with processing of an event stream
(Luckham, What’s the Difference Between ESP and CEP?, 2006) while CEP is about pro-
cessing of an event cloud (Luckham, The Power of Events: An Introduction to Complex
Event Processing in Distributed Enterprise Systems, 2002), (Luckham, A Brief Overview of
the Concepts of CEP, 2008)). An event cloud thereby is an aggregation of event streams and
thus ESP can be considered as a subset of CEP. In the following, we will subsume simple
event processing, ESP and CEP under the term Event Processing. Event detection, pattern

© ESS Consortium 2009 31


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

matching, using the relationships between events, creating and evaluating the causality vec-
tor of a complex event, deriving new information from detected events and building event
hierarchies are all aspects of Event Processing.
To describe Event Processing functionality with a simple example, let us assume we have a
validated fire warning event that is triggered through the evaluation of event streams gener-
ated by smoke detectors and temperature sensors inside a building. Smoke itself is only an
indicator of a fire – it can also be triggered by a smoking cigarette. Having a high room tem-
perature also does not necessarily mean that a fire is detected. The high temperature can for
example be caused by high solar radiation which leads to an increasing room temperature –
in some spots this can even reach critical levels. When observing the two phenomena to-
gether and looking for patterns in the event streams generated by sensors located in the
same area (e.g. room or floor), a better fire detection can be achieved (Jirka, Hahn, &
Echterhoff, 2008). A fire detection event will then result from a pattern match of two single
sensor measurements – one from the smoke sensor and one from the temperature sensor.
These baseline measurements can be included in the causal vector of the resulting event,
allowing the validation of event processing systems and tracing the base events that led to
the creation of higher-level events.
So far Event Processing has primarily been applied in enterprise business systems, for ex-
ample in the financial sector, which makes these systems event-driven. Applications of Event
Processing in the geospatial domain are emerging (Francica, 2009)(Everding & Echterhoff,
Event Processing in Sensor Webs, 2009). So far, uptake is hindered by the fact that no stan-
dard event pattern language (EPL) exists for Event Processing – unlike relational databases
where the Structured Query Language exists, with well-defined geospatial extensions
(Herring, 2006). A first attempt towards a common EPL is the Event Pattern Markup Lan-
guage (EML) (Everding & Echterhoff, Event Pattern Markup Language, 2008). This pattern
language is designed to provide basic event pattern matching functionality. It is encoded
using XML so that it can be applied in web services. As such, it can be used to integrate
Event Processing functionality in services of an SDI and therefore represents one building
block of an ED-SDI.

I5?5? P%#&Q'+9(9;"+9'*&1%3>9;%&

Whenever a client communicates with a web service, the HTTP timeout needs to be con-
sidered. This is especially true if generating the server response is a time-consuming task
that might exceed the timeout. If no countermeasures are taken the communication can fail
due to a timeout. In a SOA, the use of WS-Addressing (Gudgin, Hadley, & Rogers, 2006)
serves to overcome this issue, the idea being that the response is sent asynchronously to the
recipient – so regardless on which timeout the request message encounters the response
will be sent on a different connection. In ROA, the situation can be handled via repeated poll-
ing until the response can finally be retrieved as a resource. The Web Notification Service
(WNS) was designed to solve this problem as well (Simonis & Echterhoff, Draft OpenGIS
Web Notification Service Implementation Specification, 2006), in systems that did not use
SOAP and when ROA was not considered as an alternative to system design. The intent was
that a client would include WNS credentials in a request sent to a web service and if the ser-
vice could not generate the response in the timeout bounds then it should send it via the
WNS to the client.

32 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

The WNS can send a message not only via HTTP but over a number of transport protocols.
This is the real strength of the service. Whenever a client needs to receive notifications from
a web service or other entity, it can employ the WNS as a form of message middleware that
ensures that the message is delivered to the communication endpoints registered by the cli-
ent. Such endpoint can be an email address, for example – or an SMS number, among oth-
ers (see Figure 6).!

!
Figure 6: Web Notification Service

sending a message to recipient(s) via various protocols&

The client can thus ensure that important messages – like fire detection events – are sent to
him but even to other important recipients even if the client (e.g. human operator) is not on-
line. This is called the last-mile-mode.
The WNS not only has operations for delivering messages – it also offers operations for
managing registrations and has basic support for message caching.

I5?5@ 1%*,'3&=$%3+&M&E>%*+&1%3>9;%&

The Sensor Alert Service (SAS) is a service by which a client can subscribe for notification of
specific sensor events. This approach is different to the pull based approach of the Sensor
Observation Service (see chapter 7.1.4.6 - Sensor Observation Service). Two ways of deliv-
ering notifications to a client are supported: the default communication protocol is XMPP but
notifications can also be sent via WNS.
The service interface supports publish/subscribe, though in a proprietary manner. It does not
reuse existing web service standards like WS-Notification or WS-Eventing. In addition, it
supports only a limited set of filter functionality (see Table 2: Comparison of SAS and SES
filter functionality). However, it was the first attempt to include unit conversion in the filtering
process. This is necessary due to the heterogeneity of units used by sensors for their phe-
nomenon measurements. A service that recognizes measurement units and is able to con-
vert them on the fly to base units can meaningfully compare incoming temperature meas-
urements, for example, regardless if they are provided in Kelvin, degrees Celsius or Fahren-

© ESS Consortium 2009 33


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

heit. Unit conversion is supported by SAS only to a certain extent because the functionality is
underspecified. The SAS also has a proprietary way of acknowledging message transmis-
sions (reliable messaging).
The Sensor Event Service (SES) is the successor of SAS. It moves away from defining pro-
prietary interfaces by leveraging WS-Notification functionality. However, it still defines some
specifics that make the extension of existing WS-Notification implementations necessary to
make them compliant with the SES interface. The SES drops the acknowledging mechanism
completely, rather relying upon WS-ReliableMessaging (Davis, Karmarkar, Pilz, Winkler, &
Yalcinalp, 2009) to provide this functionality.
The filtering functionality of SES is considerably improved with respect to that of SAS – see
Table 2:

Table 2: Comparison of SAS and SES filter functionality

Leveraging the functionality provided by the OGC Filter Encoding Specification (Vretanos,
2005) the SES is able to support spatial, temporal, comparison and logical filter operators. In
addition, it can provide Event Processing functionality through EML filter statements. The unit
conversion functionality is specified in more detail. Finally, SES supports topic based filtering
as defined by WS-Notification.

I5@ )'*;$2,9'*,&

In emergency management, timely information is essential for well-informed decision making.


Many information sources that are already or can be deployed in a field of crisis provide data
on various phenomena in near real-time. Today’s IT transport protocols are able to deliver
data coming from these sources almost immediately. Therefore, it is up to the emergency
system whether the data is computed as soon as it becomes available or not.
The ESS system will need to be able to handle real-time event streams. As such, it cannot
rely on pure pull-based communication patterns. It has to support push-based communica-
tion as well. As described in this chapter, the publish / subscribe messaging pattern is one of

34 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

the core enabling technologies for EDAs. ESS should therefore implement this pattern where
required.
The System Architecture will need to define where and how the pattern is to be integrated.
As we have seen, publish / subscribe can be implemented on the service level. This can be
achieved in a SOA and / or ROA based manner. The simplicity of a ROA based system de-
sign thereby is in contrast to the amount of functionality offered by a SOA based design. ESS
has the opportunity to make a valuable contribution to the current standardization efforts in
creating a specification that takes both approaches into account. This specification – called
Event Service from now on – needs to support well-defined publish/subscribe functionality
and service policies that can be realized according to both ROA and SOA principles. The
Event Service should leverage available standards where applicable to maximize interopera-
bility with already existing publish / subscribe systems. This work should take existing stand-
ards and approaches into account, like the ones described in this chapter (SAS, SES, WS-
Notification, WS-Eventing etc). Publish / subscribe on the client side requires the implemen-
tation to act on incoming data transmissions as soon as possible. The implementation goals
thereby dictate which information can be discarded (i.e., is not relevant for the task at hand),
can wait to be processed at a later stage or needs immediate attention, likely involving the
decision from an ESS operator.
This leads to the inclusion of Event Processing functionality in ESS. As explained in this
chapter, Event Processing techniques like ESP and CEP can help the decision making pro-
cess tremendously, in filtering out irrelevant information from event streams, in detecting
event patterns that are of interest to the system and in generating higher-level information
that itself can be aggregated to finally present enriched data to the ESS operator. The inte-
gration of Event Processing functionality in the geospatial domain is not completed yet. This
is especially true for the integration into SDIs via a common markup language. ESS has the
opportunity to integrate and evaluate Event Processing functionality in WP5 Data fusion me-
diation system development – to make a valuable contribution to the development of Event
Processing capabilities in the geospatial domain.
When talking about Event Processing and the application of the publish / subscribe com-
munication pattern, the definition and design of the event itself is very important. Some suc-
cess in this direction has recently been made by the OGC through the creation of a draft ap-
plication schema for events. By taking up the existing work and continuing it, ESS again can
make considerable contributions to the standardization process and the uptake of Event Pro-
cessing in distributed computing platforms. For example, ESS could investigate common
event types (like cancellation events) and event handling mechanisms (like superseding /
replacing a previous event with an updated version) that are of interest and value to multiple
application domains.
The Web Notification Service defines an interface that is of interest for the ESS Alert System.
Though the asynchronous notification delivery is not as important as other techniques exist
that provide this functionality, the protocol transformation is quite interesting. Having a web
service to notify a certain set of end users for example via SMS but also via other protocols
(depending upon current availability) in case of crisis is critical for the ESS system. Again,
ESS can make a valuable contribution to international standardisation efforts by improving
the WNS specification, for example by designing the Alert System as a potential successor of
WNS.

© ESS Consortium 2009 35


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

The technologies described in this chapter all play a role for the development of capabilities
required for an Event Driven Spatial Data Infrastructure. In the near future, more and more
live data streams will become available that create a flood of information which needs to be
processed to result in actionable information. In this chapter we presented several building
block of an ED-SDI which all need improvement to fully enable Event Processing in the
geospatial domain in general and emergency systems in particular.

36 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

J GC)&1%*,'3&P%#&E*"#$%0%*+&

J5-5- K*+3':2;+9'*&

Sensor Web Enablement (SWE) is an Open Geospatial Consortium (OGC) initiative that ex-
tends the OGC Web services framework by providing additional models, services and encod-
ings for integrating web-connected sensors and sensor systems. Starting in 2001, the Sensor
Web Enablement Group developed a set of standards to support discovery of sensors and
sensor capabilities, Web-based access to sensor data, and tasking of sensors to control the
observation process.
The overall goal is to integrate sensors into infrastructures of interoperable systems. This
requires that sensors as well as the surrounding operating systems get façaded by a set of
services that follow a unique terminology, syntax, semantic, and use standardized encodings
and communication mechanisms. Thus, OGC SWE is implemented as a middleware layer
between the physical assets or control systems respectively, and the user that interacts with
those systems. According to Simonis (Simonis, OGC Sensor Web Enablement Architecture,
2008) the meta-platform Sensor Web integrates arbitrary sensors and sensor networks to
reflect the current real world situation, where sensors and sensor networks are operated by a
myriad of different organizations or even individuals. The power of the Sensor Web is the fact
that it allows the integration of complete sensor systems without the need of fundamental
changes to the legacy systems.

Figure 7: Sensor Web: Aggregation of Sensor Networks

(Simonis, OGC Sensor Web Enablement Architecture, 2008)

To facilitate the integration of both, individual sensors as well as sensor systems, the OGC
SWE uses a flexible sensor model. The model, developed by the R&D project SANY2, uses
the ISO RM-ODP approach to define the functionalities from different viewpoints. (RM-ODP =
Reference Model of Open Distributed Processing, (ISO/IEC, Information technology -- Open
Distributed Processing -- Reference Model: Architecture. ISO/IEC 10746-3, 1996), (ISO/IEC,
Information technology -- Open Distributed Processing -- Reference model: Foundations.

2
SANY (Sensors Anywhere, 2006-2009) is an Integrated Project (contract number 0033564)
co-funded in the sixth framework program by the Information Society and Media DG of the
European Commission within the RTD activities of the Thematic Priority Information Society
Technologies”

© ESS Consortium 2009 37


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

ISO/IEC 10746-2, 1996), (ISO/IEC, Information technology -- Open Distributed Processing --


Reference model: Overview. ISO/IEC 10746-1, 1998). The RM-ODP design concept is of
general importance to SWE and the development of architectures, so it will be introduced in
more detail in the following sections.

J5-5< GC)&1PE&1%*,'3&.':%$&

On the technology viewpoint, the model itself distinguishes three different forms of sensors:
Simple sensors, complex sensors, and sensor systems, as illustrated in the three figures
below. This fundamental design allows a uniform interface to communicate with either form
by abstracting from the concrete details of each form.

Figure 8: Model of a simple form of a Sensor

(Simonis, OGC Sensor Web Enablement Architecture, 2008)

The simple sensor observes a property of the environment and converts the raw reading into
a machine-processable signal. The may be some sensor management interfaces available.

38 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 9: Model of a complex form of a Sensor

(Simonis, OGC Sensor Web Enablement Architecture, 2008)

The complex form uses an array of sensors. The raw readings of the sensors get aggre-
gated, converted, or fusioned and are provided at a single interface in a machine-
processable form.

Figure 10: Model of a Sensor System

(Simonis, OGC Sensor Web Enablement Architecture, 2008)

The sensor system aggregates any number of simple or complex sensors and provides the
observation data for each sensor in an aggregated form.

© ESS Consortium 2009 39


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

In general, the SWE Sensor Model approach allows integrating any form of sensor. In addi-
tion, it supports even non-physical sensors, such as simulation models or statistical ana-
lyses.
On the engineering viewpoint, the OGC Sensor Model describes different mechanisms to
connect a sensor or a sensor network to the communication network.
The computational viewpoint further investigates the implementation of sensors. It distin-
guishes two perspectives, called the internal and the external perspective. The two perspec-
tives help to satisfy the looking angles of software engineers as well as hardware-oriented
people. It allows representing a sensor either as a black box, i.e. even a complex orchestra-
tion of simple and complex sensors and optionally sensor networks appears as a single,
simple sensor; or as a white box, where every sensing and processing step is exactly de-
scribed and transparent.
The SWE Sensor Model defines its applicability for non-physical sensors as part of the in-
formation viewpoint. Here, the options already laid out in the technology viewpoint are de-
scribed in a more sounded fashion.
There is no description for the enterprise viewpoint available.

J5-5? 1PE&E*+%3739,%&6%3,7%;+9>%&

The Sensor Web Enablement framework serves a fundamental role in and across enterprise
applications. It provides the middleware to integrate heterogeneous sensors with models and
simulations and decision support, fusion, and analysis tools.

Figure 11: SWE Framework

(Simonis, OGC Sensor Web Enablement Architecture, 2008)

40 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

The SWE middleware has to fulfil a number of requirements that have been collected across
several domains and communities, including those from in-situ and remote sensing:
• Quickly discover sensors and sensor data (secure or public) that can meet my
needs – location, observables, quality, and ability to task
• Obtain sensor information in a standard encoding that is understandable by hu-
mans and software
• Readily access sensor observations in a common manner, and in a form specific
to my needs
• Task sensors, when possible, to meet my specific needs
• Subscribe to and receive alerts when a sensor measures a particular phenom-
enon
Those requirements have been converted into a set of vision statements that in consequence
have to be addressed by a portfolio of information models, service specifications, and encod-
ing rules and specifications. Overall, OGC SWE formulates the following vision statements:
• Sensors will be web accessible
• Sensors and sensor data will be discoverable
• Sensors will be self-describing to humans and software (using a standard encoding)
• Most sensor observations will be easily accessible in real time over the web
• Standardized web services will exist for accessing sensor information and sensor ob-
servations
• Sensor systems will be capable of real-time mining of observations to find phenom-
ena of immediate interest
• Sensor systems will be capable of issuing alerts based on observations, as well as be
able to respond to alerts issued by other sensors
• Software will be capable of on-demand geolocation and processing of observations
from a newly discovered sensor without a priori knowledge of that sensor system
• Sensors, simulations, and models will be capable of being configured and tasked
through standard, common web interfaces
• Sensors and sensor nets will be able to act on their own (i.e. be autonomous)
In the following, we will investigate the various standards developed by OGC SWE in order to
implement the vision statements.

J5-5@ 1PE&1%3>9;%,&"*:&E*;':9*/,&

The SWE framework consists of three encoding specifications (SensorML, O&M, Transdu-
cerML) and four service specifications (SPS, SOS, SAS, WNS). Currently, some more speci-
fications are under development (SweCommonDataModel, SweCommonServiceModel). The
latest release version 1.x of the various specifications is under full revision at the moment.
Therefore, wherever available, we will represent the latest discussion in the following
clauses. The older versions have been developed as direct XML Schema implementations.

© ESS Consortium 2009 41


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

This process has changed lately. Today, all specifications are developed using Unified
Modeling Language (UML) version 2.0. The XML Schema implementations are derived
automatically from the UML models using a well-defined set of mapping rules. This ensures
consistency across the various specifications, an aspect that has been emphasized in ver-
sion SWE 2.0 a lot.

!"#"$"# %&'()*+,-&./'&0+1.2'(3+'3-.4.%/2.

TML was developed until 2006 to have an integrated encoding and access mechanism for
the description of sensor data and the necessary information for understanding the sensor
data gathering process. Further on, it is suitable for archiving and exchanging sensor data
using streaming technologies. In addition, data can be aggregated, analyzed, compared, and
represented in a common manner. Any row format as provided by sensors is suitable to be
used with TML, as the approach is flexible enough to describe both the used data format as
well as accompanying metadata. The metadata contains a number of attributes, among them
information to determine the time and location of a measurement or the relationships be-
tween various components participating in a data acquisition campaign. The figure below
illustrates how a number of transducers on the left hand side are integrated into a TML data
stream served at a TML data node.

Figure 12: TML Transducer System

The power of TML is its enabling of decoding, processing and analysing workflows of sensor
data without a need for accessing further information from other sources. The development
of TML came to a hold after its first release as an OGC standard. There are currently no on-
going developments. Nevertheless, the process of improving the specification can be re-
initiated at any moment. Thus, TML may serve as an important transport and encoding for
data, in particular data that is streamed, such as video material from sensors or archives.

42 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

!"#"$"5 6-()7&/7*-8.2'(3+'3-.4.6-()7&/2.

SensorML defines standard models and XML Schema for describing sensors systems and
processes; provides information needed for discovery of sensors, location of sensor observa-
tions, processing of low-level sensor observations, and listing taskable properties.
SensorML uses the process to model all sorts of sensors. This is a bit confusing at the be-
ginning, as ProcessML or something similar would probably better suit the design approach
of the model language. Anyway, process allows defining any simple style, complex style or
even sensor network as discussed before. To better align the model with the required attrib-
utes, SensorML distinguishes between four types of processes, as illustrated in the figure
below.

Figure 13: SensorML Process Types

According to the model, processes can be either atomic or composite processes and use
either physical or non-physical assets. An atomic and non-physical process is called a Pro-
cessModel, an example is a simple calculation A+B or a spatial transformation. A atomic but
physical process is called Component, an example is a mercury thermometer. Composite
non-physical processes, e.g. calculations such as A+B=C and C*D=E are called Process-
Chains, whereas composite physical processes are called Systems, e.g. geolocation or
image rectification processes. Common to all processes is the definition of a name, a free
text description, input and output parameters and additional parameters. The following UML
diagram illustrates this definition.

© ESS Consortium 2009 43


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 14: SensorML Process Model

Processes define inputs and outputs, i.e. the property that is observed or used (in case of a
process chain) in order to produce the output of the process. The conversion of input to out-
put is described using the ProcessModel definition. This rather simple model is used to build
the more complex models, e.g. the system model as shown in the figure below.

44 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 15: SensorML System Definition

In summary, the SensorML approach allows to define arbitrary complex sensors or sensor
systems. It is always up to the provider of the SensorML definition to decide on the level of
detail provided in the SensorML files. If SensorML processing engines become available,
SensorML descriptions could even be used to model executable sensor data processing
scripts.

© ESS Consortium 2009 45


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

!"#"$"9 :;)-&<'=>7(.?./-')+&-@-(=.4.:?/.

Observation and Measurement (O&M) defines standard models and XML Schema for encod-
ing observations and measurements from a sensor, both archived and real-time. It uses a
number of elements from other standards in order to ensure consistency across the SWE
portfolio of standards, as illustrated below.

Figure 16: Observation Schema Dependencies

(Cox, 2007)

An observation is the process of providing a value for an observed property. The key proper-
ties of an Observation are its featureOfInterest, the observedProperty, the procedure and the
result, as shown in the figure below. The featureOfInterest is a feature of any type (ISO
19109, ISO 19101), which is a representation of the observation target, being the real-world
object regarding which the observation is made.The observedProperty identifies or describes
the phenomenon for which the observation result provides an estimate of its value. It must be
a property associated with the type of the feature of interest. The procedure is the description
of a process used to generate the result. It must be suitable for the observed property. The
result contains the value generated by the procedure. The type of the observation result must
be consistent with the observed property, and the scale or scope for the value must be con-
sistent with the quantity or category type (Cox, 2007).

46 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 17: The basic observation type

(Cox, 2007)

O&M is pretty flexible and can be applied to a wide variety of observations. It supports both
vector as well as raster data. It has to be said that O&M can hardly be used as is, because
the result value itself remains undefined. Compared to the other SWE standards, O&M
needs to be used within a specialized observation language that fulfils the requirements of a
particular modelling domain.

!"#"$"$ 6A-B7@@7(.C'='./7*-8.

The SweCommon Data Model is currently under development and has not been released yet
to the public. It defines the model that shall be used within SWE to express data values. It
supports simple types, aggregated data types, spatial data type as well as property types.
The SimpleTypes as illustrated below define the basic types to be used to express data of
different formats. The simple types are then used to build the aggregated types as shown
further below.

© ESS Consortium 2009 47


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 18: SweCommon Simple Types

The aggreated types allow the combination of any number of simple types in different aggre-
gation elements. The SimpleDataRecords have fields that can be filled with any scalar
values, DataRecords that store any data, DataChoice to express options between alterna-
tives, and DataArrays as a efficient mechanism to aggregate data using alternative encod-
ings.

Figure 19: SweCommon Aggregate Types

Data can be provided using different mechanisms and encodings, as illustrated in the two
following figures.

48 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 20: SweCommon Encodings

The different data encodings allow optimizing data transport and processing depending on
the situational requirements. XMLEncoding and BinaryEncoding express the two ends re-
garding size and readability, whereas the TextEncoding provides a kind of medium way, both
in terms of human readability as well as size of data that needs to get transported.

!"#"$"D 6A-B7@@7(.6-&<>,-./7*-8.

The SweCommon Service Model is currently under development and has not been released
yet to the public. The classes defined in the SweCommon Service Model are shared among
all SWE Services. The model uses elements from the SweCommon Data Model as dis-
cussed above. In addition to the SWE packages, a number of external package dependen-
cies are used, such as Web Services Topics version 1.3, defined by OASIS (OASIS, 2006),
or Web Services Addressing as defined by the W3C (W3C, 2004). The consolidation of ab-
stract super classes for all service operations shared among SWE service specifications en-
sures consistency in the modelling approach and facilitates the implementation of the various
service instances.

© ESS Consortium 2009 49


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 21: SweCommon Service Model Package Dependencies

In addition to the package dependencies shown above, there are packages used defined by
ISO, such as ISO 19103, 19108, and 19136.

!"#"$"E 6-()7&.:;)-&<'=>7(.6-&<>,-.

The Sensor Observation Service specification defines the general access mechanism to
sensor data in SWE. The service uses a pull-based schema, i.e. clients need to send data
requests and receive sensor data or metadata in response. There is an ongoing discussion
in the Sensor Web Enablement Group if the service shall be extended with other communi-
cation patterns, such as the publish-subscribe schema. This would allow clients to receive
data once it is inserted into the service, but this discussion is still in an early stage. For now,
there seems to be a preference to continue with dedicated push-based service interfaces
such as Sensor Alert Service or Sensor Event Service.
The SOS interface definition follows the general OGC practice and defines a set of core op-
erations plus a number of optional additional operations that extend the functional set of the
service. This core plus extension model allows service providers to decide on the richness of
the service interface by themselves.
The service interface illustrated below reflects the latest, yet unpublished discussion by the
OGC SWE Group. It is likely that we will experience a number of changes within the next
months.

50 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

The core operation of the Sensor Observation Service is GetObservation.

Figure 22: SOS GetObservation operation definition

The operation allows filtering for potentially most of the aspects that might be relevant in any
particular Sensor Web application. The filter set allows filtering for
• the feature of interest, which is the ultimate real world entity of interest, e.g. a toxic
plume, or a river;
• the observed property, which is the chemical, biological, physical, or even abstract
property getting observed by the sensor(s);
• observations performed by dedicated sensors;
• result-value based, spatial and temporal subsets.
In addition, the operation defines the response format. By default, all SOS instances return
O&M encoded data, but there are other options that might be supported by particular instan-
ces. Examples are native formats such as NetCDF or image files.

© ESS Consortium 2009 51


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

The SOS specification defines eight other operations:


• GetCapabilities, to request a self-description of the capabilities from the service
• GetDataAvailability, to request metadata about newly available data sets
• GetResult, to request only the result values of an observation in order to minimize the
size of the data getting transported form server to client
• GetResultTemplate to request a description of the response format of a GetResult re-
sponse
• InsertObservation, to insert a complete new observation into a transactional SOS in-
stance
• InsertResult, to insert a new result value into a transactional SOS
• InsertResultTemplate, to define the structure of the payload used in InsertResult re-
quests
• InsertSensor, to add a new sensor to a transactional SOS instance
In summary, the SOS specification defines a very generic service that can be used in a wide
range of domains and applications. This universality comes for a price, nevertheless. It re-
quires defining a set of used observables and in an optimal situation a clear description of
the supported SensorML language spectrum in order to ensure proper client-server com-
munication.

J5-5B 1%*,'3&6$"**9*/&1%3>9;%&

The Sensor Planning Service (SPS) specification defines an interface to collection assets.
Those include, in addition to physical sensors, all other information gathering assets (i.e.
even humans) as well as the systems that surround those assets. The SPS provides oper-
ations that allow tasking the asset, whereas the tasking options depend on the service pro-
vider. The service provider may decide that clients themselves can set each parameter, or
only a subset, in order to hide certain system details from the user. This can be motivated by
simplification or security considerations.
The SPS is currently under intensive redesign and not yet published outside the OGC. The
redesign phase is likely to end mid November 2009, as it is the plan to release the first draft
of the new SPS specification version 2.0 end of this year. Thus, the currently published ver-
sion 1.0 (Simonis, OGC® Sensor Planning Service Implementation Specification, 2007) can
be considered as outdated.
The new SPS design will change the communication behaviour of the service. In version 1.0,
SPS was pretty much dependent on other services, such as the Web Notification Service, to
send update messages to the clients. The new design uses WS-Notification and WS-
Addressing to support asynchronous communication between server and client.

52 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

SPS uses SWECommon to describe planning parameters that have to be set by users. SPS
is often used together with WNS and SOS. The interaction sequence basically consists of the
following steps:

Figure 23: SPS interaction sequence

First, the SPS service needs to be registered at a registry to allow clients to discover the ser-
vice. Once discovered, the client sends a GetCapabilities request to the server to learn about
the service and its offerings. Using DescribeSensor, the client can retrieve additional infor-
mation about the sensor. The service provider decides how much a detail is published about
the sensor in response. Next, the client sends a DescribeTasking request to the server and
receives the description about the parameters that need to be set to task the sensor.
Once received, the client can start tasking the sensor, or he may decide to run a GetFeasi-
bility test first. This test is often useful if complex sensors, such as satellites, shall be tasked.
Alternatively, the client can reserve a task first and start the tasking at a later stage. This op-
tion ensures sensor availability at tasking time.

© ESS Consortium 2009 53


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Once tasked, clients can update or cancel their tasks at any time. GetStatus operations allow
learning about the latest status; DescribeResultAccess allows getting information about data
retrieval (which is handled using other services, such as e.g. Sensor Observation Service). If
client and service enable asynchronous communication patterns using WS-Notification, then
the service might push update information to the client at any time.
The following figure illustrates the different operations and shows how the SPS makes use of
packages such SweCommon Data Model and SweCommon Service Model.

Figure 24: SPS Package Dependencies

In summary, SPS can be used to task all sensors in any imaginable ESS scenario. Due to its
generic design, it can be used to task an Unattended Aerial Vehicle as well as a simple Web
cam. In addition, it can be used to task an UAV simply by providing a target position and alti-
tude, or by providing a full set of tasking parameters, such as flight paths, sensor settings,
looking angles, return dates, launch settings etc.

J5-5I 1%*,'3&=$%3+&1%3>9;%&

The Sensor Alert Service analysis has been performed as part of the Event Driven Spatial
Data Infrastructure research. The service is described in chapter 6.3.4.

54 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

J5-5J 1%*,'3&E>%*+&1%3>9;%&

The Sensor Event Service analysis has been performed as part of the Event Driven Spatial
Data Infrastructure research. The service is described in chapter 6.3.4.

J5-5R P%#&Q'+9(9;"+9'*&1%3>9;%&

The Web Notification Service analysis has been performed as part of the Event Driven Spa-
tial Data Infrastructure research. The service is described in chapter 6.3.3.

© ESS Consortium 2009 55


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

R GC)&P%#&1%3>9;%,&
Architecture of the ESS is composed from a wide variety of different tools that has the same
purpose – to ensure the complexity of tasks in emergency management. Therefore, one part
of the whole architecture (an objective of WP5) is to develop the Data fusion tool which will
obtain data from all data collecting tools that are included in the ESS system. Furthermore, it
is assumed that the Data fusion tool will also ensure data harmonization for two kinds of
data. The first group will be data collection and harmonization during the emergency or crisis
event management – incoming data can be distinguished here as the “instant” or action data.
The second group can be designated as “long life” data. Those data (like topographic data,
satellite images or demography data) serve especially for the visualization purposes, mostly
as the background for the action data.
The Emergency Support System shall use an architecture with open interfaces. In this sense,
it means that existing spatial data sources of data types mentioned above can be added via
these interfaces into the ESS.
This topic of spatial Web services is complementary to the Web services, which are used for
the transfer of sensor data from various resources.
Many time-critical applications, such as emergency event management, location based ser-
vices, real time traffic management or environmental monitoring, need an instant access to
the various kinds of data to make quick decisions and take appropriate actions. Those data
usually have a spatial extent, i.e. can be localized on the surface of the Earth. At the same
time, we can say, that those data are visualized in the form of a map as an efficient way of
communication. Creation of these maps from actual data takes some time, therefore it was
desired to have an instant access to the latest (up-to-date) spatial data. Development of the
Internet and moreover World Wide Web (WWW) provide a way to quickly access various
(spatial) data sources. Therefore, suitable form of the instant connection to desired (spatial)
data sources is a Web service. A Web service is defined by the World Wide Web Consortium
(W3C, 1999) as “a software system designated to support interoperable machine-to-machine
interaction over a network”. The concept of the Web service is based on the server – client
communication while using HTTP (Hypertext Transfer Protocol). Web services have been
used for spatial data transfer over the Web since the late of 1990's as the way how to send
data in the form of a map as a JPEG, GIF or PNG image. The Open Geospatial Consortium
(OGC) standardized this Web service as the Web Map Service in 1999. Dawn of the new
millennium extended the portfolio of spatial Web services. The brief description below will be
related to the significant spatial Web services from the ESS point of view.

R5- P%#&."7&1%3>9;%&SP.1T&

Web Map Service (WMS)(OGC, OGC Web Map Service Interface – version 1.3.0., 2004)
defines the behaviour of a service that produces spatially referenced maps dynamically from
geographic information. It specifies operations to retrieve a description of the maps offered
by a server or to retrieve a map, and to query a server about features displayed on a map.
WMS was adopted as the ISO 19128 standard in 2005.
WMS can have three main requests (operations respectivelly):

56 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

• GetCapabilities,
• GetMap and
• GetFeatureInfo.
GetCapabilites is the primary request for all OGC Web services (i.e. for all the Web services
mentioned in this part of the state-of-the art analysis). The purpose of the mandatory GetCa-
pabilities operation is to obtain service metadata, which is a machine readable (and human-
readable) description of the server’s information content and acceptable request parameter
values. In other words said, a server response to the GetCapabilities operation contains an
information about what kind of the service it is (like WMS), what version (latest WMS version
is 1.3.0), information about responsible party (e.g. an organisation that created the data),
supported formats (JPEG, GIF and/or PNG), supported coordinate systems (in the form of
the EPSG code – like „4326“ instead of „WGS 84“), spatial extent (as the minimum bounding
rectangle around the data on the Earth surface as bonding longitude and latitude in decimal
degrees) and the list of data layers that can be requested.
The mandatory GetMap operation returns a map or issue a service exception. In other words
said, if a user in a client application asks for the GetMap request with all mandatory param-
eters, he will get the map as the JPEG, GIF or PNG image. Parameters that needs to be
specified in the GetMap request are the used service (WMS), version of this service (like
1.3.0), the desired layer (e.g. forests, hydrography, highway network, etc.), styles (for exam-
ple if I need to change colour and width of the highway in the map to the 1 pixel red line),
minimum bounding rectangle (i.e. the extent of the displayed area in the decimal degrees),
coordinate reference system (like „4326“ - see above), width and height of the image (in
pixels), format (JPEG/GIF/PNG) and the transparency (just transparent or not transparent). If
I ask with all the required parameters, I will get a map in the form of JPEG/GIF/PNG image
as the response of the server as it is shown in Figure 25.

Figure 25: Demonstration of the WMS GetMap operation

The last (optional) operation is called GetFeatureInfo. This operation enables to query the
objects on the map. If a user asks for a certain object on a map (e.g. by clicking on the mark

© ESS Consortium 2009 57


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

for a region) he will get a response from the server with all information from the database
(which can for example be the name of the region, number of inhabitants, area, population
density, number of immigrants, etc.).
The main advantage and disadvantage of the WMS at the same time can be seen in the
constraint to transfer only compressed raster data. Therefore, other standards were devel-
oped – WFS (Web Feature Service) for the transfer of real vector data and WCS (Web Cov-
erage Service) for the transfer of real (usually huge) raster data.

R5< P%#&)'>%3"/%&1%3>9;%&SP)1T&

Web Coverage Service (WCS)(OGC, Web Coverage Service, 2003) provides an interface
and a mechanism to transfer and request for geographical coverages across the Web using
platform-independent calls. The coverages are objects (or images) in a geographical area,
whereas WMS returns only an image (i.e. the compressed version of the original coverage).
On the other hand, the principles are the same as in the case of WMS. The whole communi-
cation starts with the GetCapabilites operation with analogous response from the server. The
second step of this communication continues with the GetCoverage request/operation. This
operation returns a coverage (like raster data, digital elevation model data, but on the con-
trary to the WMS also with the attribute table) from the server. Data may be available in the
response in several formats, such as GeoTIFF, DTED, HDF-EOS or NITF. The last (also
mandatory) operation (like in the case of WMS) is DescribeCoverage which obtains a full
description (i.e. metadata) of one or more coverages available (the response to this request
is encoded in the XML file). The current WCS version is 1.1.2.

R5? P%#&A%"+23%&1%3>9;%&SPA1T&

Web Feature Service (WFS) (OGC, Web Feature Service Implementation – version 1.1.0.,
2005) represents an interface allowing requests for geographical features across the web
using platform-independent calls. One can think of geographical features as the objects on
the map; considering a map of Europe, each state is a separate geographical feature, as well
as the main city of each state on the same map is a separate geographical feature as well.
The geographical features can be seen as the primary unit of each map and therefore can be
encoded into the source code behind a map. The biggest advantage of this approach is that
these geographical features can be in this way edited, queried or spatially analyzed. The
response is physically realized in GML (Geography Markup Language) format, which is a
modification of XML (eXtensible Markup Language) used for the specific application area – in
this case for the storage of geographical (i.e. spatial) data (geographical features respec-
tively). Furthermore, WFS cannot be only a download service for geographical features, but
in the WFS-T (Web Feature Service – Transactional) form allows creating, deleting and up-
dating features.
Also the WFS communication starts with the GetCapabilities operation (described above)
and continues with the GetFeature operation. GetFeature request contains similar parameter
to those described in the WMS section, but the answer is the desired data in GML format
(there are different flavours of GML – from the simplest that contains just the geometry as the
point, line or polygon to a complex one storing curves, surface, multi-dimensions – time, ele-

58 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

vation, multi-band imagery to topologically integrated datasets). The last request for the non-
transactional Web Feature Service is the DescribeFeature with the same meaning as in the
WCS (see above).
As it has been mentioned, WFS furthermore enables the transactions. Thus, specific oper-
ations have been added to ensure the scope of the WFS-T. The specific requests are Insert-
Feature (which adds a new geographical feature – such as adding a new country to the
database of the European countries), UpdateFeature (e.g. changing the attribute information
about the number of inhabitants) and DeleteFeature (for example erases the old capital city
from the map). It is assumed that more users can make modifications at the same time;
therefore a LockFeature operation was added. LockFeature ensures that the modifications
on a single element are in one time provided by just one user.

R5@ P%#&63';%,,9*/&1%3>9;%&SP61T&

Web Processing Service (WPS) (OGC, OpenGIS Web Processing Service – version 1.0.0,
2007 b) defines a standardized interface that facilitates the publishing of geospatial pro-
cesses, and the discovery of and binding to those processes by clients. Processes include
any algorithm, calculation or model that operates on data. In other words said, WPS was
developed to standardize the way of calculations over the spatial data in the Web envi-
ronment. Thus, it can be assumed, that WPS can offer any functionality of a GIS (Geo-
graphic Information System). Although WPS was designed to work with spatially referenced
data, it can be used with any kind of data. In the field of GIS data is this service targeted at
processing both vector and raster data. The WPS specification is designed to allow a service
provider to expose a web accessible process, such as polygon intersection, in a way that
allows clients to input data and execute the process with no specialized knowledge of the
underlying physical process interface or API (Application Programming Interface). The WPS
interface standardizes the way processes and their inputs/outputs are described, how a client
can request the execution of a process, and how the output from a process is handled.
WPS defines three requests/operations – starting from the GetCapabilites to DescribePro-
cess and Execute. DescribeProcess operation was designed to avoid the so-called “black-
box” model. DescribeProcess operation allows a client to request and receive back detailed
information about the processes that can be run on the service instance, including inputs
required, their allowable formats, and the outputs that can be produced. The Execute oper-
ation allows a client to run a specified process implemented by the WPS, using provided in-
put parameter values and returning the outputs produced. The output format (format, encod-
ing and schema for the output respectively) is not strictly specified in Web Processing Ser-
vice specification while it is left up to the producer of the Web Processing Service instance.

R5B )"+"$'/2%&1%3>9;%&('3&P%#&S)1PT&

Catalogue Service for Web (CSW) (OGC, OpenGIS Catalogue Service Specification –
version 2.0.2, 2007 a) specification solves the interfaces, bindings, and a framework for de-
fining application profiles required to publish and access digital catalogues of metadata for
spatial data, services, and related resource information. In other words said, CSW allows a

© ESS Consortium 2009 59


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

user to find the data and services suitable for his/her application. This searching is based on
the concept of metadata (i.e. a description of a data or a service) that is stored in the stand-
ardized format (usually based on XML). This metadata XML file contains information for ex-
ample about the title of the dataset, keywords, spatial, vertical and temporal extent of this
dataset, abstract, access constraints, information about the organization that is producing the
data / created the metadata and so on. Information from this XML metadata file is then stored
at the server where CSW is running. A user can then via the client application ask for data
that corresponds to the searching criteria – like “I am searchingrivers (keyword) that cover
the area of the Czech Republic and Germany (spatial extent) and have been updated in
2008 or later (temporal extent). CSW then processes these requests and gives back all the
results that match to the specified criteria. A user can see not only the results, but also a de-
tailed description of each dataset / service.
CSW may have up to seven operations while four of them are mandatory. The first manda-
tory operation is again GetCapabilities, the second is GetRecords operation, third is the De-
scribeRecord operation and the last is GetRecordById.GetRecords operation enables to ob-
tain all the metadata records (i.e. XML files) that match to user defined criteria. For that rea-
son, a part of the GetRecords operation is a filtering language (e.g. CQL – Common Query
Language) that ensures the whole variability of filtering criteria (like is more than, is equal to,
contains, ends with, time duration, etc.). DescribeRecord operation allows a client to discover
elements of the information model supported by the target catalogue service. The operation
allows some or the entire information model to be described. The mandatory GetRecordById
request retrieves the default representation of catalogue records using their identifier. This
operation is also a subset of the GetRecords operation, and is included as a convenient short
form for retrieving and linking to records in a catalogue.
The optional GetDomain operation is used to obtain runtime information about the range of
values of a metadata record element or request parameter.
The general model of the catalogue service defines two (optional) operations that may be
used to create or update records in the catalogue. They are the transaction operation and the
harvest operation. The transaction operation may be used to “push” data into the catalogue
whereas harvest operation “pulls” data into the catalogue. That is, this operation only refer-
ences the data to be inserted or updated in the catalogue, and it is the job of the catalogue
service to resolve the reference, fetch that data, and process it into catalogue.

R5I 1HK&1%3>9;%&K*+%/3"+9'*&

Above-mentioned services can be integrated in the spatial data infrastructure (SDI), which
can be seen as the combination of different data, metadata, services, policies and standards
(see Figure 26). Services are integrated via open standard interfaces that enable client to
communicate with all services and obtain desired metadata and data. An illustration of the
infrastructure functionality can be seen in the following example. A producer of spatial data
harmonizes his data (for example to the GML format) and describes them – i.e. creates
metadata, that will be loaded into the catalogue service. Catalogue service for Web (CSW) is
a place where a producer meets a user. A user needs for example a reference data for his
thematical data; therefore he visits a Web page that is a client of the catalogue service and
can find suitable data. Searching of the suitable data is based on fulltext, spatial and tempo-

60 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

ral filtering (like typing “topographic map” into the searching field, drawing a polygon on the
map to select the area of interest and/or selecting a date of a dataset creation).

Figure 26: Example of the components and their connections in the spatial data infrastructure.

This filtering is based on metadata and the results of such queries are metadata again. The
basic difference to the ordinary search engines is that the client is not searching in just one
database, but in all databases of all catalogue service servers that have been registered.
When a user gives the suitable result(s), it is enabled to view the data via the Web Map Ser-
vice (WMS). Metadata may contain a link to a WMS server. If the user is satisfied with the
preview of data in the form of WMS (i.e. in the form of a compressed raster file) it is possible
to download the data via the Web Feature Service. If for example the coordinate system of
those data is different from the coordinate system that user uses, it can be changed via a
Web Processing Service (WPS).
Establishing of the spatial data infrastructures is a process that is common in most of the
developed countries, but also at the international level (for example see establishment of the
European spatial data infrastructure called INSPIRE - http://inspire.jrc.ec.europa.eu .

R5J )'*;$2,9'*,&

The topic of spatial Web services is important to ESS, because ESS combines action data
(i.e. data from the sensors, IMSI catchers, traffic data, etc.) and long life data (i.e. the back-
ground data). The long life data represents the data that may be obtained by an offline
method (like a distribution on CD, DVD, etc.) or online method. Spatial Web services are an
efficient way to retrieve spatial data and services for long life data. As it has been mentioned
above, this topic is important, but not crucial. Emergency systems cannot depend on the live
Web services connection during some emergency situation (connection to other vendors
may fail in these cases). Therefore, it would be better to have a duplicate database of long
life data (i.e. topographic maps, aerial and satellite images, demographic data, etc.), which
will be periodically updated.

© ESS Consortium 2009 61


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

This duplicate database can be connected via WMS/WCS/WFS to other databases that may
be the source for the update of the ESS database. WPS is not useful for the ESS system,
because the whole processing functionality will be the inner part of the ESS architecture. On
the other hand, it can be a way to connect internal components of ESS architecture.

62 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

U E0%3/%*;4&."*"/%0%*+&1+"*:"3:,&(3'0&G=1K1&

U5- K*+3':2;+9'*&

The need for harmonization and standardization in the area of emergency management led
to the creation of the OASIS Emergency Management Technical Committee (EM-TC). The
committee addresses the creation and maintenance of interoperable incident and emer-
gency-related standards. The group has created several specifications which have gained a
lot of attention in the research, governmental and industrial domains. In the following
clauses, we will provide an overview of the main standards and provide a conclusion of their
applicability to ESS.

U5< )'00'*&=$%3+9*/&63'+';'$&

To support the interchange of alert /


warning messages in an
interoperable way, the Common
Alerting Protocol (CAP) has been
designed. The official version of CAP
currently is 1.1 (Jones & Botterell,
2005) though version 1.2 is in
development and currently available
as a public review document
(Westfall, 2009).
The focus of CAP is not on actual
message exchange patterns like
publish / subscribe (see chapter 6 -
Event Driven Spatial Data
Infrastructure). Rather, CAP defines
the format of alert messages, with
emphasis on human readability and
multi-language support.
A CAP message consists of an alert
part and optional information
elements which themselves may link
to additional information (resources
like audio files or images) and may
define the geospatial extent that the
information applies (see Figure 27).
Each CAP message has a unique
identifier and defines the entity /
person that sent the message as
well as the time the message was
Figure 27: CAP 1.1 Information Model

(Jones & Botterell, 2005)


© ESS Consortium 2009 63
FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

sent. In addition, a message has a certain status, which together with the urgency, severity
and certainty of a contained information element determines which action a recipient takes
according to his Emergency Response Plan (ERP).
For correlation purposes, a CAP message may also reference to which overall incident / em-
ergency the message applies. Multiple information blocks inside a message then either iden-
tify different parameters of the incident or simply provide the information in multiple lan-
guages.
An incident commander or other entity may use CAP messages to warn the population about
categorized threats and define responsive actions that should be taken. Whether such an
action is really taken or not depends upon the message urgency, severity and certainty and
how the ERP actually handles certain constellations of these parameters. For example, a
message with urgency “immediate” usually indicates that responsive action should be taken
immediately. However, if the severity is “unknown” and the certainty is “unlikely” – for what-
ever reason – then the ERP might define that no immediate responsive action is required but
that the message rather needs validation.
Because many constellations of CAP message parameters are possible, CAP profiles have
been developed to restrict CAP functionality to match the needs of certain user domains
(Gow, Anderson, & Waidyanatha, 2007), (CAPAN, 2009), (Brooks & Dwarkanath, 2009).
The development of these profiles as well as general user feedback will be incorporated in
version 1.2 of the standard. For example, some new types of responsive actions will be in-
cluded, which also provide the functionality to give the all clear to the population.

U5? E0%3/%*;4&H"+"&EV;8"*/%&O"*/2"/%&

Because of the heterogeneity in emergency support operations, logistics, planning and fi-
nance, the EM-TC created a framework of integrated standards – called the Emergency Data
Exchange Language (EDXL) - to address these aspects in an interoperable way. So far
EDXL encompasses standards for the distribution of emergency messages as well as for
resource management and hospital availability. Development on a standard for situation re-
porting has just started but will not be covered in this report.

U5?5- H9,+39#2+9'*&E$%0%*+&SEHWOXHET&

In order to facilitate routing of properly formatted XML message in general and of emergency
messages in particular, the EDXL Distribution Element (EDXL-DE) was specified (Raymond,
Webb, & Aymond, 2006). The distribution element is a container for a number of payloads
(the format of which is not restricted by EDXL-DE; examples are CAP, EDXL-RM and EDXL-
HAVE message types) that also contains information to route the message accordingly.
With EDXL-DE, messages can be routed to recipients either by explicitly listing the recipient
endpoints (e.g. via email addresses), by stating the role of intended recipients, by adding
keywords / tags to the distribution message which recipients can filter upon or by defining a
target area to which messages shall be sent. The target area is a geographic region identi-
fied either by a simple circle, polygon, country, part of a country or UN location code.

64 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

The distribution message consists of three parts: a message header, distribution tags and
the actual payload / content:

Figure 28: Distribution Element (DE) Domain Model

(Raymond, Webb, & Aymond, 2006)

The distribution header identifies the message itself, the sender as well as the transmission
time. In addition, it classifies the message as well as its confidentiality and defines the lan-
guage used in free-text fields of the message. Message classification determines whether
the message is only a test message or a serious one as well as the message intent, for ex-
ample whether it is a simple report or a request that requires a response. Some sensor re-
lated message types are also defined.
The concepts of message update, cancellation, acknowledgement and error reporting are
also included. The semantics of these types are somewhat underspecified, though, the main
problem being that the expected messaging sequences with correct message type usage are
undefined.
The distribution part of an EDXL-DE message determines to which recipients the message
shall be sent. The available distribution options (geographic, by keyword etc.) have already
been explained above.

© ESS Consortium 2009 65


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Finally, a distribution message usually contains a payload (messages without payloads can
be acknowledgements of previous messages, for example). This payload can be a number of
content objects, either XML based or in other formats (identified by mimeType). Each content
object has to provide a short description of the relevant incident and the message confiden-
tiality level, among other properties. Security measures like encryption can be applied to en-
sure that critical information is only made available to those recipients that have the rights to
receive the message.

U5?5< D%,'23;%&.%,,"/9*/&SEHWOXD.T&

Managing resources will be of high importance in ESS. The EDXL Resource Messaging
(EDXL-RM) standard (Aymond, et al., 2009) was developed to support this functionality by
defining a set of messages for managing resources during an incident. Resources thereby
include both human and non-human resources. The former can be police, fire fighters or
other emergency teams while the latter can be sensor assets like UAVs or chemical detec-
tors, technological equipment (power generators, trucks for evacuation etc.) or supplies (e.g.
drugs, food, shelters).
EDXL-RM is used as a payload in EDXL distribution messages (see chapter 9.3.1). As such,
resource consumers – stakeholders like an incident commander who are in need of re-
sources to manage an emergency – can send resource requests which are answered by so
called resource suppliers – the stakeholders that own, maintain and offer such resources.
These requests for resources will be distributed according to the distribution options of
EDXL-DE to and from resource consumers and suppliers.
Three primary message categories can be distinguished, for which several EDXL-RM mes-
sages have been defined: resource discovery, ordering and deployment:

Figure 29: EDXL-RM operations in support of resource discovery, ordering and deployment requirements

(Aymond, et al., 2009)

66 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

The Ordering phase enables Resource Consumers to explicitly requisition Resources from
Resource Suppliers. The Deployment phase enables both actors to find about the current
status of resources in the field, request extensions and returns. [EDXL-RM])
In the discovery phase, the request consumer can query suppliers for available resources
and can also determine potential costs for these supplies. Suppliers can respond to such
requests. This can involve a direct offer but also a request for more precise information, al-
lowing a conversation between consumer and supplier to further specify the details of the
resource request or offer. A request from consumers is not even necessary – suppliers may
themselves offer resources to help in an emergency or suggest alternative resources that the
resource consumer might not have considered before. This supports the notion of community
participation in answering a crisis. Available resources can thus be discovered – using both
broadcasts for resource requests but also targeted communication – and from then on
tracked by the emergency management system.
Once the resource consumer has discovered required resources and wants to deploy them,
he can enter the ordering phase. Now the consumer can actually requisition resources and
the suppliers can commit their resources to the consumer. This model takes into account
funding of resources and also supports commitment to provide resources only under certain
conditions (the nature of which depends upon the actual emergency situation and thus is not
further defined by EDXL-RM). Declining a request for resources is also possible.
In general, EDXL-RM does not make any assumption on the command hierarchy in an em-
ergency situation. This takes into account that in some situations the resource consumer can
really commandeer the supplier to provide requested resources even if the supplier would
like to decline that request. In other cases the supplier might be outside the command hier-
archy of the responsible emergency commander. Whatever command hierarchy is actually in
place for a given emergency thus needs to be handled separately.
Once resources have been committed to support an emergency, EDXL-RM defines oper-
ations to facilitate resource management in the actual deployment phase. Suppliers (but also
consumers) can request the actual deployment status of a resource, allowing both sides to
track progress and current state of resource utilization. In some cases, suppliers might want
to order back the resources they committed, for example because they are urgently needed
elsewhere. In other cases, the consumer might want to utilize a resource longer than was
initially agreed upon with the supplier. These use cases are supported by EDXL-RM. A re-
source consumer can also release resources if they are no longer needed, allowing them to
return to their home base and be used elsewhere (which enables efficient distribution of re-
sources to incident locations on-demand).
Throughout all three phases of resource management, the actual resource schedule can be
defined. Scheduling information for example includes requested, estimated and actual arrival
of a resource at a location specified by the resource consumer. In summary, the whole life-
cycle of a resource used during an emergency can be modeled. A resource can thus be
tracked from the time when it leaves its home base through the actual deployment phase
until it finally returns to its home base. This is especially valuable because the model takes
into consideration requirements from both the resource consumer and supplier.
EDXL-RM is specified in more detail than EDXL-DE is. However, some parts of the standard
are rather unspecific. In cases where domain specific vocabularies are used, this can be a
feature – for example when EDXL-RM is used on a national level where defined vocabularies

© ESS Consortium 2009 67


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

have been put in place. However, in cross-border emergencies, an intermediate system


would need to map terms from one vocabulary to another, which usually involves semantic
technology like ontologies. The update and cancellation of EDXL-RM messages is built into
the standard as well. However, the specification is silent upon the exact meaning of these
operations and until which point in time a message can really be updated/cancelled. This
behaviour should be defined in EDXL-RM, so that at least handling of EDXL-RM messages
is truly interoperable.
Support for multiple languages is not built into EDXL-RM itself. In order to perform resource
management using this standard, a broker will likely be needed to translate an EDXL distri-
bution message from one language to the other on the fly – or a resource consumer needs to
send out resource requests in multiple languages at the same time.
EDXL-RM is quite verbose in that it does not have any mechanism to reference parts of a
resource management message that is likely repeated several times (for example the contact
information). Whether this can be considered a disadvantage or not remains to be seen.

U5?5? Y',79+"$&=>"9$"#9$9+4&EV;8"*/%&SEHWOXY=ZET&

An emergency threatens the health of involved citizens and medical treatment of injured or
otherwise affected people is required. In such cases, knowledge on available hospitals as
well as their capabilities and current status is essential information for an incident com-
mander.
The EDXL Hospital Availability Exchange (EDXL-HAVE) standard (Dwarkanath, 2008) was
developed to provide a common data format to encode important hospital information and
make it available to emergency managers and other hospitals or interested parties in an in-
teroperable way.
With EDXL-HAVE, the current status of a hospital, its services and resources can be com-
municated. Figure 30 provides an overview of the data model implemented by the standard.

68 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 30: EDXL Hospital Availability Exchange (HAVE) Element Structure

(Dwarkanath, 2008)

The model incorporates information critical for assessing a hospital’s current ability to provide
support in an emergency. The figure shows that several aspects of a hospital’s capabilities
and characteristics are taken into account. For example, using EDXL-HAVE a client can de-
termine whether a certain hospital has an emergency department and what its current status
is. In addition, information about the transport services of the hospital (ambulance and/or air
transport) can be provided. Also, how many beds of which type (adult intensive care, pediat-
rics, negative pressure / isolation etc.) are currently available can be indicated – even how
many beds can be made available within 24/72 hours. This allows an incident commander to
distribute emergency victims to the hospitals without the risk of overloading one hospital

© ESS Consortium 2009 69


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

while another hospital in the region is still under full capacity. Another aspect covered by the
model is which services a hospital provides. For example, a hospital might support surgery,
neurology and burn services but not neonatology. This information helps even more in the
appropriate distribution of victims among several hospitals. Finally, the model also incorpo-
rates a hospital’s facility status, which includes the current security level (normal, quarantine
etc.) or staffing – among others.

U5@ )'*;$2,9'*,&

The standards proposed by the Emergency Management TC of OASIS represent a valuable


source of information for the design of ESS. Even though the origin of these standards is
clearly the emergency management community of the United States3, uptake of these stand-
ards also happens in other countries worldwide. As such, the OASIS standards should be
taken into account in the design of the ESS system architecture – if the standards cannot be
used as-is then at least the concepts implemented by them are of value.
One of the drawbacks of CAP and the EDXL standards is that they do not include extension
points where arbitrary information can be inserted for testing purposes or from specifications
that extend the functionality defined by the base standards. With such extension points, ESS
could add specific information to the core messages, for example the information required to
let an ESS user operate a sensor resource via ESS interfaces himself. This would be useful
to give an ESS user (in the role of resource consumer)limited control of an otherwise au-
tonomous resource.
As mentioned in previous clauses, the standards seem to be underspecified in some places.
If ESS decided to adopt these standards, a profile / best practice guide will be needed to
handle this issue. Such guidance could be brought to the attention of the OASIS Emergency
Management TC as feedback concerning their standards, thus improving the further stand-
ardization process.
In many places, the OASIS emergency standards are using code lists of which the values
are undefined. This makes the standards usable in different domains but makes it hard for a
system like ESS as there is no common ground to start from. The incorporation of semantic
mapping techniques could be considered by ESS. However, it is impossible to create map-
pings between unknown code lists. Therefore, the ESS system should rather primarily sup-
port the adoption of code lists that are (or need to be put) in place for an emergency through
the Emergency Response Plan of the responsible administration. Such code lists could be
used to configure the ESS system when it is deployed in an emergency case.
Another aspect that is not covered by the OASIS emergency standards so far is modeling of
a command hierarchy. It appears that such a hierarchy needs to be modeled separately and
be populated according to the authoritative structures that are encountered in the region
where the ESS system is applied. An Emergency Response Plan could identify these struc-
tures.

3
for example, in EDXL-RM the funding scheme of the [U.S.] National Incident Management
System (NIMS) is mentioned while EDXL-HAVE uses trauma codes defined by the American
College of Surgeons (http://www.facs.org/trauma/hospitallevels.pdf)

70 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Utilizing CAP as a common encoding for alerts and warning messages could be utilized to
detect certain patterns that signify the imminence of an even greater threat. Event Pattern
technology – see chapter 6 - Event Driven Spatial Data Infrastructure - could be applied to
search for such patterns in streams of CAP encoded events.

© ESS Consortium 2009 71


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-[ .2$+90%:9"&1+3%"09*/&H"+"&

-[5- K*+3':2;+9'*&

Emergency management activities require a detailed assessment of the current situation in


the crisis area. This includes live streams from information sources in the field but also re-
corded data. Multimedia sources (audio and video sensors) play a vital role because they
provide a much more intuitive access to the situation at hand. This is especially true for hu-
man operators. However, the data can also be processed by client software to derive higher-
level information (like the location of a fire).
It is therefore critical to have a well-defined mechanism to provide access to multimedia data
gathered by sensors. A number of encoding formats for both audio and video data exist to-
day, each with its strengths and weaknesses, and more will be developed in the future. Also,
hardware built today is not guaranteed to be upgraded to use the latest encodings.
A system like ESS will therefore need to be able to support this encoding variety. This does
not mean that each client or service in the system would need to understand all encodings.
What is needed is a solution, which allows services to advertise in which encodings data
from a certain sensor is (or can be made) available and for a client to retrieve data in the pre-
ferred encoding.
Retrieval of recorded video streams on-demand resembles downloading a file from a web
server. This does not require real-time playback of the data and is therefore easier to handle.
Clients may use standard Internet protocols like HTTP or FTP to get the media file. Depend-
ing on the file encoding, clients can start playback even if the whole file has not been down-
loaded yet.
Live streaming of media, i.e. visualization of media in real-time, is a more difficult problem
because of several factors that need to be taken into account and that are related to each
other.
The playback quality of live-streamed media is the determining factor. If the live-stream is not
provided in sufficient quality, then it is of no use for the client. The bandwidth available to the
streaming server and the client (or clients, if the stream is multicast to several entities) de-
termines which playback quality can be achieved. Current encodings like JPEG 2000
("##$%&&'''()$*+(,-+&)$*+.///&0enable compression of the base data so that less bandwidth
is consumed. However, this also decreases the data quality. In the end, a trade off between
data resolution, sampling rate of the source and number of clients accessing the live-stream
needs to be found.
Because this trade off can only be made based upon the current situation, what is needed is
a way to facilitate the advertisement of the parameters relevant for a live-streaming session.
Then clients either can pick their preferred constellation of transport protocol and media en-
coding or negotiate this with the service. An IETF standard exists which supports the descrip-
tion of session metadata. It will be described in the following.

72 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-[5< 1%,,9'*&H%,;397+9'*&63'+';'$&

The Session Description Protocol (SDP) is a standard proposed by IETF (Handley,


Jacobson, & Perkins, 2006)!'"12"!3$*2141*3!5!4,-65#!4,-!7*32-1819+!3*331,9!6*#575#5(!:*331,93!5-*!
4,-!*;56$<*!<1=*>3#-*5619+!=17*,!,-!6?<#16*715!2,94*-*92*3!@?319+!5?71,!53!'*<<!53!=17*,!3#-*5630(!
:AB!#"*-*8C!,9<C!7*419*3!",'!#"*!3*331,9!6*#575#5!13!#,!8*!7*32-18*7D!9,#!",'!3*331,9!2,9#*9#!,-!
6*715!*92,719+3!5-*!9*+,#15#*7(!E,!5!<161#*7!*;#*9#D!#"13!9*+,#15#1,9!259!8*!52"1*=*7!?319+!#"*!:*3>
31,9! F91#15#1,9! B-,#,2,<! @:FB0! @G,3*98*-+! H! :2"?<I-199*D! J9! K44*-&J93'*-! L,7*<! '1#"! #"*! :*331,9!
A*32-1$#1,9! B-,#,2,<! @:AB0D! .//.0! 19! 2,68195#1,9! '1#"! #"*! K44*-&J93'*-! L,7*<! @G,3*98*-+D! *#! 5<(D!
.//.50(!
J22,-719+!#,!@M597<*CD!N52,83,9D!H!B*-O193D!.//P0D!59!:AB!3*331,9!7*32-1$#1,9!192<?7*3!#"*!4,<<,'19+!
194,-65#1,9%!
• Session name and purpose
• Time(s) the session is active
• The media comprising the session:
• type of media (video, audio, etc.)
• transport protocol (RTP/UDP/DCCP, etc.)
• format / encoding of the media (H.320, etc.)
• media address (multicast group or remote address for unicast)
• (remote) transport port for media
• Information needed to receive those media (addresses, ports, formats, etc.)
• Information about the bandwidth to be used by the session
• Contact information for the person responsible for the session
The following table provides a more detailed overview of the information contained in an SDP
session description.

SDP Explanation
Field
Code
v SDP protocol version
o session originator and (unique) session identifier
s session name
i session/media information (for humans)
u to further information about the session
e address of person responsible for the session
p phone number of person responsible for the session
c connection information

© ESS Consortium 2009 73


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

SDP Explanation
Field
Code
b bandwidth for session or media – e.g. CT:128 = maximum overall bandwidth of
128 kilobits/second
t time interval the session is active (given as NTP times) – useful for offering ses-
sions with finite lifetime
r repeat times – if the session is periodically available
z time zone adjustments – to handle change from daylight saving time to standard
time or vice versa in periodical sessions
k encryption key – use is not recommended, other means outside of SDP should
be used
a session or media attribute, also used for providing media type specific parameter
values (like format and bandwidth)
m media description (media type, transport protocol and format)

Table 3: Fields used in the Session Description Protocol

The following figure provides an example of a video-streaming session described with SDP.
v=0
o=- 2890844526 2890842807 IN IP4 stream.server.com
s=
i=video stream from sensor S01872
c=IN IP4 84.125.96.184
t=34750944003475137600
m=video 49170 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 sampling=YCbCr-4:2:2; interlace=1; width=720; height=480
Figure 31: Exemplary SDP session description

In this example, SDP as defined in IETF RFC 4566 is used (v=0). The unique identifier for
the session is the string “- 2890844526 2890842807 IN IP4 stream.server.com”. No specific
name has been assigned to the session (s= ). However, the information that the session is
about a video stream from sensor S01872 is provided and could be displayed on the client.
The video stream can be accessed via the Internet from the IPv4 network IP address
84.125.96.184. The session is valid from 2010-02-15T00:00:00Zto 2010-02-15T12:00:00Z
(t=3475094400 3475137600). The service provides access to the video stream via RTP - to
be exact: RTP/AVP (Schulzrinne & Casner, 2003)- on port 49170 (m=video 49170 RTP/AVP
98). The video stream is encoded as a JPEG2000 stream (Futemma, Itakura, & Leung,
2008)!'1#"!59!GEB!#16*3#56$!-5#*!,4!Q/!OMI!@5R-#$65$%QS!)$*+.///&Q////0(!L,-*!3$*21412!194,-65>
#1,9!,9!#"*!NBTU!.///!3#-*56!13!5<3,!$-,=17*7!@19!#"*!5R46#$%QS!5##-18?#*0D!#*<<19+!#"*!2<1*9#!#"5#!im-

74 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

ages are sampled in standard YCbCr 4:2:2 color space, interlaced with 720-pixel width and
480-pixel height.
This description provides enough information for a client to access the video stream. A
streaming server can also include multiple media entries in one session description or in-
clude multiple options (of encoding, clock rate, sampling regime etc.) for one medium, so that
a client can choose the one it prefers.
Various other specifications complement the functionality provided by SDP4. This includes
standards, which add new transport protocols5 and payload types (the encodings used for
streaming media)6. Security measures have also been investigated and standards been pro-
posed to IETF to complement SDP (Andreasen, Baugher, & Wing, 2006), (Arkko, Carrara,
Lindholm, Naslund, & K., 2006).
This concludes our general overview of the Session Description Protocol. We will now inves-
tigate in which other emergency systems SDP has been applied.

-[5? =77$9;"+9'*&'(&1H6&9*&E0%3/%*;4&14,+%0,&

In the ESS system, multiple video sensors will be involved. It is important for ESS to bring
those sensors into the System Architecture. The advertisement of sensor existence as well
as sensor metadata can be achieved using Sensor Web Enablement (SWE) technology (see
chapter 7 - OGC Sensor Web Enablement). Access to sensor data is also provided through
SWE. However, experience with the integration of multimedia data streams in SWE is poor.
The European Project OSIRIS7 experimented with the integration of on-demand and live
video streaming through SWE web services first. This was achieved through the definition of
a rudimentary GML Application Schema for environmental sensing with video cameras and
by leveraging the functionality offered by the Session Description Protocol.
In short, the Sensor Model Language (Botts & Robin, 2007) was used to encode metadata of
the video cameras themselves while metadata of observations made by these cameras was
encoded with the Observation & Measurement (Cox, 2007) as well as SWE Common stand-
ards (Botts & Robin, 2007). The latter provided metadata on the frequency bands that were
captured by the camera and also provided a link to an SDP session description file which
allowed clients to access video streams tailored to their needs and provided to them through
a Sensor Observation Service (Na & Priest, 2007).

4
search for „Session Description Protocol“ on http://www.rfc-editor.org/rfcxx00.html
5
see http://www.iana.org/assignments/sdp-parameters which provides a list of currently reg-
istered protocols that work with SDP
6
see http://www.iana.org/assignments/rtp-parameters which provides a list of currently regis-
tered RTP payload formats (encodings) that work with SDP
7
Open Architecture for Smart and Interoperable Networks in Risk Management based on In-
situ Sensors, http://www.osiris-fp6.eu

© ESS Consortium 2009 75


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-[5@ )'*;$2,9'*,&

Multimedia data streams provided by heterogeneous sensor systems need to be included in


the ESS system. Having interoperable access to stored and live video streams will enable
decision makers to get a better understanding of the current situation on ground. Ultimately,
this will enable a more informed decision making process.
Interoperable and standards based access to on-demand and live multimedia streams can
be achieved through the application of Session Description Protocol technology. The choice
of transport protocols and media encodings is then up to the implementing soft- and hard-
ware, which reflects the reality of deployed sensor systems.
The results of the OSIRIS project showed that SDP technology can be used in combination
with SWE and Emergency Systems. However, further work is needed to adapt these results
to the latest achievements in Sensor Web Enablement technology and distributed system
architectures.

76 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-- !3"((9;&K*('30"+9'*&K*+%3(";%,&
The world of traffic information interfaces cover a wide range of usages from delivering traffic
and travel related information into the car to suites of interfaces covering all data exchange
aspects related to running or traffic control centres (e.g. obtaining data from traffic sensors,
controlling traffic through traffic lights and variable message signs or exchanging data with
other control centres).
Initiatives to produce market agreed interfaces are promoted by government agencies (such
as the U.S. department of transport) and non-profit organizations (such as ITS America or
TISA) around the world, but only few of them have made their way to become a world stan-
dard.
The main two areas in which such standardization efforts are taking places are on supply of
data to drives (mostly through in-car navigation devices) and on the support of Traffic Control
Centres.
An evident gap in the range of existing standards and ongoing standardization efforts is on
the B2B arena, where suppliers of processed traffic information (either government agencies
or commercial organizations) provide their data to application providers who then serve the
data to end user. As most of the suppliers are also delivering traffic information directly to
cars it is likely that this gap will be filled up by expanding the interfaces for supplying data to
the car.
The ESS system cannot be classified to any specific category, as by the nature of its oper-
ation it needs to adapt to existing infrastructure and data availability:
• As a command and control system, it may interface with existing Traffic Control cen-
tres, using a subset of the interfaces defined for traffic control systems. The applic-
ability of these interfaces will differ from territory to territory, depending on the exist-
ence of such traffic control centres and weather they have implemented such stan-
dard interfaces.
• As an application, interested in traffic information, it is likely that ESS could interfaces
with existing commercial and government traffic information feeds. Such information
does already exist in different levels of details and quality in most European count-
ries, but as mentioned before there is no standard interface to obtain this data.
• As a system that is designed to guide and control the movement of people outside of
the endangered area, ESS might use existing infrastructure and interfaces to publish
alerts and guidance information into the car.
The following sections present some of the most used and advanced interfaces and stand-
ards relevant to each of the categories.

© ESS Consortium 2009 77


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

--5- 1277$4&'(&!3"((9;&K*('30"+9'*&+'&H39>%3,&

--5-5- DH1X!.)&

##"#"#"# F-(-&'8.:<-&<>-A.

Traffic Message Channel (TMC) is a technology for delivering traffic and travel information to
drivers. It is typically digitally coded using the FM-RDS system on conventional FM
radiobroadcasts. It can also be transmitted on DAB or satellite radio.
TMC allows silent delivery of high quality accurate, timely and relevant information, in the
language chosen by the user and without interrupting normal services. Services, both public
and commercial, are now operational in many countries worldwide and to date it is probably
the most widely used interface for delivering live traffic information to in-car navigation de-
vices. When data is integrated directly into a navigation system, this gives the driver the op-
tion to take alternative routes to avoid traffic incidents.

##"#"#"5 %-,G(>,'8.H)1-,=).

There are 3 main challenges the RDS-TMC interface addresses:


• Bandwidth limitation – the RDS channel is very limited in bandwidth. The TMC inter-
face needs to compress the data and optimize data transmission to ensure that rel-
evant information is delivered to the end user in due time.
• Location referencing – traffic information is location related. Each piece of information
is related to a certain road at a certain direction. Different navigation systems use dif-
ferent digital maps, with no common standard.
• Multi language support – the information should be delivered to the end user in his
preferred language, independently from the territory he is in. This should enable a
driver from Germany to receive the traffic information in his own language when driv-
ing in France.
These challenges are met by the TMC interface using the following methods:
• Compressing data into small binary structure – the TMS translated the traffic informa-
tion into a list of codes, which are then published in a very efficient binary structure
over the RDS channel. The codes are de-coded and used by the receiving navigation
system.
• Aggregation of the data to incidents – the data in the TMC interface is aggregated
into “incidents”. Each Incident describes a certain abnormality (or expected problems)
in traffic conditions. For example – an incident may describe congestion on a certain
highway between two junctions (junction 4 and junction 7).
• Alert C codes – every type of incident that can be published in TMC is identified using
a unique code that describes the nature of the incident. The Alert-C code may be a
general description (e.g. delay of up to 20 minutes) or may describe the cause for the

78 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

incident (e.g. roadwork or heavy rain). The TMC forum maintains the list of Alert-C
codes.
• Location Table –Ideally, for each country a single location table is defined, in which
the main roads and each major junction on them is identified and given a unique iden-
tifier. This definition should be done according to the RDS-TMC standards and is cer-
tified by the TISA. Each incident published on TMC is referenced to the road network
using these definitions (e.g. between junction 35061 and junction 35062).
• Translation of location table to individual digital maps – every map provider (e.g.
TeleAtlas, NavTeq) maps the road links in his data set to the definitions of the official
location table in each territory.
• Optimization of transmission – as TMC is transmitted using the FM infrastructure; the
data transmitted by each transmitter is filtered to include only information relevant to
the area covered by this transmitter. Furthermore, different incidents are given differ-
ent transmission priority according to the Alert-C code associated with them.
• Usage of codes – the usage of codes (Location table definition, Alert-C codes etc.)
enables the navigation system to translate the incident information to any supported
language, to match the user’s preference.

##"#"#"9 6='(*'&*>I'=>7(.H)1-,=).

The RDS-TMC standard was developed and managed by the TMC forum - a non-profit orga-
nization whose members are service providers, receiver manufactures, car manufactures,
map vendors, broadcasters (public and private), automobile clubs, public authorities and oth-
ers. The standard was published as an ISO standard (ISO 14819, latest update on 2003).
The forum is also the body that maintains the Alert-C codes, and certifies the TMC location
tables.
On 11 November 2007 the TMC-Forum and the TPEG-Forum merged into TISA (Traveller
Information Services Association). TISA has taken over all TMC-Forum activities

##"#"#"$ J(=-&K',-.L-(-K>=).'(*.2>@>='=>7().

Interface benefits:
• RDS-TMC is very widely spread. In most European countries operational RDS-TMC
services are operated by commercial and government agencies.
• Technology for using data provided through TMC is mature and available on the mar-
ket.
• The FM broadcast infrastructure is less likely to be affected by crisis situations than
other communication infrastructure (such as internet or mobile infrastructure).
• If damaged by crisis, FM transmission network can be recovered more easily and
quickly than alternative communication means.
Interface limitations:

© ESS Consortium 2009 79


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

• As it is using a very narrow bandwidth broadcast channel, RDS-TMC is limited in the


amount and complexity of data it can deliver to clients.
• The location table enables reporting data at the granularity of major junction on a
road. More accurate location referencing is not possible.
• Bandwidth limit as well as the usage of location tables for geographical referencing
limits the usability of RDS-TMC on lower level roads and especially on urban envi-
ronments.

##"#"#"D H**>=>7('8.B7@@-(=).

TMC is not the only application offered by RDS. One of the RDS applications that might be of
benefit for ESS systems is the Emergency Warning System (EWS) application, which can be
used for broadcasting emergency warnings to first responders and the general public. These
applications (and similar ones) are widely used in implementation of Early Warning Systems
in the U.S.A and Asia.

##"#"#"E H**>=>7('8.M-K-&-(,-).

Topic Reference
RDS http://en.wikipedia.org/wiki/Radio_Data_System
TMC http://en.wikipedia.org/wiki/Traffic_Message_Channel
DAB http://en.wikipedia.org/wiki/Digital_Audio_Broadcasting
TISA http://en.wikipedia.org/wiki/TISA
TMC standards http://www.iso.org/iso/catalogue_detail.htm?csnumber=36922#
Emergency Warning http://www.ewsradio.com/4-system.html
Systems
Table 4: TMC Information and References

80 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

--5-5< !6EC&

##"#"5"# F-(-&'8.:<-&<>-A.

The Transport Protocol Experts Group or TPEG, was founded in 1997 by the European
Broadcasting Union (EBU). It is a group of experts led by the EBU coming from all areas of
the Traffic and Travel Information businesses, as well as broadcasting. The group developed
the TPEG specifications for transmission of language independent multi-modal Traffic and
Travel Information. Validation of the initial work was undertaken by the part-funded European
Commission TPEG Project which had a 3 year duration.
The TPEG work was partly based on the work done with RDS-TMC, but TPEG data are hu-
man understandable as well as machine-readable.
TPEG technology has been designed to provide a 21st century multimodal Traffic and Travel
Information data protocol for delivering content to the end-user, regardless of location or cli-
ent type in use. A common Location Referencing methodology has been developed to allow
any client device to take advantage of content without necessarily having a location database
installed.
TPEG currently comes in two "flavours". The TPEG binary data format is designed for trans-
mission over Digital audio Broadcasting (DAB) and Digital Multimedia Broadcasting (DMB) or
HD-Radio or any other digital bearer. tpegML is the XML implementation designed for use in
editing systems and delivery via the Internet.
In contrast to RDS-TMC, TPEG is a modular set or toolkit of specifications, offering a wider
range of services to a wider range of users and devices. The TPEG tool-kit contains the fol-
lowing set of applications (either already developed or under development):
• RTM - Road Traffic Message.RTM is an application that deals, as the name says with
traffic information. It is a full application that can encode a wide range of road traffic
information, from accidents, obstructions to congestion and delays.
• PTI - Public Transport Information.PTI is the natural counterpart to RTM, dealing with
public transport from rail, bus to air traffic and ferry services.
• Loc - Location referencing, used in conjunction with applications
• PKI - Parking Information.PKI is an application that will allow information about park-
ing facilities to be transmitted.
• TEC - Traffic Event Compact.TEC is a compact application for traffic event informa-
tion, aimed primarily at dynamic route guidance navigation devices.
• TFP – Traffic Flow and Prediction – enabling the broadcast of detailed current traffic
flow information as well as predicted traffic on roads.
• WEA - Weather information for travellers
• FPI – Fuel pricing information.

© ESS Consortium 2009 81


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

• RPI – Road pricing information.


##"#"5"5 %-,G(>,'8.H)1-,=).

In the early days of the TPEG development applications were designed in two halves. On the
one hand there were coding experts and on the other designers. At that time the primary
focus was on a binary delivery using DAB. With the XML becoming more mainstream it was
very quickly adopted by the TPEG developers who unified the two separate approaches. At
the same time it was clear that XML provided another channel to deliver Traffic and Travel
Information.
More recently TPEG developers have turned to UML to hold the conceptual content and to
build new applications. Current work programmes include building UML extracts that will
automatically generate the XML and binary specifications.
A major difference between TPEG and RDS-TMC is the methods used for location referen-
cing. Although classic, table-based TMC location referencing is supported, other location
referencing, such as TPEG-Loc and AGORA-C (ISO 17572-1, -2 and -3) are also supported.
These methods do not assume the existence of any pre-coded tables describing the road
network in the client application. These methods also enable TPEG to support better granu-
larity of location referencing than offered by TMC Location Table. At the same time the TPEG
location referencing methods do not compromise the map independent principle of TMC,
enabling data provider and client application to operate on different digital maps.
Another important design principle of TPEG is language independence. By using sets of pre-
defined tables, TPEG enables the information provider to code the traffic information into a
set of codes. These codes are then de-coded by the client application and translated to the
relevant language. The client application can display TPEG based data in any required lan-
guage and do not require the data provider to be aware of the languages in which the data is
presented.
As it is not limited by the bandwidth and location referencing limitations of RDS-TMC, TPEG
can support delivery of very detailed and accurate traffic information. This can include current
and predicted travel times or speed as well as TMC style incidents.
TPEG is designed as an open tool-kit that enables the addition of new applications to the
existing ones. The TPEG standard set contains general specification that set up the founda-
tions for all applications (e.g. TPEG LRC – that sets up the foundations for the TPEG location
referencing methods), and specific standards that define the details of specific applications.

##"#"5"9 6='(*'&*>I'=>7(.H)1-,=).

TPEG standards are developed by the Traveller Information Services Association (TISA),
TISA was established as a not-for-profit company (ASBL under Belgian law) to ensure an
international framework for market-driven, coordinated, proactive implementation of traffic
and travel information services and products based on existing standards such as RDS-TMC
and TPEG. It also works towards the development and deployment of future standards and
services.

82 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

TISA has taken over all the activities undertaken by the previous TMC Forum, TPEG Forum
and the German "Mobile.Info" project. It also supports standards that provide elements or
framework for services and products covering traffic and travel information, including roads,
public transport and related information needs such as points of interest, weather and envi-
ronmental information.
TISA’s secretariat is hosted by ERTICO – ITS Europe, although it is financially independent.
TPEG technology is now specified in a suite of worldwide international Standards that have
been adopted by CEN and ISO, which include ISO 18234 and ISO 24530. TPEG PKI is cur-
rently at ISO TS 24530-5 Draft for Comments stage.
Meanwhile the TISA TPEG Applications Working Group continues to support the mainte-
nance and development of these specifications.

##"#"5"$ J(=-&K',-.L-(-K>=).'(*.2>@>='=>7().

Interface benefits:
• TPEG technology is already standardised worldwide and recognised by the Traffic
and car industries as providing the "tool-kit" for delivering all types of Traffic and
Travel Information content by any required delivery channel.
• As TPEG is being implemented in more countries, it is likely that an operational
TPEG service would be supported in most territories ESS will be operated in.
• TPEG is suitable for a variety of transmission channels, such as Digital Radio (e.g.
DAB, HD or satellite radio), Internet, Digital TV (e.g. DVB-x or DMB), GPRS and Wi-
Fi. This feature is of particular importance in the context of ESS as transmission can
be done over channels that are still operational at times of crisis.
• The dual embodiment of TPEG as binary format as well as tpegML, makes TPEG
perfect for environments where the available bandwidth is guaranteed (as is the case
in the scenarios relevant to ESS). In use cases where only narrow bandwidth is avail-
able (either because the broadband communication failed or when the main trans-
mission channel is limited) the binary format is used and when broadband communi-
cation is available tpegML can be used.
• TPEG technology provides human, language independent, content and machine
readable content
• TPEG applications use a common Location Referencing method suitable for all client
devices presenting text or icons on map displays.
• TPEG can be used to report very accurate and detailed traffic information including
predictive values.
• TPEG is an open toolkit that can be used to develop new applications, if such appli-
cations are required for ESS.

© ESS Consortium 2009 83


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Interface limitations:
• Unlike the car and traffic information industry, TPEG is not yet acknowledged as the
leading toolkit for delivering traffic and travel information by government agencies and
traffic control centres integrators.
• TPEG was originally defined as a broadcast interface. This communication model is
less common in the Internet environment where request – response communication
patterns are more natural. Nevertheless, TPEG over IP connections with such a re-
quest response method is being developed.

##"#"5"D H**>=>7('8.M-K-&-(,-).

Topic Reference
EBU http://www.ebu.ch/
DAB http://en.wikipedia.org/wiki/Digital_Audio_Broadcasting
DMB http://en.wikipedia.org/wiki/Digital_Multimedia_Broadcasting
DVA http://en.wikipedia.org/wiki/Digital_Video_Broadcasting
TISA http://www.tisa.org/
TPEG http://www.iso.org/iso/search.htm?qt=18234&sort=rel&type=simple&published=on

AGORA-C http://www.tisa.org/en/news__newsletter/agora-c_iso_news.htm
Table 5: TPEG Information and References

--5-5? =/'3"X)&

##"#"9"# F-(-&'8.:<-&<>-A.

One of the main challenges of traffic information delivery is the location referencing methods.
As different systems are using different digital maps, there is a need to provide a method by
which data suppliers and clients are sharing a common location referencing language. Usu-
ally, this challenge is met by either using geographical reference or by relying on some kind
of agreement between the client and supplier (either by suing an approved reference like
TMC table or by publishing the reference table / network to the client).
AGORA-C provides an “on-the-fly” location referencing method, which is considered a key
technology for many future applications in the fast developing world of telematics, in the first
place for traffic information services and traffic management applications (on both the data
collection and distribution sides), but also for the emergency and other position dependent
services that are a centre of current attention.
On the fly in fact means map-based, where the map database is used as the location table.
An adequate location code is created from the map database on the sender side, transmit-

84 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

ted, and decoded using the map database on the receiver side. On-the-fly coding can be
seen as a next generation location coding, and a future successor to TMC location coding.
One of the problems is that TMC cannot address every location, as locations need to be pre-
coded and stored in location tables. So, while TMC is still in use, a method like AGORA-C
could be used to reference locations that are not part of the major network and for which
messages need to be given less frequently, and that are therefore not included in location
tables. It is expected that only at a later stage TMC referencing might be replaced completely
by on-the-fly-referencing. Another issue is that future extensions of the network covered for
traffic messages may be such that it is not feasible anymore to include all these locations in
location tables. Extension to urban areas is being discussed and may be-come possible
through the use of floating car data.
AGORA-C was adopted by TPEG as one of its location referencing methods.

##"#"9"5 %-,G(>,'8.H)1-,=).

In general the process applied by AGORA-C is as follows:


• The geographical reference on data supplier’s digital map is coded into a series of
geographical points and associated attributes.
• The coded information is sent to the client application.
• The client application decodes the points in reference to its own digital map and as-
sociates the referenced information to the relevant road links.
Although is possible that due to differences between different map vendors and versions the
client application will fail to associated the data with its own digital map, AGORA-C is proved
to achieve more than 95% and in some cases up to 100% hit rate.
AGORA-C has developed an efficient data model that optimizes the bandwidth used by this
method of location referencing.

##"#"9"9 6='(*'&*>I'=>7(.H)1-,=).

AGORA-C is patent protected and is owned by a joint group including Matsushita Electric
Industrial Co., Ltd. (Panasonic), Tele Atlas BV, Siemens AG, and Robert Bosch GmbH.
AGORA-C is an approved ISO standard - ISO 17572-3

##"#"9"$ L-(-K>=).'(*.2>@>='=>7().

Benefits:
• Widely accepted location referencing (adopted by leading standards like TEPG).
• Provides on the fly interoperable location referencing method.
• Good hit rate.
• Efficient.

© ESS Consortium 2009 85


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Interface limitations
• Patent protected and requires users to pay royalties.
• Assumes enough computation power on client side.

86 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

##"#"9"D H**>=>7('8.M-K-&-(,-).

Topic Reference
AGORA-C Patent http://www.wipo.int/pctdb/en/wo.jsp?WO=2009006351&IA=US200
8068675&DISPLAY=DESC
AGORA-C http://www.iso.org/iso/catalogue_detail.htm?csnumber=45962#
Standard
Table 6: AGORA-C Information and References

--5-5@ G7%*OD&

##"#"$"# F-(-&'8.:<-&<>-A.

OpenLR is a recent initiative by TomTom to suggest an alternative royalty-free technology


and open Industry Standard for on the fly location referencing.

##"#"$"5 %-,G(>,'8.H)1-,=).

The main idea of OpenLR is describing a line location completely with a concatenation of
(several) shortest-paths where:
• The concatenation of such shortest-paths shall cover the location completely
• Each shortest-path is specified by information about its start and its end. Start/End in-
formation is combined in so called location reference points (LRPs)
• The LRPs are ordered from the start of the location to the end of the location
• The shortest-path between two subsequent LRPs covers a part of the location
• The concatenation of all such shortest-path(s) is called location reference path
OpenLR requires the digital map used to comply with specific OpenLR requirements (such
as existence and values of functional road class and form of way attributes).
Preliminary tests using OpenLR show good decoding success rates.

##"#"$"9 6='(*'&*>I'=>7(.H)1-,=).

A new initiative not yet standardized or accepted as a location referencing method by any
existing standard.

© ESS Consortium 2009 87


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

##"#"$"$ L-(-K>=).'(*.2>@>='=>7().

Benefits:
• Provides a royalty free alternative to AGORA-C
Limitations:
• A new initiative whose acceptance is yet to be proven.
• Requires the digital map to comply with some OpenLR specifications.

##"#"$"D H**>=>7('8.M-K-&-(,-).

Topic Reference
OpenLR http://www.tomtom.com/page/openLR
Table 7: OpenLR Information and References

--5< K*+%3(";%,&('3&!3"((9;&)'*+3'$&)%*+3%,&

--5<5- \.!)&

##"5"#"# F-(-&'8.:<-&<>-A.

Launched in 1997, the Urban Traffic Management and Control (UTMC) initiative, funded and
led by the UK Department for Transport, developed and trialled an open and modular ap-
proach to the design and implementation of Intelligent Transport Systems (ITS).
Within UTMC systems, a common approach to data management enables the integration
and management of intelligent transport systems including:
• Strategic network management, facilitating timely operator response to changes in
network conditions.
• Comprehensive performance monitoring, allowing the benefits of an ITS strategy to
be measured through pre and post implementation monitoring and analysis.
• Traveller information, to help with accessibility to work, health, leisure and education
via the web, mobile devices, public kiosks and other channels.
• Congestion monitoring, including management of information to enable targeted in-
vestment.
• Streamlined fault management, for all integrated systems, enabling faster fault resolu-
tion and improved
• Equipment availability.

88 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

• Consolidated asset management, a single inventory of ITS equipment.


The adoption of a common approach to data management early in the procurement cycle of
urban ITS, provides a powerful means of migration, preserving existing investment in legacy
systems. New or replacement applications can be introduced as and when needed or afford-
able.
• Framework Technical Specification – development of a framework technical specifi-
cation, which presents the core technical standards recommended for use by UK
Traffic Managers in their systems.
• Objects Registry - provides format standards for shared data (i.e. data communicated
between applications of a UTMC system, or between a UTMC system and an exter-
nal system) through:
• Holding definitions of current UTMC Objects, and making them available to users;
• Receiving submissions for potential new UTMC Objects, and coordinating consulta-
tion as necessary;
• Facilitating contact between Object developers;
• Advising on changes to potential new UTMC Objects;
• Registering new UTMC Objects.
It also provides some guidance on how to configure the exchange of data.

##"5"#"5 %-,G(>,'8.H)1-,=).

UTMC specifications provide a technical infrastructure for the definition and design of UTMC
systems. The specification describes the ways such design should be specified and doc-
umented to be regarded as UTMS compliant.
The UTMC specifications also set up the outline of UTMC architectures, and identify the ap-
plicable standards for interfacing between different types of components in the UTMC archi-
tecture. For the purpose of ESS, the most applicable model is the Centre-to-Centre model
where the standard favours the use of CORBA and XML implementations (through web ser-
vices).
UTMC also sets the framework for the implementation of a common DB for the various appli-
cations and defines the preferred approaches to the implementation of such DB using either
CORBA or XML approaches.
UTMC assumes IP (internet) network as the basis for its communication infrastructure. The
specification also defines the basis for adaptation of wireless communications for parts of
UTMC systems.
The UTMC data object definition includes definitions of objects that are relevant for ESS
such as Traffic Events and Traffic Control objects.

© ESS Consortium 2009 89


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

##"5"#"9 6='(*'&*>I'=>7(.H)1-,=).

The UTMC project is sponsored by the UK department of Transport. UTMC projects around
the UK are required to comply with these specifications.
The UTMC definitions are not an approved standard of any official standardization agency.

##"5"#"$ J(=-&K',-.L-(-K>=).'(*.2>@>='=>7().

Interface benefits:
• In the absence of an official standard for interfaces between Traffic Control Centres,
UTMC definitions provide a detailed infrastructure for the definition of Traffic informa-
tion and control interfaces.
• The UTMC specification set up the normative approach to the design of UTMC com-
pliant systems and interface, but is open enough to allow different implementations
for different use cases.
• UTMC provides a detailed data model for data items related to traffic control and traf-
fic management.
Interface limitations:
• As it allows different implementations, UTMC does not provide an out-of-the-box
compatibility for systems that are compliant with the UTMC standards. It is expected
that two UTMC compliant systems will have to undergo some form of integration pro-
cess before they can work together.
• UTMC is not a wide spread standard and therefore it is unlikely Traffic Control Cen-
tres outside of the UK would use it.

##"5"#"D H**>=>7('8.M-K-&-(,-).

Topic Reference
UTMC http://www.utmc.uk.com/index.php
UTMC technical http://www.utmc.uk.com/technical/index.php
specifications

Table 8: UTMC Information and References

90 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

--5<5< Q!)K6&

##"5"5"# F-(-&'8.:<-&<>-A.

The NTCIP is a family of standards that provides both the rules for communicating and the
vocabulary necessary to support the communication between traffic control centres and be-
tween them and traffic control equipment. It provides interoperability between systems and
equipment provided by different manufacturers. It is designed to allow traffic control to use a
mixture of equipment from different manufacturers, as well as adding new equipment to ex-
isting systems.
To assure both manufacturer and user community support, NTCIP is a joint product of the
National Electronics Manufacturers Association (NEMA), the American Association of State
Highway and Transportation Officials (AASHTO), and the Institute of Transportation Engi-
neers (ITE). Those organizations teamed in 1996 to form the NTCIP Steering Group, which-
has been reorganized as the Joint Committee on the NTCIP, an official Steering Committee
of the FHWA-funded project.
The NTCIP is part of a larger effort to develop a family of ITS standards, which include
(among others) the Traffic Management DataDictionary (TMDD) standard adds additional
vocabulary not contained in NTCIP standards for use by traffic management centres in
achieving their mission critical tasks. Likewise, the Data Dictionary for Advanced Traveller
Information Systems (ATIS) contains vocabulary for transmission to travellers.
NTCIP standards offer increased flexibility and choices for agencies operating transportation
management systems. NTCIP standards usage removes barriers to interagency coordination
and allows equipment of different types and different manufacturers to be mixed on the same
communications line.

##"5"5"5 %-,G(>,'8.H)1-,=).

NTCIP provides communications standards for two types of ITS communications:


• The communication between a traffic control centre system and multiple control or
monitoring devices in the field managed by that centre (C2F communication).
• Messages sent between two or more centre systems (C2C communication). This part
of the standard is more applicable for the purpose of ESS.
NTCIP allows different systems to communicate on the same communication channel – any
number of control centres or end units may communicate using the same communication
channel.
On the C2C communication NTCIP assumes the existence of IP networks (either TCP/IP or
UDP) using a fixed line or a dial up connection. On this bearer, NTCIP uses the following
communication methods:
• Datex (ISO 14827) - using either requires response pattern or subscription pattern of
communication.

© ESS Consortium 2009 91


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

• C2C XML - providing XML based communication using web services architecture,
according to the World Wide Web Consortium specifications. SOAP is also sup-
ported, according to the W3C specifications. These methods are more bandwidth
demanding than the DATEX method but are easier to implement.
• File transfer, over FTP or TFTP, is also implemented in the C2C use case.
On the functional area data dictionaries, NTCIP relies on the definitions of the Traffic Man-
agement Data Dictionary (TMDD), which defines the data dictionaries for the use of traffic
management centres.
The NTCIP standards family also defines in details the transport profiles and sub network
profiles to be used in C2C communications.
The NTCIP also provides guidelines on how to implement and test NTCIP systems and solu-
tion.

##"5"5"9 6='(*'&*>I'=>7(.H)1-,=).

The NTCIP is an industry- and consensus-based open ITS standard, sponsored by the U.S.
DOT Research and Innovative Technology Administration (RITA) ITS Standards Program,
under a cooperative agreement with the following standard organization: : AASHTO, ASTM,
ITE, IEEE and SAE.

##"5"5"$ J(=-&K',-.L-(-K>=).'(*.2>@>='=>7().

Interface benefits:
• NTCIP provides a very clear and detailed standard for Traffic Control Centres com-
munication, covering all aspects of communication. If not used as is, it can provide a
very useful reference in the specification of the ESS standards.
• As the American market adopts it, it is expected that more traffic control centres will
implement this interface. It is not clear however if and how quickly this interface will
be adopted by Traffic Control Centres in Europe.
Interface limitations:
• It seems that the main focus of the NTCIP is in the C2F communication and interop-
erability. Therefore, the parts of this standard that are relevant ESS are limited.
• As this standard deals with connectivity between traffic control centres during their
everyday operation, it assumes existing broadband communication and does not deal
with issues resulting from loss or damage of communication infrastructure.
• The interface is targeted for Traffic Control and management and is not open to addi-
tional applications that might be needed for the purpose of ESS (e.g. alarms, evacu-
ation control).
• It is not clear to what extent the NTCIP addresses location referencing and language
independence issues.

92 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

##"5"5"D H**>=>7('8.M-K-&-(,-).

Topic Reference
NTCIP http://www.ntcip.org/
TMDD http://www.ite.org/standards/TMDD/
Table 9: NTCIP Information and References

--5<5? H"+%V&KK&

##"5"9"# F-(-&'8.:<-&<>-A.

DATEX was designed and developed as a traffic and travel data exchange mechanism by a
European task force set up to standardise the interface between traffic control and informa-
tion centres. It has been the reference for applications that have been developed and imple-
mented in Europe. The existing DATEX network consists of 50 to 60 operational nodes or-
ganised in different network and node types throughout Europe. The majority of nodes are
used for national exchange of data, but some of them support international exchange.
The development of DATEX II was begun in late 2003 and has been supported and partially
funded by the European Commission who see it as playing a fundamental role in the ITS
domain within European states. This role now extends from traffic control centre / road auth-
ority usage to include all types of service provider usage in the ITS domain. Its data content
domain is also now extended from the trunk / motorway / TERN road network to include
urban network information. Thus DATEX II is aimed at a very wide user base, which is far
broader than that of the original DATEX specifications.
The original DATEX specifications suffered from a number of shortcomings, which made it
unlikely to achieve “plug and play” interoperability between DATEX nodes from different
manufacturers. Updating the technology, addressing the interoperability issues and the latest
stakeholder requirements were the key drivers in the development of DATEX II. DATEX II
was not intended to be a rigid set of specifications, but rather one that allowed a degree of
choice and one that was able to evolve to allow stakeholders to exchange additional new
types of information in the future. However, interoperability between disparate DATEX II sys-
tems was still given a high priority.

##"5"9"5 %-,G(>,'8.H)1-,=).

DATEX II offers a platform independent data model that is expandable to cater for additional
needs. The data model is separated to “level A” – a rich “out of the box” data model that can
cater form the majority of needs and “level B” model which enables application to add exten-
sions to the existing “level A”. These models/applications will remain interoperable with “A”
model compliant suppliers/consumers: they can exchange objects structured according to
these enriched models. DATEX II also provides a modelling infrastructure for additional data

© ESS Consortium 2009 93


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

models that are not direct extension of “level A” models (called “level C”). These are not in-
teroperable with “level A” compliant applications.
DATEX II data model is defined using UML, but it supports a conversion process to XML.
DATEX II support two types of push data exchange mechanisms (on event and periodic both
using Web services over HTTP) and one pull mechanism (direct HTTP 1.1 pull mechanism
or Web Services over HTTP).
Information exchanged with DATEX II systems is composed of different basic elements:
• Road and traffic related events (called “Traffic elements”)
• Operator actions
• Impacts
• Non-road event information
• Elaborated data (derived/computed data, e.g. travel times, traffic status)
• Measured data (direct measurement data from equipments or outstations, e.g. traffic
and weather measurements)
In addition there are also Predefined Locations and Measurement Site Table information
exchanged. These are not part of the basic elements, but are required if the corresponding
information in the basic elements is to be understood by a client.
The previous basic elements can be exchanged individually or grouped. For these ex-
changes, the notion of publication is used. There are 4 main publications:
• Situation publication – containing Traffic Elements, Operation action, Impacts and
Non road information events.
• Elaborated data publication – containing Traffic Status, Travel times, Traffic values,
Weather values.
• Measured data publication – containing Traffic Status, Travel times, Traffic values,
Weather values.
• Traffic View publication - containing Traffic Elements, Operation action, Traffic Status,
Travel times, Traffic values, Weather values.
DATEX II is using a variety of location referencing methods, including the usage of TPEG
and TMC methods. DATEX II also support a publication of pre-defined location sets (either
points, linear or Areas) that could then be referenced to in the specific data publications. In-
dividual locations can be defined with several location referencing systems (ALERT-C, geo-
graphic coordinates, TPEG-Loc, etc.): for interoperability, the Supplier and its Clients MUST
use at least one common location referencing system which is a result of an interchange
agreement.
DATEX II assumes that data suppliers and Clients agree on an “interchange agreement”.
This document describes all the information that is needed for the data exchange to take
place, such as Access details (IPs, usernames and passwords), Data exchange (data model
version, operating mode, update mode and location referencing method) and rights and obli-
gations of each party.

94 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

##"5"9"9 6='(*'&*>I'=>7(.H)1-,=).

DATEX II is intended to become a multi-part Technical Specification, maintained by CEN


Technical Committee 278 (Road Transport and Traffic Telematics). There are currently en-
quiries to confirm the first three standardization work items, dealing with the most mature and
widely used parts of DATEX II: the modelling methodology (called Context and Framework)
as part 1, Location Referencing as part 2 and the most widely used DATEX publication for
traffic information messages (called SituationPublication) as part 3.
Subject to modification requirements from the CEN feedback process, the final version
DATEX II v2.0 will then be published in mid 2010. The benefits and limitations of the inter-
face are as follows:
Interface benefits:
• DATEX II provides a well-defined infrastructure of data model and data exchange
models.
• Sponsored by the EU with a growing number of systems around Europe.
• DATEX II provides methods to expand the data model, while still maintaining interop-
erability with systems still using the basic model.
• DATEX II is using a variety of location referencing methods, which allow accurate lo-
cation referencing as well as interoperability with other standards (such as RDS-TMC
and TPEG).
Interface limitations:
• Not yet an approved standard.
• Requires an interchange agreement between data supplier and clients and therefore
do not support “out of the box” interoperability.
• DATEX II assumes existing broadband communication and does not deal with issues
resulting from loss or damage of communication infrastructure.
• Does not address language independence issues.

##"5"9"$ H**>=>7('8.M-K-&-(,-).

Topic Reference
DATEX web site http://www.datex2.eu/
Table 10: DATEX Information and References

--5? K*+%3(";%,&('3&!3"((9;&=77$9;"+9'*,&S]<]T&

As mentioned above, there is an evident gap in standardization for B2B Traffic Interfaces.
One area of standardization, which is applicable also for traffic information, is the supply of
geographically referenced information as information layers to be presented on a map.

© ESS Consortium 2009 95


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

These include KML and WMS – both international standards of the Open Geospatial consor-
tium.

--5?5- ^.O&

##"9"#"# F-(-&'8.:<-&<>-A.

Keyhole Markup Language (KML) is an XML-based language schema for expressing geo-
graphic annotation and visualization on existing or future Web-based, two-dimensional maps
and three-dimensional Earth browsers. KML was developed for use with Google Earth, which
was originally named Keyhole Earth Viewer.

##"9"#"5 %-,G(>,'8.H)1-,=).

The KML file specifies a set of features (place marks, images, polygons, 3D models, textual
descriptions, etc.) for display in Google Earth, Maps and Mobile, or any other 3D earth
browser (geobrowser) implementing the KML encoding. Each place always has a longitude
and latitude.
KML files are very often distributed in KMZ files, which are zipped files with a .kmz extension.
The contents of a KMZ file are a single root KML document (notionally "doc.kml") and op-
tionally any overlays, images, icons, and models referenced in the KML including network-
linked KML files. The root KML document is typically a file named "doc.kml" at the root direc-
tory level but the first .kml file entry in the KMZ file is the actual one selected in Google Earth
regardless of its name. By convention the root KML document is at root level and referenced
files are in subdirectories (e.g. images for overlay images), but this is not required.
The main usage of KML for the purpose of traffic information is for producing “level of ser-
vice” maps that represent the traffic situation. This is done using coloured lines on each side
of the road representing the traffic condition on the corresponding direction of travel. The
colour of the line represents the traffic condition (e.g. red is represents slow traffic and green
represents free flow traffic). The following picture demonstrates such implementation:

96 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 32: KML based level of service map

In KML level of service maps can be implemented in two ways:


• Using images of the level of service maps (raster KML). These images are then over-
laid as an additional layer on top of the basic map.
• By publishing the level of service lines as separate polygons which are then overlaid
on top of the map (vector KML).

##"9"#"9 6='(*'&*>I'=>7(.H)1-,=).

KML is an international standard of the Open Geospatial Consortium.

##"9"#"$ J(=-&K',-.L-(-K>=).'(*.2>@>='=>7().

Interface benefits:
• A main stream, widely used open standard interface.
• Easy to implement and integrate.
• Level of service map does not require any location referencing and do not rely on the
existence of any digital map on the client application.
Interface limitations:
• The interface provides the processed map or vectors without the underlying data that
was used for generating this map. This limits the usage the client application can do
with the data (data cannot be used for purposes other than presentation).
• Although vector KML provides a bit more details as each polygon represents a spe-
cific segment of road, the polygons are not referenced to any digital map, so the in-
formation cannot be used for calculations such as route finding or travel time calcula-
tions.
• Not a very efficient protocol and therefore requires large bandwidth to support rea-
sonable performance.

##"9"#"D H**>=>7('8.M-K-&-(,-).

Topic Reference
OGC http://www.opengeospatial.org/
KML Specifica- http://www.opengeospatial.org/standards/kml/
tions
Google KML http://code.google.com/apis/kml/documentation/
Documentation

© ESS Consortium 2009 97


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Table 11: KML Information and References

--5?5< P.1&

##"9"5"# F-(-&'8.:<-&<>-A.

The OpenGIS® Web Map Service Interface Standard (WMS) provides a simple HTTP inter-
face for requesting geo-registered map images from one or more distributed geospatial data-
bases. A WMS request defines the geographic layer(s) and area of interest to be processed.
The response to the request is one or more geo-registered map images (returned as JPEG,
PNG, etc) that can be displayed in a browser application. The interface also supports the
ability to specify whether the returned images should be transparent so that layers from
multiple servers can be combined or not.

##"9"5"5 %-,G(>,'8.H)1-,=).

As with KML, WMS is used in the context of traffic information to supply level of service
maps. These are delivered as transparent map layers; similar to the way it is done with KML
images.

##"9"5"9 6='(*'&*>I'=>7(.H)1-,=).

WMS is an international standard of the Open Geospatial Consortium.

##"9"5"$ J(=-&K',-.L-(-K>=).'(*.2>@>='=>7().

WMS is similar in its benefits and limitations to the KML.


WMS may provide better performance than KML as it is more efficient.
The usage of WMS is less widespread than KML (especially among non GIS application de-
velopers).

##"9"5"D H**>=>7('8.M-K-&-(,-).

Topic Reference
OGC http://www.opengeospatial.org/
WMS Specifica- http://www.opengeospatial.org/standards/WMS/
tions

Table 12: WMS Information and References

98 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-< !3"((9;&.%",23%0%*+,&.%+8':,&

-<5- !3":9+9'*"$&0%+8':,&

-<5-5- _'23*"$9,+9;&"*:&Y20"*&D%7'3+%:&K*('30"+9'*&

The oldest way to collect traffic information is by using human reports. People on the ground
report the traffic conditions, as they perceive it to be. These may include official representa-
tives on the ground (such as policemen, road patrols etc), professional reporters or regular
road users. These reports are gathered in a control / operations / editorial centre where they
may be correlated with other reports or verified with other agencies, and supplied to the
users (government agencies, command and control systems or the general public) using
various channels. Pre-planned road works and events may also be considered as belonging
to this category.
The main drawbacks of this type of information are:
• The Information is subjective and not necessarily accurately describes the situa-
tion on the road (the road user may think it is a very serious traffic jam but actually
it causes only 1-2 minutes delay).
• The reports are dependent on the reporters being on the scene. The report may
be delayed (or not happen) if the reporter does not arrive to the scene.
The main benefits of this type of information over other methods are:
• This method provides the cause for the traffic situation (e.g. Traffic jam due to an
accident) and descriptive information from the scene that cannot be obtained in
any other way.
• Relatively simple and do not require any expensive infrastructure.

-<5-5< !3"((9;&.%",23%0%*+&!%;8*'$'/9%,&
The traditional methods to actually measure the traffic on the road network are based on
installing fixed sensor infrastructure beneath, above or along the road. The main technolo-
gies in this category are:
• Cameras – cameras installed near the road. These are usually connected to a control
centre, where the traffic condition observed by the camera is analysed by human op-
erators, or using automated video analysis algorithms. The more advanced imple-
mentations of this method can also supply accurate measurement of traffic speed and
vehicle density on the road.
• Loop detectors – induction loops that are installed beneath the road are used to
measure the traffic speed and the number of vehicles passing the detector. As the
loop is measuring the traffic conditions at the spot it is installed, a series of loop de-
tectors is required in order to provide a complete picture of the traffic along a certain
road segment (usually installed every 500-1000 meters).

© ESS Consortium 2009 99


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

• ANPR cameras – Automatic Number Plate Recognition cameras that are installed
over the road can measure the travel time and number of vehicles passing the stretch
of road between two measurement points. ANPR solution may also be used to pro-
vide origin and destination information (from where to where people are travelling and
what are their travel times).
• Speed detectors – speed detection cameras and radar are also used to measure
traffic.
The common characteristic of these technologies is the fact that they are based on fixed
infrastructure, which is very expensive to install and maintain. In addition to the installation
and maintenance of such infrastructure usually involves obstruction of traffic on the road and
requires careful planning. Therefore, the rollout of these solutions is usually limited to the
most important roads and does not provide an overall coverage of the road network.
Most of the roadside infrastructure is also heavily influenced by weather and light conditions
and is sensitive to maintenance actives on the road (such as road works).

-<5< A$'"+9*/&Z%89;$%&H"+"&

The floating vehicle approach uses a vehicle travelling the road to measure actual travel
times along the road. With more technology and communication installed in the vehicles, this
approach has become in recent years the state of the art approach to measuring traffic con-
ditions. To date floating vehicle approach is applied using two main technologies:
• GPS – obtaining GPS readings from vehicle equipped with GPS devices (usually
from vehicles belonging to fleet management systems). Analysing these readings the
travel routes and travel times of these vehicles are deduced.
• Cellular information – by using information from cellular networks the location and
movement of cellular phones can be identified. Phones that are associated with trav-
elling cars are identified to resolve the car’s route and travel time.
The key success factor for floating vehicle technologies is the number of vehicles monitored.
These technologies can cover any road, as long as they have a big enough sample of cars
along this road. The bigger the sample size is the more accurate is the measurement.
Because it is more likely to have probe car on a road travelled by more cars, these technolo-
gies usually provide better coverage on the roads where there is lots of traffic. This feature is
specifically important to emergency situations where a secondary road, where fixed infra-
structure is not available, may become the main evacuation route.
As these technologies are not reliant on any roadside infrastructure they are much cheaper
to install and maintain.
IITS is a world leading pioneer in the usage of floating vehicle data for traffic information: It
launched the world first commercial GPS based floating vehicle solution in the UK and since
2004 has been installing cellular based floating vehicle solutions around the globe. Today
ITIS technology is installed in 5 continents and has the largest number of commercial cellular
installations in the world.

100 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-<5? )'002*9+4&#",%:&,'$2+9'*,&

In the last few years, with the penetration of GPS embedded cellular phones and off-board
navigation systems into cars, several community-based initiatives have emerged. These so-
lutions are based on users sharing their locations and travel speeds with other users, to pro-
duce a community-based network of traffic information.
Despite several successful trials, these solutions have not yet managed to prove their ability
to produce a big enough community that will provide an alternative to GPS floating vehicle
data. It is also not clear whether private users will be willing to disclose their locations for
such communities.
ITIS is running a community based solution in the UK using NOKIA N95 phones.

-<5@ )'*;$2,9'*&

Although stated by users as one of the most important data inputs for an emergency support
system, traffic information is not included as an integral part in many emergency support sys-
tems. ESS recognizes the importance of traffic information and puts it as an important, inte-
gral part of its concept and architecture. By doing so, ESS enables a deeper study of emer-
gency commanders’ needs on traffic information that could feed back both industry and re-
search with new requirements and use cases.
To date, most government agencies, traffic control rooms and traffic C4I systems are using
traditional data sources (fixed sensors and journalistic data), owned and operated by the
agency (government agency, police, road operating company). As described above, these
solutions are limited in coverage and costly to operate. Their limited coverage is problematic
in use cases of emergency where a secondary road that is not installed with sensors may
become important. Most emergency support systems are integrated with existing traffic con-
trol systems and therefore are designed to use data obtained from such sources.
ESS is demonstrating the usage of floating vehicle data, and specifically the usage of cellular
based solutions which are the state of the art in this field. These sources offer ESS greater
coverage that can adapt to the changing, un-regular traffic conditions of an emergency situa-
tion.
Furthermore, ESS is demonstrating a concept where traffic information can be obtained not
only from government owned sources, but from commercial systems which are operated
alongside or instead the government owned infrastructure. ESS will promote the usage of
market leading interfaces that could enable those data sources to be fused together into one
consolidated traffic picture. As a world leading supplier of traffic information, ITIS has unique
capabilities in fusing traffic information from various sources including journalistic and human
sources, fixed sensors and floating vehicle data, which provide ESS with a unique and rich
input of traffic information.

© ESS Consortium 2009 101


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-? )%$$&]3'":;",+&1%3>9;%&
This assessment will describe the Cell Broadcast short message service (CBS). It permits to
broadcast information to end-users without having the need for special equipments.

-?5- H%,;397+9'*&

Whereas Short Message Service (SMS) allows delivering messages to one or more specified
mobile phones, Short Message Service Cell Broadcast (or Cell Broadcast Service) permits to
send a single text or binary message to be broadcasted to all mobile phones within a particu-
lar region. Areas involved are known as cell broadcast areas and can be as small as a single
radio cell or big as the entire PLMN and any cluster of areas in between. It is analogous to
the Teletex service offered on television.
The CBS message comprises of 82 octets, which, using the default character set, equates
to93 characters. Up to 15 of these messages (pages) may be concatenated to form a macro-
message.
SMSCB is formatted by/for the SMSCB application, and is intended for customer viewing.
The SMS Cell Broadcast service is also designed to minimize the battery usage require-
ments for a MS.AM Scan read the first part of a CB message and then decide whether or not
to read the rest of the message. In addition, the network may broadcast Schedule Messages,
providing information in advance about the CB messages that will be sent immediately after-
wards. The MS may use this scheduling information to restrict reception to those messages
the customer is interested in receiving. This SMS CBDRX feature is optional inthe network
and the MS.
SMSCB messages may originate from a number of CBEs (Cell Broadcast Entities), which
are connected to the CBC (Cell Broadcast Centre) and then sent from the CBC to the BTSs
(Base Transceiver Station) according with the CBS’s coverage requirements. The MS does
not acknowledge SMSCB messages.
CBS messages are broadcasted cyclically by the BTS at a frequency and for a duration
specified by the information provider. The frequency at which messages are repeatedly
transmitted will be dependent on the information that they contain; for example, it is likely that
dynamic information such as road traffic information will require more frequent transmission
than weather information. The repetition rate will also be affected by the desire for messages
to be received by high-speed mobiles, which rapidly traverse cells.
All suitably equipped mobiles within the catchment area of the transmitting BTS will be able
to receive the broadcast messages, provided that they are switched on, in the idle state and
with cell broadcast channel activated. CBS messages may be broadcast on two different cell
broadcast channels, which are characterized by different QoS. A MS is always able to read
the basic channel and the reading of the extended channel may collide with other tasks of
the MS. Because of this the reading of the extended channel for MSs is optional.
To enable mobiles to selectively display only those messages required by the MS user, CBS
messages are assigned a message class of service, which categorizes the type of informa-
tion that they contain and the language in which the message has been compiled. Each

102 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

message has a serial and version number. Through the use of appropriate MMI (Man Ma-
chine Interface), the user is then able to ignore message types that he does not wish to re-
ceive, e.g. advertising information or messages in an unfamiliar language.
An example of the basic network structure of CBS inside GSM networks is shown in Error!
Reference source not found.. In Error! Reference source not found. there is a Cell
Broadcast Network Structure inside an UMTS network.

Figure 33: CBS structure inside GSM (2G) network

Figure 34: CBS inside UMTS (3G) network

The following table compares Short Message Service Cell Broadcast to the standard Short
Message Service that is used for texting in consumer-to-consumer communication on a daily
basis.

Characteristic Short Message Service Cell Broadcast Message


(SMS) (SMSCB)
Transmission Type Messages sent point-to- Messages sent point-to-area
point
Mobile Number Depend- Dependent. Requires Independent. Does not require

© ESS Consortium 2009 103


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Characteristic Short Message Service Cell Broadcast Message


(SMS) (SMSCB)
ency specific phone numbers to phone number input
be input
Location Dependency Independent. Only pre- Dependent. All numbers within a
registered numbers will be geographical area will be notified.
notified; message can be The Cell Broadcast Service al-
received anywhere. lows messages to be broadcast to
all MS in a given country, all MSs
in a selected group of geographi-
cal locations, or all MSs in a par-
ticular cell area.
Message Type Static messages will be Tailored messages can be sent to
sent to all pre-registered different areas based on the alert
numbers. level for each area.
Bi-directionality Yes. Users can both re- Yes. Two-way messaging is an
ceive and respond directly option that may beprovided by the
to the sender via SMS. CB authoritythrough embedded
numbers or URLs to which the
usermay respond. If using'native'
software then the user must 'click'
on the linkThe phone will then
either phone the number or open-
the WAP browser and go tothe
link.
Congestion and delay Subject to congestion as Broadcasts are sent to a cell area
messages are queued. on dedicated channels, eliminat-
Immense numbers will ing congestion. Delays may only
cause delays. occur in poor coverage areas.
Message Length 140-160 characters in 93 charactersIt is possible to
length Can ‘concatenate’ ‘concatenate’ up to 15 ‘pages’
up to 5 times, advisably. together to produce a single mes-
But it may not be sup- sage of up to80 * 15 = 1200
ported by all mobile ser- ‘bytes’ of data.
vices.
Security Poor authenticity. No indi- Yes, but limited. No reception if
cation that a message is broadcast is sent before mobile is
generated by a legitimate switched on. However, if updates
authority that cannot be to the cell broadcast are sent,
emulated by typing in a they will be received if mobile
text message from an- remains on.
other phone.
Service Barring No barring. Limited. Received only if the-
broadcast reception status is set

104 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Characteristic Short Message Service Cell Broadcast Message


(SMS) (SMSCB)
to “ON”.
Reception Yes. Message Received Yes, but limited. No reception if
once the mobile is switch broadcast is sent before mobile is
on. switched on. However, if updates
to the cell broadcast are sent,
they will be received if mobile
remains on.
Delivery Confirmation Yes. Sender can request No. No confirmation of delivery.
delivery confirmation.

Repetition Rate No repetition rate. Yes. Can be repeated periodically


within 2 second to 32-minute in-
tervals. In a UMTS environment,
the highest repetition rate is 1 s.
Message Storage Yes No. However, the user may
[Most important for first choose to at his/her discretion
responders and gov- should the appropriate firmware
ernment officials re: public be housed on the handset. In
warning] some cases, the message is
placed in a special area of the
inbox and the alarm goes off. In
other cases the message is
flashed straight on the screen and
also placed in the inbox.
Language Identical to all receivers. Multi-language broadcasts can be
broadcast to multiple channels
simultaneously.
Table 13: Comparison of SMSBC and SMS

(Udu-gama, 2009)

-?5< 1;8%:2$9*/&'(&K*('30"+9'*&!3"*,7'3+&

The network supporting the SMSCBDRX feature transmits Schedule Messages. A schedule
Message includes information about a number of immediately following consecutive CB
messages, planned for that cell. The length of time covered by the CB messages referred to
in a Schedule Message is called the Schedule Period of that message. For optimum DRX, a
new Schedule Message should follow the last message of a Schedule Period. When no in-
formation is known about a CB message, e.g., because no Schedule Message has been
received referring to that CB message, a MS shall read (at least) the first part of the CB mes-
sage. Schedule Messages shall be sent on the basic and extended CBCH independently.

© ESS Consortium 2009 105


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

The network may override the published schedule to transmit new high-priority SMSCB mes-
sages. However, after any schedule deviation, the network shall resume the schedule, by
transmitting the scheduled CB messages at the scheduled times listed in the Schedule Mes-
sage. The Schedule Message contains a Message Description for each CB message to be
broadcast during the scheduling period, in order of transmission. The position of a CB mes-
sage is called the "message slot number" of the CB message, and it indicates the position of
the CB message in the schedule period. Each Message Description includes various infor-
mation, including for SMSCB messages directly or indirectly all or part of their message iden-
tifier, and whether an occurrence is a repetition or not .Each Schedule Message includes a
Begin Slot Number field and an End Slot Number field. The End Slot Number field indicates
the length of the schedule period (i.e., specifically the number of CB message slots about
which information is provided). In the case where the network uses Schedule Messages to
describe all message slots in advance, the first Schedule Message of the next schedule pe-
riod will be transmitted in the message slot pointed by End Slot Number plus 1. The Begin
Slot Number is defined to allow the network to broadcast several Schedule Message refer-
ring to the same schedule period. The Begin Slot Number field indicates the message slot
number of the CB message following the received Schedule Message. The networks may
send unscheduled Schedule Messages during empty message slots. The network only
needs to update the Begin Slot Number in an unscheduled Schedule Message to reflect the
current offset within the Schedule Message of the next message to be transmitted.

-?5? Q':%,&'(&)]1&"3;89+%;+23%&

-?5?5- )%$$&#3'":;",+&%*+9+4&

The CBE is responsible for all aspects of formatting CBS, including the splitting of a CBS
message into a number of pages.

-?5?5< )%$$&#3'":;",+&;%*+3%&

The CBC may be connected to several BSCs and to several CBEs. The CBC shall be re-
sponsible for the management of cell broadcast short messages including

• allocation of serial numbers;


• modifying or deleting messages held by the BSC;
• initiating broadcast by sending fixed length cell broadcast short messages to a BSC
for each language provided by the cell, and where necessary padding the message
with the appropriate character to a length of 82 octets;
• determining the set of cells/BTSs to which a message should be broadcast, and indi-
cating within the Serial Number the geographical scope of each message;
• determining the time at which a message should commence being broadcast;
• determining the time at which a message should cease being broadcast and subse-
quently instructing each BSC to cease broadcast of the message;

106 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

• determining the rate at which broadcast of the message should be repeated;


• determining the cell broadcast channel, on which the message should be broadcast.
To work efficiently on the interfaces, the BSC - which is normally controlling more than one
cell of a broadcast area - should be used as a concentrator as far as CB message handling
is concerned. Hence, the CBC should work on lists of cells when issuing CB related requests
towards the BSC.

-?5?5? ]",%&,+"+9'*&;'*+3'$$%3&

In general the BSC is the functional entity within the GSM architecture that is responsible for
RR (Radio Resource) allocation to a Mobile Station, frequency administration and handover
between BTS (Base Transceiver Station) controlled by the BSC. The BSC function may be
physically located with the BTS.
In a Cell Broadcast contest, the BSC shall be responsible for:
• interpretation of commands from the CBC;
• storage of cell broadcast messages;
• scheduling of cell broadcast messages on the CBCH;
• providing an indication to the CBC when the desired repetition rate cannot be
achieved;
• providing to the CBC acknowledgement of successful execution of commands re-
ceived from the CBC;
• reporting to the CBC failure when a command received from the CBC is not under-
stood or cannot be executed;
• routing cell broadcast messages to the appropriate BTSs;
• transferring CBS information to each appropriate BTS via a sequence of 4 SMS
BROADCASTREQUEST messages or 1 SMS BROADCAST COMMAND message
(see GSM 08.58), indicating the channel which shall be used;
• optionally generating Schedule Messages, indicating the intended schedule of trans-
missions;
• optionally receiving CBCH Load Indication messages and reacting by broadcasting a
burst of scheduled SMSCB messages or by suspending the broadcast for a period
indicated by BTS.
To work efficiently on the interfaces, the BSC should forward CB related messages to the
CBC using cell lists as far as applicable.

-?5@ .':%&'(&G7%3"+9'*&

Commands interpreted by the BSC will result in a sequence of 4 SMS BROADCAST


REQUEST messages or 1 SMS BROADCAST COMMAND message being sent to a BTS,
which in turn result in a sequence of 4 messages being transferred via the BTS-MS interface.

© ESS Consortium 2009 107


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

With the SMS BROADCAST REQUEST mode of operation, the 88 octet fixed length CBS
page is split into four octet block which are carried in SMS BROADCAST REQUEST mes-
sages.
With the SMS BROADCAST COMMAND mode of operation, indeed, the BSC sends to the
BTS in one single message the 88 octet fixed length CBS page. The BTS then splits the
page into four 22 octet blocks, adds the sequence number and transmits the four resulting
blocks on the air.

-?5B )'*;$2,9'*,&

The main advantage of Cell Broadcast service is the capability of reaching a lot of users in a
short time without increasing network traffic because messages are not individually indexed
and are sent over traffic channels, which are partially independent of signalling channels.
Cell broadcasting is a timely and efficient means of sending a message to an entire GSM
covered and specific area without the lag times associated with transmitting messages via
SMS, that are queued. Compared with SMS service, it is less vulnerable to congestion and
can reach a broader audience with no privacy infringement. It can now be used for commer-
cial purposes thanks to a growing number of available commercial devices. Cell broadcast is
an easily standardized system since it is a simple technology, universally available regard-
less of mobile communication system, and international standardization will soon be avail-
able through the work of the ITU.
Because of these features SMS-CB messages may be used to send emergency information
towards the area of interest:
• Operators may send information about network status or coverage area (e.g. operator
name, cell information, and so on),
• Other providers to send commercial information or weather reports.
This service could be used in area where, for its characteristics, legacy alert systems like
sirens or loudspeakers can no longer be as effective.
Although TV and radio are fairly ubiquitous, the mobile phone is fast becoming the most
common technology available to all classes. Moreover, the mobile phone is a device that is
available and easily accessible by the majority of people. Although resorts may have a public
announcement system, cell broadcasts received over a mobile phone could be perceived as
less intrusive and cause less panic.

-?5I D%$%>"*+&$9*N,&
http://pda.etsi.org/exchangefolder/gsmts_0341v050300p.pdf

http://pda.etsi.org/exchangefolder/gsmts_0349v050700p.pdf

http://pda.etsi.org/exchangefolder/ets_300943e01p.pdf

http://en.wikipedia.org/wiki/Cell_Broadcast

http://www.gsm-modem.de/sms-cell-broadcast.html

108 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

© ESS Consortium 2009 109


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-@ 1"+%$$9+%&!%;8*'$'/9%,&
Satellite Internet services are used in locations where terrestrial Internet access is not avail-
able and also for users who move frequently. Broadband Internet access via geostationary
satellite is available almost everywhere, including ships and mobile land vehicles. Similar, but
slower Internet service is also available through Low Earth Orbit (LEO) satellites, however
their coverage areas include the polar regions at extreme latitudes, making them truly global.
Bidirectional satellite networks will also be assessed because they actually can be con-
sidered a proven technology to set-up communication infrastructure in emergency conditions
(there is also a relevant FP6 project called WISECOM that make use of this approach).

-@5- H%,;397+9'*&

The system architecture is mainly structured in two separate functional blocks that use the
satellite channel to exchange information (network requests and replies).The core system is
located on the Service Provider site (commonly referred as HUB), which basically allows to
encapsulate the Internet data – by normally using proprietary technology – and to provide the
requested information to the end user, via the satellite transmission channel.
The proprietary technologies used in the satellite networking environment are the standards
involved in the television broadcasting (over terrestrial, cable and satellite channels); those
standards allow to inject audio, video and any other kind of data into the logical data struc-
tures which compose the transmission flow (such as the c Transport Stream for digital televi-
sion providing or the DOCSIS standard). Both the standards mentioned above were and are
already used in satellite communications.
By the other side, there is the client, which system presents a modem satellite equipment to
connect the PC and radio frequency equipment including a dish satellite antenna correctly
oriented to the satellite direction. Finally, there is the satellite transmission channel used to
the information interchange. The figure below shows the components of a typical bidirec-
tional satellite architecture.

110 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 35: bi-directional satellite architecture

-@5-5- 1"+%$$9+%&Y\]&

The HUB is the network satellite structure composed by provisioning and management ser-
vers to provide service administration, resource management and network monitoring. It is
the gateway that manages and controls traffic among satellite network subscribers and the
satellite network.
Additionally to the HUB architecture presented in the figure above, HUB system is supported
by the NOC (Network Operation Centre) system.
NOC is the central location where the company's servers and networking equipment are lo-
cated. The NOC may reside either within a company's campus or at an external location.
Smaller businesses and organizations often have an internal NOC, in which local technicians
administer and monitor the servers. Larger companies may have a NOC setup at a location
developed specifically to house server equipment.
Network operations centres, often called data centres, are almost always connected to a
high-speed Internet connection.

-@5-5< 12#,;39#%3&+%309*"$&

The Subscriber Terminal (ST) is the satellite network endpoint at the customer premises. It
constitutes the interface between the customers’ computing equipment and the satellite net-
work. Its main tasks are down converting downstream signal from RF to baseband, up con-
verting upstream signal from baseband to RF and interconnecting the RF part of the system
with the customer computing equipment via 10/100BaseT Ethernet interface. It is designed
for “zero-touch” provisioning and requires no network-specific configuration; no location-
specific information to be programmed into the modem and no software to be installed and
configured on the customers’ computers.
The Subscriber Terminal includes an Outdoor Unit (ODU) and an Indoor Unit (IDU). These
units are connected by the Intra-Facility Link (IFL), which consists of two cables, one for
transmission and one for reception.
The ODU is similar to a DTH satellite television dish, but with transmit capabilities. It is com-
posed by a satellite reflector and feed, transmit and receive electronics and an associated
mounting kit to affix the unit to the customer’s home. If the service is operated in Ku-band,
the ODU electronics includes a Ku-band feed assembly, a Low Noise Block down-converter
and a Block Up Converter, while in Ka-band it includes a Ka-band feed assembly and a
transceiver with integrated transmission block and LNB.
The IDU mainly consists of a compact Satellite Modem. The SM performs all the processing
functions for the ST: Modulation, Demodulation and MAC-layer processing. It is provided with
10/100 BaseT interface for interconnection with the CPEs LAN and with two interfaces,
transmission and reception, for interconnection with the ODU.

© ESS Consortium 2009 111


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 36: IDU Concept

-@5-5? 1"+%$$9+%&!3"*,09,,9'*&)8"**%$&

The transmission channels use either the satellite television band Ku or the Ka band that
allow to employ smaller satellite dish antennas. The transmission system is a full duplex
asymmetric service with about 2-3 Mb/s of maximum bandwidth in downlink and about 300
kb/s in uplink. The modulation systems used are QPSK and 8PSK on transmission and re-
ception (at the uplink side other modulation systems can be implemented). The error correc-
tion is based on forward error correction (FEC) mechanisms such as Reed Solomon or Turbo
Coding. The latency of the system is estimated in about 600 ms considering delays caused
by distance and by the HUB system process too.

-@5-5@ 1%3>9;%,!'7'$'/9%,&

Typical Internet services supported by a bidirectional satellite system are:


• Browsing HTTP/HTTPS;
• Downloading FTP;
• VoIP: Skype and SIP;
• Video streaming

-@5-5B )39+9;"$&G7%3"+9'*&)'*:9+9'*,&G*&1"+%$$9+%&Q%+`'3N,&

Critical operation conditions on satellite networks are mainly due to the physical operation
environment of the transmission channel by the fact that variability of meteorological condi-
tions can affect strongly the correct operability of the system and cause, in extreme condi-
tions, “out of service” or NLOS (specially on Ka band). This vulnerable operability of satellite

112 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

systems need attention from providers in order to support adequate modulation schemes,
codification mechanisms and specific technologies to protect systems.
Another critical operational condition that affects directly the application performance is the
satellite delay due to propagation times required for a transaction execution. Latency on sat-
ellite systems is averaged in 600 ms, with 250 ms of propagation time and additional oper-
ations process time.

-@5< 1"+%$$9+%&1%3>9;%&63'>9:%3,&

In the European area there are two Service Providers that distribute consumer satellite solu-
tions:
1) SES ASTRA with the ASTRA2Conntect™ system;
2) Eutelsat (with their subsidiary Skylogic) for the Tooway™ system.

-@5<5- =1!D=<)'**%;+™&

ASTRA2Connect™ is a two-way satellite broadband Internet service available across Eu-


rope, which was launched in March 2007, and uses the ASTRA series of geostationary satel-
lites. ASTRA2Connect™ is owned and operated by ASTRA Broadband Services (ABBS), a
subsidiary of SES ASTRA, itself a subsidiary of SES based in Betzdorf, Luxembourg.
ASTRA2Connect™ provides high-speed Internet access (at up to 2Mbit/s) at a flat rate cost
to end users, along with VoIP, IPTV, and content-on-demand facilities, without any require-
ment for a landline, cable or terrestrial wireless connection.
ASTRA2Connect™ uses a satellite link to carry IP data in both directions between the central
HUB and remote terminals. At the HUB, routers connect to the Internet backbone and IP
data is embedded in a DVB-S2 format carrier to be up linked to the satellite from SES
ASTRA’s teleport and, from there, down linked to the remote terminal where the signal is
received with a domestic-type dish for the satellite internet modem, which extracts the IP
data for the end-user’s PC.
The return path is handled in a similar way, but with a low power 500mW transmitter on each
terminal dish providing the uplink to the satellite, with multiple-frequency time division multi-
ple access techniques employed to handle many remote terminals simultaneously.
ASTRA2Connect™ combines 2 standards for the return path: Satmode for modulation and
coding and DVB-RCS for the access scheme.
A Belgian company called Newtec develops the central hub and terminal technology.
ASTRA2Connect™ uses the Astra 1E communications satellite at the 23.5° East orbital posi-
tion to handle uplinks and downlinks in both directions. A number of transponders are used
for the hub-to-terminal downlink in the satellite TV downlink segment of the Ku band
(10.70GHz-12.75GHz). The terminal-to-hub uplink to the satellite uses the uplink segment of
the Ku band (14.00GHz-14.50 GHz) and extended Ku band (13.75GHz-14.25GHz).

© ESS Consortium 2009 113


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-@5<5< !''`"4™&

Tooway™ is a bidirectional satellite broadband Internet service available for consumers


across Europe. The service was launched in 2007 and it use two Eutelsat geostationary sat-
ellites, HOT BIRD 6 at 13° East and EUROBIRD 3at33° East orbital position.
At the moment Tooway™ service allows a downlink up to 3.6Mbps and an uplinkof about
384Kbps at a flat rate price and without the need for a terrestrial connection.

Uplink Downlink
Ka-band 29.5 GHz - 30.0 GHz 19.7 GHz - 20.2 GHz
Ku-band 12.75 GHz - 14.5 GHz 10.7 GHz - 12.75 GHz
Table 14: Tooway Uplink / Downlink Frequencies

In 2010 Eutelsat will launch KA-SAT, the first European high-capacity multi-beam satellite in
Ka-band. KA-SAT will be positioned at 13° East, Eutelsat's prime orbital position and will be
dedicated to delivering Tooway™ broadband and broadcast services toward Europe and the
Mediterranean Basin.
Tooway™ and the ViaSat SurfBeam™ technology are optimized for Ka-band. This band is
approximately twice as high in frequency as Ku-band which implies a smaller but more pow-
erful beam, which contributes towards smaller end-user terminals.
Smaller beams also imply better individual coverage that ensures a more efficient use of sat-
ellite power on the forward link and improved G/T (Gain-over-Temperature) on the return link.
Smaller beams draw smaller cells on ground (beam footprint), which also permits to gather
more cells in a given service area hence to increase frequency reuse.
Moreover, Ka-band has less interference issues than Ku-band, since there are very few sat-
ellites operating in this frequency today.
In summary, Ka-band offers higher system capacity than Ku-band, which allows increasing
the data rates, the quality of service, the amount of terminals in the system or a combination
of these improvements.
Tooway™ and ViaSat SurfBeam™ also make use of DVB-S2 ACM and VCM technologies.
ACM (Adaptive Coding and Modulation) gathers fading conditions from each terminal and
adapts the signal, the encoding and the modulation to each individual terminal's receiving
condition. This technology allows transmissions with optimized efficiency to each terminal,
without degenerating the efficiency of the whole network. A return channel is required on the
end-user terminal to notify fading condition changes.
VCM (Variable Coding and Modulation) does not require a return channel and does not ad-
apt to fading conditions in real-time. Instead a static efficiency is defined for each terminal
according to the availability needed. This technology permits to optimize waveform efficiency
as opposed to CCM (Constant Code and Modulation) which forces to apply the worst link
budget to the entire spot.
In the comparison table below are briefly explained the system features of each solution:

114 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

!! =1!D=<)'**%;+& !''`"4&
KH\&SK*:''3&\*9+T& !! !!
!"#$%&''()# !! !!
L,7?<5#1,9&V,719+! G5#*!W&.D!.&XD!X&YD!Z&PD!P&[D![&S!@\B:]0! G5#*!.&XD!X&YD!Z&PD!S&Q!E?-8,!@SB:]0!
G5#*!W&.D!.&XD!X&YD!Z&PD!S&QD!Q&W/! G5#*!W&.D!.&XD!X&YD!Z&P!E?-8,!@\B:]0!
@\B:]0! V,925#*95#*7!_,-'5-7!T--,-!V,--*2>
G5#*!^D!.&XD!X&YD!Z&PD!S&QD!Q&W/!@SB:]0! #1,9!@_TV0!2,719+!
J75$#1=*!V,719+!H!L,7?<5#1,9!
@JVL0!
L,7?<5#1,9&:2"*65! SB:]!>!\B:]! SB:]!>!\B:]!
:C68,<!G5#*! A`a>:!%!W>YZ!L3$3! Z!b!X/!L3$3!
A`a>:.!%!X>X/!L3$3!
A5#5!G5#*! W>S/!L8$3! Z>[.!L8$3!
*"#$%&''()# !! !!
:JELKATD!UL:]!aE!R!/DZ! G5#*!W&.D!X&Y!E?-8,!
L,7?<5#1,9&V,719+! G5#*!W&.D!.&XD!X&Y!E?-8,!@UL:]0! G**7>:,<,6,9!,?#*-!2,7*!@K$#1,95<0!
L,7?<5#1,9&:2"*65! UL:]! \B:]!
:C68,<!G5#*! >! WP/D!X./D!PY/D!W.S/!,-!.ZP/!O3$3!
A5#5!G5#*! WP/!>!ZW.!O8$3! WZ/!>!XZ//!O8$3!
B*-4,-6592*! !! !!
Gc! >!! P!L8$3!!
Ec! >!! W(Z!L8$3!!
L595+*6*9#! K=*->#"*>51-!3,4#'5-*!H!2,941!+?-5#1,9! d*8!UeF!<,25<!715+9,3#123!597!
?$75#*3D! :fLB>853*7!-*6,#*!
K=*->#"*>51-!6,91#,-19+D!3*<4>#*3#!597! 6595+*6*9#!597!2,9#-,<!
715+9,3#123!
A?5<!35#*<<1#*!2,941+?-5#1,9!3*##19+3!
gJf!F9#*-452*! T#"*-9*#!W/&W//!853*E!@GN>YZ0! T#"*-9*#!W/&W//!853*E!@GN>YZ0!
f*#',-O19+! B-,#,2,<3%! FB!F9#*->9*#',-O19+!
eABD!FBD!FVLBD!FULB=.D!EVBD!JGBD!_EBD! E-593$5-*9#!EVB!597!MEEB!522*<*-5>
AMVBD!Af:!252"19+&-*<5CD! #1,9!
T97>#,>*97!AC95612!G*5<!E16*!\,:!hD! f*#',-O!J77-*33&B,-#!E-593<5#1,9W!
e91253#D!L?<#1253#D! \?5<1#C>,4>:*-=12*!
19#-59*#!3*-=12*3(! g5C*-!.bY!$52O*#!2<53314125#1,9!597!
B*-4,-6592*%! 41<#*-19+!
8?1<#>19!EVB>522*<*-5#1,9D!MEEB!$-*> B*->4<,'!i?*?19+!597!$,<1219+!
4*#2"19+D! :*2?-1#C!
75#5!2,6$-*331,9D!#',>'5C!EVB!*9> _1-*'5<<!'1#"!:#5#*4?<!B52O*#!F93$*2>
2-C$#1,9! #1,9!@:BF0W!

© ESS Consortium 2009 115


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

!! =1!D=<)'**%;+& !''`"4&
V,9#*9#!41<#*-19+!

T44*2#1=*9*33! K$*-5#19+!#*6$*-5#?-*%! K$*-5#1,95<%!/j!#,!lY/j!V!


/!#,!Y/jV! :#,-5+*%!>X/j!#,!lPZj!V!
T;#*-95<!B,'*-!3?$$<C%! M?6171#C%!/!#,!QZm!@9,9>2,97*9319+0!
19$?#! J<#1#?7*%!W/D///!4**#!
.W/>.P/!`JVD!Z/MI! B,'*-!3?$$<C%!SZ!b!.PY!`JVn!Y[!b!PX!
W//>WX/!`JVD!P/MI! MI!
,?#$?#!
WZ!`AV!
L5193!B,'*-!2,93?6$#1,9%!
kX/dD!192<(!$,'*-!2,93?6$#1,9!,4!
KAe(!
!! !! !!
GH\&SG2+:''3&\*9+T& !! !!
J9#*995! [Q!26!@,-!W(.!60! P.!,-!W./!26!
]5!8<,2O! >! K?#$?#!_-*i?*92C%!.Q(Z!b!X/(/!UMI!
F9$?#!_-*i?*92C%!WQ([!b!./(.!UMI!
f,6195<!TFGB%!YS(X!b!ZS(Z!7ad!
V,99*2#1,93! >! E',!G_!2,99*2#,-3!#C$*!_!@4*65<*0!5#!
[Z!,"6!
]?!8<,2O! @1gfa0!K?#$?#!4-*i?*92C%!WYD/!b!WY(Z! K?#$?#!_-*i?*92C%!WY(/!b!WY(Z!UMI!
UMI!3#5975-7!]?!,-!WXD[Z!>!WY!UMI!*;> F9$?#!_-*i?*92C!G59+*%!W/(QZ!b!WW([!
#*97*7!]?! UMID!WW([!b!W.(.!UMI!,-!W.(.Z!b!
F9$?#!4-*i?*92C!%!W/D[!b!W.D[Z!UMI! W.([Z!UMI!
f,6195<!TFGB%!XP!7ad! f,6195<!TFGB%!Y.!b!YP(W!7ad!
V,99*2#1,93! E',!G_!2,99*2#,-3!#C$*!_!@4*65<*0!5#! E',!G_!2,99*2#,-3!#C$*!_!@4*65<*0!5#!
[Z!,"6! [Z!,"6!
B,<5-1I5#1,9! B"C3125<!6,?9#19+! V1-2?<5-!,-!<19*5-!,-#",+,95<!

116 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

!! =1!D=<)'**%;+& !''`"4&
T44*2#1=*9*33! J681*9#!E*6$*-5#?-*%!>X/!#,!lP/jV! J681*9#!E*6$*-5#?-*%!>Y/j!#,!lZZj!V!
d*5#"*-!$-,#*2#1,9%!FBP[! @?$!#,!lS/j!V!3?-=1=5<0!
M?6171#C%!/m!#,!W//m!@2,97*9319+0! M?6171#C%!/!#,!W//m!@2,97*9319+0!
:,<5-!G5715#1,9%!WW./d&6.!65;16?6! G519%!W.([!66&"!@?$!#,[P(.!66&"!
G519%!e$!#,!Y/!66&"! 3?-=1=5<0!
d197%!e$!#,!WS/!O6&"! d197%![.O6&"!
A?3#D!_?9+?3D!:597!597!:5<#!_,+%!
d1#"3#5973!597!,$*-5#*3!'1#",?#!
7*+-575#1,9!19!#"*!$-*3*92*!,4!7?3#D!
4?9+5<!+-,'#"D!3597!597!35<#!4,+!
Table 15: Feature comparison ASTRA2Connect and Tooway

-@5? )'*;$2,9'*,&

Services availability of bidirectional broadband satellite networking systems has been a re-
ality for some years, but till now the cost of the infrastructures and the high investments
needed for this kind of services were something that only enterprises could afford. In the last
two years the situation has gotten much better, because the most important worldwide satel-
lite companies have been making a great effort in trying to transform this kind of technology
into something closer to the consumer world.
The use of satellite broadband networking technology in emergency situations is an import-
ant and very easy way to recover network connections in the disaster areas. To validate this
statement we can consider that, after the Abruzzo earthquake, network connections have
been restored by using the Tooway™ system provided by Eutelsat a few days after the
event. This kind of satellite service together with other terrestrial solutions helped to solve, in
real time, the communications problems due to the earthquake and thanks to the Internet
recovery Civil Protection agency could better face the most urgent problems. According with
this agency some satellite user terminals were installed in homeless camps in order to make
logistics easier.
The main advantage of using these satellites solutions is the easy portability of the system
especially in Ka band, where we can use smaller and more portable dish antennas, whose
advantages are the inexpensiveness and the simplified portability; but for a right evaluation
of the usability of these satellite solutions is very important to consider these system pecu-
liarities:

1. Modulation Parameters Adaptation


2. Bandwidth Management Policy
3. Satellite Signal Propagation Delay
4. Satellite Antenna Pointing
The above-mentioned peculiarities will be briefly described in the following paragraphs.

© ESS Consortium 2009 117


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-@5?5- .':2$"+9'*&7"3"0%+%3,&=:"7+"+9'*&

Satellite communications are affected by moisture and different meteorological conditions


(such as rainfalls, fog, snowfalls, etc.) in the signal path between end-users (or ground sta-
tion) and the satellite. The effects are less serious on the lower frequency (L and C bands)
but can become quite severe on the higher frequency in Ku and Ka band.
Increasing the size of the satellite communication dish so as to gather more of the satellite
signal on the downlink and also to produce a more intense transmission on the uplink can
reduce the amount of time during which the service is lost. Modern consumer dish antennas
tend to be fairly small, which reduces the rain margin or increases the required satellite
downlink power and cost. Satellite broadband systems are intended to allow the modulation
method to be dynamically modified, in response to rain problems or other bad weather condi-
tions. This allows the bit rates to be increased substantially during normal clear sky condi-
tions and to be dynamically reduced in bad weather conditions.

-@5?5< ]"*:`9:+8&."*"/%0%*+&6'$9;4&

To ensure fair Internet access for all subscribers generally a satellite broadband provider
maintains a bandwidth management policy (called, for example, Fair Access Policy – FAP or
Fair Use Policy - FUP). These kinds of policies establish an equitable balance in Internet
access for the subscribers. The provider assigns a download threshold to each service plan
that limits the amount of data that may be downloaded/uploaded during a typical service pe-
riod. A subscriber, who exceeds this limit, will experience a temporary reduction of speed.
The “Fair Policy” is straightforward. Based on an analysis of customer usage data, the ser-
vice provider has established a download threshold for each of the service plans that is well
above the typical usage rates. Subscribers who exceed that threshold will experience re-
duced download/upload speeds.
During this recovery period, the satellite service may still be used, but speeds will be slower.
Web browsing, for example, will be significantly slower than the subscribers’ normal browsing
experience. All the users will return to normal download speeds since the next service period
start. In emergency situations the use of this policy must be disabled.

-@5?5? 1"+%$$9+%&19/*"$&63'7"/"+9'*&H%$"4&

The main problem in a satellite broadband system is the latency. The latency is the signal
propagation delay between requesting data and the receipt of a response. Compared to
ground-based communication, all geostationary satellite communications experience high
latency due to the signal having to travel to an altitude of 35,786km above sea level (from the
equator) out into space to a satellite in geostationary orbit and back to Earth again.
The signal delay, as mentioned above, is about 600ms, which makes this service unusable
for applications requiring real-time user input, such as online games or remote surgery. This
delay can be irritating with interactive applications, such as VoIP, videoconferencing or other
person-to-person communication. The functionality of live interactive access to a distant
computer can also suffer from the problems caused by high latency. However these prob-
lems are more than tolerable for just basic email access and web browsing and in most

118 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

cases they are barely noticeable. This latency problem with satellite communications can be
attenuated with TCP acceleration features that shorten the round trip time (RTT) per packet
by splitting the feedback loop between the sender and the receiver. Such acceleration fea-
tures are present in recent technology developments embedded in new satellite Internet ser-
vices.

-@5?5@ 1"+%$$9+%&=*+%**"&6'9*+9*/&

In emergency situations the antenna pointing can become a problem. In the Ku band system
it is possible to employ the same satellite finder used for television satellite dishes pointing,
because the frequencies used in the downlink channel happen to be the same as satellite
digital television frequencies. In the Ka band system instead we need to use a Spectrum
Analyzer in order to correctly evaluate the antenna position and to perfectly set polarization,
elevation and Azimuth.
It’s important to say that end users must be aware of the different types of satellite communi-
cation systems and the technical issues involving each of them, such as latency and signal
loss due to precipitation, in order to make informed decisions on which system would suit
them best.

-@5@ D%$%>"*+&$9*N,&

http://www.wisecom-fp6.eu
http://www.ASTRA2Connect.com
http://www.tooway.com
http://http://www.viasat.com/broadband-satellite-networks/surfbeam
http://www.etsi.org
http://http://en.wikipedia.org/wiki/Satellite_internet
http://http://www.eutelsat.com/news/compress/en/2009/pdf/PR%203109%20Tooway%203-
6Mbps.pdf

© ESS Consortium 2009 119


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-B Y97%3O=QM<&
This assessment will address an overview of HiperLAN/2 wireless LAN technology.

-B5- H%,;397+9'*&

HiperLAN/2, which stands for High Performance Radio Local Area Network, is a wireless
LAN standard developed by the Broadband Radio Access Networks (BRAN) division of the
European Telecommunications Standards Institute (ETSI). HiperLAN/2 defines a very effi-
cient, high-speed wireless LAN technology that fully meets the requirements of Europe's
spectrum regulatory.
Similar to IEEE 802.11a, HiperLAN/2 operates in the 5GHz frequency band using orthogonal
frequency division multiplexing (OFDM) and offers data rates of up to 54Mbps. In fact, the
physical layer of HiperLAN/2 is very similar to the one that 802.11a defines.
The similarities between 802.11a and HiperLAN/2, however, stop at the medium access con-
trol (MAC) layer. While 802.11a uses Carrier Sense Multiple Access with Collision Avoidance
(CSMA/CA) to transmit packets, HiperLAN/2 uses Time Division Multiple Access (TDMA).
A typical topology could be shown in Figure1:

Figure1: typical HiperLAN/2 topology

Mobile Terminals (MT) can communicate with each other over the air interface using only an
Access Point (AP) intermediate node .
General features of HiperLAN/2 technology are:
High-speed transmission: HiperLAN/2 has a very high transmission rate, which at the
physical layer extends up to 54 Mbit/s. To achieve this, HiperLAN/2 makes use of a
modularization called Orthogonal Frequency Digital Multiplexing (OFDM) to transmit
the analogue signals. This modulation is very efficient in time-dispersive envi-
ronments, e.g. within offices, where the transmitted radio signals are reflected from
many points, leading to different propagation times before they eventually reach the
receiver. Above the physical layer, the Medium Access Control (MAC) protocol is all

120 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

new which implements a form of dynamic time-division duplex to allow for most effi-
cient utlilization of radio resources.
Connection-oriented: in a HiperLAN/2 network, data is transmitted on connections be-
tween the MT and the AP that have been established prior to the transmission using
signalling functions of the HiperLAN/2 control plane. Connections are time-division-
multiplexed over the air interface. There are two types of connections, point-to-point
and point-to-multipoint. Point-to-point connections are bidirectional whereas point-to-
multipoint are unidirectional in the direction towards the Mobile Terminal. In addition,
there is also a dedicated broadcast channel through which traffic reaches all termi-
nals transmitted from one AP.
Quality-of-Service (QoS) support: in HiperLAN/2 each connection can be assigned a
specific QoS, for instance in terms of bandwidth, delay, jitter, bit error-rate, etc. It is
also possible to use a more simplistic approach, where each connection can be as-
signed a priority level relative to other connections. This QoS support in combination
with the high transmission rate facilitates the simultaneous transmission of many dif-
ferent types of data streams, e.g. video, voice, and data.
Automatic frequency allocation: Access Points in HiperLAN/2, have a built-in support for
automatically selecting an appropriate radio channel for transmission within each
AP’s coverage area. An AP listens to neighboring APs as well as to other radio sour-
ces in the environment, and selects an appropriate radio channel based on both what
radio channels are already in use by those other APs and to minimize interference
with the environment.
Security support: HiperLAN/2 network has support for both authentication and encryption.
Mobility support: MT will see to that it transmits and receives data to/from the “nearest”
AP, or more correctly speaking the MT uses the AP with the best radio signal as
measured by the signal to noise ratio.
Network & application independent: HiperLAN/2 is based on flexible architecture to allow
adaptation and integration with a variety of fixed networks.
Power save: a MT save power mechanism is based on MT-initiated negotiation of sleep
periods. It may request the AP to enter a low power state. In this state, the AP will de-
fer any pending data to a MT until its sleep period expires.

-B5< )'00%*+,&(3'0&K*>%,+9/"+'3&

It seems no HiperLAN/2 products are currently available for consumer purchase. Much of
this probably has to do with regulatory issues and big supporters pulling out of the Hiper-
LAN/2 movement. In addition IEEE released the 802.11h revision that make it more suitable
for deployment in Europe, which is where HiperLAN/2 could be dominant if anywhere. Cur-
rently, IEEE 802.11h standard is dominant in commercial scenario.

-B5? D%$%>"*+&$9*N,&

http://www.wi-fiplanet.com/tutorials/article.php/2109571

© ESS Consortium 2009 121


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-I 1%$(X'3/"*9L%:&Q%+`'3N,&
This assessment will address the technologies that can provide a robust and localized alert
distribution system.
In particular assessed technologies will address two requirements for the ESS architecture:
• a data-casting system that can be able to send alerts making an efficient use of the
bandwidth (e.g. using broadcast/multicast approaches)
• a lightweight network infrastructure as backup link (e.g. integrating a terrestrial mobile
radio network with a bi-directional satellite link)
As GSM operator Wind will assess 3GPP’s SMS-CB technology as major solution to the first
problem.
Bi-directional satellite networks will also be assessed because actually can be considered a
proven technology to set-up communication infrastructure in certain conditions (there is also
relevant FP6 project called WISECOM that make use this approach).
Finally it is important to assess emerging technologies that can also be used to set-up light-
weight and reconfigurable network infrastructures (like “ad-hoc networking”).

-I5- H%,;397+9'*&

Effective countermeasures at the earliest stage of disasters cannot be carried out due to lack
of enough information about the disasters. Gathering and transmission of images in disaster
areas can be difficult to accomplish. Continuous macroscopic visual monitoring of buildings
and roads for collapse, spreading of fires, and submergence of land in floods will be essential
to mitigate the disaster beginning at the initial phase. Nation-wide ownership of disaster in-
formation is needed to control and mitigate the disasters.
Cell broadcasting is a service provided by the Mobile Service Providers, which allows text
messages to be broadcast to all mobile handsets in a given geographical area. This area can
be range from the area covered by a single cell to the whole network. Because cell broadcast
works by targeting particular cells and sends SMS to the handsets about the affected region.
For example, data from the meteorological agency will be broadcast to phones from cell
towers. The goal is to give notice to people in the few seconds between an earthquake strik-
ing and the strong shaking waves reaching people.
From Wikipedia:
“Because Cell Broadcast messaging is not affected by traffic load therefore it may be usable
during a disaster when load spikes tend to crash networks, as the 7 July 2005 London bomb-
ings showed. Another example was during the Tsunami catastrophe in Asia where Dialog
GSM (an operator in Sri Lanka was) was able to provide ongoing emergency information to
its subscribers, to warn of incoming waves, to give news updates, to direct people to supply
and distribution centers, and even to arrange donation collections using Celltick's Cell Broad-
cast Center, based on Cell Broadcast Technology.”

122 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Disasters can occur anytime and anywhere. Whether the emergency is an act of nature or an
act of man, the ability to set up and maintain communications throughout the situation is criti-
cal for a successful disaster relief effort.
A disaster relief team requires full communication capabilities, whether in a densely popu-
lated area where there is damage to the terrestrial infrastructure or an isolated location
where there is minimal existing connectivity. Satellite is unaffected by terrestrial issues where
damage to ground equipment can be widespread. Satellite also can provide redundancy and
is easily deployed on short notice. Satellite is a good platform because of territory coverage
and bandwidth. For example mobile phone producer started to commercialize DVB-H hand-
sets. DVB-H can be used to provide digital television and radio news but can be also used to
send data packets using IP multicast.
There are also bi-directional satellite solutions: for example Eutelsat developed a commercial
low-cost product called Tooway™, which can provide the speed of a legacy ADSL link.
WISECOM (Wireless Infrastructure over Satellite Emergency COMmunication) is a FP6
European project where DVB-RCS (Return Channel System) is used to build communication
infrastructure in emergency conditions.
From WISECOM site:
“The system integrates terrestrial mobile radio networks - comprising GSM, UMTS, WiFi, and
optionally WiMax and TETRA - over satellite, using Inmarsat BGAN and DVB-RCS systems.
WISECOM uses lightweight and rapidly deployable technologies, and incorporates location-
based services. The infrastructure is intended to cover immediate needs in the first hours
and days after a disaster event, as well as medium to longer term needs, during the recovery
and rebuilding phase following an emergency.”
Other interesting technologies that can be used to build networks without an usable infra-
structure is based on the use of self-organized networks like ad-hoc (or mesh) networks. The
basic concept in this kind of technology is the fact that every object that use the network
(phones, sensors, UAV, and so on…) is itself a router.
A commercial company called TerraNet AB, for example, as developed an ad-hoc technol-
ogy that enables communications without a regular mobile network.
From TerraNet AB Site:
“Units within such a network can communicate with each other directly up to a certain dis-
tance depending on frequency and the environment. If the distance is larger, the communica-
tion is relayed through one or more of up to seven intermediate units. Consequently, the
network will gradually cover larger and larger areas as more units are connected to it.
A TerraNet network requires no central system, base stations or telecom provider. Every-
thing is handled by the units themselves and the network is formed automatically.
The network can be connected to the rest of the world through a computer network or some
other established network structure. To connect a TerraNet network to a computer, you just
install a gateway and make sure that one of the units in the TerraNet network is within reach
of the computer. To connect it to a traditional telephony network structure, standard methods
of interconnection are applicable.”

© ESS Consortium 2009 123


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-I5< 63'a%;+&.E1=&

Since 2000, the European Telecommunications Standards Institute (ETSI) and the Tele-
communications Industry Association (TIA) established an international partnership to pro-
duce globally applicable technical specifications for digital mobile broadband technology,
aimed initially at the sectors of public safety and disaster response. Project MESA (Mobility
for Emergency and Safety Applications) is the name of this cooperative process developing
new exciting specifications and standards for a series of revolutionary wireless platforms, for
mobile broadband technologies and services. These platforms have been designed to meet
the needs of the world’s public protection, public safety, disaster relief and peacekeeping
agencies or organizations. 0
A significant challenge faced by professionals conducting public protection and disaster relief
(PPDR) operations is solving the problems resulting from incompatible communications sys-
tems, for example between different PPDR organizations (e.g. police, emergency and medi-
cal services, fire fighters). The risk derived from such communications incompatibilities grows
as the scale of the PPDR response increases. In the case of international PPDR responses
to disasters (e.g. flood, earthquake) such communications issues are almost inevitable. Also,
different PPDR scenarios (Indoor, urban, or rural environment; small or wide area scenario;
routine, emergency or disaster situation) with different communications requirements have to
be kept in account. In the case of disastrous situations, local communications infrastructures
could be no longer available or in existence.
Thus, in emergency or disaster scenarios it is fundamental to set-up lightweight and recon-
figurable (and self-organized) network infrastructures, like ad-hoc networks and/or mesh
networks.

-I5? =:&8';&Q%+`'3N,&

Adhoc is Latin meaning “for this purpose.” Ad hoc network therefore refer to a local area
network (LAN) created for a particular purpose and also, by extension, improvised or im-
promptu. That means ad-hoc networks are often created on-the-fly and for one-time or tem-
porary use. They are built spontaneously as devices (a group of workstations or other wire-
less devices) connect and, instead of relying on a base station to coordinate the flow of mes-
sages to each node in the network, the individual network nodes (terminals) exchange pack-
ets each other.
Adhoc networks are generally closed in that they are not connected to the Internet and are
typically created between participants. But, if one of the participants has a connection to a
public or private network, this connection can be shared among other members of the adhoc
network. This will allow other users on the spontaneous adhoc network to connect to the In-
ternet as well.

-I5?5- P93%$%,,&":&8';&*%+`'3N,&

A wireless ad hoc network is a wireless network that does not rely on a preexisting infrastruc-
ture, such as routers in wired networks or access points in managed (infrastructure) wireless
networks. Instead, each node participates in routing by forwarding data of other nodes, and

124 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

so the determination of which nodes forward data is made dynamically based on the network
connectivity. The decentralized nature of wireless ad hoc networks makes them suitable for a
variety of applications where central nodes can’t be relied on. Minimal configuration and
quick deployment make ad hoc networks suitable for emergency situations like natural disas-
ters or military conflicts. The presence of a dynamic and adaptive routing protocol will enable
ad hoc networks to be formed quickly. [2]&
We could image that members of a relief team can keep radio communication with each
other and/or with a close means of relief or drones (unmanned ground/aerial/underwater tele-
operated or autonomous vehicle). A mobile (wireless) ad hoc network is necessary in this
case.

-I5?5< .'#9$%&":&8';&*%+`'3N,&

A mobile (multihop) ad hoc network (MANET) is a self-configuring network of mobile devices


connected by wireless links. Each device in a MANET is free to move independently in any
direction, and will therefore change its links to other devices frequently. Every device must
forward traffic unrelated to its own use, and therefore it must be a router. The primary chal-
lenge in building a MANET is to make it possible for each device to continuously maintain the
information required to properly route traffic.
If a MANET could be sufficient in case of emergency in a small area, it could be not in case
of disaster. When PPDR operations affect wide areas (i. e. flood, fire, earthquake or tsu-
nami), connections with other intervention teams and with remote headquarter(s) are neces-
sary. Also, when large scale operations are carried out, like environmental monitoring or civil
protection at regional, national or international level, a mix of fixed and mobile nodes inter-
connected via wireless links, and connectivity to a public or private network and thus to the
Internet is needed too. So, we should move to mesh networks.

-I5?5? .%,8&Q%+`'3N,&

Mesh networks are ad hoc networks in which most (or all) the component parts are infra-
structure nodes, mobile or not, as opposed to classical ad hoc networks in which all nodes
are terminals that are also willing to route traffic from other terminals nearby. In both cases,
however, the topology of nodes is expected to be more or less dynamic, and could even use
the same protocols.
The mesh topology provides redundant paths between each pair of endpoints, significantly
increasing communications reliability, eliminating single points of failure and potential bottle-
neck links within the mesh. Network resilience and robustness against potential problems is
also ensured by the existence of multiple possible destinations (i.e., any of the egress points
toward the Internet) and alternative routes to these destinations. (Bruno, Conti, & Gregori)
A wireless mesh network (WMN) is a fully wireless network that employs multihop communi-
cations to forward traffic en route to and from wired Internet entry points. Different from flat
ad hoc networks, a mesh network introduces a hierarchy in the network architecture with the
implementation of dedicated nodes (called wireless routers) communicating among each
other and providing wireless transport services to data travelling from users to either other
users or access points (access points are special wireless routers with a high-bandwidth

© ESS Consortium 2009 125


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

wired connection to the Internet backbone). The network of wireless routers forms a wireless
backbone (tightly integrated into the mesh network), which provides multihop connectivity
between nomadic/mobile users and wired gateways. The meshing among wireless routers
and access points creates a wireless backhaul communication system, which provides each
mobile user with a low-cost, high-bandwidth, and seamless multihop interconnection service
with a limited number of Internet entry points and with other wireless mobile users. To sum-
marize, Figure 37 illustrates the mesh network architecture, highlighting the different compo-
nents and system layers. The mesh network architecture addresses the emerging market
requirements for building wireless networks that are highly scalable and cost effective, offer-
ing a solution for the easy deployment of high-speed ubiquitous wireless Internet. (Bruno,
Conti, & Gregori)
Obviously, imaging the necessity to deploy a telecommunications mesh network after a natu-
ral disaster such as an earthquake or tsunami, under the assumption that communications
infrastructures such as fibre backbone and/or trellis are no longer available, the
wired/wireless link to the Internet in Figure 37 could be substituted with a SatCom.

Figure 37: Infrastructure/backbone WMNs

(Akyildiz, Wang, & Wang)

The adoption of peer-to-peer networking to build a wireless distribution system provides all
the advantages of ad hoc networking, such as self-configuration and self-healingness. Con-
sequently, network setup is automatic and transparent to users. For instance, when adding
additional nodes in the mesh, these nodes use their meshing functionalities to automatically
discover all possible wireless routers and determine the optimal paths to the wired network.
In addition, the existing wireless routers reorganize, taking into account the new available
routes. Thus, the network can easily be expanded, because the network self-reconfigures to
assimilate the new elements. (Bruno, Conti, & Gregori)

126 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

The WMN infrastructure/backbone can be built using various types of radio technologies (i.e.
WiMax, Zigbee, Cellular networks, …) in addition to the mostly used IEEE 802.11 technolo-
gies (b/g, a/h). The mesh routers form a mesh of self-configuring, self-healing links among
themselves. With gateway functionality, mesh routers can be connected to the Internet. This
approach, also referred to as infrastructure meshing, provides backbone for conventional
clients with Ethernet interface (they can be connected to mesh routers via Ethernet links) and
enables integration of WMNs with existing wireless networks, through gateway/bridge func-
tionalities in mesh routers.
WMNs will deliver wireless services for a large variety of applications in personal (WPANs),
local (WLANs), campus (WCANs), and metropolitan areas (WMANs). Sensor networks could
be connected too. In addition to the above applications, WMNs can also be applied to Spon-
taneous (Emergency/ Disaster) Networking and P2P Communications. For example, wireless
networks for an emergency response team and fire fighters do not have in-advance know-
ledge of where the network should be deployed. By simply placing wireless mesh routers in
desired locations, a WMN can be quickly established. (Akyildiz, Wang, & Wang)

-I5?5@ ^%4&907$%0%*+"+9'*&3%b293%0%*+,&

Before a network is designed, deployed, and operated, factors that critically influence its per-
formance need to be considered. For WMNs, the critical factors are summarized as follows
(Akyildiz, Wang, & Wang):
• Radio techniques. Driven by the rapid progress of semiconductor, RF technologies,
and communication theory, wireless radios have undergone a significant revolution.
Currently many approaches have been proposed to increase capacity and flexibility of
wireless systems. Typical examples include directional and smart antennas, MIMO
systems, and multi-radio/multi-channel systems. To date, MIMO has become one of
the key technologies for IEEE 802.11n, the high speed extension of Wi-Fi. Multi-radio
chipsets and their development platforms are available on the market. To further im-
prove the performance of a wireless radio and control by higher layer protocols, more
advanced radio technologies such as reconfigurable radios, frequency agile/cognitive
radios, and even software radios have been used in wireless communication.
• Scalability. Multi-hop communication is common in WMNs. For multi-hop networking,
it is well known that communication protocols suffer from scalability issues, i.e., when
the size of network increases, the network performance degrades significantly. Rout-
ing protocols may not be able to find a reliable routing path, transport protocols may
loose connections, and MAC protocols may experience significant throughput reduc-
tion.
• Mesh connectivity. Many advantages of WMNs originate from mesh connectivity
which is a critical requirement on protocol design, especially for MAC and routing pro-
tocols. Network self-organization and self-configuration require all protocols in WMNs
to be distributive and collaborative.
• Broadband and QoS. Different from other ad hoc networks, most applications of
WMNs are broadband services with various QoS requirements. Thus, in addition to
end-to-end transmission delay and fairness, more performance metrics such as delay

© ESS Consortium 2009 127


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

jitter, aggregate and per node throughput, and packet loss ratios, must be considered
by communication protocols.
• Cross layer design. In WMNs, because of the ad hoc feature, network topology con-
stantly changes due to mobility and link failures. For example, the physical channel in
a wireless environment is variable in terms of capacity, bit error rate, etc. Although
different coding, modulation, and error control schemes can be used to improve the
performance of the physical channel, there is no way to guarantee fixed capacity,
zero packet loss rate, or reliable connectivity as expected by higher layers. Therefore,
higher layer protocols will be inevitably affected by the unreliable physical channel.
Such dynamic network topology impacts multiple protocol layers. Thus, in order to
improve protocol efficiency, cross-layer design becomes indispensable. For instance,
a MAC protocol for WMNs may include a mechanism for network topology control
and self-organization. Such information can be directly shared by a routing protocol.
To avoid broadcast storming in a routing protocol, the underlying MAC protocol can
optimize the procedure of transmitting signalling messages initiated by routing proto-
cols.
• Compatibility and inter-operability. It is a desired feature for WMNs to support network
access for both conventional and mesh clients. Thus, WMNs need to be backward
compatible with conventional client nodes; otherwise, the motivation of deploying
WMNs will be significantly compromised. Integration of WMNs with other wireless
networks requires certain mesh routers to have the capability of interoperation among
heterogeneous wireless networks.
• Security. Without a convincing security solution, WMNs will not be able to succeed
due to lack of incentives by customers to subscribe to reliable services. The network
architecture of WMNs is different from a conventional ad hoc network, which causes
differences in security mechanisms. As a consequence, security schemes ranging
from encryption algorithms to security key distribution, secure MAC and routing pro-
tocols, intrusion detection, and security monitoring are needed.
• Ease of use. Protocols must be designed to enable the network to be as autonomous
as possible, in the sense of power management, self-organization, dynamic topology
control, robust to temporary link failure, and fast network-subscription/user-
authentication procedure. In addition, network management tools are needed to effi-
ciently maintain the operation, monitor the performance, and configure the param-
eters of WMNs.
We already wrote that WMN infrastructure/backbone can be built using various types of radio
technologies: IEEE 802.11b/g (WiFi @ 2.4GHz), IEEE 802.11a/h and ETSI HiperLAN/2 @
5GHz, 802.15, 802.16, 802.20… But we cannot forget professional and mobile radio sys-
tems. (ETSI)
A significant part of the Standards work related to Public Safety is in the need for emergency
telecommunications, including many scenarios ranging from a minor road traffic accident to a
major incident like a passenger train crash, a terrorist incident or a natural disaster such as
an earthquake or tsunami. Public safety is enhanced by good communications, whether as a
result of Professional (or Private) Mobile Radio (PMR) or its close relation; Public Access
Mobile Radio (PAMR) or via resilient and secure public [tele-] communications networks.
(ETSI)

128 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Analogue Private Mobile Radio ("#$) has enjoyed great success in Europe for many years,
and serves a very broad community of users. Available for both licensed and unlicensed
spectrum use, PMR applications extend from low-cost walkie-talkies aimed at the consumer
market through to public safety and mission-critical systems. A comparable technology
known as Specialized Mobile Radio (SMR) exists in the United States. (ETSI)
Changes to the professional environment have meant that the operational requirements
placed on communication equipment have evolved, and the traditional analogue service is no
longer able to meet the users' needs completely. A demand for more sophisticated services
has raised a need for a technology enhancement and inevitably this has led to a redefinition
of PMR based on digital technology: the Digital Mobile Radio (DMR). (ETSI)
The technology promises improved range, higher data rates, more efficient use of spectrum,
and improved battery. Significantly, DMR has been designed to fit into existing licensed PMR
bands, meaning that there is no need for re-banding or re-licensing, thus aiding the transition
from analogue to digital. The new standard imposes no fundamental changes in the architec-
ture of either conventional or trunked systems - the focus is on a change in the over-the-air
protocol that will facilitate the use of applications that are beyond the capability of analogue
schemes. (ETSI)
Features supported include fast call set-up, calls to groups and individuals, short data and
packet data calls. The communications modes include individual calls, group calls, broadcast
calls and, of course, a direct communication mode among the mobiles. Other important DMR
functions such as emergency calls, priority calls, full duplex communications, short data
messages and IP-packet data transmissions are supported. (ETSI)
For example, it is possible to find on the market product of Motorola (MOTOTRBO™ Profes-
sional Digital Two-Way Radio System) and the Nexedge family products, based on NXDN,
an European “open proprietary” digital format developed jointly by Kenwood and Icom for
Digital Mobile Radio.

-I5@ )'*;$2,9'*,&

The capability of self-organization in WMNs reduces the complexity of network deployment


and maintenance, and the backbone of WMNs provides a viable solution for users to access
the Internet anywhere anytime. It can also enhance the reliability of the mobile ad hoc net-
work of mesh clients. WMNs enable the integration of multiple wireless networks. WMNs can
be built up based on existing technologies.(Akyildiz, Wang, & Wang)
This makes WMNs really interesting and useful to meet the needs of the world’s public pro-
tection, public safety, disaster relief and peacekeeping agencies or organizations.
Integrating multiple heterogeneous wireless networks is still an on-going task for WMNs, due
to the difficulty in building multiple wireless interfaces and the corresponding gateway/bridge
functions in the same mesh router (there are several mesh router products on the market
anyway, generally with two different kinds of technology radio on board). Use of Software
Defined Radio (SDR) may be the ultimate solution to this problem.
SDR approach could also enable to realize Cognitive Radio (CR). CR is a paradigm for
wireless communication in which either a network or a wireless node changes its
transmission or reception parameters to communicate efficiently avoiding interference with

© ESS Consortium 2009 129


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

licensed or unlicensed users. This alteration of parameters is based on the active monitoring
of several factors in the external and internal radio environment, such as radio frequency
spectrum, user behaviour and network state.
In a natural disaster scenario, it is easy image that it should be very useful to be able to
sense the environment, plan actions according to input from sensors and network policies,
decide which scenario fits best its end-to-end purpose using a reasoning engine, and finally
act on the chosen scenario. Thus, it should be very important to work with a Cognitive Net-
work, that is a network with cognitive process that can perceive current network conditions,
plan, decide, act on those conditions, learn from the consequences of its actions, all while
following end-to-end goals. The system learns from the past (situations, plans, decisions,
actions) and uses this knowledge to improve the decisions in the future.
Cognitive network is different from cognitive radio as it covers all the layers of the OSI model
(not only layers 1 and 2 as with cognitive radio).

-I5B D%$%>"*+&$9*N,&
http://www.projectmesa.org

http://en.wikipedia.org/wiki

http://www.etsi.org/WebSite/Technologies/Technologies.aspx

http://www.wisecom-fp6.eu

http://www.terranet.se/

http://www.tooway.net/

130 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-J 6%'7$%&H%+%;+9'*&"*:&O';"+9'*&=,,%,,0%*+&

-J5- O';"+9*/&6%'7$%&"+&)39,9,&c'*%,&&

Locating people at crisis zone is critical for saving lives and for providing better response
during emergency situations. Knowing how many people are located in the disaster scene is
critical information for decision makers. It is also very important to be able to locate lost peo-
ple in order to help them. Using cellular location technologies can collect this intelligence.
The solution type depends on the viability of the cellular service in the crisis area.

-J5-5- )%$$2$"3&O';"+9'*&9*&)",%&'(&63'7%3&)%$$2$"3&1%3>9;%&

Assuming there is a viable cellular service, which is not damaged due to infrastructure col-
lapse or due to access overload.
Cellular Location-based Applications and Systems (LBS) have experienced growing demand
and interest in the last few years. The driving forces behind this development include:
Emergency services regulations (E911, E112)
• Increased demand from government agencies
• Location-based services as a major revenue promoter
• LBS employ a range of diverse methods and technologies. These include:
• Network-based solutions (for example, Cell ID, Enhanced Cell ID, RF-fingerprints
and U-TDOA)
• Handset-based solutions (for example, GPS)
• Hybrid solutions (network-based solutions combined with handset-based solutions
(for example, E-OTD and A-GPS)
• Because network-based mobile location technologies are handset independent, they
are quite suitable for security and emergency response.
Most of the lawful interception interfaces provide the targets last known Cell ID accuracy
which maybe not fresh and not accurate enough for some operational needs. In order to pro-
vide better accuracy and most fresh location data of the targets’ mobiles, VERINT for exam-
ple, offers the following network-based technologies as its LBS solution:
• Cell ID/ E-CID, as a cost-effective, coarse resolution technology
• RF-Fingerprints or U-TDOA/AOA or A-GPS, as a high-resolution technology
By using these mobile location technologies, government authorities are provided with fresh
and higher location accuracy than the Last known Cell ID accuracy which is returned by most
of the lawful interception interfaces.
The high-resolution technologies are provided as a result of VERINT’s co-operation with
worldwide leading mobile location determination technologies vendors.

© ESS Consortium 2009 131


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 38: Approximate Location Accuracy in GSM networks

The main relevant standards are: 3GPP TS 23 271 for GSM/UMTS and J-STD-036-A for
CDMA. The following figure provides an overview of the general LBS connectivity in GSM
networks.

Figure 39: General LBS Connectivity in GSM

The terminology used in the figure above is as follows:


• A-GPS: Assisted GPS
• AOA: Angle Of Arrival
• CDL: Call Detailed Log
• DCM-Data Base Correlation method
• E-CID: Enhanced Cell ID
• GMLC (GSM/UMTS): Gateway Mobile Location Center. A GSM/UMTS network ele-
ment that mediates location requests between the cellular network and the location-
based applications. The GMLC is connected by map to the cellular core network. The
equivalent in CDMA network is called MPC.

132 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

• LBA: Location Based Application.


• LBS: Location Based Service/System.
• LCS: Location System.
• LMU: Location Measurement Unit. Measures the up-link signal power and phase as
received from a target mobile.
• MO: Mobile Originated
• MPC- Mobile Positioning Centre. A CDMA network element that mediates location
requests between the cellular network and the location-based applications. The MPC
is connected by IS-41 to the cellular core network.
• MS: Mobile Station.
• MT: Mobile Terminated
• PDE: Position Determination Entity. A system that is responsible for the Location
Calculation Function in CDMA networks.
• RAN: Radio Access Network.
• RRC: Radio Resource Control
• SMLC: Serving Mobile Location System. A system that is responsible for the Location
Calculation Function in GSM/UMTS networks. The equivalent in CDMA network is
called PDE.
• UE: User Element.
• U-TDOA: Uplink Time Difference of Arrival

-J5-5< O]1&)'073%8%*,9>%&1'$2+9'*&

LBS comprehensive solution is divided into two complementary domains:


• Passive/Massive Location System
• Active/Selective Location System

#!"#"5"# N'))><-O/'))><-.27,'=>7(.6P)=-@.

Basically, this is a Cell-ID/E-CID (Enhanced Cell ID) data-centric location system based on
VERINT’s robust signalling probes. The passive solution in GSM/UMTS can be extracted to
provide high-resolution location such as RF-Fingerprints location method (also known as
Database Correlation Method-DCM).
The passive/massive location system extracts Cell ID and E-CID location information in real-
time from the CDMA IS-634/IOS4.x interface, GSM-A interface and UMTS-IuB interface
(relying on IuR and Iu interfaces) and provides the last known mobile location.
The real-time location information exists for any type of messaging between the cellular net-
work and the mobiles. These include:
• MT/MO voice call

© ESS Consortium 2009 133


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

• MT/MO SMS
• Active data session
• Active-to-dormant state
• Handover
• Periodic registration
• Location area update
• Power-up and power-down registration
The passive/massive connectivity in GSM/UMTS is shown in the following diagram:

Figure 40: Passive/massive connectivity in GSM/UMTS

#!"#"5"5 H,=><-O6-8-,=><-.27,'=>7(.6P)=-@.

The active/selective location system is a target-centric location system based on standard


GMLC, which is an active entity in the GSM/UMTS core network. It is able to locate any
GSM/UMTS mobile using E-CID. For example, Cell ID and TA (GSM Timing Advance), or
RTT (UMTS Round Trip Time) can be located without having to implement any modifications
in the mobiles and without creating any type of indication in the target mobile. Moreover, the
active/selective location system can be used for high-resolution technologies, such as A-
GPS, U-TDOA and RF-Fingerprints method.
The active/selective connectivity in GSM/UMTS (based on E-CID and U-TDOA) is shown in
the following diagram:

134 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 41: Active/selective connectivity in GSM/UMTS

-J5-5? )'0#9*"+9'*& '(& =;+9>%& "*:& 6",,9>%& !%;8*'$'/4& d& =& )'073%8%*,9>%& O';"+9'*&
A3"0%`'3N&

In high-density areas, the cells are very dense (in 3G the typical cell radius is 50-100 meter)
and this has a positive effect on E-CID/Cell ID location accuracy. However, in order to gain
better location accuracy in dense area and if the height data is also required one can chose
to implement the RF fingerprints method as well.
Although A-GPS is an accurate technology, one should be aware that it is handset-centric
technology and there are few, if any, A-GPS-capable UMTS handsets in circulation. In addi-
tion, it has poor indoor coverage. Finally, it may cause some indication at the MS and there-
fore the silence facility would be lost. For all these reasons, the U-TDOA/AOA or RF finger-
prints are offered as an alternative, high-resolution technology, to A-GPS. U-TDOA and RF
fingerprints methods are absolutely silent to the target mobiles, have high accuracy indoors
and outdoors and are handset independent (this means that it fits all handset types).
The passive/massive location technology is a complimentary technology to the ac-
tive/selective location technology. Although each of these technologies can be supplied
separately, creating an active/passive constellation provides a highly efficient, economical
and flexible mobile positioning mechanism. The advantages of such a configuration are:

© ESS Consortium 2009 135


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

• The active location technology provides immediate location data, indicating where the
mobile is now. The passive location technology provides the very last known location
data, indicating the last known location of the mobile.
• The active location activation rate is limited by the cellular network capacity, whereas
the passive technology performance is not. The hybrid solution overcomes network
capacity limitations because it saves HLR interrogations (the serving MSC is known
from the passive system) and because there is a logical, closed loop between the ac-
tive and passive technologies. For example, the active system can be provisioned by
the active system for each mobile that enters or exits the high-resolution areas.
• The passive technology reduces a customer’s dependency on the switch vendors and
enables them to use the active system in the most efficient manner.
• The active technology may enforce paging interaction with the target and as a result
the E-CID data can be extracted by the passive system immediately, in order to pro-
vide fresh fix information.
• The hybrid constellation enables to apply the RF fingerprints method to idle mobiles
by turning them to active in a silent way (by the GMLC), while taking the RF meas-
urements from the probes.
General active/passive LBS solution in GSM/UMTS is shown in the following diagram:

Figure 42: Active/passive LBS Solution

-J5-5@ .%:9"+9'*&1%3>%3&

Location Mediation Servers perform the combination of the logic of the active/selective and
passive/massive domains. This provides the bridge between location-based applications at

136 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

the monitoring centre (back-end) and the location determination infrastructure at the front-
end. The mediation server gathers and routes location information from the operator's net-
work to the applications.

-J5-5B C.O)&SC"+%`"4&.'#9$%&O';"+9'*&)%*+3%T&

The GMLC is used to obtain fresh on-demand location data through the active/selective do-
main including E-CID, U-TDOA, A-GPS and RF Fingerprints. The GMLC also enables the
fallback from high accuracy technology to mid-low accuracy technology, e.g. from U-TDOA to
E-CID. The GMLC messaging flow is shown in the following diagram.

Figure 43: GMLC messaging flow in UMTS

-J5< )%$$2$"3&O';"+9'*&.%+8':,&&

Although, all location methods are described here in the GSM/UMTS context, they are also
valid for CDMA the difference is in the terminology (e.g. GSM ‘Time advance’ equivalent is
‘CDMA Delay‘).

-J5<5- )%$$&KH&

This network-based, coarse location technology is based on the cell in which the handset is
connected to the centre of mass of the serving cell and sector.
The cell ID uses a simple methodology, as follows. No calculations are required to obtain
location information, which is performed quickly, making it suitable for massive capacity. Its
accuracy depends on cell density, with that in urban area locations being considerably better
than that in rural areas. 3G-cell density is much higher than cell density in 2G, and therefore

© ESS Consortium 2009 137


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

the potential Cell-ID accuracy in 3G is superior. Because of its simplicity, this is currently the
most widely deployed solution.
This technology can be implemented using both passive/massive architecture (based on
VERINT's signalling probes) and active/selective architecture (based on VERINT GMLC and
Switch Interface Collection Devices) for 2G and 3G. A Cell ID, which is the centre of mass of
the serving cell, is shown in the following diagram.

Figure 44: Cell ID

-J5<5< E*8"*;%:&)%$$&KH&SEX)KHT&

Network-based technology, which combines Cell ID with UMTS RTT (Round Trip Time) or
GSM TA (Time advance) is used to improve the coarse accuracy of the Cell ID. RTT/TA is
used to estimate the distance between the cell tower and the mobile station. In 3G, multiple
RTTs are employed due to soft handovers in 3G, which means better accuracy as intersec-
tion and triangulation algorithms can be applied.
This technology can be implemented in passive/massive architecture for 3G (based on VER-
INT's U- probes) as well as in active/selective architecture (based on VERINT GMLC) for 2G
and 3G.
E-CID based on single RTT/TA is shown in the following diagram.

Figure 45: Enhanced Cell ID based on single RTT/TA

E-CID in a 3G soft handover scenario is shown in the following diagram.

138 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 46: Enhanced Cell ID based on 3 RTTs

-J5<5? \7$9*N&!90%&H9((%3%*;%&'(&=339>"$&S\X!HG=T&

U-TDOA is a high-resolution, cellular location technology, which is standardized by 3GPP. It


involves specialized receivers (LMU-Location Measurement Units) that are added to the
base stations. This technology is handset independent and calculates the location of a hand-
set by using the intersection between TDOA hyperbolas from different receivers. At least
three receivers (LMUs) are needed to locate a mobile. The U-TDOA's expected accuracy is
50-70 meters while the 3G U-TDOA accuracy is better than in 2G due to a better time resolu-
tion.
In this technology, the greater the number of measurements, the better the accuracy. The U-
TDOA structure is shown in the following diagram.

Figure 47: U-TDOA principle

© ESS Consortium 2009 139


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-J5<5@ =,,9,+%:XC61&S=XC61T&

An assisted GPS is a system in which outside sources, such as assistance server and refer-
ence network help a GPS receiver to perform the tasks required to make range measure-
ments and to provide position solutions. The assistance server has the ability to access in-
formation from the reference network, while also possessing computing power far beyond
that of the GPS receiver.
The assistance server communicates with the GPS receiver via a wireless link. With assist-
ance from the network, the receiver can operate more quickly and efficiently than it would
unassisted, because a set of tasks that it would normally handle is shared with the assist-
ance server. The resulting A-GPS system, consisting of the integrated GPS receiver and
network components, boosts performance beyond that of the same receiver in standalone
mode.
There are three basic types of data that the assistance server provides to the GPS receiver:
• Precise GPS satellite orbit and clock information
• Initial position and time estimate
• Receivers, satellite selection, range, and range-rate information (for AGPS only)
The assistance server is also able to compute position solutions, leaving the GPS receiver
with the sole job of collecting range measurements. The architecture of an AGPS implemen-
tation compared to a conventional GPS is shown in the diagram below.

Figure 48: A-GPS principle

140 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-R )@K&14,+%0,&
There is very limited standardization in the world of crisis management C4I systems. It is an
issue that is addressed by several task forces around the world. None of these efforts resul-
ted with an accepted standard up to now. On the military arena there are standards defined
by military organization and government agencies, but these are usually classified and there-
fore are not open to the public. The following sections give some examples to the different
types of standards / efforts in this arena. The material is partly copied from web sites, as in-
formation about systems that are of relevant in the military domain is often extremely scarce.
Nevertheless, it has been captured here to shed some light on this important area of system
development and integration.

-R5- KEEE&-B-<&

IEEE 1512 is a Common Incident Management Message Sets for Use by Emergency Man-
agement Centres. IEEE 1512 Base Standard is a family of related standards that address the
intercommunication needs of emergency management centres.
The goal of this family of message standards is to support efficient communication for the
real-time, interagency management of transportation-related events and public safety inci-
dents that require transportation coordination and support.
This standard specifies common incident management message sets to allow vital data ex-
change for information and coordination. It provides a common mechanism for this data ex-
change. This standard is independent of communication protocols used in any local imple-
mentation. It also assumes that the mechanics of communication, such as addressing, are
handled by communication management, which is not addressed in this standard.
Other companion standards will provide specific content and usage guidance for other types
of centres that could participate in a local incident management system. Companion stand-
ards dealing with the unique needs of transportation management, public safety, hazardous
materials centres, and mobile equipment have been developed as well.
The Base Standard specifies messages, data frames, and data elements for the basic under-
lying communication involved in real-time interagency transportation-related incident man-
agement. Together, the Base Standard and companion standards are referred to as the
“IEEE 1512 Family of Standards.”
Clause 6 and Clause 7 of IEEE 1512 present the specified messages, data frames and data
elements in XML formats. A complete set of listing in XML schema are presented in the an-
nexes.
IEEE 1512 standards include a base standard and four companion volumes:
• The Base Standard, IEEE 1512-2000, message sets for traffic management, public
safety and hazardous materials incident response in general.
• IEEE 1512.1-2003, traffic management message sets for transportation and public
safety agencies in transportation incident management.

© ESS Consortium 2009 141


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

• IEEE P1512.2, message sets for interagency coordination, dispatching and asset
management for transportation and public safety agencies.
• IEEE 1512.3-2002, message sets for the management of hazardous materials in
transportation incidents.
• IEEE 1512.4, incident management message sets for mobile equipment for use by
emergency management centres.

The IEEE Vehicular Technology Committee sponsors the IEEE 1512 standards develop-
ment, which is being done under the auspices of the US Department of Transportation.
Future requirements of IEEE 1512 should support object-oriented, Web Services and SOA
development, and it should define: standard “objects” for public safety, standard “message”
to “object” mappings, new extensions for broader safety concepts. It will also be very con-
venient a complementary implementation guide to address Web Services and Service Ori-
ented Architectures.
Incident management message standardisation is no longer a luxury or “nice to have”, it is
essential for accommodating the increased complexity of regional, national or international
incident management of all types, and it is very important the effective adoption of a common
pervasive method for exchanging messages between interested parties.

Topic Reference
IEEE 1512 http://standards.ieee.org/announcements/pr_1512guide.html
Table 16: IEEE 1512 Information and Reference

-R5< 1YKA!&

The SHIFT environment promotes the situational awareness of all the actors in crisis man-
agement, namely, military and civil authorities, international organisations, NGOs and local
actors. SHIFT is not owned by any of the authorities or the interested actors. A SHIFT or-
ganisation, for example, a particular association dedicated to providing SHIFT services, does
not have any operational ambitions; instead, it provides different actors with a forum for open
information sharing.
SHIFT is accessible via the internet and provides authorised users with a wide range of ITC
services, such as a portal, virtual meetings and the ‘Shiftpedia’ where up-to-date and user-
relevant information is gathered, just as in the Wikipedia. SHIFT technology includes a situa-
tion picture that all actors complement. For the situation picture, a culture independent — or
as universal as possible — set of symbols has been developed. The situation picture is con-
sidered to be self-sustainable because it is, as a rule, in the interests of all actors that the
picture is accurate. However, the open system may also leave the way open to misuse. This
is why the developers have carefully examined how to prepare for misuse in the right way.
At national level, the SHIFT principle and technology have been used in preparedness exer-
cises like the Barents Rescue 07 exercise in the wilderness of Lapland. The purpose has

142 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

been to explore ways of using this technology when public authorities, Finnish actors in crisis
areas and NGOs cooperate with each other. Other international tests are linked to MNE5
events in 2008 and 2009 and the Viking 08 exercise in Sweden.
The objective is to make an international breakthrough utilising current technology and trans-
lating it into practical action. The reality is that field-level crisis management and peace build-
ing does not clearly make full use of the possibilities available today. Potential development
steps are huge, which is in fact the biggest obstacle to any advance on the present situation.
People’s working methods and ways of thinking have to change to improve the outcome.
When the needed steps are finally taken, crisis management organisations will wonder about
the odd old times without adequate information exchange in crisis areas.

Topic Reference
SHIFT http://ec.europa.eu/external_relations/ifs/publications/articles/book2/book%20vol2_part2
_chapter22_creating%20comprehensive%20action%20in%20peacbuilding%20-
%20shift_kalle%20liesinen.pdf
http://akseli.tekes.fi/opencms/opencms/OhjelmaPortaali/ohjelmat/Turva/fi/Dokumenttiark
isto/Viestinta_ja_aktivointi/Seminaarit/Seminaarit_2008/Basaari_kansallinen_2008_06_
10/Turva_tilannetietoisuus_final_Virrantaus_2008-06-10.pdf
http://www.uscrest.org/files/mne5.pdf
Table 17: SHIFT Information and References

-R5? K!).&

The Information Technology and Crisis Management (ITCM) project brings together gov-
ernmental, non-governmental and private actors to develop the international community's
capacity to respond rapidly and effectively to humanitarian emergencies and crisis situations.
The project is part of the Crisis Management Initiative's Crisis Management Programme.
The Crisis Management Initiative (CMI) initiated the Information Technology and Crisis Man-
agement (ITCM) project in 2001 to address the identified need to improve the information
sharing practises and communications systems of humanitarian response and crisis man-
agement actors. The ITCM project recognizes security management as the core issue
around which to improve organizational interconnectivity and information sharing.
The ITCM project aims to achieve its overarching aim of enhancing the recovery of popula-
tions affected by crisis, through improving the security of those living and working in the area.
The ITCM-project is a catalytic initiative: by using shared security management solutions,
organisations responding to crisis can shift life-critical resources from ad hoc self-protection
exercises to their core activities of supporting community crisis recovery.

-R5?5- ]";N/3'2*:&

Over the past 15 years, the scale of contemporary international crisis management has in-
creased dramatically. During the Cold War, the international community typically responded

© ESS Consortium 2009 143


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

to comparatively straightforward natural disasters. Today, it routinely engages inpolitically-


sensitive peacekeeping and peace enforcement actions and large-scale, extremely complex,
often interminable, civilian capacity-building operations. As a consequence, today’s crisis
management community consists of many actors: local and national governmental, interna-
tional governmental, intergovernmental, and both international and local non-governmental
organisations, representing disparate sectors with divergent missions and agendas, required
to carry out their charge over an indefinite period of time in the same arena. In these circum-
stances, effective response to crises requires intensified inter-intra-agency and cross-border
co-operation as well as interoperability of management as well as ICT systems among the
responding organisations.
The Brahimi Report to the UN Secretary General in 2000 recognized a core challenge for UN
crisis response agencies. The report called on agencies engaged in peace operations to ad-
apt to information age technologies and practices. Its message was that all crisis response
operations should secure and coordinate appropriate information and interactive communica-
tion technologies to fulfil their missions. According to the report, information technology and
interoperability, as well as knowledge management, are necessary to the success of future
peace operations.
Characterised by high staff turnover and with personnel drawn from many cultures with dis-
parate operating styles, international humanitarian agencies suffer from a lack of organized
institutional knowledge. ICTs offer the ability to capture and manage knowledge gained
through experience. Used appropriately, these technologies can bridge staffing gaps, pre-
serve lessons learned, support continuity of practice, and facilitate the transfer of information
and systems to local actors.
Transforming lessons learned and best practices into institutional knowledge and operational
protocols represents the international crisis response community’s biggest challenge. Among
international agencies, political barriers exist within and between organisations, which pre-
vent effective use of resources. Barriers include competition for funds, an absence of sys-
tematic data collection formats, a lack of trust between organisations, incredulity about the
benefits of information sharing and, finally, the politics of personality. Add to this complex of
issues, the difficulty for commercial providers to work with public sector organisations due to
differences in administrative and financial systems.
On the national front, the complexities increase. Areas affected by crisis often lack physical
and communication infrastructure and many local actors, including governments and civil
society members, suffer lack of skills and access to ICT. Moreover, where new technologies
have been introduced, interoperability with partner organisations is not a prerequisite. Plan-
ning and developing communications systems typically occurs in isolation within international
organizations, with the result that while solutions may meet organisational requirements, they
cannot operate with sister crisis response systems, both local and international. Such a
patchwork of separate systems neither improves information sharing nor guarantees the
safety and security of communities and personnel in high-risk environments.
Security in the broadest sense provides a community focal point engaging all entities (local
government, crisis management actors, and the population at large). Regardless of specific
mandates, skills and resource levels, or institutional approaches, all entities recognise their
fundamental responsibility to safeguard the well-being of populations living in and staff de-
ployed in the crisis area.

144 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-R5?5< =::%:&Z"$2%&

As noted above, political leaders, international organisations and non-governmental organi-


sations need to muster the political will to work together in developing common information-
sharing practices and cooperative management processes in their crisis response efforts.
Increased effectiveness requires leadership that commits to an ethic of professionalism and
to a practice of sharing information.
Currently, no agreement exists about how inter-agency information sharing should be organ-
ised in the crisis arena. Typically, each crisis response organisation operates from a unique
or proprietary platform that acquires and keeps its own security-related information. This
means that not only does each collect information differently from other organisations but
each distributes and thinks about it differently.
Through appropriate use of ICTs, ITCM proposes to introduce new coordination mecha-
nisms, concepts, and information about how to develop operational efficiency and safety of
personnel and the local population. In addition, the project identifies and makes available
information on new ICT initiatives and best practices about information-sharing models
among the community of crisis responders.
Multi-sector partnerships are pivotal to designing and developing solutions that respond to
user needs in the crisis area. ITCM’s value to the effort is its ability to engage actors from
crisis management community and local actors with private sector experts in a combined
effort to improve connectivity and co-operation in crisis environments.

-R5?5? 1+"*:"3:9,"+9'*&

The ITCM-project supports the development of standardised technical solutions and working
practices in crisis management.
Information systems in crisis environments and elsewhere depend on standards - not just in
terms of hardware and software, but also in terms of staff capacity. The international com-
munity therefore needs to move towards standardisation if it is to take full advantage of ICT:
It is standardisation at every stage in the information cycle that will allow information to be
integrated and compared with across different organisations.
The use of open standards in the technical development ensures that new crisis manage-
ment tools are interoperable with each other. The ITCM-project cooperates with the Object
Management Group (OMG), which is a non-profit consortium that produces and maintains
computer industry specifications for interoperable enterprise applications. OMG and ITCM
project organise together bi-annual CREATE meetings, which serve as a platform for the
development of technical and operational standards and establish a more structured cooper-
ation between international organisations and ICT-vendors. For further information, see
http://www.itcm.org.

© ESS Consortium 2009 145


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-R5@ 18"3%:&G7%3"+9'*"$&69;+23%&EV;8"*/%&1%3>9;%,&S1G6E1TR&

During Crisis Response management Operations (CRO), whether those operations occur
during peacetime, crisis, or war, CRO crisis management operation members have a need to
support decision-makers at all levels - from strategic to the target engagement level - with
tactical ground picture information. Existing ground surveillance and reconnaissance systems
currently provide part of the “picture”, or situational awareness to decision-makers and com-
manders. This picture, however, is incomplete, and remains a “patchwork”, with various ele-
ments of relevant information not integrated. Operational inefficiencies in “Operation Allied
Force” (OAF) in Kosovo highlighted the consequences of current C4I systems shortfalls in
fulfilling these requirements. It is therefore of utmost importance that in future coalition oper-
ations all available information, that may be relevant to the production of a decision-quality
tactical ground picture, irrespective of source and type, must be made available to all eligible
participants with actionable information consistent with the military requirement and level of
command.
It is not the vision of the C4I DTF that SOPES would be used to provide information ex-
change at all levels of the command structure: information exchange should take place at the
Component level and then be disseminated throughout the component, as required, utilizing
existing Component C2I Systems. The advantages of SOPES is that it will facilitate the in-
formation exchange through standardization and will expedite the availability and improve the
quality of information available to decision makers.
A particular challenge to the implementation of a SOPES solution will be the requirement to
meet the many security requirements and to ensure that information is only available to those
that the owner of the information has identified as an authorized user. The C4I DTF is work-
ing with the Security SIG and others within OMG to ensure that the appropriate level of se-
curity can be developed to support the realization and implementation of SOPES.

Topic Reference
SOPES http://c4i.omg.org/C4I_SOPES.htm

Table 18: SOPES Information and References

-R5B C$'#"$&)'00"*:&"*:&)'*+3'$&14,+%0&d&_'9*+&SC))1X_TU&

The Global Command and Control System – Joint (GCCS-J) enhances information superi-
ority and supports the operational concepts of full-dimensional protection and precision en-
gagement. It fuses select C2 capabilities into a comprehensive, interoperable system by ex-
changing imagery, intelligence, status of forces, and planning information. GCCS-J provides
a robust and seamless C2 capability to the Combatant Commands, SECDEF, NMCC, CDRs,
JFCs, and Service Component Commanders. GCCS-J offers vital connectivity to the sys-
tems the joint war fighter uses to plan, execute, and manage military operations. GCCS-J is

8
http://c4i.omg.org/C4I_SOPES.htm
9
http://www.disa.mil/gccs-j/

146 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

defined and supported by DISA – the Defence Information Systems Agency in the U.S De-
partment of Defence.
GCCS-J is a Command, Control, Communications, Computer, and Intelligence (C4I) system,
consisting of hardware, software, procedures, standards, and interfaces to provide worldwide
connectivity. The system uses the Defence Information Systems Network (DISN) and must
work over tactical communication systems to ensure connectivity with deployed forces in the
tactical environment. GCCS-J employs an open system client/server architecture that allows
a diverse group of commercial-off-the-shelf (COTS) and government-off-the-shelf (GOTS)
software packages to operate at any GCCS-J location.
The GCCS-J core infrastructure includes the Integrated C4I System Framework (ICSF) that
provides data communications, fusion, and display needs, enabling a full Personal Computer
(PC) client. The infrastructure provides Directory Services, Enterprise Management, Web
Services, Collaboration Services, and Security Services to include anti-viral and encryption
software. The architecture is constructed so that GCCS-J interfaces easily with external sys-
tems to provide data flow to and from GCCS-J and the external systems providing access to
information from the Services, Agencies, and other national assets.
GCCS-J is primarily an integration program and the GCCS-J Program Management Office
(PMO) develops limited mission capabilities in house. It is those mission applica-
tions/capabilities, integrated together with the core infrastructure, that support the GCCS-J
mission areas: Force Deployment/Redeployment, Force Employment, Force Planning, Force
Protection, Force Readiness, Force Sustainment, Cross-Functional/Infrastructure, Intelli-
gence, and Situational Awareness.
With an eye to the future, the DISA program management and engineering teams are ac-
tively engaged with their NCES and NECC counterparts. GCCS-J Block V has adopted an n-
tier, J2EE-based architecture for its applications, thus providing the foundation for smoothly
adopting an NCES-based service-oriented architecture. In addition, for GCCS-J 4.2, GCCS-J
is developing net-centric infrastructure elements such as dynamic discovery, web service
security, and operational context based data provisioning, based on emerging NCES and
NECC standards. As its end-user applications adopt these standards, GCCS-J will move
steadily throughout Block V toward becoming a service-oriented architecture atop early ele-
ments of the future NCES and NECC products.

Topic Reference
DISA http://www.disa.mil
GCCS-J http://www.disa.mil/gccs-j/

Table 19: GCCS-J Information and References

The three GCCS-J baselines are described below:


• Global - The GCCS-J Global Release focuses on migrating the applications that are
fielded in combatant command local environments, such as the Common Operational
Picture (COP), Integrated Imagery and Intelligence (I3), adaptive courses of action,
and others. In addition, the GCCS-J Global Release provides enhanced functional
capabilities in such areas as the Theater Ballistic Missile Defense and dynamic and

© ESS Consortium 2009 147


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

static iCOP (internet COP), as well as increased horizontal integration and access of
intelligence capabilities with the Modernized Intelligence Database.
• JOPES - The Joint Operation Planning and Execution System (JOPES) is an inte-
grated joint command and control system used to support military operation monitor-
ing, planning, and execution activities. JOPES incorporates policies, procedures, per-
sonnel, and facilities by interfacing with Automated Data Processing (ADP) systems,
reporting systems, and underlying GCCS ADP support to provide senior-level deci-
sion makers and their staffs with enhanced capability to plan and conduct joint mili-
tary operations. JOPES procedures and ADP systems are the mechanisms for sub-
mitting movement requirements to USTRANSCOM for Joint operations and exer-
cises.
• SORTS - Status of Resources and Training System (SORTS) is an integrated, auto-
mated reporting and assessment toolset providing vital readiness information needed
to make timely resource allocation and force commitment recommendations to deci-
sion makers. SORTS is the single automated reporting system within DoD that pro-
vides the NCA and the CJCS with authoritative identification, location, assignment,
personnel, and equipment data.

-R5I !";+9;"$&19+2"+9'*&G#a%;+&

This asset has been developed and tested within the OASIS IP. The TSO is supported by an
open-source TSO editor developed by EdiSoft (Portugal). It has been successfully used for
exchanging information between actors involved in emergency management (organizations
and people) and also between the software components of the OASIS system.

-R5I5- H%,;397+9'*&

The Tactical Situation Object (TSO) is a proposed standard for exchanging information dur-
ing disaster and emergency management. Thus, a TSO can describe all sort of events, the
resources engaged in the operation, and the tasks in progress. The data inside the TSO are
in code format that is both computer and human readable and that can be exchanged be-
tween independent systems. Due to this interoperability, these TSO can be transmitted and
displayed in the recipient's preferred format, language or platform.
The first version of the TSO has been defined in the frame of the European Union project
OASIS (Open Advanced System for dISaster & emergency management); then the next ver-
sions have been discussed and set up in the CEN Workshop (the 'Information System for
Disaster and Emergency Management' workshop).

-R5I5< )'00%*+,&(3'0&K*>%,+9/"+'3&

On the one hand, the TSO schema proved its value within OASIS. It has a chance to be-
come a standard. On the other hand, it is not clear if EADS France will continue its work on
supporting and developing TSO.

148 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-R5I5? D%$%>"*+&O9*N,&

http://www.tacticalsituationobject.org/

© ESS Consortium 2009 149


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

-U Z9,2"$&=*"$4+9;,&
The concept and research discipline of Visual Analytics emerged in response to the grand
challenge posed by the overwhelming and rapidly growing amounts of data and information
from numerous sources. This includes such diverse types of data as texts (documents, news,
Web pages, email, etc., databases (corporate, government, scientific, etc.) images and video
(satellite and aerial images, security observation, traffic monitoring, etc.) sensor measure-
ments (environment, medicine, manufacturing, etc.), and many others. People need to make
sense from these oceans of diverse data in order to make right and timely decisions. The
information may be disparate, incomplete, inconsistent, dynamically changing. Among the
massive amounts of data, relevant information content may be hidden in a few nuggets. A
grand challenge is to support the analyst in
• distilling the relevant nuggets of information from disparate information streams;
• understanding the connections among relevant information;
• gaining insight from data.
However, current technologies cannot support the scale and complexity of the growing ana-
lytical challenge. On the one hand, purely automatic analysis procedures are only possible
for well-defined problems whereas most of the real-world problems are ill-defined. Such
problems can only be solved with the participation of human analysts applying their creative
and versatile thinking, imagination, multifaceted knowledge and experience, and common
sense. On the other hand, while the computer performance grows at a rapid pace, basic hu-
man skills and abilities do not change significantly. There are fundamental limits, which are
being asymptotically approached. This means that large-scale problems have to be reduced
to a scale that humans can comprehend and act on. Hence, the advances in the computer
technology by themselves are insufficient. Moreover, they are doomed to be under-utilised
unless principally new solutions are found which fundamentally improve the division of labour
between humans and machines so that the computational power could amplify the human
perceptual and cognitive capabilities. Finding such new solutions is the task of Visual Analyt-
ics.
The term “Visual Analytics” stresses the key role of visual representations as the most effec-
tive means to convey information to human’s mind and prompt human cognition and reason-
ing. As is stated in (McCormick, DeFanti, & Brown, 1987), “An estimated 50 percent of the
brain's neurons are associated with vision. Visualization […] aims to put that neurological
machinery to work”.
Visual Analytics is defined as the science of analytical reasoning facilitated by interactive
visual interfaces (Thomas & Cook, 2005). Visual analytics combines automated analysis tech-
niques with interactive visualizations so that to extend the perceptual and cognitive abilities
of humans and enable them to:
• synthesize information and derive insight from massive, dynamic, ambiguous, and of-
ten conflicting data;
• detect the expected and discover the unexpected;
• provide timely, defensible, and understandable assessments;

150 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

• communicate assessment effectively for action.


Data and problems involving geographical components are an appropriate target for Visual
Analytics (Andrienko G. , et al., 2007).

-U5- C%'/3"789;&=*"$4,9,&

Geographic analysis, or spatial analysis, explicitly takes into account the spatial localization
of the phenomenon under study and various spatial relationships among components of the
phenomenon and between the phenomenon and its environment. Geospatial data are typi-
cally massive and complex, as a consequence of the inherent complexity and heterogeneity
of the geographical space (Andrienko G. , Andrienko, Dykes, Fabrikant, & Wachowicz, 2008).
Geospatial data need to be treated in specific ways taking into account the particular features
of the geographical space, such as spatial autocorrelation, anisotropy, and scale depend-
ence.
As the heterogeneity of the space and the variety of properties and relationships occurring
within it cannot be adequately represented in a machine-oriented form for fully automatic
processing, geographic analysis relies heavily upon the human analyst’s sense of the space
and place, tacit knowledge of their inherent properties and relationships, and space / place -
related experiences. These are incorporated into the analysis through the use of an appro-
priate human-oriented (i.e. visual) representation of the geographical space that serves as an
adequate model of reality. However, the size and complexity of the data and problems re-
quire combining visualisation with computational analysis methods, database queries, data
transformations, and other computer-based operations. The goal is to create visual analytics
environments for synergetic work of humans and computers where the computational power
amplifies the human abilities and is, in turn, directed by human’s background knowledge and
insights gained.

-U5< =*&=77$9;"+9'*e&=*"$4,9,&'(&.'>%0%*+&9*&C%'/3"789;"$&17";%&

Thanks to the recent progress in positioning and tracking technologies, data about various
mobile objects or agents are currently collected in growing amounts. Analysis of such data
can yield valuable knowledge about the behaviours of the moving objects and about the envi-
ronment in which they move.
Traditional approaches to visualization and interactive exploration of movement data, such
as animated map (Andrienko, Andrienko, & Gatalsky, Supporting Visual Exploration of Object
Movement, 2000) or interactive space-time cube (Kapler & Wright, 2005)(Kraak, 2003), cannot
cope with the large amounts of movement data, which are available today. There is a press-
ing need in appropriate visual analytics methods for movement data. Development of such
methods has been a major topic in our recent research. We have used several example
datasets with real movement data of different types:
• data describing movements of a single entity during a long time period;
• data about simultaneous movements of multiple unrelated entities;
• data about simultaneous movements of multiple related entities.

© ESS Consortium 2009 151


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

We have found out that the pertinent analysis tasks significantly differ for these types of data,
as is shown in Table 20.
Table 20: Types of movement data and related analysis tasks

Data Analysis tasks


Movements of a single entity Analysis of the entity’s behaviour: significant
places, times and durations of the visits to
different places, typical trips, times and dura-
tions of the trips, deviations and their reasons
Movements of multiple unrelated entities 1) Studies of space use, accessibility, per-
meability, connectivity, major flows, typical
routes between places
2) Studies of emerging patterns of collective
movement: concentration/ dispersion, con-
vergence/divergence, propagation of move-
ment characteristics etc.
Movements of multiple related entities Studies of relative movements (approaching,
encountering, following, evading, etc.) and
interactions between the entities

Due to the difference of the analysis tasks, each type of data requires its own analytical pro-
cedures. However, some analytical techniques may be applicable to more than one type of
movement data.
Let us consider examples of the three aforementioned types of movement data and the pos-
sible analyses performed with the use of visual analytics techniques.

-U5<5- =*"$4,9,&'(&0'>%0%*+&'(&"&,9*/$%&%*+9+4&

One of the example datasets we have used consists of positions of a private car, which has
been GPS-tracked during about a year. The car owner has voluntarily given the data to us.
An important task in the analysis of individual movement behaviour is extraction of significant
places of the moving agent. In case of data about a person, these are the places of home,
work, shops, school(s) and/or kindergarten(s) attended by person’s child or children, homes
of person’s friends and relatives, etc.
Significance of a place is indicated by considerable amounts of time spent there and/or re-
peated visits to this place. Hence, in order to discover the significant places of some moving
agent, one should extract the stops, i.e. the time intervals when the agent did not move and
the corresponding spatial positions. This can be done by means of database queries. Then
spatial clustering can be applied to the extracted positions of the stops to find the places of
repeated stops. To interpret the places, it is useful to take into account the typical times and
durations of the stops occurring in these places.

152 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 49: The temporal histograms show the weekly (A) and daily (B) distributions of the stops of the
personal car with the duration of 3 hours or more

Thus, to discover and interpret the significant places of the car owner, we have first extracted
the positions of the stops lasting 3 hours or more and applied the spatial clustering tool,
which has produced two major clusters. We have visualised the distribution of the stop times
over the days of a week and the hours of a day by means of segmented histograms with the
segments corresponding to the clusters Figure 49.
In Figure 49A we can see that the stops of cluster 1 (red) occur on all days of the week and
the stops of cluster 2 (blue) occur from day 1 to day 5, i.e. from Monday to Friday. Figure
49B shows us that the stops of cluster 1 occur mostly in the second half of the day; the
maximum occurrences are from 19 to 20 o’clock. The stops of cluster 2 occur mostly in the
morning hours. Such a distribution makes us quite confident that cluster 1 is located near
person’s home and cluster 2 is near person’s work. In a similar way, we extracted, analysed,
and interpreted the places of shorter visits (Andrienko, Andrienko, & Wrobel, Visual Analytics
Tools for Analysis of Movement Data, 2007). In particular, to find the places of person’s shop-
ping, we applied interactive filtering to consider separately the times of visits in the working
days and on the weekends.
The next group of analysis tasks deals with the trips, which are described by the sequences
of recorded positions between the stops. In order to discover the typical trips, we applied the
spatial clustering tool using appropriate distance functions, which measure the degree of
similarity between two position sequences. The cluster analysis is supported by an interac-
tive visual interface, which allows the analyst to interpret the results of the clustering and to
direct the work of the clustering tool.
Figure 50 to Figure 52 demonstrate examples of findings resulting from the trip analysis. Fig-
ure 2 presents three alternative routes from work to home, which have been discovered by
clustering the trips according to the similarity of the routes. The clusters of trips are shown on
a map in a summarised form. The three selected clusters are shown in orange, blue, and
purple colours. Dark grey indicates common parts of two or more routes. The frequency his-
togram of the trip durations in Figure 51 shows that the “orange” route typically takes much
less time than the other two, which may mean that the person makes intermediate stops on
the “blue” and “purple” routes. In Figure 52 , the graduated circles represent the mean times
spent in different places along the routes. Two biggest circles are located in two shopping
areas, which have been previously detected among the other significant places of the per-
son. More details about the trip analysis can be found in (Andrienko, Andrienko, & Wrobel,
Visual Analytics Tools for Analysis of Movement Data, 2007).

© ESS Consortium 2009 153


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 50: Three different routes from work to home

Three different routes from work to home

Figure 51: The frequency histogram of the trip durations. The coloured segments correspond to the clus-
ters of trips shown in Figure 50

Figure 52:The graduated circles show the mean times spent in different places along the three selected
routes

As can be seen from these examples, aggregation and summarisation are used in the analy-
sis of large amounts of data, even when the data describe the movement of just a single en-
tity. The use of aggregation and summarisation becomes indispensable when it comes to
analysing the movement of hundreds or thousands of entities. Thus, one of the datasets we

154 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

have used in our research contains more than 2 million records collected by GPS-tracking of
17,241 cars in Milan (Italy) during one week (the data have been kindly provided by the
Municipality of Milan for the use within the project GeoPKDD).

-U5<5< =*"$4,9,&'(&0'>%0%*+,&'(&02$+97$%&2*3%$"+%:&%*+9+9%,&

To approach the subject in a systematic way, we have introduced a formal model of collec-
tive movement of multiple entities as a function µ: E ! T " S where E is the set of moving
entities, T (time) is the continuous set of time moments and S (space) is the set of all pos-
sible positions [5, 7]. As a function of two independent variables, m can be viewed in two
complementary ways:
• {µe: T " S | e ! E}, where each function µe: T " S describes the movement of a sin-
gle entity. We call the function µe the trajectory of the entity e. The decomposition of
µ into a set of µe may thus be called trajectory-oriented view;
• {µt: E " S | t ! T}, where each function µt: E " S describes the spatial positions
(and, possibly, additional attributes) of all entities at a time moment t. We call the
function µt the traffic situation on the moment t (the term “traffic” is used in an abstract
sense and may be applied to any kind of entities). The decomposition of µ into a set
of µt may be called traffic-oriented view.

Hence, in the trajectory-oriented view, the movement is seen as a set of trajectories of all
entities. In the traffic-oriented view, the movement is seen as a time-ordered sequence of
traffic situations.
For each of the two views, different methods of aggregation and summarization are appro-
priate. In the traffic-oriented view, it is necessary to aggregate and summarize traffic situa-
tions. These basically consist of points in space and point-related characteristics. Therefore,
the aggregation and summarization methods suitable for point data can be applied here. In
particular, the points can be aggregated by spatial compartments (e.g. cells of a regular grid),
by time intervals, which may be defined according to the linear or cyclical model of time, and
by values of movement attributes such as direction and speed. The resulting aggregated
data can be visualized by means of animated or static maps with the use of colouring or
shading, graduated symbols, or diagrams, and non-cartographic displays such as temporal
histograms. We particularly suggest two cartographic visualization techniques: mosaic dia-
grams for the exploration of cyclical patterns in traffic variation (Figure 53) and directional bar
diagrams for the exploration of movements in different directions. These and other methods
are described in more detail in (Andrienko & Andrienko, 2008).
In the trajectory-oriented view, it is necessary to aggregate and summarize trajectories,
which are much more complex objects than points. One of the possible approaches is to
group trajectories according to the positions of their starts and ends using a previously de-
fined partitioning of the space into areas. The aggregation is done by putting together the
trajectories with the starts and the ends fitting in the same areas. The aggregates can be
visualized by means of an origin-destination matrix and by a map with vectors (directed lines)
varying in their widths and/or colours or shades according to the characteristics of the aggre-
gates. Thus, Fig.6 demonstrates an origin-destination matrix where the sizes of the gradu-

© ESS Consortium 2009 155


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

ated squares in the cells are proportional to the numbers of moves between the respective
districts of the city during a selected time interval. The matrix can also show other aggregate
characteristics of the groups of trajectories, such as the mean (median, minimum, maximum)
travel time or speed of the movement.

Figure 53:A map with mosaic diagrams

Figure 54: An origin-destination matrix

156 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Another kind of aggregation and summarisation is used in combination with clustering of tra-
jectories. The method is based on treating trajectories as sequences of moves between
small areas, which are defined automatically using characteristic points of the trajectories,
i.e. starts, ends, turns, and stops. The areas are built as circles around clusters of character-
istic points from multiple trajectories and around isolated points. The aggregation is done by
putting together moves connecting the same areas. To visualize a cluster of trajectories, only
the moves from the trajectories of this cluster are aggregated. The aggregated moves are
shown on a map by vectors (this aggregation-based visualisation method has been already
used in Figure 50 and Figure 52). The visualization can be interactively manipulated. Thus,
the user may choose to see only the moves occurring in at least k trajectories, where the
parameter k can be dynamically changed Figure 55.

Figure 55: Summarised representation of the major clusters of trajectories from the suburbs of Milan
towards the centre on Wednesday morning. Only the moves occurring in at least 10 trajectories are visi-
ble as a result of interactive filtering

-U5<5? =*"$4,9,&'(&0'>%0%*+,&'(&02$+97$%&3%$"+%:&%*+9+9%,&

In analysing movements of related entities, the analyst may be interested in uncovering the
interactions between the entities in the process of their movement. Movement data usually
consist of time-stamped position records and do not contain any explicit information about
interactions; hence, it is only possible to detect indications of possible interactions. An im-
portant indication is spatial proximity between two or more objects at some time moment or
during a time interval. The notion of spatial proximity depends of a number of factors; some
of them are listed in Table 21.

Table 21: Factors influencing the notion of spatial proximity

Factor Factor

© ESS Consortium 2009 157


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Type of movement walking, cycling, driving, …


Type of relation in focus (analysis task) possibility to observe, possibility to talk,
possibility to touch, …
Place city centre, shopping mall, nature park, high-
way, …
Time early morning, rush hours, late evening,
night, …

An example dataset requiring the analysis of possible interactions between moving agents
was collected by tracking movements of 303 schoolchildren while they were playing an out-
door mobile game. According to the rules of the game, the children were supposed to visit
various places in a city and answer place-related riddles. The players were organised in
competing teams. The goals of the analysis are to find out whether the players cooperated
within the teams and whether there were conflicts between members of different teams. De-
tecting and examining indications of possible interactions between the players may help an-
swer these questions.
In case of a large dataset, possible interactions need to be extracted from the data by means
of computational techniques. We have developed a simple and fast computational method
for extracting possible interactions from movement data. The user is expected to specify
threshold values for the spatial and temporal distances between positions of two objects. The
method first searches for pairwise interactions. For each pair of objects, it tries to find respec-
tive positions in their trajectories such that the spatial and temporal distances between them
are within the given thresholds. In case of detecting such positions, the following positions of
the trajectories are checked. After extracting pairwise interactions, the method combines
interactions sharing a fragment of a trajectory. Extracted interactions may be visualised on a
map and in a space-time cube (Figure 8) for being inspected by the analyst. More details
about the methods for the extraction, visualisation, and interactive examination of possible
interactions between moving entities are available in (Andrienko N. , Andrienko, Wachowicz, &
Orellana, 2008).
A major problem we have encountered in developing methods and tools for the analysis of
interactions is the large number of possible interactions that can be extracted from move-
ment data. Thus, hundreds of possible interactions (the exact number depends on the cho-
sen threshold values) can be extracted from the data about the mobile game. This exceeds
the capacity of the analyst to inspect and interpret each interaction. Hence, there is a need in
automated classification of interactions according to their essential properties. For this pur-
pose, it is necessary to define the essential properties of interactions and the ways of extract-
ing these properties from movement data. This is a topic of our further research.

158 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 56: Visual representation of possible interactions between moving entities

-U5? =,,%,,0%*+&('3&E11&

The mission of Visual Analytics is to help people analyse large and complex data by amplify-
ing their perceptual and cognitive capabilities. For this purpose, Visual Analytics combines
automated analysis techniques with interactive visualisations. Spatial analysis is an important
application area for Visual Analytics. In our research, we develop visual analytics methods
and tools for analysis of different varieties of movement data. In this paper, we have con-
sidered three different types of movement data, the major analysis tasks related to these
data types, and the appropriate methods, which combine visual representations and interac-
tion techniques with database processing, clustering, computational aggregation and sum-
marisation, and other computational techniques.

© ESS Consortium 2009 159


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

<[ Z9,2"$$4X:39>%*&G7+909L"+9'*&!''$&('3&E>";2"+9'*&1;8%:2$9*/&

<[5- 18'3+&H%,;397+9'*&

Application of the ideas of visual analytics is a promising approach to supporting decision


making, in particular, where the problems have geographic (or spatial) and temporal aspects.
Visual analytics may be especially helpful in time-critical applications, which pose hard chal-
lenges to decision support. We have designed a suite of tools to support transportation-
planning tasks such as emergency evacuation of people from a disaster-affected area. The
suite combines a tool for automated scheduling based on a genetic algorithm with visual ana-
lytics techniques allowing the user to evaluate tool results and direct its work. A transporta-
tion schedule, which is generated by the tool, is a complex construct involving geographical
space, time, and heterogeneous objects (people and vehicles) with states and positions vary-
ing in time. We apply a task-analytical approach to design techniques that could effectively
support a human planner in the analysis of this complex information.

The research agenda of Geovisual Analytics for Spatial Decision Support (Andrienko &
Andrienko, 2008) sets the support to time-critical decision making as one of the priority direc-
tions. It also points to the need to find appropriate ways to visualize and analyze complex
spatio-temporal constructs, such as scenarios and action plans.

The problem of transportation scheduling is considered in the area of Operations Research,


where it is ascribed to a generic class of Vehicle Routing Problems (Andrienko G. , Andrienko,
Dykes, Fabrikant, & Wachowicz, 2008). For this class of optimization problems, deterministic
mathematical techniques do not work sufficiently well while heuristic methods, such as Ge-
netic Algorithms (Andrienko G. , et al., 2007), offer a powerful alternative (Andrienko &
Andrienko, 2007)(Andrienko, Andrienko, & Wrobel, 2007)(Andrienko, Andrienko, & Gatalsky,
2000). As we have noted, the problem usually cannot be solved fully automatically and re-
quires the involvement of a human analyst with his/her domain expertise and knowledge of
the geographic area. Existing software systems for automated transportation planning typi-
cally include visualizations to present the results of schedule computation and optimization to
the user and allow the user to modify the schedule (Andrienko N. , Andrienko, Pelekis, &
Spaccapietra, 2008)(Andrienko N. , Andrienko, Wachowicz, & Orellana, 2008)(Kapler & Wright,
2005)(Kraak, 2003). Commonly used types of display are table and Gantt chart (a horizontal
bar chart representing the duration of tasks against the progression of time). As these dis-
plays do not contain geographic information, they are often combined with maps showing the
geographic locations involved (Andrienko N. , Andrienko, Pelekis, & Spaccapietra, 2008). Some-
times, planned shipments and vehicle moves are also represented on a map as directed
lines (vectors) connecting source and destination locations (Kapler & Wright, 2005). A disad-
vantage is that the spatial and temporal aspects of a schedule are shown separately, and it is
not easy for the user to establish links between them. To alleviate this problem, the user is
offered a chart where the horizontal dimension represents time and the vertical dimension
provides positions for the names of the locations (Andrienko N. , Andrienko, Wachowicz, &
Orellana, 2008)(Kraak, 2003). In this chart, diagonal lines represent movements of vehicles

160 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

from place to place and horizontal lines or bars indicate their staying in a location. Lines dif-
fering in colour show movements of several vehicles.

A shortcoming of these approaches to schedule visualization is their lack of scalability. Thus,


a table or Gantt chart representing hundreds of orders can hardly facilitate schedule analysis,
and a map with hundreds of overlapping and intersecting vectors is completely unreadable.

In (McCormick, DeFanti, & Brown, 1987), the authors present a solution based on the mi-
cro/macro display concept advocated by E.Tufte (Tufte, 1990): the macro features (overall
shape) of a graph capture dispersion and trend information about the entire data set while
micro encoding represents individual data items. This idea has been used for the visualiza-
tion of data concerning planned transportation of injured and sick people to medical treat-
ment facilities. Tiny symbols representing individual patients are positioned according to the
planned departure times or readiness times while the colour and shape of a symbol can en-
code attributes of the patient. The symbols for scheduled and unscheduled patients are
stacked on two sides of the time axis. In the result, the macro features of the display show
the total number of the patients and the distribution of the planned vs. unplanned patients
over time. This visualization, however, does not present information about the transportation
means (vehicles), source and destination locations, and durations of the trips. It does not
seem that the micro/macro display concept can be straightforwardly applied also to these
types of information. Another approach is representing data in an aggregated way. In
(Thomas & Cook, 2005), temporal, geographic and categorical aggregations are used to visu-
alize data about multiple events distributed in space and time. These ideas can be adapted
to the visualization of transportation orders taking into account the differences in the data
structure.

In time critical situations, software tools automating some of people’s activities or suggesting
solutions to problems are of great benefit. However, machine-generated solutions can gen-
erally be used only after a verification and validation by a human expert, who takes the re-
sponsibility for the decisions made. Hence, the expert needs tools that enable effective re-
viewing of these solutions in the shortest possible time. Although visualization plays a great
role here, large amounts of information cannot be efficiently examined without the involve-
ment of computational techniques for analysis and summarization.
We have developed a software system to support civil protection services in planning evacu-
ation of people from disaster-affected areas. The system includes a module that automati-
cally builds transportation schedules and a suite of techniques enabling the inspection of the
schedules by a human planner. To handle large amounts of data, we integrate interactive
visual displays with computational techniques for data transformation, according to the para-
digm of visual analytics (Thomas and Cook 2005, Keim 2005). This distinguishes our ap-
proach from the usual tools (e.g. ILOG 2007, TurboRouter2007, Fagerholt 2004).
In (Andrienko et al. 2007), we described the main features of the automated schedule builder
and presented our task-centered design of the tools for schedule examination. We also dem-
onstrated the appropriateness of the tools for the task by an example of schedule analysis. In
this presentation, we focus on the display manipulation techniques, coordination between
different views, and dynamic transformations of the data.

© ESS Consortium 2009 161


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

<[5< Z9,2"$&=*"$4+9;,&!''$,&

<[5<5- !8%&H"+"&+'&#%&EV"09*%:&

In an emergency evacuation, it is necessary to schedule the transportation of many people


from multiple sources (original locations) to multiple destinations (shelters). There may be
diverse categories of people such as general public, disabled people, and critically sick or
injured persons. These categories need to be handled differently, which includes the selec-
tion of proper destinations and proper types of vehicles as well as proper timing of the trans-
portation.
The input data for the evacuation planning include
• the sources of the endangered people,
• the numbers and categories of these people,
• the latest allowed departure times per place and category;
• possible destinations and their capacities by people categories;
• types of vehicles and their capacities for the people categories they are suitable for;
• available vehicles and their initial locations.
The automated schedule generator produces a collection of transportation orders assigned
to the vehicles, where each order specifies one trip of a vehicle: source and destination loca-
tions, start and end times, and the category and number of the people to be delivered. One
schedule may consist of hundreds of orders. A human planner cannot examine each order
individually, especially under time-critical conditions. Hence, the information needs to be pre-
sented to the planner in a summarized form adequate to the purpose of detecting possible
problems (e.g. people remaining in the sources, time limits exceeded, etc.) and understand-
ing their reasons.

<[5<5< H4*"09;&=//3%/"+9'*&

To provide a summarized representation of the data while enabling the planner to focus on
various subsets, we combine interactive filtering of the data with dynamic aggregation. The
user may set one or more data filters of different types: by people category, by time interval,
by source, and/or by destination. The aggregation is applied to the portion of the data that
have passed through the filters and immediately re-applied when the filters change. For this
purpose, several types of dynamic aggregators are created. A dynamic aggregator is a spe-
cial object linked to a number of data records and able to derive certain statistical summaries
from those records which satisfy current filters. These summaries are presented on visual
displays, and the aggregators are responsible for updating the displays when the filters
change. Different types of aggregators are attached to individual locations (e.g. counters of
remaining people in the source locations and counters of used and free capacities in the des-
tinations), to pairs of locations (trip aggregators), or to the entire territory (e.g. aggregator of
people by states and calculator of the vehicle use).

162 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

<[5<5? Z9,2"$9L"+9'*&"*:&\,%3&K*+%3";+9'*&

A transportation schedule is a complex construct involving geographical space, time, and


heterogeneous objects (people and vehicles) with states and positions varying in time. All
this information cannot be appropriately presented in a single display. Our toolkit includes
several coordinated views presenting different aspects:
• a summary view of the transportation progress over time (Figure 57), which also
serves as a direct manipulation interface to the time filter;
• a map display showing the situation on a user-selected time interval (Figure 58 and
Figure 59);
• a source-destination matrix presenting summarized data for pairs of locations (Figure
60), which also serves as a direct manipulation interface of the filter by source and/or
destination;
• a Gantt chart providing a detailed view of the distribution of the trips over time (Figure
61 and Figure 62).
All the views are dynamically updated when the user changes current filters: selects an item
category, a time interval, a source, and/or a destination.
Thus, in Figure 1, the user has selected the category of people “general people or children”
in the choice control at the bottom of the window. As a result, the transportation progress
summary display shows only summarized data relevant to the selected category. This refers
to the numbers of people, destinations, and vehicles (only the destinations and the vehicles
suitable for the selected category are counted). Additionally, the user has selected the time
interval from minute 30 till minute 31 since the start of the evacuation (by clicking on a bar
corresponding to this interval in the upper chart of the display in Figure 57). The selection of
the time interval does not affect the summary view, but the map (Figure 58) and the Gantt
chart (Figure 62) represent only the information relevant to the selected people category and
time interval.
In our presentation, we are going to demonstrate how the tools enable detection of possible
problems and investigation into their reasons.

© ESS Consortium 2009 163


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 57: summary view of the transportation progress

Figure 58: A fragment of a map view

Figure 59: map legend

164 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 60:the source-destination matrix

Figure 61:the Gantt chart; original appearance (no filtering)

Figure 62: the Gantt chart after filtering by people category and time interval

<[5<5@ .':9(9;"+9'*&'(&"&1;8%:2$%&

A possible result of the examination of a schedule is that the schedule or some parts of it are
unacceptable and must be improved. Another reason for modification is changes in the situa-
tion such as appearance of additional people to be evacuated, deviations of the real travel
times from the estimated ones, some resources becoming unavailable or new resources be-
ing added. Manual correction of individual transportation orders is time-consuming and there-
fore not appropriate in emergency situations. The scheduling algorithm can be utilized not
only for the generation of schedules but also for modification. For this purpose, the algorithm
is devised in such a way that it can be re-applied to a subset of a previously produced

© ESS Consortium 2009 165


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

schedule in order to correct and optimize it (meanwhile, the satisfactory part of the schedule
can be taken for execution). Before that, the user needs to update the input data: add new
people sources and/or new resources, correct the numbers of people in the sources and/or
the time limits, and remove unavailable resources. This is done with the help of interactive
visual interfaces It should be borne in mind that the most critical problems (people remaining
in the sources, time limits being exceeded, and the use of unsuitable resources) arise be-
cause of the lack or deficiency of appropriate resources. Hence, before trying to improve the
schedule, the planner needs to find additional resources and add the corresponding informa-
tion to the input data.
In order to divide the set of orders into acceptable and requiring correction without the need
to view and mark individual orders, the planner may apply the following division criteria:
• people category: the user selects one or more categories, and the system fixes the
respective orders including the empty trips of vehicles to the source locations of these
people;
• time: the user selects a time moment, and the system fixes the orders that will have
been fulfilled before it or will be under execution at this time moment. This way of di-
vision is applied, in particular, when the schedule needs to be adapted to changes in
the situation;
• source location: the user selects a subset of source locations, and the system fixes
the orders for in- and outgoing trips.

<[5? )'*;$2,9'*,&

We have devised a set of tools to support efficient examination of large transportation


schedules involving multiple geographical locations and diverse categories of transported
items and types of vehicles. The size and complexity of the information and the need to ana-
lyze it in the shortest possible time call for a synergy of visual and computational methods as
stated in the ‘Visual Analytics Mantra’ (Keim 2005). Our tools combine visual displays and
interactive techniques with dynamic aggregation and summarization of the data.
The topic is really relevant. The system has been evaluated by firemen within the OASIS
project and received extremely positive feedback. However, the approach should be further
developed and extended for successful usage in ESS:
• Connecting to SDI for getting access to location data, maps and routing tools
• Improvement of candidate plan selection procedure by clustering and classification of
the variants of the evacuation plans produced by the optimizer.
This asset could be a good candidate for developing applications that demonstrate the value
of the ESS architecture and infrastructure. However, the system has specific technical re-
quirements that should be taken into account in the architecture.

166 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

<[5@ .'3%&H%+"9$,&

Gennady Andrienko, Natalia Andrienko, Ulrich Bartling: Visual Analytics Approach to User-
Controlled Evacuation Scheduling Information Visualization, 2008, v.7 (1), pp. 89-103
http://dx.doi.org/10.1057/palgrave.ivs.9500174

© ESS Consortium 2009 167


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

<- Z9,2"$&=*"$4+9;,&!''$N9+&
This asset could be a good candidate for being used in the data fusion WP and for develop-
ing applications that demonstrate the value of the ESS architecture and infrastructure.

<-5- H%,;397+9'*&

We propose a general framework for analysis of various kinds of spatio-temporal data. The
framework is supported by the visual analytics toolkit that consists of tightly integrated visual
and computational methods. The visual methods include a variety of dynamic and animated
maps, space-time-cube, and statistical graphics techniques. The computational methods
include clustering and classification that take into account specifics of different types of data
data. The toolkit can be applied, for example, to GPS tracks of cars, mobile phone usage
data, time-series produced by sensors etc.

<-5< )'00%*+,&(3'0&K*>%,+9/"+'3&

We already have experience of cooperation with WIND for analysis of locations and times of
calls of their customers. The methods that we are developing can be extended for estimating
traffic flows (under normal conditions or in emergency situation), monitoring the situation and
detecting abnormal behaviours, and for providing adaptive services to customers (e.g. rec-
ommending safe evacuation routes in emergency).

<-5? D%$%>"*+&O9*N,&

• Natalia and Gennady Andrienko. Exploratory Analysis of Spatial and Temporal Data.
A Systematic Approach.715 p. 282 illus., 37 in colour., Hardcover, Springer-Verlag,
December 2005, ISBN 3-540-25994-5
http://geoanalytics.net/eda
• Gennady Andrienko, Natalia Andrienko, Stefan Wrobel. Visual Analytics Tools for
Analysis of Movement Data. ACM SIGKDD Explorations, 2007, v.9 (2), pp.38-46
• Gennady Andrienko, Natalia Andrienko. Spatio-temporal aggregation for visual analy-
sis of movements. IEEE Visual Analytics Science and Technology (VAST 2008). Pro-
ceedings, IEEE Computer Society Press, 2008, pp.51-58

168 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

<< ?H&Z9,2"$9L"+9'*&'(&.",,9>%&C%'/3"789;"$&H"+",%+,&

<<5- K*+3':2;+9'*&

“In the frame of ESS project, CS will specify, design and integrate an innovative 3D carto-
graphic system that will serve as a central interface to provide a complete three dimensional
view of the situation, while offering means to the operators to interact with the displayed in-
formation in order to command and control the related elements, or to query additional infor-
mation.”
Nowadays, enormous amounts of geographical data and digital information about the earth
are available. This tremendous dataset has become impossible to handle with a single soft-
ware solution, due to its heterogeneity and wide variety of formats, uses and needs. The fast
growing market of GIS has produced over the last decade a large amount of technologies,
standards, and use cases. Crisis management information systems are among these use
cases.
The 3-Dimensional Geographic Information System (3D GIS) has been advancing rapidly
due to recently prompt development of Internet, geographic information system (GIS), high-
speed network, knowledge-based database, sensor network technology, and information
technology (IT), and availability of high-resolution space- and air-borne images. Web based
platforms, such as Google Earth, Virtual Earth and Sensor Map, further demonstrated real-
time interactions with global users in utilization of GIS data and its applications. It is undeni-
able that the GIS are making great impact to our daily life. It is also predictable that the im-
pact is increasing in both breadth and depth with the advancement of relevant technology
and application areas.
An extensive list of geo-referenced data can be displayed on a map in the framework of crisis
management information system. A small overview contains: GPS tracked entities such as
personal, vehicles or sensors position, pressure, wind, humidity and temperature reports,
traffic data, chemical, radioactive and hazardous sensors data, video streams, first
responders reports, seismologic data, flood risks, land erosion identification, wildfire perim-
eter, evacuation management, common operating picture, available logistics and resources,
hospital occupancy, etc. Hence, considering the 3D visualization of massive geographical
dataset is of utmost importance for the ESS project.
This state of the art assessment will focus on two aspects. On one hand, we will study exist-
ing technologies and tools for the 3D visualization of massive geographical dataset, we will
pay a special attention on the rendering performances, the web compliant aspects and the
capacity to access to remote geographic and cartographic data. On the other hand, we will
consider the capacity of these visualization systems to display heterogeneous and geo-
referenced data from sensors and data fusion system, with the support of the main standards
and the capacity to interoperate with external and heterogeneous systems or servers.

© ESS Consortium 2009 169


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

<<5< !''$,&

The following section describes existing technologies for 3D visualization of massive geo-
graphical dataset, with pros and cons in accordance with ESS needs and requirements.

<<5<5- C''/$%&E"3+8&

GoogleEarth is widely adopted by the general public because the viewer is free, combined to
an amazing geographic database and an impressive dissemination capacity. Unfortunately,
this huge dataset being based in the USA, using it for the purpose of ESS bears some risks,
for instance that of network failures. We can notice that Google provides a solution (Google
Earth Enterprise Fusion and Server) that allows accessing a database from a local server.

Google Earth interfaces are well known, hence it has a great capacity to interoperate with
many other systems and products, and it comes with its own API for developers. Anyway,
this API is provided as a black box; it does not offer the possibility to use or implement new
algorithms for data fusion, or improvement of 3D visualization performances.
Due to its wide dissemination and adoption by the public, many GIS application providers
implemented interoperability features with Google Earth (common interfaces, exchange of
data, format exports…). Google Earth can also be interfaced with external database and ser-
ver (meteo, traffic, directories, news, etc); as well as other Google databases (Street View,
Google Maps).
Google specified KML, hence it supports the KML format, as well as 3D models import
(sketchup), geo-referenced images, or GPS traces (GPX). Google Earth is also compatible
with external web services such as WMS, but with some limitation in terms of visualization
performance. For instance, it handles WMS by image superimposition, with no texture cache,
neither virtual texturing.
Google Eearth is available as a standalone application, which embeds a web browser, and
provides user friendly interface and tools (layer management, drawing and measurement
tools); it is also available as a plug-in, then the 3D viewer is embedded in a web browser.
The standalone version offers more features but requires an installation process, while the
plug-in version is lighter, but it is not available under Linux environment and will not be sup-
ported by all web browsers.

170 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 63: Google Earth

<<5<5< .9;3','(+&]9*/&."7,F&Z93+2"$&E"3+8&'3&f"8''g&."7,&

A similar analysis as the one made for Google Earth can be made for other Earth viewer so-
lutions such as Microsoft Bing Maps, Virtual Earth or Yahoo! Maps, which are similar pro-
ducts and offer equivalent services, tools and functionalities. Nevertheless, none of them
have a dataset equivalent to the one owned by Google. They suffer of a lack of performance
for the interactive visualization of non-static and massive geographical dataset, in compari-
son, for instance, to Google Earth. Although the free services and solutions provided by
Google Earth, Google Maps, Street View, Virtual Earth, Bing Maps, Yahoo maps, and other
Geoportal are free of charge, and provide numerous functionalities both in 2D and 3D appli-
cations, they are, in a large proportion, addressed to the general public, and cannot replace
the integration work of IT companies inside many different and specific structures and critical
systems. Furthermore the source code being not available to the ESS consortium it is difficult
to adapt or integrate it (even with the API) in a critical operational system for homeland se-
curity, for which we must control the core of the applications to perform the necessary op-
timizations.

© ESS Consortium 2009 171


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 64: Microsoft Bing Maps

<<5<5? Q=1=&P'3$:&P9*:&

WorldWind is a solution developed by NASA. It has the advantage to be open source and
can therefore benefit from the Open source community developments. WorldWind has ac-
cess to an online digital geographic database (NASA) which is an advantage although this
database is much less complete than Google’s or Microsoft’s one. However, the access to
this database is free for other applications. Therefore, we will also benefit from its availability.
WorldWind was originally available in C#/DirectX, so only on Windows platforms. It has been
recently ported to Java, which makes it cross-platform. Unfortunately, the performances have
greatly suffered from this porting. The 3D engine performances are limited especially for the
interactive visualization of vector data and massive geographical dataset.

Figure 65: NASA WorldWind

172 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

<<5<5@ !%33"&EV7$'3%3&

TerraExplorer is another Earth globe viewer. It comes with a set of ActiveX controls that al-
low customizing the software interface; but it is of course not suitable for the needs of ESS
project, as we must have access to the core of the application in order to perform necessary
optimizations. It also comes with the Skyline TerraSuit that offers a complete architecture for
GIS exploitation. TerraExplorer provides features that are of great interest for ESS project,
such as the possibility drape UAV feeds directly onto the terrain background (not tested in
the frame of this study), the management of layer, creation of draws and notes onto a layer.
Nevertheless, as a proprietary solution, Skyline does not offer to access the source code of
its software, hence it is not possible to perform the necessary optimizations.

Figure 66: Skyline Terra Explorer

<<5<5B G,,906$"*%+&

OssimPlanet is an Open Source project for the visualization of 3D geographical data. It is


based on Open Scene Graph and Qt which are respectively a 3D rendering library and the
Open Source library of Nokia for GUI development. It supports numerous GIS standards
such as KML/KMZ/OGC/WMS. The pros of this solution are that it’s based on open source
solution coded in C++ and cross platform, thus we could benefit of the source code to im-
plement particular functionalities and optimizations. Still the GIS features are rather rare and
the SDK that comes with is suitable for 3D programmers and not for GIS or non-expert pro-
grammers.

<<5<5I O2;9":F&6DE1=CK1F&D=!.=Q&"*:&E1DK&

Luciad, PRESAGIS and ESRI provide professional solutions for the visualization of geo-
graphical datasets, and target advanced users of GIS systems (ESRI), or experts in the field
of simulation (Luciad, PRESAGIS).

© ESS Consortium 2009 173


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Luciad Maps comes with a 3D visualization module of cartographic data, but it doesn’t have
good performances; it is robust, multiplatform and supports the most common standards
(OGC, XML, Digest, OMG, Corba, Geocapi, ISO). Nevertheless, it is Java based which im-
pact the overall performances of the application. Luciad is well established in NATO, and
provides applications oriented towards military domain with numerous cartographic manipu-
lation tools. It is also expensive.

PRESAGIS solutions (VegaPrime and Lyra) for display of geographical data are mostly ori-
ented towards the visualization of simulation data in cartographic environments, hence the
required functionalities for a web based application such as the one required by ESS Project
are not implemented, or not fully supported (WMS, WFS), since there is no required need for
the use of dynamic data in simulation systems, like for instance in a web client.

ESRI solution for 3D visualization is 3D Analyst. As a professional tool, it provides a huge set
of features for the manipulation of geographic and cartographic data, and it is tightly inte-
grated with others ESRI solutions. It has good 3D performance, but it is single user. ESRI
solutions are very oriented toward the GIS domain, and may lack the features required for
the interactive visualization of massive dataset in the domain of crisis management. This
solution provides a user interface designed for expert users in the field of GIS, and is not
suitable for non GIS expert.

Figure 67: ESRI - 3D Analyst

RATMAN is a real-time terrain rendering framework able to asynchronously access terrain


information from remote servers. It consists of a high performance portable rendering library
used as a rendering engine, and of a simple networked viewer integrated with many different
data sources. This solution from CRS4 is free and comes with a GNU GPL licence, so we
can benefit of the source code. It has good performance, in particular for terrain rendering.
The framework also offers the possibility to implement code for displaying real time informa-
tion such as meteorological data, and support WFS protocol.

174 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 68: Ratman

<<5<5J Z93+2"$&C%'&

Software applications developed by CS for the needs of ESS project will be based on Vitual-
Geo product. Developed and distributed by CS since 2000, VirtualGeo is a robust and field-
proven application for the 3D interactive visualization of very-large, namely planet-size,
geospatial datasets. Initially dedicated to 3D visualization, VirtualGeo has become a standa-
lone application that combines simplicity of use, comparable to the WorldWind or Google
Earth globe viewer, and both the robustness and visualization performances required for
critical industrial and operational applications. The rendering engine developed by CS offers
good performances both for the visualization of 3D dataset and display of aerial imagery
thanks to virtual texture management and memory cache. Hence the performances for the
dynamic visualization of remote and massive geographical data are suitable for the exploit-
ation in a web based application. Currently Virtual Geo is not a web application (such as
Google Earth plugin for web browsers), but we have the knowledge and the code source,
what lets us envisage any possible development and optimization for the needs of ESS, both
for the visualization and graphical user interface.

© ESS Consortium 2009 175


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 69: CS Virtual Geo

The above analysis provides a non-exhaustive but an overall picture of state of the art tech-
nologies for 3D visualization of massive geographical datasets. Each of these solutions tar-
gets one or further markets and needs (e.g. urban planning, GIS, simulation, tourism, ar-
chaeology, crisis management, etc). None is particularly dedicated to crisis management
application, and few can be adapted to.

<<5<5R ?H&>9,2"$9,"+9'*&'(&/%'/3"789;&:"+",%+&,4,+%0,&('3&;39,9,&0"*"/%0%*+&

Some initiatives can be highlighted that attempt to integrate 2D / 3D geographic and carto-
graphic visualization system, in web-based crisis management information system. Such
initiatives are of great interest to the ESS project, since it could allows us to identify dead end
approaches or killing features.
In that frame, it is interesting to mention Sensor Map, which is a 2D/3D geographical viewer
based on Microsoft Bing Maps solution. It is a web-based application for the 2D and 3D visu-
alization of geo-referenced sensor data, such as meteorological, temperature sensor or
webcams embedded within a cartographic application. It is mostly used to share sensing
resources and visualize data with interactive tools, along with authenticated access. It pre-
sents interesting tools such as authenticable management of remote sensor, and display
options, but is still too limited and not oriented towards emergency crisis management do-
main. This technology suffers of the lack of performance of Bing Maps and no news has
risen since November 2008 on the SenseWeb project.

176 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Figure 70: Sensor Map

The Taiwan’s NARL initiative of GEO Grid Project has the goal to deploy a high-resolution
3D GIS platform, which can be expanded for any appropriate applications (Chang, Tsai, Lin,
Chang, & Te-Lin, 2008). This research project provides a framework infrastructure based on a
computing/data/sensor grid, a service interface, and an application module, which provide a
platform for developing various modules for different applications, such as disaster reduction
or Homeland Security. This project integrates Virtual Reality systems for the interactive 3D
visualization of massive dataset, as well as web services for the visualization of remote sen-
sor and geographical data. Still the whole system seems heavy and not easily deployable in
operational fields at clients needs.

Figure 71: Geo Grid Framework

Virtual Alabama is an initiative of the Alabama Department of Homeland Security to provide a


3D geographic visualization platform that would help stakeholders, users and decision mak-
ers understand, collaborate and share data. The 3D visualization technology used in this
project is Google Earth. We can notice some of the actual features associated to the Virtual
Alabama activities: Common operational picture, Emergency evacuation routine, vehicles

© ESS Consortium 2009 177


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

and asset tracking, visualization of risks, plume modelling and real time sensor feeds, dam-
age assessment, etc.

Figure 72: Virtual Alabama Views

From this few examples we can assume that 3D visualization of geographical data in the
frame of crisis management information systems represents a strong market opportunity. It
appears of high importance for the geographic visualization tool in the crisis management
domain to implement interoperability features and a modular architecture. So that it can be
easily deployed for a wide variety of crisis and emergency needs.

<<5<5U 1200"34&

Two approaches are possible for the access to geographical dataset. It can be either web
based à la Google Earth, or from local hard drive or LAN server. The web based approach
offers more modularity and appears to be the best answer to user needs, given that the Web
infrastructure is not affected by the crisis or an ad-hoc alternative can be provided. Hence it
is important to consider the support of the main GIS standards in terms of web services and
data format exchange. Even though those systems have been designed to highly distributed
computing platforms, they even run on single machines and still keep the advantages of the
high modularity.
Few of the studied solutions integrate data fusion systems to enable the interoperability of
geographical data with the operation field data, combined to a user friendly interface that
enable its exploitation by non expert GIS users. From the end user point of view, it appears
of utmost importance to have a common operational picture, as close as possible to reality,
which integrates real time sensor data. It appears also important for the ESS project to con-
sider user requirements related to GUI aspects of the final application (how to access and
represent the data). Indeed, not considering this aspect could lead the targeted users to re-
ject the whole system, as the interface could not be compliant to their expectations. Indeed,
many of the studied solutions provide the features expected for crisis management informa-

178 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

tion system, but few implement the graphical user interface that enables the proper exploit-
ation by non GIS experts users, i.e. crisis managers.
To summarize, 3D visualization of geographical dataset within crisis management informa-
tion system will be in any case available in the near future to the end-consumer. This as-
sumption is based on the fact that different research labs and companies are working on
solutions, and market potentials for consumers are evident and extremely large. A system
providing a web-based architecture that is modular and interoperable (i.e. access through a
web portal, data fusion system to provide crisis manager with actionable information, support
of main GIS standards, web services, etc) will have a major impact and a high market poten-
tial.
It seems a key differentiator to offer cutting-edge rendering performances, with high realism
for landscape at interactive speed, combined with web based approach for the visualization
of real time sensor data (with data fusion algorithms) and GIS like functionalities.

<<5? D%$%>"*+&O9*N,&

http://delivery.acm.org/
http://www.skylineglobe.com
http://research.microsoft.com/en-us/projects/senseweb
http://ratman.sourceforge.net/
http://earth.google.com/enterprise
www.virtual.alabama.gov
www.bing.com/maps
www.ossim.org
http://georezo.net/
http://www.presagis.com/products/visualization/

© ESS Consortium 2009 179


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

<? K*('30"+9'*&!%;8*'$'/4&9*&A'3%,+&A93%&."*"/%0%*+&

<?5- A'3%,+&A93%&E0%3/%*;4&

Forest fire is an emerging civil security issue since damage to property and death toll is rising
every year. Despite their natural role in the Mediterranean ecosystems, uncontrolled forest
fires (called wildfires in the US literature) have an immense impact on both human population
and the environment, as witnessed in several regions worldwide such as Indonesia (1997),
Australia (2005), Portugal (2003), Greece (2007) etc. Little practical assistance is possible
beyond fire suppression and humanitarian aid to affected populations during and after the
fire. However, existing technology can support operational organizations in order to map fire
potential, detect fire starts, monitor fire movement, and assess the impact of the fire at the
local, regional and even the global scale. Large wildfires, so-called “Megafires”, favoured by
the climate change, become a growing hazard in most regions of the planet, presenting a
threat to property, societies and human life.
Most of the fire starts are caused by human activity or intention and thus prevention can
greatly reduce the number of fires and burned areas. Independently of their origin (natural or
human-caused) forest fires represent a constant threat to ecological systems, infrastructures
and human lives. Very large fires the last decades funnelled by strong winds and burning
areas with no fuel management activity claimed several human lives in Greece (80 in 2007),
Spain (23 in 2005), Australia (Melbourne 173 in 2009), California (12 in 2007) to mention
some figures. The average annual global total number of deaths is 59.5 fatalities per annum
according to the CRED EM-DAT, the International Disasters database.

Figure 73: Annual forest fire fatalities (CRED EM-DAT Data base)

Care is needed in the interpretation of the above as CRED only record events that kill ten or
more people, thus these values consistently underestimate the true toll, but nonetheless the
unusual impact of these events is clear. Furthermore hundreds of thousand hectares of
vegetation are burned every year in both hemispheres, thousand houses are damaged or
destroyed by fire in the wild land urban interface or rural areas making thousands homeless

180 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

every year. Thus the forest fires have profound effects on land cover, land use, production,
local economies, global trace gas emissions, and health.
Requirements vary widely at each stage of the fire management cycle. Fire potential quanti-
fies the likelihood of a fire when there is ignition. Fire potential requires collecting baseline
vegetation information, daily to weekly monitoring of vegetation condition or vigour, daily
monitoring of weather conditions, and acquiring risk management information. Fire detection
requires daily monitoring of fire starts. Fire monitoring requires daily monitoring of fire scars
and of smoke and haze during the burn. Fire risk assessment requires modelling of fire be-
haviour and analysis of the spatial distribution of the values at risk. Finally the fire impact
assessment requires analysis of the fire burns and periodic monitoring of the vegetation tran-
sitions in the burned areas.
Significant research and applications of the elements of the fire analysis cycle are under way
or in use. At the national level, many countries are implementing fire potential models to miti-
gate the impact of fire. Fire detection and monitoring are critical. Admittedly, the most import-
ant application is the minimizing direct harm to human populations.

<?5< A93%&H"*/%3&D"+9*/&

Fire risk assessment is normally supported by means of Fire Danger Rating systems, which
are tools for estimating the probability of fire occurrence, the potential of fire behaviour, the
difficulty of suppressing a fire etc. These systems are associated with relevant indices, which
are calculated based on the values of meteorological parameters i.e. air temperature, relative
humidity, wind speed and drought.
The NFDRS (Burgan, 1988) is a complex set of equations that use user-defined constants and
measured variables to calculate daily indices and components that can be used for support-
ing decisions of fire management. A Fire Danger Rating level takes into account current and
antecedent weather, fuel types, and both live and dead fuel moisture. Each day during the
fire season, national maps of selected fire weather and fire danger components of the
National Fire Danger Rating System are produced.
The Canadian Forest Fire Weather Index (FWI) System (Stocks, et al., 1989) is a fire danger
rating system which consists of six components that account for the effects of fuel moisture
and wind on fire behavior. The first three components are fuel moisture codes and are nu-
merical ratings of the moisture content of litter and other fine fuels, the average moisture con-
tent of loosely compacted organic layers of moderate depth, and the average moisture con-
tent of deep, compact organic layers. The remaining three components are fire behavior in-
dexes which represent the rate of fire spread, the fuel available for combustion, and the
frontal fire intensity; their values rise as the fire danger increases.
Regarding fire danger rating at the European level, the European Forest Fire Information
System (EFFIS) has been established by the Joint Research Centre (JRC) and the Director-
ate General for Environment (DG ENV) of the European Commission (EC) to support the
services in charge of the protection of forests against fires in the EU and neighbor countries.
Using a variety of fire danger and fire risk assessment indices EFFIS provides EU level as-
sessments of fire management issues from pre-fire to post-fire phases, thus supporting fire
prevention, preparedness, fire fighting and post-fire evaluations
(http://effis.jrc.ec.europa.eu/about).

© ESS Consortium 2009 181


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Fire danger rating is a common technique used for mapping the spatial distribution of fire
danger and organizing fire mitigation and tactical prevention measures accordingly. Most fire
management authorities in Europe, US, Australia and Canada produce fire danger maps on
a daily basis for supporting preparedness plans.

<?5? A'3%,+&A93%&H%+%;+9'*&

Fast and effective detection is a key factor in managing forest fires. Early detection efforts
were focused on early response, accurate day and nighttime use, the ability to prioritize fire
danger, and fire size and location in relation to topography. Fire lookout towers have been
used since the beginning of the last century for detecting fires in the forest. Fires were then
reported using telephones, carrier pigeons, and heliographs. Aerial and land photography
using instant cameras were used in the 1950s until infrared scanning was developed for fire
detection in the 1960s. However, information analysis and delivery was often delayed by
limitations in communication technology. In the US, early satellite-derived fire analyses were
hand-drawn on maps at a remote site and sent via overnight mail to the fire manager. During
the Yellowstone fires of 1988, a data station was established in West Yellowstone, permitting
fire information delivery in approximately four hours.
Currently, local population, travelers, fire lookout towers, and ground as well as aerial patrols
are used as means of early detection of forest fires. However, accurate human observation
may be limited by operator fatigue, time of day, time of year, and geographic location. Elec-
tronic systems have gained popularity in recent decades as a possible resolution to human
operator error. Several systems for detecting forest fires are available in the market. Most of
these systems use single or multiple sensors which are sensitive in the infrared-near infrared
and visual range of the spectrum. Such systems include ARES (Faenzi Srl,
http://www.faenzi.it/ambiente), CICLOPE (INOV, http://www.inov.pt/pages/casestudies/
case_2.php), Bosque (Faba-Bazan, http://www.dcomg.upv.es/~chernan/sistema_integral/
incendios/Bosque.htm), BSDS (Teletron, http://www.teletroneuroricerche.it), Fire Hawk (En-
vironet Solutions Intl, www.firehawk.co.za/), Forest Watch (Envirovision,
http://www.evsolutions.biz/Forestwatch-index.php), AWFS (Fire Watch AG, http://www.fire-
watch.ch/index.php?option=com_content&task=view&id=14&Itemid=29) etc. The perform-
ance of these systems varies. All the systems are able to detect early fires of small dimen-
sions from several Kilometers, typically smoke clouds of one square meter at approximately
ten kilometers or a ten square meter smoke cloud at a distance of twenty kilometers.
Larger, medium-risk areas can be monitored by scanning towers that incorporate fixed cam-
eras and sensors to detect smoke or additional factors such as the infrared signature of car-
bon dioxide produced by fires. Brightness and color change detection and night vision capa-
bilities may be incorporated also into sensor arrays. Automatic fire detection suffers from the
increased number of false alarms that in some cases jeopardize the use of such systems.
Techniques used for reducing the problem of false alarms include the combination of infrared
and visual images, combination of information from several sources, validation with risk data
from GIS layers etc.
An integrated approach of multiple systems can be used to merge satellite data, aerial im-
agery, and personnel position via GPS into a collective whole for near-real time use by wire-
less Incident Command Centers.

182 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

A small, high risk area that features thick vegetation, a strong human presence, or is close to
a critical urban area can be monitored for potential fire occurrence using a local network of
miniaturized sensors. Recent advances in computer technology have spurred the develop-
ment of small low-power computers (motes), 0.8 inches by 2 inches (2 x 5 cm) in size, called
"motes". They host a wide variety of sensors, including: Temperature, Humidity, Barometric
pressure, and GPS-determined location. Motes communicate using high-frequency low-
power radios. They may be programmed with applications allowing them to self-organize into
wireless networks using mesh network topology for reporting data to remote clients. These
networks are battery-powered, solar-powered, or even tree-rechargeable i.e. able to re-
charge their battery systems using the electrostatic difference between the base of the tree
and the tree's canopy (Tree volt system). Pilot projects of wireless sensor networks for fire
detection and monitoring use commercial systems available in the market like Fireless
(Minteos Srl, http://www.minteos.com/nuovosolution.htm), Fire-Alert (SPS, http://www.s-p-
s.com/pdf/FIRE_VA.pdf), Firementor (NTUA, http://www.firementor.gr/english.htm), Firebug
(Crossbow, http://blog.xbow.com/xblog/2007/09/researchers-cre.html) etc to mention some
of them.
Mobile systems for supporting the detection of forest fires in combination with other activity
e.g. monitoring of environmental parameters are currently used in some cases. The Unat-
tended Ground-based Monitoring System (UGS) of Faenzi Srl (http://www.faenzi.it) is a typi-
cal autonomous, mobile, peripheral unit for fire detection, which has wireless link with the fire
management operational center.
UAVs and High Altitude Platforms equipped with video sensors are also used for fire detec-
tion and monitoring. Unmanned Aerial Vehicles (UAVs) have been proposed for surveillance
and monitoring applications in different scenarios. These applications require the develop-
ment of perception systems to perform autonomously detection and tracking functions. Fire
detection is a significant function in many scenarios in which UAVs play an important role.
For a fire detection mission, the UAV fleet is endowed with a tasks consisting of patrolling an
area. The task planner takes into account the characteristics of the UAV (payload and time of
flight) and the onboard sensors (field of view) to compute the paths to be assigned to each
one. Then, the autonomous detection relies on the ability of the system to detect the fire in
the images provided by the UAVs and to localize the alarm.
Aeronautics uses a civil UAV platform (Aerostar) with long flight endurance, equipped with a
FLIR camera, in order to detect small fires (new or spot fires) at long distances during day
and night and transmit alerts to the fire management authorities and the ground firefighting
teams (http://www.aeronautics-sys.com/?CategoryID=254&ArticleID=167). The UAV can be
also used to map the precise coordinates of the hottest points of the fire front in real time and
enhance the efficiency of the fire fighting operations. The UAV can also fly over burned areas
and scan for locating reigniting of the fire.

<?5@ A93%&.':%$$9*/&

Fire modelling is a significant tool for supporting preparedness, readiness and response to
any forest fire emergency. In computational science, forest fire modelling is concerned with
numerical simulation of the fire propagation based on fire behaviour characteristics. Forest
fire modelling can ultimately aid forest fire suppression, namely increase safety of fire-

© ESS Consortium 2009 183


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

fighters and the public, reduce risk, and minimize damage. Forest fire modelling can support
the protection of ecosystems, watersheds, and air quality as well.
With the forest fire modelling there is an attempt to reproduce the behaviour of the fire in the
forest, in order to assess the speed of the fire spreading, its direction as well as the fire line
intensity. The fire behaviour modelling supports also the estimation of potential fire transition
from the surface fuels (a "surface fire") to the tree crowns (a "crown fire"), as well as extreme
fire behaviour including blow-up of the fire spread, fire whirls, and tall well-developed convec-
tion columns. Fire modelling also attempts to estimate fire impact, such as the ecological and
hydrological effects of the fire, fuel consumption, tree mortality, and amount and rate of
smoke produced.
Meteorological factors, fuel type, and the terrain slope affect wild land fire behaviour. The
wind increases the fire spread in the wind direction, higher temperature makes the fire burn
faster, while higher relative humidity and precipitation (rain or snow) may increase fuel mois-
ture content and slow fire down or extinguish it completely. Weather involving fast wind
changes can be critical to fire fighting operations, since they can suddenly change the fire
direction and cause extreme fire behaviour. Such weather includes cold fronts, foehn winds,
thunderstorm downdrafts, sea and land breeze, and diurnal slope winds.
Forest fuel types include grass, shrubs, open and closed stands of conifers, hardwoods and
mixed forests. Small dry twigs burn faster while large logs burn slower; dry fuel ignites more
easily and burns faster than wet fuel. The forest fuels description is standardized in order to
be used in fire behaviour assessment models such as BEHAVE (Andrews, 1986). BEHAVE is
a non-spatial fire behaviour prediction tool which utilize inputs of fuel type, topography,
weather data, and initial fuel moisture data in order to calculate the fire behaviour and the fire
characteristics for a given area.
Topography factors that influence forest fires include the orientation toward the sun, which
influences the amount of energy received from the sun and the slope (fire spreads faster
uphill). Fire can accelerate in narrow canyons and it can be slowed down or stopped by bar-
riers such as creeks and roads.
BEHAVE has been operationally used in the US for predicting fire behaviour and subse-
quently mapping probable scenarios of fire spread during a given time period. In a similar
way Prometheus system was used in Canada for supporting prescribed burning and oper-
ational fire prevention and suppression activity. During the last decade several fire manage-
ment decision support systems have been developed in Europe as well. Most of them are
based in the BEHAVE system for assessing the fire behaviour. A set of equations is used to
simulate the propagation (shape and direction) of the fire front using an elliptical fire growth
model. These systems integrate fire danger rating with fire propagation calculations. Most of
them were developed in context of European R&D projects funded by the EC.
While more complex models have value in studying fire behaviour and testing fire spread in a
range of scenarios, from the application point of view, FARSITE and Palm-based applica-
tions of BEHAVE have shown great utility as practical in-the-field tools because of their ability
to provide estimates of fire behaviour in real time. GIS based fire simulators are considered a
valid operational option for addressing current fire management requirements in Europe as
well. G-FMIS (http://www.g-fmis.com/) is a forest fire simulator based in the BEHAVE system
which has been developed by ALGOSYSTEMS and tested in several EC countries in the
past. G-FMIS support forest fire risk assessment by estimating the potential spread of the fire

184 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

in an area within a certain time period. Topography, forest fuel map and actual meteorologi-
cal conditions are the required input of the simulation.
G-FMIS is included in the C4I system of the Greek Security Services for simulating forest fire
situations. The simulator can provide the user with estimations of the potential fire spread,
the expected fireline intensity and the respective flame length based on the topography,
weather conditions and forest fuel typology. The output of the model can be used for support-
ing decisions concerning the number and the type of resources required for addressing a
specific fire incident, the time available for controlling the situation. It can also support prop-
erly prevention planning and coordination of suppression operations.

<?5B =,,%,,0%*+&('3&E11&

In the frame of the ESS project, fire management information technology can provide com-
ponents such as forest fire simulation and forest fire detection and monitoring technology,
which can be integrated in the mobile platform or the back-office system of ESS.

Table 22: References on Forest Fire Managemenet

Further References
Darko Stipani#ev, Tomislav Vuko, Damir Krstini$, Maja %tula, Ljiljana Bodro&i$. Forest Fire
Protection by Advanced Video Detection System - Croatian Experiences. Department for
Modelling and Intelligent Systems.
Klaver R.W., Singh A., Fosnight E.A. - Global Forest Fire Watch: Forest fire potential, detec-
tion, monitoring and assessment. United Nations Environment Programme. EROS Data
Center EROS Data Center Sioux Falls, SD, US Sioux Falls, SD, US
Kührt E., Knollenberg J., Mertens V. , An automatic early warning system for forest fires,
Annals of Burns and Fire Disasters - vol.XIV - n. 3 - September 2001
Martinez-de Dios J.R., B. C. Arrue and A. Ollero. Distributed intelligent automatic forest-fire
detection system. INNOCAP’99, 28th of 29th of April, Grenoble
Martínez-de Dios J. Ramiro, Merino Luis and Ollero Aníbal. Fire detection using autonomous
aerial vehicles with infrared and visual cameras

© ESS Consortium 2009 185


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

<@ K!\&=;+9>9+9%,&('3&E0%3/%*;4&."*"/%0%*+&
International Telecommunication Union (ITU) is the leading United Nations agency for infor-
mation and communication technology issues, and the global focal point for governments
and the private sector in developing networks and services (http://www.itu.int). For ESS, it is
very important to reflect on past activities undertaken by ITU for the standardization of emer-
gency telecommunications and for the handling of crisis situations, as it helps to ground ESS
developments to a more realistic level. The following sections provide a good overview on
these activities and shall be seen as a portfolio of aspects highly relevant in crisis manage-
ment situations from the perspective of the telecommunication business. Note: the following
sections are based on “ITU News Year 2007 Number 10” and on other references mentioned
in the text.

<@5- G>%3>9%`&#4&K!\&1%;3%+"34&C%*%3"$&

In 2007 the dr. H.I. Touré (ITU Secretary-General) stated that ITU made emergency tele-
communications one of his three priorities (along with closing the digital divide and cyber-
security).
Information and communication technologies (ICT) play a vital role in ensuring that relief
teams go about their activities effectively for the benefit of disaster victims, but this requires
national, regional and international cooperation. For this purpose ITU launched the Frame-
work for Cooperation in Emergencies (IFCE). This flagship initiative was an important tool for
coordinating the development and deployment of telecommunications and ICT resources for
disaster relief. The IFCE is built on three pillars: technology, finance and logistics.
After disasters, ITU Telecommunication Development Bureau has sent equipment to assist
affected countries, providing basic telecommunications and telemedicine applications via
satellite. The ITU Telecommunication Standardization Sector is developing new technical
standards for manufacturers to make equipment that can work within and across borders for
disaster monitoring and management.
The World Radiocommunication Conference (in 2007) also took important steps to make
faster response to disasters. ITU is handling a database of available frequencies for use in
emergencies, in collaboration with Member States, who have been urged to provide, on a
voluntary basis, up-to-date information concerning their national frequency allocations and
spectrum management practices for emergency and disaster relief.

<@5< &h1">9*/& $9>%,ie& C$'#"$& A'320& '*& +8%& 3'$%& '(& +%$%;'002*9;"+9'*,&
"*:&K)!&9*&:9,",+%3&0"*"/%0%*+&&&

ITU organized a Global Forum on Effective Use of Telecommunications/ICT for Disaster


Management: “Saving Lives”, that took place in Geneva on 10–12 December 2007. The
participants have discussed and mapped out strategies and adopted practical measures for
using ICT in disaster early warnings, preparedness, and relief and response, as well as re-
habilitation of telecommunication networks. The forum adds to progress made at the United

186 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Nations International Meeting to Review the Implementation of the Programme of Action for
the Sustainable Development of Small Island Developing States (Mauritius, 10–14 January
2005), and the World Conference on Disaster Reduction (Kobe, Japan, 18–22 January
2005). It is also based on a series of meetings that focused on the establishment of a tsu-
nami early-warning system for the Indian Ocean, as well ITU workshops on emergency tele-
communications and disaster mitigation (see article "Sharing experience, coordinating a re-
sponse").
Besides the Forum saw the launch of new ITU activities. These include:
• ITU Framework for Cooperation in Emergencies (IFCE)
• ITU Network of Volunteers for Emergency Telecommunications
• New partnerships: ITU signed 12 partnership agreements, which focus on co-
financing future activities, aimed at mitigating the impact of disasters through the use
of emergency telecommunications.
For the disaster management and mitigation a multi-disciplinary and multi-sectoral approach
is applied.
At the end of the Forum, the participants endorsed the outcomes of the Forum and declared
that:
“a) While natural disasters cannot be entirely prevented, ITU and partners through telecom-
munication/information and communication technologies (ICT) should help reduce their im-
pact through monitoring, detection, and prediction of hazards and impending disasters in-
cluding limiting the impact of global warming and climate change.
b) The effort towards bridging the digital divide and the creation of a truly global information
society should be closely linked with emergency telecommunications for the dissemination of
information to raise awareness on disaster preparedness, for early warning, and for disaster
relief.
c) Effective policies and regulations are essential in support of deployment and use of tele-
communications/ICT for disaster mitigation and management. The regulatory regime has to
be continuously reviewed, and where other barriers to the use of telecommunication re-
sources for disaster response and relief exist, these should be addressed. These barriers
could include, but not limited to, regulations restricting the movement of telecommunications
equipment and personnel, at both national and international levels, and regulations on the
use of relevant frequency spectrum should be in accordance with the ITU Radio Regulations.
It is important that while governments develop policies on disaster management, that the use
of telecommunications/ICT resources is at the core of such planning. The World Radiocom-
munication Conference (WRC-07) and Radiocommunication Assembly (R-7) approved sev-
eral resolutions on the use and further development of Radiocommunication systems in risk
assessment and disaster mitigation. Countries are encouraged to contribute to ITU-R studies
called by these Resolutions.
d) It is essential for the relevant ITU-D Study Question dealing with emergency telecommuni-
cations, relevant ITU-D Programme in coordination with other relevant Programmes to ad-
dress the issue of regulation for emergency telecommunications. Accordingly, ITU/BDT will
take the issue of regulation to the 8th Global Symposium for Regulators (GSR) and the Glo-

© ESS Consortium 2009 187


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

bal ICT Industry Leaders Forum which will be held in Thailand from 11-13 March 2008 as
well as, to future GSRs.
e) Harmonization of rules and regulations and/or spectrum usage must be consistent, or in
conformity with, existing International Telecommunication Union’s rules and regulations.
f) Cooperation and coordination at international, regional and national levels is essential for
effective use of telecommunications/ICT and alerting as well as disaster response/relief as it
maximizes the use of limited resources and save lives. The cooperation should involve gov-
ernment authorities, United Nations Agencies, non-governmental organizations. The private
sector especially ITU Sector Members play a very important role in this cooperation by con-
tributing resources to humanitarian teams.
g) The ITU/IFCE through its three clusters serves as an essential mechanism for effective
deployment of telecommunication resources to countries requiring assistance in the immedi-
ate aftermath of disasters, humanitarian organizations, and local communities.
h) Under the IFCE, ITU is encouraged to provide telecommunications/ICT facilities to its
Member States and other entities and stakeholders involved or affected by disasters in a fair
and neutral manner. These telecommunications/ICT resources should, at the request of an
ITU Member State, be deployed at the site of a natural disaster within the first 48 hours.
i) Member States and ITU-D Sector Members as well as non-sector members including VET
are called upon to support and cooperate with ITU/BDT with regard to the implementation of
the IFCE since ITU/BDT is mandated to tap resources from its membership including Sector
Members and non-sector members to attract inputs into the IFCE, as well as work with the
other two ITU Sectors in order to ensure coordination.
j) The Technology Cluster of the IFCE should consist of all possible technology service pro-
viders and operators such as Satellite Operators and Land Earth Station Operators, Tele-
communications Operators especially Mobile Service Providers, Remote Sensing applica-
tions/services providers, radio communication equipment providers/manufacturers, TV/Radio
broadcast, amateur radio, and community-based communication organizations, providers of
telemedicine for social and medical services. Different technologies should be made avail-
able for emergency telecommunications and should be easily deployed in a timely manner
when disasters strike. As much as possible the use of existing infrastructure, telecommunica-
tion/ICT systems, and frequencies allocated for emergencies should be optimized.
k) A stand-by fund for emergency telecommunications under the Finance Cluster otherwise
referred to as Emergency Telecommunications Fund (ETF) should be established under the
Finance Cluster of the IFCE. The Fund will finance disaster-related initiatives and activities
including, but not limited to, deployment of equipment and financing air-time. Possible fund-
ing sources may come from Member States in terms of Funds-In-Trust, regional economic
groups, development banks, and the private sector. In this regard, Save Life Short Message
Service (SLSMS) demonstrates a good concept and should be used for public participation in
contributing resources into the Fund. The SLSMS presupposes that when a disaster strikes,
individuals and corporations send SMS to their service provider contributing a specified
amount which they can be levied on their next bill. The service provider will then remit the
funds to the Disaster Fund. Other proposals were made calling for innovative ideas on rais-
ing financing for emergency telecommunications such as the drafting of bankable projects
and also ensuring that the High Level Panel on Emergency Telecommunications gets fully

188 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

involved in facilitating in this process, and a proposal for a ‘one-day’ salary contribution by
individuals to contribute towards the financing of emergency telecommunications.
l) Transport providers such as air freight companies and international couriers play an im-
portant role in facilitating the deployment of telecommunications/ICT resources in times of
emergencies. ITU/BDT should pursue Service Agreements with many partners in the logis-
tics industry that would transport equipment at negotiated rates under its IFCE’s Logistics
Cluster.
m) Remote sensing systems by satellite are invaluable sources of information for decision
making in disaster management especially for initial assessments of the nature and magni-
tude of damage and destruction in the aftermath of disasters thereby saving lives and prop-
erty. Some of the most significant progress in disaster reduction is being made in mitigation
using historical and contemporary remote sensing data in combination with other geospatial
data sets as input to predictive models and early warning systems.
Therefore, emergency telecommunications should use remote sensing applications and ser-
vices. Work of the ITU-R in Remote Sensing in addition to the work under ITU-D Study
Group 2 Question 22/2 on the Utilization of ICT for disaster management, resources, and
active and passive space-based sensing systems must be continued and supported to
achieve its objectives working in close cooperation with the relevant Study Groups in ITU-R
n) ITU should provide assistance to developing countries and in particular, Small Islands De-
veloping States and Least Developed Countries in the development of National Emergency
Telecommunication Plans (NETP) and related Standard Operating Procedures (SOPS).
Regular training workshops on emergency telecommunications covering disaster prepared-
ness including early warning systems, disaster response, and reconstruction should be pro-
vided at national, regional and international levels. ITU-T X.1303 Common Alerting Protocol
(CAP) based on OASIS CAP V1.1 standard is a useful tool in this regard as it is a simple,
lightweight XML-based schema that provides a general-purpose format for the exchange of
emergency alerts for safety, security, fire, health, earthquake and other events over any net-
work. CAP also associates emergency event data (such as public warning statements,
photographs, sensor data with basic metadata such as time, source and level of urgency,
and with geographic locations).
o) ITU, through its Telecommunication Standardization activities should continue to work on
the harmonization of national emergency number.
p) The Global Forum on the Use of Telecommunications/ICT for Disaster Management: Sav-
ing Lives should be held regularly, every two years, to ensure that emergency telecommuni-
cations adapt to rapid technological changes and pave way for the use of innovative multi-
hazard solutions, mapping of effective emergency telecommunications strategies by count-
ries, and facilitation of information sharing among countries and humanitarian actors.
ITU/BDT should use this Forum to present the plan and progress of each cluster to ensure its
transparency and accountability.
q) Increased assistance should be provided to developing countries as a way of enhancing
their capacity to develop and deploy appropriate systems for disaster management taking
into account the special needs and challenges of Land-Locked Developing Countries, Small
Islands Developing States, economies in transition, and Least Developed Countries.

© ESS Consortium 2009 189


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

r) The Telecommunication Development Bureau (BDT) should sustain the current momen-
tum of promoting and enhancing the participation of multi-stakeholders in emergency tele-
communications, and should continue to coordinate and facilitate the creation of partnerships
between governments and private enterprise, and between all other stakeholders involved in
the deployment and use of telecommunications in humanitarian work.
s) Member States are encouraged to consider resolutions with regard to disaster manage-
ment and take into consideration, if appropriate, the ratification and implementation of the
Tampere Convention while observing domestic legal requirements. ITU/BDT should continue
providing assistance required by the Member States in the ratification and implementation of
the Tampere Convention in accordance with ITU Plenipotentiary Conference (PP-06) Reso-
lution 36, and the World Telecommunication Development Conference (WTDC-06) Resolu-
tion 34.“

Table 23: ITU Article on emergency telecommunications

Topic Reference
ITU: Sharing experience, coordi- http://www.itu.int/itunews/manager/display.asp?lang=e
nating a response n&year=2007&issue=10&ipage=regionalPercepctive&e
xt=html

<@5? K!\j,&3'$%&9*&%0%3/%*;4&+%$%;'002*9;"+9'*,&

ITU, as the United Nations specialized agency for telecommunications and ICT, is dedicated
to ensuring that communications are at hand when they are needed most in emergencies
and disasters. Each of ITU’s three Sectors is involved in this effort, as resumed hereafter.

<@5?5- D":9';'002*9;"+9'*,&SK!\XDT&

To reduce the impact of disasters, it is essential to quickly disseminate authoritative informa-


tion before, during, and after each event. Radiocommunications make this possible, but the
airwaves need to be managed appropriately in order for governments and humanitarian
workers to respond effectively to emergencies.
Activities by ITU’s Radiocommunication Sector (ITU–R) make an invaluable contribution to
disaster management. They help in predicting and detecting disasters, and in providing early
warnings, through coordinating the effective use of the radio-frequency spectrum and by the
establishment of radio standards and guidelines concerning the use of radiocommunication
systems.

190 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

<@5?5< 1+"*:"3:9L"+9'*&SK!\X!T&

The ITU global standards also play a vital role in ensuring an effective emergency response
in times of crisis. For example, a number of Recommendations have been developed by
ITU’s for call priority schemes that ensure relief workers can make contact.
Fixed and mobile telecommunication networks incorporate a feature that can give priority to
calls from specially authorized users in the event of a disaster. Based on an ITU protocol, the
International Emergency Preference Scheme (IEPS) ensures that preference is given to calls
made by personnel involved in directing and coordinating relief operations. IEPS is now also
operational for new technologies such as Internet protocol-based networks, cable networks
and next-generation network systems.
In addition, standards for delivering emergency alerts are being developed for the various
communication systems defined by ITU.

<@5?5? H%>%$'70%*+&SK!\XHT&

ITU–D considers emergency communications to be an integral part of its agenda. Much effort
is directed at promoting disaster management as part of ICT projects, such as appropriate
infrastructure development and the establishment of enabling policy, legal and regulatory
frameworks.
In the immediate aftermath of disasters, equipment is sent to assist affected countries, pro-
viding basic telecommunications and telemedicine applications via satellite.
Reconstruction and rehabilitation of networks is another important task of ITU–D.

Table 24: Details on ITU–T’s work in emergency telecommunications

Topic Reference
ITU–T’s work in emergency telecom- http://www.itu.int/itunews/manager/main.
munications asp? lang=en&iYear=2006&iNumber=06

<@5@ !8%&!"07%3%&)'*>%*+9'*&&

In Tampere (Finland), 225 delegates from 75 countries gathered in June, 1998, for the Inter-
governmental Conference on Emergency Telecommunications. That landmark meeting cul-
minated in the adoption and signing of the Tampere Convention on the Provision of Tele-
communication Resources for Disaster Relief and Mitigation and Relief Operations — the
world’s first global treaty recognizing the vital importance of communication technology in
humanitarian crises.
The Tampere Convention came into force on 8 January 2005, following its ratification by 30
States just two weeks after the massive Indian Ocean tsunami in December 2004. It has
been ratified by a total of 36 countries to date. The United Nations Secretary-General is the
Depository of the Convention.

© ESS Consortium 2009 191


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

The Tampere Convention seeks to expedite the use of information and communication tech-
nologies (ICT) by emergency teams, by allowing for the temporary waiving of national laws
covering the importation, licensing and use of communications equipment. It also assures
legal immunity for aid workers using emergency ICT systems in responding to disasters.
The treaty provides for improved disaster preparedness by creating a mechanism for the
sharing of information and best practice. In addition, it sets out a clear framework for interna-
tional cooperation, managed by ITU through national focal points.
Even though telecommunications can save lives following disasters, regulatory barriers can
make it difficult to use the necessary equipment. ITU was a driving force in drafting and pro-
moting the Tampere Convention. It calls on States to waive regulatory barriers that impede
the use of ICT. These barriers include licensing requirements to use frequencies, restrictions
on importing equipment, and limits on the movement of humanitarian teams.

<@5B K!\&3%,7'*:,&+'&*"+23"$&:9,",+%3,&

When communication infrastructure is damaged or destroyed during a natural disaster — or


when it is lacking in remote areas — links need to be established quickly so that help can be
organized as swiftly and efficiently as possible. In addition, damage assessments must be
carried out and future communication systems planned with disaster preparedness in mind.
ITU is responding to these needs following major disasters around the world. Some events,
such as floods in Africa and the death and destruction wrought by a tropical cyclone in Ban-
gladesh, bring home the urgency with which challenges need to be addressed.

<@5B5- A$'':,&9*&]"*/$":%,8&

ITU has sent 30 satellite terminals to help restore vital communication links in remote areas
of Bangladesh, which has been ravaged by severe floods. Response efforts have been ham-
pered by damaged roads and airstrips, and lack of telecommunication facilities.
ITU pays for all expenses, including the transportation and usage of equipment, and training
of personnel. The terminals, which are from Thuraya Satellite, are dedicated mainly to voice
communication. They are equipped with solar panels to provide an independent source of
energy.

<@5B5< \/"*:"*&($'':,&&

In October 2007, ITU deployed 25 satellite terminals to help restore vital communication links
following severe floods that affected the eastern and northern regions of Uganda from Au-
gust 2007. Several districts were ravaged by torrential rains and flash floods that swept
through the country taking lives, marooning over 140 000 people, destroying roads and sub-
merging crops.
The mobile terminals were transported by helicopter to serve people most in need. ITU pro-
vided Thuraya handheld satellite phones and Inmarsat GAN (Global Area Network) termi-
nals. The phones use both satellite and GSM (Global System for Mobile communications)

192 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

networks, and can provide accurate global positioning coordinates to aid relief and rescue.
The terminals were mainly used for voice communications and, in some cases, for high-
speed data. ITU paid all expenses for the transportation of the equipment and its usage.

<@5B5? K*:9"*&G;%"*&+,2*"09&

The worst natural disaster in recent years was the Indian Ocean tsunami that struck on 26
December 2004. ITU played its part in offering practical help for survivors and by helping to
plan the restoration of networks.
With its partner Inmarsat, ITU sent 14 portable GAN satellite terminals to Sri Lanka, for em-
ergency use while telecommunication infrastructure was rebuilt. ITU also sent an expert to
Thailand to train technicians in the use of the terminals.
ITU provided USD 250 000 from its TELECOM Surplus Fund for a project to provide expert
services to the tsunami-hit countries of Indonesia, Maldives and Sri Lanka. The money was
used to help carry out an assessment of telecommunication infrastructure in the affected
areas, prepare a rehabilitation plan, and help develop a national plan for emergency tele-
communications as part of the tsunami early-warning system for the Indian Ocean.
The Government of Australia made a voluntary contribution to ITU of CHF 500 000 for plan-
ning the rehabilitation of telecommunication infrastructure and an early-warning system for
the countries affected by the tsunami. This contribution went a long way towards assisting
with work on disaster preparedness.

<@5B5@ 1+2:4&'(&%0%3/%*;4&+%$%;'002*9;"+9'*,&9*&]"*/$":%,8&

Bangladesh was not seriously affected by the 2004 tsunami, but it is at risk of such a disas-
ter, and others. After the tsunami, the Bangladesh Telecommunication Regulatory Commis-
sion (BTRC) asked ITU to assess the country’s telecommunication network in the context of
disasters. This was followed by an additional request to ITU in 2007 to conduct a case study
in Chittagong of emergency telecommunications and early-warning systems. It should act as
a benchmark for the development of disaster preparedness for other communities in Bangla-
desh.

<@5B5B 6"N9,+"*&%"3+8b2"N%&

Immediately following the massive earthquake that struck the Pakistan-India border area in
October 2005, ITU sent 55 satellite terminals to help restore vital communication links. The
terminals were used to coordinate relief and rescue operations, and to help establish public
call centres for people seeking news of their loved ones.
Fifteen of the terminals were of the GAN type and from ITU’s stock, procured following the
signing of a co-financing agreement with Inmarsat Limited, which also contributed a further
40 regional broadband global network (RBGAN) satellite terminals, free of charge. ITU
undertook the responsibility of transporting and deploying all 55 terminals, as well as paying
for all the air time arising from their use.

© ESS Consortium 2009 193


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

The 15 GAN terminals provided voice, data and video services, and the 40 RBGAN terminals
provided high-speed data communications. All were charged by solar panels, as the public
power supply was badly damaged during the earthquake. ITU trained local personnel how to
operate the terminals. Training was also provided to physicians at a hospital in Rawalpindi on
using the RBGAN terminals that were later deployed by medical teams to help injured people
in remote areas. Diagnostic information on patients was transmitted via satellite to hospitals,
for expert analysis and advice.

<@5B5I A$'':,&9*&1239*"0%&

Heavy rains fell on Suriname in May 2006, causing several major rivers to rapidly rise and
submerge an area estimated at 30 000km2. ITU deployed satellite terminals to the country in
response to a request from its government. The equipment helped the flow of information
among humanitarian workers in the field. The satellite terminals were charged by solar pan-
els and supported voice, high-speed data and video applications.

<@5B5J K*:'*%,9"*&%"3+8b2"N%&

On 27 May 2006, a major earthquake struck the island of Java, in Indonesia, killing some
6000 people, injuring thousands more, and making more than 1.5 million homeless. In part-
nership with the United Nations Satellite Agency (UNOSAT), ITU assisted the government of
Indonesia with the provision of satellite imagery, mapping services and training for the recon-
struction and protection of telecommunication networks. The high-resolution geographical
mapping allowed vulnerable zones to be identified and new networks planned.

<@5B5R E0%3/%*;4&>%89;$%,&('3&139&O"*N"&

Following a request by the Telecommunications Regulatory Commission of Sri Lanka for


assistance in guiding the development of mobile emergency communication vehicles, in July
2007, ITU provided a consultant to undertake the study and prepare an investment project.

<@5B5U E"3+8b2"N%&9*&6%32&

The only radio station in the Pacific island country of Nauru has lost its transmission capabili-
ties due to a fire and aging equipment. The Government of Nauru asked ITU to replace and
enhance the existing FM transmitter and its components, with the aim of providing an early-
warning system in emergencies and disasters, in addition to a news service. In November
2007, ITU provided consultants to study Nauru’s requirements and make recommendations
on the design and specifications for the FM broadcasting system.
Following the devastating earthquake measuring 7.9 on the Richter scale that struck south-
ern Peru on 15 August 2007, ITU deployed 50 satellite terminals (12 GAN and 38 RBGAN) to
help restore vital communication links in remote areas. Mountainous terrain in Peru severely
hampered access by relief teams and the coordination of rescue operations. The restoration
of telecommunication resources helped to bridge gaps and provide for the transmission of

194 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

high-speed data and voice communications. ITU was responsible for transporting and de-
ploying all the terminals, as well as paying for the airtime used.

<@5B5-[ ]%++%3&$9*N,&9*&+8%&."3,8"$$&K,$"*:,&

In the Marshall Islands, the Ministry of Transport and Communications asked ITU to under-
take a pilot project in establishing community telecentres, not only to improve links with rural
communities, but also to enhance disaster preparedness and response. The aim is to identify
a model, which is technically, socially and economically viable in the Pacific island country. In
September 2007, ITU provided a consultant to carry out the study and recommend technol-
ogy options and an investment plan for communication infrastructure and services in a re-
mote island.

<@5I P'3$:&D":9';'002*9;"+9'*&)'*(%3%*;%&SPD)X[JT&

The World Radiocommunication Conference (WRC-07) that took place in Geneva on 22


October–16 November 2007 ended with the signing by 155 countries of revised and updated
Radio Regulations, the international treaty governing the use of the radio-frequency spec-
trum and satellite orbits.
Rapid technological developments and growth in the information and communication tech-
nologies (ICT) sector have fuelled the demand for radio-frequency spectrum. WRC-07 con-
sidered some 30 items, dealing with almost all terrestrial and space radio services and appli-
cations. These included International Mobile Telecommunications (IMT) — the concept that
embraces advanced broadband mobile technology for use on a global basis, systems in the
fixed- and broadcasting-satellite services, aeronautical telemetry and telecommand systems,
meteorological applications, maritime distress and safety signals, digital broadcasting, and
the use of radio in the detection of natural disasters.
One of the main issues for WRC-07 was the consideration of new allocations and identifica-
tion of spectrum for International Mobile Telecommunications (IMT). This is the name of
ITU’s vision of global mobile access, encompassing both IMT-2000 (also known as 3G) and
IMT-Advanced. New spectrum was sought to expand coverage and capacity for future IMT
development.
The conference identified the band 450–470 MHz for IMT. This band is extensively used for
private mobile networks and may not be available for IMT in Europe and the Americas until
these networks have migrated to other frequency bands.
A significant result of the conference is the additional allocation of the band 790–862 MHz to
the mobile service in those parts of the world where such allocation was not yet available.
This made possible the identification of spectrum within the upper part of the UHF band
(470–862 MHz) spectrum for mobile broadband services, as well as spectrum in the higher
frequency bands for the next generation of advanced mobile services.
Several agenda items were related to further development of science services. The confer-
ence extended existing primary frequency allocations for Earth-exploration satellite services
(EESS). This should facilitate research and exploration of the environment and Earth’s re-
sources. Although only a few countries operate scientific and meteorological satellites, EESS

© ESS Consortium 2009 195


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

are key global assets that serve the world as a whole. As well as being used to monitor re-
sources, they are invaluable in the prediction and monitoring of natural disasters, for meteor-
ology and in the monitoring and prediction of climate change.

<@5J )'07%*:920&'(&K!\j,&`'3N&9*&E0%3/%*;4&!%$%;'002*9;"+9'*,&

In October 2007 ITU issued the “Compendium of ITU’s work in Emergency Telecommunica-
tions”, i.e. a publication that presents for the first time the work done by ITU’s three Sectors
(Radiocommunication, Telecommunication Standardization, and Telecommunication Devel-
opment) in the field of Emergency Telecommunications.
The publication is comprehensive and contains factual information, well organized for easy
access, particularly by practitioners in the area of disaster management. It simplifies the
complex technical issues that characterize the rapidly evolving field of telecommunication /
information and communication technologies.

<@5R K!\X!&D%;5&W5-?[?&S)'00'*&=$%3+9*/&63'+';'$T&&

In 2007 ITU-T issued a prepublished version of Rec. X.1303 Common Alerting Protocol (CAP
1.1), that is based on OASIS Standard CAP (see clause 9.2 Common Alerting Protocol). The
Scope of this ITU-T Spec is described in its “Summary”, reported hereafter.
“The common alerting protocol (CAP) is a simple but general format for exchanging all-
hazard emergency alerts and public warnings over all kinds of networks. CAP allows a con-
sistent warning message to be disseminated simultaneously over many different warning
systems, thus increasing warning effectiveness while simplifying the warning task. CAP also
facilitates the detection of emerging patterns in local warnings of various kinds, such as
might indicate an undetected hazard or hostile act. CAP also provides a template for effec-
tive warning messages based on best practices identified in academic research and real-
world experience.
This Recommendation also provides both an XSD specification and an equivalent ASN.1
specification (that permits a compact binary encoding) and allows the use of ASN.1 as well
as XSD tools for the generation and processing of CAP messages. This Recommendation
enables existing systems, such as H.323 systems, to more readily encode, transport and
decode CAP messages.”

196 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

<B D%$"+%:&63'a%;+,&
A number of research and development projects have been identified and further investi-
gated in order to round up the overview of important technologies and approaches relevant
to ESS. Those projects are shortly introduced in the following section.

<B5- Y\.]GOH!&

HUMBOLDT is a four-year (2006 – 2010) EU project that contributes to the implementation


of a European Spatial Data Infrastructure that integrates the diversity of spatial data available
for a multitude of European organisations. To achieve this objective, primary focus is on the
development the software tools and processes to demonstrate the advantages of spatial data
infrastructures.
The main software components of the spatial Web services are the Mediator service (a proxy
service that executes transformation chains to provide harmonised geodata), the Workflow
service (a service that analyses data sets and decides which processing is required to match
a target product description), the context service (an easy to use service that can be used to
define transformation products). Furthermore, HUMBOLDT develops several transformation
services exposed as OGC Web Processing Services, such as Coordinate Transformation
Service and Edge Matching Service. Especially the Edge Matching Service aligns edges and
points of vector geometries so that they will be gapless (in other terminology also called
seamless). It has two modes of operation Align-to-Reference and Distribute-Errors, which
can be used when there are no reference data sets that can be used as “ground truth”. The
HUMBOLDT project (on the contrary to the ESS project) solves especially the services that
will be used on the underlying data sets instead of the combination spatial Web services it-
self. Development of the derived databases from the Web services, metadata integration as
well as sensor Web services are also out of the scope of this project.

<B5< 1=Qf&

SANY (Sensor Anywhere) was the three-year (2007 – 2009) integrated EU project that fo-
cuses on interoperability of in-situ sensors and sensor networks, and assuring the sensor
data can be easily processed and used as a basis for decision making. SANY uses envi-
ronmental application to verify the proposed principles of the SANY services – i.e. self-
describing and capable of seamless “plug and measure” and sharing (“virtual networks”).
Reference implementations of re-usable sensor- and domain-agnostic services, including
decision support and generalized data fusion services were created as one of the results.
Besides, all above mentioned implementation were tested in three risk management applica-
tions covering the areas of air pollution, marine risks and geo hazards. The spatial Web ser-
vices are used to integrate observation data, contextual data and phenomenological models
from different sources in order to obtain new environmental information where and when
sensor measurements are not available. It is obvious, that only a small part of the research
has been related to the combination of the sensor data and data coming from the spatial
Web services. Thus, this gap is a challenge to be solved in the ESS project. On the other

© ESS Consortium 2009 197


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

hand, ESS uses the results of the SANY project in the field of sensor networks integration
and extends them in a new application domain of the emergency management. More infor-
mation about this project can be found on the website http://www.sany-ip.eu.

<B5? G1KDK1&

OSIRIS (Open architecture for Smart and Interoperable networks in Risk management based
on In-situ Sensors) provides a service oriented architecture addressing the smart deploying,
use and reconfiguration of in-situ sensor system and was solved in the years 2006 – 2009.
One of the three most important research streams was to product and delivery the services
which are using sensor data to enhance monitoring, preparation and response phases of
Environmental Risk – Crisis Management. OSIRIS project has done the implementation of
the Sensor Web Enablement (in that time the set of drafts from the Open Geospatial Consor-
tium). Results of these projects were the inputs to the SANY project at the same time. Archi-
tecture of OSIRIS system was highly focused on the sensor part, while combination with
other Web services was out of the scope. All specific parts about spatial and sensor data
harmonization and fusion were not solved. More information about this project can be found
on the website http://www.osiris-fp6.eu.

<B5@ G=1K1&

OASIS (Open advanced system for disaster and emergency management) represents an EU
6th Framework Programme project from the years 2004 – 2008. The aim of the OASIS pro-
ject was to define and develop a first version of an open, modular and generic Disaster and
Emergency Management system. Definition of the OASIS architecture was also based on the
services. Unfortunately the services were used mostly for the exchange of the textual infor-
mation, support of the spatial Web services was not widely considered. More information
about this project can be found on the website http://www.oasis-fp6.org (at the time of this
state-of-art creation out of service).

<B5B QK6K&

NIPI (Národná infra'truktúra priestorov(ch informácií; National Infrastructure for Spatial In-
formation) is the establishment of the Slovak national spatial data infrastructure, including
data harmonization, metadata, Web services and related policies. These issues were solved
in the research project called “Tools for integration and distributed usage of geospatial infor-
mation” between years 2004 – 2007. Primary aim of this project was to explore the possibili-
ties of the INSPIRE (INfrastructure for SPatial InfoRmation in Europe) compliant spatial data
infrastructure development while focusing on environmental applications. Results can be
used as the input methodology – i.e. establishment of the infrastructure from contemporary
resources in the ESS project. On the contrary, NIPI has not solved the sensor networks,
other application fields than the environmental, neither the semantic Web services.

198 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

The ESS project has discovered the gaps between above mentioned projects and therefore
in the field of spatial Web services aims mainly at:
• Integration of the research that is close to the Sensor Web Enablement and spatial
Web services used for so-called long-life data (i.e. background data that are used as
reference maps). Almost all above mentioned projects solved (or are still solving) ser-
vices just for the sensor part or for the spatial Web services part separately. A little ef-
fort has been addressed to the effective communication between sensor data ser-
vices and general spatial services based on geographical data sets so far.
• Fusion of spatial data from heterogeneous Web services and creation of a duplicate
database that can be used for the emergency management applications. Develop-
ment of a duplicate database from the fused spatial Web services is a specific task –
in the case of the emergency it cannot be relied on the existing data sources and ser-
vices, but a “backup” database has to be accessible during the whole time of the em-
ergency event. This task automatically requires development of the services fusion
methodology which has not been covered by the above mentioned projects.
• Sensor registration to the catalogue service. This issue was partly solved in the
SANY project, however the communication between sensor and a catalogue service
according to the OGC needs more research and development to achieve an efficient
way of communication. Different metadata (which are the inputs to the catalogue ser-
vice) for sensor data and general spatial data sets causes the barriers of their com-
mon use in one searching interface. This task contains an application of automatic
discovery of the sensors that were added to the sensor network.
• Ontologies and their connection to the spatial Web services. Research focused on
so-called semantic Web services (enriching Web services with machine-processable
semantics) will be a part of ESS project to achieve dynamic, scalable and cost-
effective infrastructure for electronic translation. This approach uses ontologies,
which provide hierarchy and matching of the semantic terminology, i.e. are a key to
linking conceptual real-world semantics defined and agreed upon by communities of
users.

<B5I PK1E)G.&

Wireless Infrastructure over Satellite for Emergency COMmunications (WISECOM) is a


European project founded using the STREP instrument inside the 6th Framework Program
(Information Society Technologies).
“It studies, develops, and validates by live trials candidate rapidly deployable lightweight
communications infrastructures for emergency conditions (after a natural or industrial haz-
ard).” (WISECOM WEB site)
The main aim of the WISECOM project was the development of a lightweight telecommuni-
cation infrastructure in order to provide early communications infrastructures (before the first
24 hours after an emergency event occurs).
The basic choice of the WISECOM project is to use bi-directional satellite telecommunication
systems as bridge between intact telecommunication infrastructures and the legacy terminals
in the hands of people and rescue workers inside the location of the disaster.

© ESS Consortium 2009 199


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

“The aim of WISECOM is to develop and test an instantly deployable micro-cell base station
providing GSM or 3G coverage and wireless data access (e.g. WiFi) that can be carried by
one person on board a flight and be deployed within minutes. The backhaul connection to the
intact network infrastructure is realized by means of a satellite link. Such a system could be
set up anywhere in the world where there is satellite coverage; the satellite technology identi-
fied for this purpose is Inmarsat BGAN, providing essentially global continuous coverage.
This solution for the very first hours and days after an emergency should be replaceable by a
medium-term unit that allows higher capacity and lower usage costs than the portable one. It
may be used for days or weeks during the recovery phase, with connection ensured by
means of a broadband satellite DVB-RCS link.” (WISECOM WEB site)
The general WISECOM architecture is described in the following picture (taken from project's
site).

Moreover the architecture provides Location Based Services (LBS) mainly for logistics and
search/rescue operations.
Because most of the technical information about the architecture is confidential, it is difficult
to compare this project with ESS. For example it is not possible to compare their LBS solu-
tion with the ESS approach.
Compared to the ESS architecture, the WISECOM does not make use of on-field sensors in
order to provide an automatic environmental monitoring. This is an important aspect in logis-
tics and rescue operations.
Moreover ESS is a framework where most of the key services aremade available through
standard interfaces based on Internet protocols and using the WEB distributed architecture.
In this sense ESS is not bound to a specific communication technology. In order to provide
services that are not reachable through Internet (for example SMS broadcasting), ESS will
provide relevant interfaces in order to developspecific gateways.
However the WISECOM developed architecture may be integrated inside the ESS frame-
work as one of the possible solution to provide Internet connectivity necessary for human

200 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

communications and also to provide the Internet between the sensors and the ESS core
components.

© ESS Consortium 2009 201


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

<I )'*;$2,9'*,&('3&E11&
The state-of-the-art report gave an overview of the latest discussions in a selected portfolio
of technological, strategic, and organizational domains. This last chapter will briefly reflect
the most important aspects. It will layout a first strategy for the further advancement in regard
of selected technologies. It will provide guidance on aspects that shall be addressed by ESS
in particular to develop a system that sets apart from all existing emergency management
and crisis situation handling systems.
With the OGC framework of service interfaces, encodings, and formats, ESS can built on a
reference framework that is perfectly suited to integrate and process heterogeneous sources,
formats, and models. The crisis situation immanent demand to integrate large data sets of
sensor data in order to get the situational picture that is base to so many decision making
process requires a fast deployment and dynamic adaptation to new sensors and devices at
runtime. The well-harmonized Sensor Web Enablement suite in conjunction with well-tested
and robust services such as the Web Mapping Service can serve as a base layer for the ESS
architecture, but need to be concretized in crisis and emergency situation specific profiles.
Those currently non-existent profiles would allow rapid modifications in the ITC layer of the
management model.
In addition to concrete profiling, another challenge ahead for ESS is the optimal integration of
OGC technologies with standards provided by OASIS, OMG, and W3C to fill in the gaps and
missing bits and pieces in the SWE portfolio, e.g. the integration of event system, broadcast-
ing and mass alerting functionalities, proper support of motion imagery etc. Domain stand-
ards such as TPEG can complement powerful information gathering, knowledge creation, as
well as data and command dissemination. The complexity of emergency and crisis situations
and the singularity of each event require an IT system that loads required modules at runtime
and uses existing services and produces equally.
The next challenge is to integrate existing and future C2 and C4I systems. Those systems
often do not provide sufficient interfaces and have high requirements for security settings due
to the military origin. The ESS system therefore has to emphasize on security mechanisms
and services, which is currently not the case in OGC SWE, for example, but needs to be de-
veloped by ESS.
The ESS system will not be a pure technology, but needs integrate human resources and
human requirements similarly. That means that the system has to reflect to decision hier-
archies and command processes. ESS system workflows have to adapt to changing com-
munication structure for a given situation. It is not very likely that the staffing situation will
change towards more people involved at the various organizations and their teams respec-
tively. The ESS system even needs to take this aspect into account. One of the key aspects
that make the ESS standing out against all existing systems will be its flexibility to adapt to
new situations and scenarios. This includes new sensors, new communication patterns, new
workflows, unreliable communication channels, and other issues usually caused by crisis
situations. To achieve this goal, standardization is key for the development of the various
system components, data formats, interfaces and encoding models.

202 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

<I5- !3"((9;&."*"/%0%*+&

The situation in the traffic management standardization is pretty advanced in some areas,
but seems not as consolidated as in the geo-spatial world. Standards exist, but not all areas
are covered, e.g. the missing access to traffic feeds or the rather static agreement on stan-
dard location table due to bandwidth limitations of RDS-TMC. This situation may cause major
problems in particular in cross-border scenarios.
TPEG covers almost all needs for traffic information (detailed information, independent of
base maps) but currently lacks uptake in governmental agencies and traffic control integra-
tors. The question remains to which level it can be used it in ESS. One potential strategy is to
integrate TPEG activities with OGC activities in order to strengthen the role of TPEG and to
foster its uptake on the governmental level. The ESS consortium has already taken first ac-
tions in this direction during the first months of the project.
Further harmonization of spatio-temporal IT aspects could be achieved by starting round
table discussions between developers of SWE and traffic management standards such as
OpenLR and AGORA-C. Harmonized information models would fructify the integration pro-
cess of currently heterogeneous data sets enormously and would further support interna-
tional initiatives such as GMES, INSPIRE, or GEOSS.
UTMC provides a robust framework for traffic control interfaces and data models; unfortu-
nately it is UK only. As it favours XML and Web services based communication, it might be
easy enough integrated into an ESS system. The question remains, to which extent ESS is
interfacing to various traffic control systems, plus to which extent UTMC will be used outside
of the UK in the future.
NTCIP is based on an IP stack as well and features Web service and SOAP as well as XML
based communication. Thus, it fits well into a Web-oriented architecture.
DATEX II seems to be the most promising set of standards. Under the umbrella of CEN,
DATEX II is likely to become European standard in the near future. It is well aligned with
other standardization efforts, such as TMC and TPEG. On the backhand, it expects further
agreements between communication partners in order to achieve interoperability.

<I5< )%$$&]3'":;",+9*/&

Emergency situations often require the immediate notification of a number of people in the
area of an event. Those notifications stretch from simple alerts to evacuation instructions.
Given the ubiquitous availability of mobile phones, cell broadcast services represent the most
promising technology for mass notifications given that the physical network is still present.
Even if the physical network is destroyed, technologies such as IMSI-catchers are available
that can be deployed in minimum time to replace the former network. ESS shall further inves-
tigate in the usage of cell broadcasting services. Though the technology is available, a num-
ber of open questions still exist, such as the acceptance of broadcasted messages, the op-
timization of messages in order to control human behaviour, and other social aspects of point
to multipoint communication.
Satellite communication

© ESS Consortium 2009 203


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

As no communication infrastructure is available in the crisis area or got destroyed during the
crisis itself, satellite communication comes into play. From a technological point of view, sat-
ellite communication can be considered to be available in Europe at reasonable costs and
supporting sufficient data transfer rates. With SES Astra and Tooway, two providers are on
the market being able to provide bi-directional communication with a maximum speed of
384kBit/sec. The speed currently available shall be sufficient to transport speech and some
data, but fails if it comes to mass data transportation, e.g. multiple parallel video streams.
Thus, ESS shall assume that a minimum data transport is available in almost all situations.
On the other hand, satellite system immanent delays may disqualify the system for VoIP
communication between inexperienced users.

<I5? Q%+`'3N,&

Various forms of either ad-hoc or dynamic wireless network approaches and technologies do
exist, but have to be evaluated in ESS very carefully. Interoperability between the various
systems is still a major issue if not abandoned at all, and cross-system devices bridging from
one network to another are still rare on the market and do not support all current technolo-
gies. The high rate of innovation and technological progress in the area of broadband wire-
less networks makes it even more unlikely that more cross-technology components will be on
the market soon. In ESS, it might be wise to refer incompatibilities across different systems
to other projects, but build an architecture that abstracts from the underlying network in order
to be applied easily to changing underlying communication systems.
Regarding framework conditions of the ESS architecture, it can be said that the market fol-
lows the requirements for high-throughput, robust, self-healing and scalable wireless net-
works. Just, often physical parameters or orthogonal optimization directions make it unlikely
that a single technology will emerge that will be shared across public protection and disaster
relief forces. Thus, the ESS architecture shall take software and hardware approaches into
account that address incompatibility issues among communication partners and devices. The
optimal architecture adapts to the concrete and usually non-predictable circumstances of a
given crises and optimizes parameters such as scalability, mesh connectivity, data through-
put, quality of service, security, and ease of use for any given situation.

<I5@ )@K&

The international crisis management and response community reflects some of the major
issues ESS is faced with. Those issues are less of technological nature, but address political
barriers that exist within and between organizations and prevent effective use of resources.
Barriers include competition for funds, an absence of systematic data collection formats, a
lack of trust between organizations, incredulity about the benefits of information sharing and,
finally, the politics of personality. All those aspects will not directly affect the design of the
ESS architecture and ESS components, but span a reference framework that needs to be
considered when it comes to identify technologies and distribution approaches in ESS. Even-
tually, ESS shall integrate various organizations and inner-organizational groups into a distri-
buted though singular system. The lack of standards in the C4I is reflecting this complex
situation. C4I systems are immanently based on multiple sources for collection, processing,

204 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

integration, analysis, evaluation, and interpretation of available information in order to im-


prove situational awareness and decision-making. The multiplicity exponentially complicates
the development of standards that always require consent on all aspects that are covered.
Given that planning and developing communication systems typically occurs in isolation, the
challenge for integrating C4I systems is even higher. ESS will have to balance very carefully
all decisions pro and con specific technologies. ESS will have to master a patchwork of sepa-
rate systems and will therefore need to make one or the other assumption in order to build a
successful system at the end.

<I5B H"+"&Z9,2"$9L"+9'*&

There are a lot of public domain tools available supporting visualization of three-dimensional
data, such as Google Earth, NASA World Wind, and others. Unfortunately, those systems
lack either performance or availability of source code that might be necessary to embed
those systems reasonably into ESS. Nevertheless, those tools mark the feature level that
can be expected by up-to-date visualization systems and therefore shall be at least met by
ESS developments. In addition, the ESS system needs to support the specific requirements
of non-GIS experts, but crisis managers and decision makers. Thus the ESS graphical user
interface design and the representation of data have to adapt perfectly to the specific needs
of the various authorities and teams involved in crisis management.
Another data visualization challenge is the display of massive data sets even in 2D if reada-
bility of individual information is important. Here, the concept of micro/macro displaying rep-
resents the state of the art. The concept differentiates between general tendency visualiza-
tion on the macro level and individual data item visualization on the micro level. In crisis
situations, the number of data items to be displayed can be very high. The use of intelligent
aggregation concepts is the key to efficiently support decision makers. The current concepts,
originated in the transportation and medical domain, still lack some important features, such
as the proper integration of temporal and spatial aspects into the visualization model. ESS
needs to further elaborate on the paradigm of visual analytics in order to optimize the support
of human decision makers by offering intelligent graphical displays. Visual displays need to
be integrated with planning tools and need to provide sufficient analysis capacities in order to
allow human interception, validation, and examination.
In order to improve the visual analytics, ESS needs to develop a standardized data infra-
structure that allows the real time integration of new data from sensors or other sensing de-
vices or humans. So far, visual analytics mostly work on proprietary data sets and have no
interfaces to standardized data services. In an ESS environment, where multiple organiza-
tions, even across regional and national borders need to interact, such a system fails. Thus,
ESS will further enhance visual analytic techniques and systems to support standardized
data models and encodings as well as data services.

<I5I 6%'7$%&O';"+9'*&

The localization of people in crisis situation is a very important feature. There are interception
methods available that make use of diverse technologies built in mobile cell phones and the
terrestrial radio access network. ESS shall investigate the applicability of those new tech-

© ESS Consortium 2009 205


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

nologies for people localization and tracking based on uplink time difference of arrival and
radio frequency fingerprints. In particular active methods, which track mobile phones without
any indication of their activity on the mobile device, bear a great potential for the usage in
crisis scenarios.

<I5J D%$"+%:&63'a%;+,&

A number of related projects have been identified and addressed in this state of the art re-
port. Members of the ESS consortium have or had played a role in most of those projects.
Thus, technological approaches started or developed in those projects will directly slip into
the ESS research and development process. After consultation of all partners in ESS, the
importance of standardization needs to be reemphasized, as the lack of it led to the end of a
number of valuable ideas in past projects.

206 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

<J ]9#$9'/3"784&
Akyildiz, I., Wang, X., & Wang, W. (n.d.). Wireless mesh networks: a survey.
www.sciencedirect.com.
Altmann, J., Buyya, R., & Rana, O. F. (Eds.). (2009). Grid Economics and Business Models.
Springer Verlag.
Andreasen, F., Baugher, M., & Wing, D. (2006). Session Description Protocol (SDP) Security
Descriptions for Media Streams. Session Description Protocol (SDP) Security Descriptions
for Media Streams .
Andrews, P. (1986). Fire behavior prediction and fuel modeling system-BURN subsystem,
part 1, Gen. Tech. Rep. INT-194. Ogden, UT: U.S. Department of Agriculture, Forest
Service, Intermountain Research Station.
Andrienko, G., & Andrienko, N. (2008). Spatio-temporal aggregation for visual analysis of
movements. IEEE Symposium on Visual Analytics Science and Technology (VAST 2008),
IEEE Computer Society Press, (pp. 51-58).
Andrienko, G., Andrienko, N., & Wrobel, S. (2007). Visual Analytics Tools for Analysis of
Movement Data. ACM SIGKDD Explorations , 9 (2), 38-46.
Andrienko, G., Andrienko, N., Dykes, J., Fabrikant, S., & Wachowicz, M. (2008).
Geovisualization of Dynamics, Movement and Change: Key Issues and Developing
Approaches in Visualization Research. Information Visualization , 7 (3/4), 173-180.
Andrienko, G., Andrienko, N., Jankowski, P., Keim, D., Kraak, M.-J., MacEachren, A., et al.
(2007). Geovisual Analytics for Spatial Decision Support: Setting the Research Agenda,
International Journal Geographical Information Science. 21 (8), 839-857.
Andrienko, N., & Andrienko, G. (2007). Designing visual analytics methods for massive
collections of movement data. Cartographica , 42 (2), 117-138.
Andrienko, N., Andrienko, G., & Gatalsky, P. (2000). Supporting Visual Exploration of Object
Movement. In V. Di Gesù, S. Levialdi, & L. Tarantino (Ed.), Proceedings of the Working
Conference on Advanced Visual Interfaces AVI 2000,, (pp. 217-220). Palermo, Italy.
Andrienko, N., Andrienko, G., Pelekis, N., & Spaccapietra, S. (2008). Basic Concepts of
Movement Data. In F. Giannotti, & D. Pedreschi, Mobility, Data Mining and Privacy -
Geographic Knowledge Discovery (pp. 15-38). Berlin: Springer.
Andrienko, N., Andrienko, G., Wachowicz, M., & Orellana, D. (2008). (2008). Uncovering
Interactions between Moving Objects. In T. Cova, H. Miller, K. Beard, A. Frank, & M.
Goodchild (Ed.), GIScience, 5th international conference, (pp. 16-26).
Arkko, J., Carrara, E., Lindholm, F., Naslund, M., & K., N. (2006). Key Management
Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol
(RTSP). Key Management Extensions for Session Description Protocol (SDP) and Real Time
Streaming Protocol (RTSP) .
Aymond, P., Brooks, R., Grapes, T., Ham, G., Ianella, R., Robinson, K., et al. (2009).
Emergency Data Exchange Language Resource Messaging (EDXL-RM) 1.0. Emergency
Data Exchange Language Resource Messaging (EDXL-RM) 1.0 .

© ESS Consortium 2009 207


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Baranski, B., Schäffer, B., & Redweik, R. (2009). Geoprocessing in the Clouds. 52° North
Initiative for Geospatial Open Source Software GmbH.
Bartling, U., & Mühlenbein, H. (1997). Optimization of large scale parcel distribution systems
by the Breeder Genetic Algorithm (BGA). T. Bäck (Ed.): Proceedings of the 7th International
Conference on Genetic Algorithms, pp. 473-480.
Benatallah, B., Sheng, Q. Z., & Dumas, M. (2003). The Self-Serv Environment for Web
Services Composition. IEEE Internet Computing , 7, 40-48.
Berry, D., & Chappell, D. (2007). SOA - Ready for Primetime: The Next-Generation, Grid-
Enabled Service-Oriented Architecture. The SOA Magazine Issue X: September 2007 , 9.
Botts, M., & Robin, A. (2007). Sensor Model Language (SensorML) Implementation
Specification. Sensor Model Language (SensorML) Implementation Specification .
Box, D., Cabrera, L. F., Critchley, C., Curbera, F., Ferguson, D., Graham, S., et al. (2006).
Web Services Eventing (WS-Eventing). Web Services Eventing (WS-Eventing) .
Brooks, R., & Dwarkanath, S. (2009). Common Alerting Protocol Version 1.1 - USA
Integrated Public Alert and Warning System Profile Version 1.0. Common Alerting Protocol
Version 1.1 - USA Integrated Public Alert and Warning System Profile Version 1.0 .
Bruno, R., Conti, M., & Gregori, E. Mesh Networks: Commodity Multihop Ad Hoc Networks.
CNR, Italy.
Burgan, R. E. (1988). 1988 revisions to the 1978 National Fire-Danger Rating System. Res.
Pap. SE-273. Asheville, NC: U.S. Department of Agriculture, Forest Service, Southeastern
Forest Experiment Station.
CAPAN. (2009). Canadian Profile of the Common Alerting Protocol (CAP-CP). Canadian
Profile of the Common Alerting Protocol (CAP-CP) .
Chappell, D., & Liu, L. (2006). Web Services Brokered Notification 1.3 (WS-
BrokeredNotification). Web Services Brokered Notification 1.3 (WS-BrokeredNotification) .
Computerwoche. (2006). Gartner propagiert SOA 2.0. Gartner propagiert SOA 2.0 .
Cox, S. (2007). Observations and Measurements - Part 1 - Observation schema.
Observations and Measurements - Part 1 - Observation schema .
Davis, D., Karmarkar, A., Pilz, G., Winkler, S., & Yalcinalp, Ü. (2009). Web Services Reliable
Messaging (WS-ReliableMessaging) Version 1.2. Web Services Reliable Messaging (WS-
ReliableMessaging) Version 1.2 .
Dwarkanath, S. (2008). Emergency Data Exchange Language (EDXL) Hospital AVailability
Exchange (HAVE) Version 1.0.
ETSI. (n.d.). ETSI Technologies. (The European Telecommunications Standards Institute)
Retrieved 2009 from http://www.etsi.org/WebSite/Technologies/Technologies.aspx
Everding, T., & Echterhoff, J. (2008). Event Pattern Markup Language. Event Pattern Markup
Language .
Everding, T., & Echterhoff, J. (2009). Event Processing in Sensor Webs.
Everding, T., & Echterhoff, J. (2009). OGC OWS-6 SWE Event Architecture Engineering
Report.

208 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Fagerholt, K. (2004). A computer-based decision support system for vessel fleet scheduling -
experience and future research. 37 (1).
Faison, T. (2006). Event-Based Programming: Taking Events to the Limit. (J. Hassell, Ed.)
Apress.
Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software
Architectures. University of California, Irvine.
Fitzpatrick, B., Slatkin, B., & Atkins, M. (2009). {PubSubHubbub Core 0.2 -- Working Draft}.
{PubSubHubbub Core 0.2 -- Working Draft} .
Foster, I., Kesselman, C., Nick, J., & Tuecke, S. (2003). Grid Computing - Making the Global
Infrastructure a Reality. In F. Berman, G. C. Fox, & A. Hey (Eds.). Wiley.
Francica, J. (2009). Deriving Location Intelligence from Complex Event Processing for
National Security Applications. Deriving Location Intelligence from Complex Event
Processing for National Security Applications .
Fredrikson, A., C., N., Plaisant, C., & Shneiderman, B. (1999). Temporal, geographic and
categorical aggregations viewed through coordinated displays: a case study with highway
incident data, . Proceedings of Workshop on New Paradigms in Information Visualization and
Manipulation (NPIVM’99), pp.26-34.
Futemma, S., Itakura, E., & Leung, A. (2008). RTP Payload Format for JPEG 2000 Video
Streams. RTP Payload Format for JPEG 2000 Video Streams .
Galatopoullos, D., Kalofonos, D., & Manolakos, E. (2008). A P2P SOA Enabling Group
Collaboration through Service Composition. ICPS’08, July 6–10, 2008, Sorrento, Italy.
Goldberg, D. (1989). : Genetic Algorithms in Search, Optimization, and Machine Learning.
Reading, MA.: Addison-Wesley Pub. Co.
Golden, B., & Assad, A. (1988). Vehicle Routing: Methods and Studies . Volume 16.
Gow, G., Anderson, P., & Waidyanatha, N. (2007). Hazard Warnings in Sri Lanka:
Challenges of Internetworking with Common Alerting Protocol. In B. V. de, P. Burghardt, & C.
Nieuwenhuis (Ed.)., ISCRAM2007, pp. 281-293.
Graham, S., Hull, D., & Murray, B. (2006). Web Services Base Notification 1.3 (WS-
BaseNotification). Web Services Base Notification 1.3 (WS-BaseNotification) .
Gregorio, J. (2007). The Atom Publishing Protocol. The Atom Publishing Protocol .
Gudgin, M., Hadley, M., & Rogers, T. (2006). Web Services Addressing 1.0 - Core. Web
Services Addressing 1.0 - Core .
Handley, M., Jacobson, V., & Perkins, C. (2006). SDP: Session Description Protocol. SDP:
Session Description Protocol .
Herring, J. R. (2006). OpenGIS Implementation Specification for Geographic information -
Simple feature access - Part 2: SQL option.
ILOG. (n.d.). ILOG Transport PowerOps. Retrieved 2007 )*+ 20-March from
http://www.ilog.com/products/transportpowerops/

© ESS Consortium 2009 209


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

ISO/IEC. (1998). Information technology -- Open Distributed Processing -- Reference Model:


Architectural semantics. ISO/IEC 10746-4. Information technology -- Open Distributed
Processing -- Reference Model: Architectural semantics. ISO/IEC 10746-4 .
ISO/IEC. (1996). Information technology -- Open Distributed Processing -- Reference Model:
Architecture. ISO/IEC 10746-3. Information technology -- Open Distributed Processing --
Reference Model: Architecture. ISO/IEC 10746-3 .
ISO/IEC. (1996). Information technology -- Open Distributed Processing -- Reference model:
Foundations. ISO/IEC 10746-2. Information technology -- Open Distributed Processing --
Reference model: Foundations. ISO/IEC 10746-2 .
ISO/IEC. (1998). Information technology -- Open Distributed Processing -- Reference model:
Overview. ISO/IEC 10746-1. Information technology -- Open Distributed Processing --
Reference model: Overview. ISO/IEC 10746-1 .
Jirka, S., Hahn, D., & Echterhoff, J. (2008). Applying the Sensor Web Enablement
Architecture to Reliable Fire Detection. International Council on Systems Engineering
(INCOSE). 3, pp. 1557-1569. Curran Associates, Inc.
Jones, E., & Botterell, A. (2005). Common Alerting Protocol, v. 1.1.
Kao, O. (2008). Quality of Service Aspects in Grid Computing. Quality of Service Aspects in
Grid Computing .
Kapler, T., & Wright, W. (2005). GeoTime information visualization. Information Visualization
, 4 (2), 136-146.
Keller, W. (2003). Enterprise Application Integration. Dpunkt Verlag.
Knights, M. (2007). Grid computing misses the point, says academic. Grid computing misses
the point, says academic .
Kraak, M.-J. (2003). The space-time cube revisited from a geovisualization perspective.
Proc. of the 21st International Cartographic Conference, (pp. 1988-1995). Durban, South-
Africa.
Loureiro, E., Bublitz, F., Barbosa, N., Perkusich, A., Almeida, H., & Ferreira, G. (2006). A
Flexible Middleware for Service Provision Over Heterogeneous Pervasive Networks. (pp.
609-614). IEEE Computer Society.
Luckham, D. (2008). A Brief Overview of the Concepts of CEP.
Luckham, D. (2002). The Power of Events: An Introduction to Complex Event Processing in
Distributed Enterprise Systems. Addison-Wesley Longman.
Luckham, D. (2006). What’s the Difference Between ESP and CEP?
McCormick, B., DeFanti, T., & Brown, M. (1987). Definition of Visualization. ACM
SIGGRAPH Computer Graphics , 21 (6), 3.
Mondejar, R., Garcia, P., Pairot, C., & Gomez, A. F. (2006). Enabling Wide-Area Service
Oriented Architecture through the p2pWeb Model. (pp. 89-94). IEEE Computer Society.
Na, A., & Priest, M. (2007). Sensor Observation Service. Sensor Observation Service .
OASIS. (2006). Web Services Topics 1.3. Web Services Topics 1.3 .

210 © ESS Consortium 2009


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

OGC. (2004). OGC Web Map Service Interface – version 1.3.0.


http://www.opengeospatial.org/standards/wms.
OGC. (2007 a). OpenGIS Catalogue Service Specification – version 2.0.2.
http://www.opengeospatial.org/standards/cat.
OGC. (2007 b). OpenGIS Web Processing Service – version 1.0.0.
http://www.opengeospatial.org/standards/wps.
OGC. (2003). Web Coverage Service. http://www.opengeospatial.org/standards/wcs.
OGC. (2005). Web Feature Service Implementation – version 1.1.0.
http://www.opengeospatial.org/standards/wfs.
Pankratz, G. Dynamic Vehicle Routing by Means of a Genetic Algorithm. . 35 (5, pp. 362-
383).
Potter, S., Ball, R., & Elm, W. (1996). Supporting aeromedical evacuation planning through
information visualization. Proceedings of the 3rd Symposium on Human Interaction with
Complex Systems (HICS '96), August 25 - 27, 1996, Dayton, Ohio, USA.
Raymond, M., Webb, S., & Aymond, P. I. (2006). Emergency Data Exchange Language
(EDXL) Distribution Element.
Reed, C. (2006). An Introduction to GeoRSS: A Standards Based Approach for Geo-enabling
RSS feeds.
Reeves, C., & Rowe, J. (2002). Genetic Algorithms - Principles and Perspectives: A Guide to
GA Theory. Vol. 20 (Operations Research / Computer Science Interfaces Series).
Richardson, L., & Ruby, S. (2007). RESTful Web Services. O'Reilly.
Rosenberg, J., & Schulzrinne, H. (2002). An Offer/Answer Model with the Session
Description Protocol (SDP).
Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., et al.
(2002a). SIP: Session Initiation Protocol.
Saint-Andre, P., Hildebrand, J., & Wyman, B. (2008). AtomSub: Transporting Atom
Notifications over the Publish-Subscribe Extension to the Extensible Messaging and
Presence Protocol.
Schulte, R. (2003). The Growing Role of Events in Enterprise Applications. The Growing
Role of Events in Enterprise Applications .
Schulzrinne, H., & Casner, S. (2003). RTP Profile for Audio and Video Conferences with
Minimal Control.
Simonis, I. (2007). OGC® Sensor Planning Service Implementation Specification. OGC®
Sensor Planning Service Implementation Specification .
Simonis, I. (2008). OGC Sensor Web Enablement Architecture. Open Geospatial
Consortium.
Simonis, I., & Echterhoff, J. (2006). Draft OpenGIS Web Notification Service Implementation
Specification.

© ESS Consortium 2009 211


FP7-SEC-2007-4.2.01 Network enabled command and control system
ESS D2.1 State-of-the-Art Report ESS– 217951

Smith, S., Hildum, D., & Crimm, D. (2005). Comirem: An Intelligent Form for Resource
Management. 20 (2).
Srinivasan, L., & Treadwell, J. (2005). An Overview of Service-oriented Architecture, Web
Services and Grid Computing. An Overview of Service-oriented Architecture, Web Services
and Grid Computing .
Stocks, B., Lawson, B., Alexander, M., Van Wagner, C., McAlpine, R., Lynham, T., et al.
(1989). The Canadian Forest Fire Danger Rating System: An Overview. Forest Chronicle ,
65 (6), 450-457.
Thomas, J. J., & Cook, K. (2005). Illuminating the Path. IEEE.
Tufte, E. (1990). Envisioning information. Cheshire, CT, USA: Graphics Press.
TurboRouter software. Schedule visualization. (n.d.). Retrieved 2007 )*+ 20-3 from
http://www.marintek.sintef.no/TurboRouter/visualisations.htm
Udu-gama, N. (2009). Mobile Cell Broadcasting for Commercial Use and Public Warning in
the Maldives.
Vambenepe, W., Graham, S., & Niblett, P. (2006). Web Services Topics 1.3 (WS-Topics).
Vinoski, S. (2007). REST Eye for the SOA Guy. IEEE Internet Computing , 11, 82-84.
Vretanos, P. A. (2005). OpenGIS Filter Encoding Implementation Specification. OpenGIS
Filter Encoding Implementation Specification .
W3C. (2004). Web Services Addressing (WS-Addressing). Web Services Addressing (WS-
Addressing) .
Westfall, J. (2009). Common Alerting Protocol Version 1.2.

212 © ESS Consortium 2009

S-ar putea să vă placă și