You are on page 1of 212
FP7-SEC-2007-4.2.01 Network enabled command and control system ESS D2.1 State-of-the-Art Report ESS– 217951 ESS Emergency Support

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

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

ESS

Emergency Support System

Project Number: 217951 (IP)

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

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

FP7-SEC-2007-4.2.01 Network enabled command and control system ESS D2.1 State-of-the-Art Report ESS– 217951 !"#$%&'(&)'*+%*+,& DELIVERABLE D2.1

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

FP7-SEC-2007-4.2.01 Network enabled command and control system ESS D2.1 State-of-the-Art Report ESS– 217951 !"#$%&'(&)'*+%*+,& DELIVERABLE D2.1

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

 

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!

 

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!

 

24!

25!

25!

 

6.3! AVAILABLE SPECIFICATIONS

30!

6.3.1! Event Model

30!

 

31!

32!

33!

 

6.4! CONCLUSIONS

34!

7!

OGC SENSOR WEB ENABLEMENT

37!

7.1.1! Introduction

37!

 

38!

 

7.1.3! SWE

40!

7.1.4!

SWE Services and Encodings

41!

7.1.5! Sensor

52!

7.1.6!

Sensor Alert Service

54!

7.1.7!

55!

7.1.8!

55!

8! OGC WEB SERVICES

56!

56!

 

8.2! WEB COVERAGE SERVICE (WCS)

58!

8.3! WEB FEATURE SERVICE (WFS)

58!

8.4! WEB PROCESSING SERVICE

59!

8.5! CATALOGUE SERVICE FOR WEB (CSW)

59!

8.6! SDI SERVICE INTEGRATION

60!

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

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

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

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!

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!

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!

93!

11.3! INTERFACES FOR TRAFFIC APPLICATIONS (B2B)

95!

 

11.3.1!

96!

11.3.2! WMS

98!

 

99!

12.1! TRADITIONAL METHODS

99!

99!

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!

106!

107!

13.4! MODE OF OPERATION

107!

13.5! CONCLUSIONS

108!

13.6! RELEVANT LINKS

108!

14! SATELLITE TECHNOLOGIES

110!

14.1!

110!

14.1.1! Satellite HUB

111!

111!

 

14.1.3!

Satellite Transmission Channel

112!

14.1.4! ServicesTopologies

112!

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

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

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

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!

 

120!

 

15.2!

COMMENTS FROM INVESTIGATOR

121!

15.3! RELEVANT LINKS

121!

 

122!

 

16.1! DESCRIPTION ..........................................................................................................

122!

16.2! PROJECT MESA

124!

16.3! AD HOC NETWORKS

124!

 

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!

 

131!

 

17.1! LOCATING PEOPLE AT CRISIS ZONES

131!

 

131!

133!

 

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!

 

138!

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!

 

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!

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

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

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

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!

 

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!

 

168!

22! 3D VISUALIZATION OF MASSIVE GEOGRAPHICAL DATASETS

169!

 

22.1! INTRODUCTION

169!

 

22.2! TOOLS

170!

 

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

176!

 

22.2.9! Summary

178!

 

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

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!

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

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

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

24.5.2! Ugandan floods

192!

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!

194!

194!

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!

 

204!

26.5! DATA VISUALIZATION ...............................................................................................

205!

26.6! PEOPLE LOCATION

205!

26.7!

RELATED PROJECTS

206!

27!

BIBLIOGRAPHY ..........................................................................................................

207!

FP7-SEC-2007-4.2.01 Network enabled command and control system ESS D2.1 State-of-the-Art Report ESS– 217951 - ."*"/%0%*+&1200"34& -5-

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

FP7-SEC-2007-4.2.01 Network enabled command and control system ESS D2.1 State-of-the-Art Report ESS– 217951 - ."*"/%0%*+&1200"34& -5-

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

FP7-SEC-2007-4.2.01 Network enabled command and control system ESS D2.1 State-of-the-Art Report ESS– 217951 < =##3%>9"+9'*,&"*:&=;3'*40,& 3D

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

FP7-SEC-2007-4.2.01 Network enabled command and control system ESS D2.1 State-of-the-Art Report ESS– 217951 < =##3%>9"+9'*,&"*:&=;3'*40,& 3D

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FP7-SEC-2007-4.2.01 Network enabled command and control system ESS D2.1 State-of-the-Art Report ESS– 217951 ? !"#$%,& Table

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

FP7-SEC-2007-4.2.01 Network enabled command and control system ESS D2.1 State-of-the-Art Report ESS– 217951 ? !"#$%,& Table

? !"#$%,&

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!

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!

190!

191!

FP7-SEC-2007-4.2.01 Network enabled command and control system ESS D2.1 State-of-the-Art Report ESS– 217951 @ A9/23%,& Figure

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

FP7-SEC-2007-4.2.01 Network enabled command and control system ESS D2.1 State-of-the-Art Report ESS– 217951 @ A9/23%,& Figure

@ A9/23%,&

Figure 1: Client scalability of publish/subscribe system

27!

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!

42!

43!

44!

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!

50!

Figure 22: SOS GetObservation operation definition

51!

Figure 23: SPS interaction sequence

53!

Figure 24: SPS Package Dependencies

54!

57!

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

 

61!

64!

65!

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

66!

69!

Figure 31: Exemplary SDP session description

74!

Figure 32: KML based level of service map

97!

103!

Figure 34: CBS inside UMTS (3G) network

103!

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

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

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

Figure 35: bi-directional satellite architecture

111!

Figure 36: IDU Concept

112!

126!

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!

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!

156!

Figure 55: An origin-destination matrix

156!

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!

159!

Figure 58: summary view of the transportation progress

164!

Figure 59: A fragment of a map view

164!

Figure 60: map legend

164!

165!

165!

165!

Figure 64: Google Earth

171!

172!

172!

173!

Figure 68: ESRI - 3D Analyst

174!

Figure 69: Ratman

175!

176!

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

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

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

Figure 71: Sensor Map

177!

Figure 72: Geo Grid Framework

177!

Figure 73: Virtual Alabama Views

178!

180!

FP7-SEC-2007-4.2.01 Network enabled command and control system ESS D2.1 State-of-the-Art Report ESS– 217951 B C%*%3"$&=3;89+%;+23%&=773'";8%,& B5-

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

FP7-SEC-2007-4.2.01 Network enabled command and control system ESS D2.1 State-of-the-Art Report ESS– 217951 B C%*%3"$&=3;89+%;+23%&=773'";8%,& B5-

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:

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

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

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

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 pert i- 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 “RESTfu l- 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.

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

There a number of different, and partly even contradicting, definitions of what a Service Ori- ented Architecture (SOA) is. Instead of discussing the similarities and differences of those definitions, ESS adopts the definition given by Srinivasan (Srinivasan & Treadwell, 2005):

“The term service-oriented architecture refers to a style of building reliable distributed sys- tems that deliver functionality as services, with the additional emphasis on loose coupling between interacting services.”

Though being usually implemented using Web Service technology in the context of the Inter- net, SOA is not bound to any specific service technology. In fact, SOA and Web Services are not mutually dependent. In the context of the Internet, SOAP, XML or key-value pairs over HTTP POST and GET is used for client server communication. Services often described using WSDL, Web Service Description Language, which principally allows dynamic binding of arbitrary services at runtime.

An implementation of SOA usually follows a number of design principles and relies, in addi- tion to the services as such, on a number of additional facilities (Vinoski, 2007),(Srinivasan & Treadwell, 2005). As SOA implements the publish-find-bind pattern, service providers publish their service capabilities and location at a registry that allows clients to discover and bind the service at runtime. In addition, SOA requires service definition languages, which developers use to define service contracts; and service platforms, which provide design-time and run- time support for service creation, deployment, and execution. Services advertise details such as their capabilities, interfaces, policies, and supported communications protocols. Imple- mentation details such as programming language and hosting platform are not revealed. SOA features loose coupling, which implies that communicating components minimize their knowledge of each other. Required information for communication is discovered at runtime.

The benefits of this approach are:

improved flexibility, as a service can be relocated easily as long as the registry gets updated,

better scalability, as services can be added or removed on demand,

replaceability, as an underlying implementation can change as long as the service interface is maintained, and

higher fault tolerance, as clients can discover alternative services if a previously used service becomes unavailable

One of the design principles of REST, the statelessness, is also an important feature of the loose coupling implemented in SOA. When a state has to be preserved in a SOA implemen- tation, this can be done at server or client side.

B5@

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

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

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

FP7-SEC-2007-4.2.01 Network enabled command and control system

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

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

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 differ ent 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 perf orm 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

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

FP7-SEC-2007-4.2.01 Network enabled command and control system

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

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

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

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

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

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

FP7-SEC-2007-4.2.01 Network enabled command and control system

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

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

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

FP7-SEC-2007-4.2.01 Network enabled command and control system ESS D2.1 State-of-the-Art Report ESS– 217951 I E>%*+&H39>%*&17"+9"$&H"+"&K*(3",+32;+23%& I5-

FP7-SEC-2007-4.2.01 Network enabled command and control system

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

FP7-SEC-2007-4.2.01 Network enabled command and control system ESS D2.1 State-of-the-Art Report ESS– 217951 I E>%*+&H39>%*&17"+9"$&H"+"&K*(3",+32;+23%& I5-

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. Ch apter 5

describes these different styles of system architecture design in more detail.

Comparing SOA and EDA reveals that the two approaches are quite different (see 5.1).

Characteristic

Traditional SOA

EDA

Interaction

Loosely Coupled

Strongly Decoupled

 

Interaction Flow Control

Synchronous

Asynchronous

 

Communication Initiator

Client

Service

Main Messaging Patterns

Request-Response

Publish/Subscribe

 

Process Communication Models

1:1

1:1, 1:n, n:m

 

Primary Technical Goal

Service

Component

Rapid

Sense

/

Re-

Reuse

sponse

Table 1: Comparison of Service Oriented and Event Driven Architecture

While traditional SOA is about the reuse of service components, EDA focuses on highly reac-

tive (business) processes and rapid sense and respond functionality – a feature that is of

high interest for ESS. However, the boundaries between the two design styles are fluent. For

example, many data infrastructures that are in place today, like SDIs, use both synchronous

and asynchronous request-response.

In this chapter we will concentrate on how traditional SDIs, following SOA design principles,

can be enhanced to leverage the advantages that EDA offers. Ultimately, the combination of

the two approaches will lead to the development of Event Driven Spatial Data Infrastructures

(ED-SDI).

In the following, we will first provide an overview of technologies that are relevant for realizing

an ED-SDI. Before concluding the chapter, we will provide an overview of specifications that

support EDA functionality.

I5<

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

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

EDA/ED-SDI (Everding & Echterhoff, Event Processing in Sensor Webs, 2009). It allows cli-

ents to subscribe at a web service for automatically being notified when an event that is of

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

FP7-SEC-2007-4.2.01 Network enabled command and control system

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

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

interest to the client is detected by that service. The pattern allows integration of various su b-

scription models (e.g. channel, type, filter or group based subscriptions) and introduces d e-

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-Security 1 into the system. This is doable in both WS-Eventing and WS-Notification.

1

Which

in

version 1.1

is

in

fact

a

open.org/specs/index.php#wssv1.1

large set of specifications, see

http://www.oasis-

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

FP7-SEC-2007-4.2.01 Network enabled command and control system

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

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

However, when scalability is concerned the situation is different. Here, having a well-defined

notification broker interface enables scaling of publish / subscribe services.

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

FP7-SEC-2007-4.2.01 Network enabled command and control system

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

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

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.

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

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.

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

Figure 2: Client and publisher scalability of publish/subscribe system requires intelligent connection algorithm

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

FP7-SEC-2007-4.2.01 Network enabled command and control system

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

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

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

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.

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

FP7-SEC-2007-4.2.01 Network enabled command and control system

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

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

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

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

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.

FP7-SEC-2007-4.2.01 Network enabled command and control system ESS D2.1 State-of-the-Art Report ESS– 217951 I5? =>"9$"#$%&17%;9(9;"+9'*,& Some

FP7-SEC-2007-4.2.01 Network enabled command and control system

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

I5?

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

FP7-SEC-2007-4.2.01 Network enabled command and control system ESS D2.1 State-of-the-Art Report ESS– 217951 I5? =>"9$"#$%&17%;9(9;"+9'*,& Some

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 happenin gs 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 Fe a-

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

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

FP7-SEC-2007-4.2.01 Network enabled command and control system

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

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

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

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

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

FP7-SEC-2007-4.2.01 Network enabled command and control system

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

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

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

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

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 i s 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 se r-

vice could not generate the response in the timeout bounds then it should send it via the

WNS to the client.

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

FP7-SEC-2007-4.2.01 Network enabled command and control system

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

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

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-

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

FP7-SEC-2007-4.2.01 Network enabled command and control system

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

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

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:

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

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

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

FP7-SEC-2007-4.2.01 Network enabled command and control system

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

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

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