ess emergency technologies s o t a

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 1

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 integrated)

ESS consortium for pub-lic release



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

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!



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!



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!



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!



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!



- ."*"/%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.



< =##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



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



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



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



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



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



? !"#$%,&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!



@ 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!



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!



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!



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:



• 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.



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:



• 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



• 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



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.



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

Reuse Rapid Sense / Re-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



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



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



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



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.



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.



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.:



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



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.



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-



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



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.



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.



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”



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


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.



Figure 9: Model of a complex form of a Sensor


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


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



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




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.



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.



!"#"$"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.



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.



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.



!"#"$"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).



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.



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.



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.



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.



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.



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.



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.



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.



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.



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):



• 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



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-



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



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-



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.



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.



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)



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.



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.



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)



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



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.



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



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)



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.



-[ .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.



-[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 Field Code

Explanation

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



SDP Field Code

Explanation

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-



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



-[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.



-- !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.



--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



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:



• 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 Systems

http://www.ewsradio.com/4-system.html

Table 4: TMC Information and References



--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.



• 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.



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.




• 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-



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.



Interface limitations

• Patent protected and requires users to pay royalties.

• Assumes enough computation power on client side.



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

Topic Reference

AGORA-C Patent http://www.wipo.int/pctdb/en/wo.jsp?WO=2009006351&IA=US2008068675&DISPLAY=DESC

AGORA-C Standard

http://www.iso.org/iso/catalogue_detail.htm?csnumber=45962#

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.



##"#"$"$ 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.



• 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.



##"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.


• 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-&-(,-).

Table 8: UTMC Information and References

Topic Reference

UTMC http://www.utmc.uk.com/index.php

UTMC technical specifications

http://www.utmc.uk.com/technical/index.php



--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.



• 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.


• 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.



##"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



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.



##"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).


• 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.



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:



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.


• 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-tions

http://www.opengeospatial.org/standards/kml/

Google KML Documentation

http://code.google.com/apis/kml/documentation/



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-&-(,-).

Table 12: WMS Information and References

Topic Reference

OGC http://www.opengeospatial.org/

WMS Specifica-tions

http://www.opengeospatial.org/standards/WMS/



-< !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).



• 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.



-<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.



-? )%$$&]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



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 (SMS)

Cell Broadcast Message (SMSCB)

Transmission Type Messages sent point-to-point

Messages sent point-to-area

Mobile Number Depend- Dependent. Requires Independent. Does not require





ency specific phone numbers to be input

phone number input

Location Dependency Independent. Only pre-registered numbers will be notified; message can be received anywhere.

Dependent. All numbers within a geographical area will be notified. The Cell Broadcast Service al-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 sent to all pre-registered numbers.

Tailored messages can be sent to different areas based on the alert level for each area.

Bi-directionality

Yes. Users can both re-ceive and respond directly to the sender via SMS.

Yes. Two-way messaging is an option that may beprovided by the 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 messages are queued. Immense numbers will cause delays.

Broadcasts are sent to a cell area on dedicated channels, eliminat-ing congestion. Delays may only occur in poor coverage areas.

Message Length 140-160 characters in length Can ‘concatenate’ up to 5 times, advisably. But it may not be sup-ported by all mobile ser-vices.

93 charactersIt is possible to ‘concatenate’ up to 15 ‘pages’ together to produce a single mes-sage of up to80 * 15 = 1200 ‘bytes’ of data.

Security Poor authenticity. No indi-cation that a message is generated by a legitimate authority that cannot be emulated by typing in a text message from an-other phone.

Yes, but limited. No reception if broadcast is sent before mobile is switched on. However, if updates to the cell broadcast are sent, they will be received if mobile remains on.

Service Barring No barring. Limited. Received only if the-broadcast reception status is set





to “ON”.

Reception Yes. Message Received once the mobile is switch on.

Yes, but limited. No reception if broadcast is sent before mobile is 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 delivery confirmation.

No. No confirmation of delivery.

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 [Most important for first responders and gov-ernment officials re: public warning]

Yes No. However, the user may choose to at his/her discretion should the appropriate firmware be housed on the handset. In 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.



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;



• 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.



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



-@ 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.



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.



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



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).



-@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:



!! =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#*!W&.D!.&XD!X&YD!Z&PD!S&QD!Q&W/!@\B:]0!G5#*!^D!.&XD!X&YD!Z&PD!S&QD!Q&W/!@SB:]0!

G5#*!.&XD!X&YD!Z&PD!S&Q!E?-8,!@SB:]0!G5#*!W&.D!.&XD!X&YD!Z&P!E?-8,!@\B:]0!V,925#*95#*7!_,-'5-7!T--,-!V,--*2>#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!A`a>:.!%!X>X/!L3$3!

Z!b!X/!L3$3!

A5#5!G5#*! W>S/!L8$3! Z>[.!L8$3!

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

L,7?<5#1,9&V,719+!:JELKATD!UL:]!aE!R!/DZ!G5#*!W&.D!.&XD!X&Y!E?-8,!@UL:]0!

G5#*!W&.D!X&Y!E?-8,!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!?$75#*3D!K=*->#"*>51-!6,91#,-19+D!3*<4>#*3#!597!715+9,3#123!A?5<!35#*<<1#*!2,941+?-5#1,9!3*##19+3!

d*8!UeF!<,25<!715+9,3#123!597!:fLB>853*7!-*6,#*!6595+*6*9#!597!2,9#-,<!

gJf!F9#*-452*! T#"*-9*#!W/&W//!853*E!@GN>YZ0! T#"*-9*#!W/&W//!853*E!@GN>YZ0!

f*#',-O19+! B-,#,2,<3%!eABD!FBD!FVLBD!FULB=.D!EVBD!JGBD!_EBD!AMVBD!Af:!252"19+&-*<5CD!T97>#,>*97!AC95612!G*5<!E16*!\,:!hD!e91253#D!L?<#1253#D!19#-59*#!3*-=12*3(!B*-4,-6592*%!8?1<#>19!EVB>522*<*-5#1,9D!MEEB!$-*>4*#2"19+D!75#5!2,6$-*331,9D!#',>'5C!EVB!*9>2-C$#1,9!

FB!F9#*->9*#',-O19+!E-593$5-*9#!EVB!597!MEEB!522*<*-5>#1,9!f*#',-O!J77-*33&B,-#!E-593<5#1,9W!\?5<1#C>,4>:*-=12*!g5C*-!.bY!$52O*#!2<53314125#1,9!597!41<#*-19+!B*->4<,'!i?*?19+!597!$,<1219+!:*2?-1#C!_1-*'5<<!'1#"!:#5#*4?<!B52O*#!F93$*2>#1,9!@:BF0W!



!! =1!D=<)'**%;+& !''`"4&

V,9#*9#!41<#*-19+!

T44*2#1=*9*33! K$*-5#19+!#*6$*-5#?-*%!/!#,!Y/jV!T;#*-95<!B,'*-!3?$$<C%!19$?#!.W/>.P/!`JVD!Z/MI!W//>WX/!`JVD!P/MI!,?#$?#!WZ!`AV!L5193!B,'*-!2,93?6$#1,9%!kX/dD!192<(!$,'*-!2,93?6$#1,9!,4!KAe(!

K$*-5#1,95<%!/j!#,!lY/j!V!:#,-5+*%!>X/j!#,!lPZj!V!M?6171#C%!/!#,!QZm!@9,9>2,97*9319+0!J<#1#?7*%!W/D///!4**#!B,'*-!3?$$<C%!SZ!b!.PY!`JVn!Y[!b!PX!MI!

!! !! !!

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!UMI!3#5975-7!]?!,-!WXD[Z!>!WY!UMI!*;>#*97*7!]?!F9$?#!4-*i?*92C!%!W/D[!b!W.D[Z!UMI!f,6195<!TFGB%!XP!7ad!

K?#$?#!_-*i?*92C%!WY(/!b!WY(Z!UMI!F9$?#!_-*i?*92C!G59+*%!W/(QZ!b!WW([!UMID!WW([!b!W.(.!UMI!,-!W.(.Z!b!W.([Z!UMI!f,6195<!TFGB%!Y.!b!YP(W!7ad!

V,99*2#1,93! E',!G_!2,99*2#,-3!#C$*!_!@4*65<*0!5#![Z!,"6!

E',!G_!2,99*2#,-3!#C$*!_!@4*65<*0!5#![Z!,"6!

B,<5-1I5#1,9! B"C3125<!6,?9#19+! V1-2?<5-!,-!<19*5-!,-#",+,95<!



!! =1!D=<)'**%;+& !''`"4&

T44*2#1=*9*33! J681*9#!E*6$*-5#?-*%!>X/!#,!lP/jV!d*5#"*-!$-,#*2#1,9%!FBP[!M?6171#C%!/m!#,!W//m!@2,97*9319+0!:,<5-!G5715#1,9%!WW./d&6.!65;16?6!G519%!e$!#,!Y/!66&"!d197%!e$!#,!WS/!O6&"!

J681*9#!E*6$*-5#?-*%!>Y/j!#,!lZZj!V!@?$!#,!lS/j!V!3?-=1=5<0!M?6171#C%!/!#,!W//m!@2,97*9319+0!G519%!W.([!66&"!@?$!#,[P(.!66&"!3?-=1=5<0!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.



-@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



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



-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



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



-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.”



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.”



-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



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



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)



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



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)



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



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/



-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.



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.



• 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



• 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:



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:



• 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



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



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.



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



-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



-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.



• 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



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/Dokumenttiarkisto/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



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.



-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.



-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.

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/

Topic Reference

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



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.

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

Topic Reference

DISA http://www.disa.mil

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



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.



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

http://www.tacticalsituationobject.org/



-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;



• 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.



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.



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).



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



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-



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



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



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.



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.



<[ 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



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.



<[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).



<[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.



Figure 57: summary view of the transportation progress

Figure 58: A fragment of a map view

Figure 59: map legend



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



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.



<[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



<- 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



<< ?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.



<<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.



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.



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



<<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).



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.



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.



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.



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



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-



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/



<? 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



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).



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.



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-



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



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



<@ 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



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-



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



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.



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-nating a response

http://www.itu.int/itunews/manager/display.asp?lang=en&year=2007&issue=10&ipage=regionalPercepctive&ext=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.



<@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-munications

http://www.itu.int/itunews/manager/main.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.



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)



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.



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



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



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.”



<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



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.



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.



“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



communications and also to provide the Internet between the sensors and the ESS core components.



<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.



<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



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,



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-



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.



<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 .



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.



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/



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 .



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.



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.

ess emergency technologies s o t a

Documents