Military Communications and Information Technology: A Trusted ...

Military Communications 

and Information Technology: 

A Trusted Cooperation Enabler 

Volume 1 

Warsaw 2012

Reviewers: 

Prof. Milan Šnajder, LOM Praha, Czech Republic 

Prof. Andrzej Dąbrowski, Warsaw University of Technology, Poland 

Editor: 

Marek Amanowicz 

Co-editor: 

Peter Lenk 

© Copyright by Redakcja Wydawnictw Wojskowej Akademii Technicznej. 

Warsaw 2012 

ISBN 978-83-62954-31-5 

ISBN 978-83-62954-51-3 

Publication qualified for printing without editorial alterations made by the MUT 

Publishing House. 

DTP: Martyna Janus 

Cover design: Barbara Chruszczyk 

Publisher: Military University of Technology 

Press: P.P.H. Remigraf Sp. z o.o., ul. Ratuszowa 11, 03-450 Warszawa 

Warsaw 2012

Contents 

Foreword ............................................................................ 7 

Chapter 1 

Concepts and Solutions for Communications and Information Systems .................... 9 

Building a Layered Enterprise Architecture Using COTS Products for NATO Air Command 

& Control Information Services ......................................................... 11 

Hasan Turksoy, Mutlu Uysal, Orhan Cetinkaya, Atilla Malas, Ismail Akcaoglu, Yavuz Okur 

Applying NAF for Performance Analysis: Performance Analysis of SOA Systems 

Using LQN Models ................................................................... 21 

Arkadiusz Wrzosk 

Openness in Military Systems .......................................................... 37 

Jessica Connah, Abigail Solomon, John McInnes, Olwen Worthington, Dale Chambers 

The Concept of Integration Tool for the Civil and Military Service Cooperation During Emergency 

Response Operations .................................................................. 49 

Łukasz Apiecionek, Tomasz Kosowski, Henryk Kruszyński, Marek Piotrowski, Robert Palka 

CFBLNet: A Coalition Capability Enabling Network ....................................... 61 

Edgar Harmsen, Syvert Maesel, Fred Jordan, Rob Goode, Einar Thorsen, Jan-Willem Smaal 

Selected Aspects of Effective RCIED Jamming ............................................. 71 

K. Wilgucki, R. Urban, G. Baranowski, P. Grądzki, P. Skarżyński 

Advanced Road Traffic Service Demonstrator ............................................. 83 

Marek Małowidzki, Przemysław Bereziński, Tomasz Dalecki, Michał Mazur 

Modern Low Cost Aircraft Instruments .................................................. 93 

Radek Bystricky, Premysl Janu 

Chapter 2 

Communications and Information Technology for Trusted Information Sharing ......... 103 

SOA in the CoNSIS Coalition Environment: Extending the WS-I Basic Profile for Using SOA 

in a Tactical Environment ............................................................ 105 

Hartmut Seifert, Markus Franke, Anne Diefenbach, Peter Sevenich 

CoNSIS: Demonstration of SOA Interoperability in Heterogeneous Tactical Networks .......... 117 

Trude H. Bloebaum, Ketil Lund 

Protected and Controlled Communication Between Military and Civilian Networks ............ 131 

Anders Fongen 

Use of Cross Domain Guards for CoNSIS Network Management ............................ 149 

Philipp Steinmetz

4 Military Communications and Information Technology... 

The CoNSIS Approaches to Network Management and Monitoring .......................... 161 

Christoph Barz, Anne Diefenbach, Fatih Abut, Matthias Wilmes, Peter Sevenich, 

Pierre Simon, Norbert Bret 

Multi-Topology Routing for QoS Support in the CoNSIS Convoy MANET .................... 179 

Mariann Hauge, Jon Andersson, Margrete A. Brose, Jostein Sander 

Chapter 3 

Information Technology for Interoperability and Decision Support Enhancement ........ 199 

Mathematical Foundations of Interoperability and Composability ........................... 201 

Andreas Tolk 

Semantic Interoperability by Means of Computer Languages ............................... 209 

Ľubomír Dedera 

Semantic Model for Context – Aware Service Provision in Disadvantaged Network Environment ...221 

Joanna Śliwa 

Run-Time Ontology on the Basis of Event Notification Service .............................. 239 

Kamil Gleba, Joanna Śliwa, Damian Duda, Joanna Głowacka, Piotr Pyda 

A Robust and Scalable Peer-to-Peer Publish/Subscribe Mechanism .......................... 253 

Tobias Ginzler 

Automatic Exploitation of Multilingual Information for Military Intelligence Purposes .......... 265 

Sandra Noubours, Matthias Hecking 

Information Fusion Under Network Constraints .......................................... 281 

Felix Govaers, Alexander Charlish, Wolfgang Koch 

Examination of Combination Rules for the Purpose of Information Fusion in C2 Systems ....... 295 

Ksawery Krenc 

Commanding Multi-Robot Systems with Robot Operating System Using Battle 

Management Language .............................................................. 305 

Thomas Remmersmann, Alexander Tiderko, Marco Langerwisch, 

Stefan Thamke, Markus Ax 

Application of CID Server in Decision Support for Command and Control .................... 317 

Krzysztof Muchewicz, Marek Piotrowski, Henryk Kruszyński, Robert Palka 

Managing Lessons Learnt from Daily Missions – Methodology and Tool ...................... 331 

Witold Hołubowicz, Wojciech Dymowski, Tomasz Springer 

Chapter 4 

Information Assurance & Cyber Defence ............................................. 345 

Federated Cyber Defence System – Applied Methods and Techniques ......................... 347 

Bartosz Jasiul, Rafał Piotrowski, Przemysław Bereziński, Michał Choraś, 

Rafał Kozik, Juliusz Brzostek 

Identity and Access Services in NATO Federation Scenarios ................................ 359 

Robert Malewicz, Rui Fiske, Graeme Lunt 

Development of High Assurance Guards for NATO ....................................... 377 

Konrad Wrona, Geir Hallingstad 

Network Traffic Characteristics for Detecting Future Botnets ............................... 395 

Jonathan P. Chapman, Felix Govaers

Contents 

5 

Methodology for Gathering Data Concerning Incidents in Cyberspace ........................ 415 

Adam Flizikowski, Jan Zych, Witold Hołubowicz 

Problems of Detecting Unauthorized Satellite Transmissions from the VSAT Terminals ......... 431 

Przemysław Bibik, Stanisław Gradolewski, Wojciech Zawiślak, Jacek Zbudniewek, 

Radoslav Darakchiev, Jerzy Krężel, Mateusz Michalski, Krzysztof Strzelczyk 

On Multi-Level Secure Structured Content: A Cryptographic Key Management 

– Independent XML Schema for MLS Content ........................................... 439 

Mikko Kiviharju 

Generation of Nonlinear Feedback Shift Registers with Special-Purpose Hardware ............. 455 

Tomasz Rachwalik, Janusz Szmidt, Robert Wicik, Janusz Zabłocki 

Effective Generation of Cryptographic Material for Large Hierarchical Communication Networks ...465 

Marcin Grzonkowski, Jacek Jarmakiewicz, Wojciech Oszywa 

Improving the Efficiency of Cryptographic Data Management by Using an Adaptive 

Method of Planning .................................................................. 475 

Tomasz Czajka, Wojciech Oszywa, Michał Gawroński, Rafał Gliwa 

Modern Usage of “Old” One-Time Pad .................................................. 485 

Mariusz Borowski, Marek Leśniewicz 

Acoustic Steganographic Transmission Algorithm, Using Signal Coherent Averaging ............ 497 

Krzysztof Wodecki, Zbigniew Piotrowski, Jarosław Wojtuń 

Index ............................................................................. 509

Foreword 

Modern military operations are conducted in a complex, multidimensional 

and disruptive environment. The challenging political and social environment 

of the operations necessitates establishing coalitions, consisting of many different 

partners of differing levels of trust, e.g. partners from NATO nations, as well 

as non-NATO nations and others such as the local government bodies and local 

forces. Tight collaboration with these partners and the guarantee that the appropriate 

information is shared within the community is vital to the mission efficiency. 

This also requires understanding of these differences and greater trust as well as 

acceptance of the greater risk involved. 

Dynamic environmental changes and limitations of the technical infrastructure 

assets creates additional challenging issues for the effective collaboration 

of the coalition partners. The fragile nature of the communications infrastructure, 

especially at the tactical level, requires robust methods and mechanisms to 

deal with long delays, communication failures or disconnections and available 

bandwidth limitations. 

These all necessitate a better understanding of the environmental conditions 

and appropriate procedural actions, as well as strong technological support, to 

provide the required levels of interoperability, flexibility, security and trusted collaboration 

in connecting heterogeneous systems of all parties involved in the action. 

Many research efforts aimed at the elaboration and implementation of innovative 

communications and information technologies for military systems, 

enabling trusted information exchange and successful collaboration in disadvantaged 

environments, have been undertaken world-wide. The latest selected 

results of such activities that include novel concepts for military communications 

and information systems, as well as innovative technological solutions, are 

presented in this book. 

The book contains the papers originally submitted to the 14 th Military Communications 

and Information Systems Conference (MCC) held on 8–9 October 2012 

in Gdansk, Poland. The MCC is an annual event that brings together experts from 

research establishments, industry and academia, from around the world, as well 

as representatives of the military Communications and Information Systems 

community. The conference provides a useful forum for exchanging ideas on the 

development and implementation of new technologies and military CIS services.

8 

Military Communications and Information Technology... 

It also creates a unique opportunity to discuss these issues from different points of 

view and share experiences amongst European Union and NATO CIS professionals. 

The papers included in this book are split into two volumes, each contains 

selected issues that correspond to the conference topics, and reflect the technology 

advances supporting trusted collaboration of all parties involved in joint 

operations. The first volume is focused on: Concepts and Solutions for Communications 

and Information Systems, Communications and Information Technology 

for Trusted Information Sharing, Information Technology for Interoperability and 

Decision Support Enhancement and Information Assurance & Cyber Defence, while 

the latter on the following: Tactical Communications and Networks, Spectrum 

Management and Software Defined Radio Techniques, Mobile Ad-hoc & Wireless 

Sensor Networks and Localization Techniques. 

The editors would like to take this opportunity to express their thanks to the 

authors and reviewers for their efforts in the preparation of this book. We trust 

that the book will contribute to a better understanding of the challenging issues in 

trusted collaboration in modern operations, scientific achievements and available 

solutions that mitigate the risk and increase the efficiency of information exchange 

in hostile and disruptive environments. We believe that the readers will find the 

content of the book both useful and interesting. 

Marek Amanowicz 

Peter Lenk

Chapter 1 

Concepts and Solutions 

for Communications 

and Information Systems

Building a Layered Enterprise Architecture 

Using COTS Products for NATO Air Command 

& Control Information Services 

Hasan Turksoy 1 , Mutlu Uysal 2 , Orhan Cetinkaya 2 , 

Atilla Malas 2 , Ismail Akcaoglu 1 , Yavuz Okur 2 

1 STM A.S., Software Engineering Division, Ankara, Turkiye, 

{hturksoy, iakcaoglu}@stm.com.tr 

2 NCI Agency, Capability Development, C2 and Operations Services, 

{Mutlu.Uysal, Orhan.Cetinkaya, Atilla.Malas, Yavuz.Okur}@ncia.nato.int 

Abstract: The development of a Network Enabled Capability (NEC) is viewed by NATO as the most 

effective way to support future operations. In the current state of art, NATO NEC (NNEC) is achieved 

by integrating different systems within a layered Service Oriented Architecture (SOA). Using multi- 

-layered architecture is composed of well-defined standards-based services supported or provided 

by modern Commercial-off the Shelf (COTS) products. Although multiple COTS usage provides 

many benefits in terms of productivity, consistency and flexibility, it also brings some challenges 

such as harmonization of different COTS in a product and serving them in a layered architecture. 

This paper explains the utilization of heterogeneous COTS products/applications within a layered 

SOA based architecture in air command and control domain. Harvesting of COTS in multi-layered 

architecture will increase the flexibility and efficiency of the system, and therefore it will help to 

improve operational effectiveness in NATO. 

Keywords: Air Command & Control; Layered Architecture; COTS; Service Oriented Architecture 

(SOA) 

I. Introduction 

NATO Air Command & Control Information Services (AirC2IS) is a strategic 

and operational level command and control information system which provides 

an automated capability for supporting NATO operational staff to continuously 

adapt to the constantly changing NATO environment and to address the security 

challenges. AirC2IS will support the joint air planning, tasking, monitoring, and 

analysis efforts for NATO air operations, including Tactical Ballistic Missile Defense 

(TBMD) operations. 

AirC2IS leverages a modern, robust, integrated and flexible Service Oriented 

Architecture (SOA)-based solution. It is the first example of the NATO Network


Enabled Capability (NNEC) from the design, delivering the first air and TBMD 

service libraries to the NNEC services framework. 

Integration capability provides flexibility to operate with other Bi-Strategic 

Command Automated Information Systems (Bi-SC AIS) components and national 

systems. AirC2IS interacts with joint, land, maritime, air and other information 

systems to support operational tasks. It will utilize existing Bi-SC AIS core services 

and other NATO Command and Control (C2) applications such as Core Enterprise 

Services (CES) to provide an integrated command and control capability to 

NATO air staff. AirC2IS provides execution of air C2 across all levels of command 

as a single homogeneous process based on seamless, transparent and timely flow 

of data and information. 

These responsibilities and integration with Bi-SC AIS Functional Services and 

Core Services capabilities need using modern software engineering technology 

and provides a comprehensive toolset which is needed to execute responsibilities 

of the NATO war fighter. For this, suitable Commercial-off the Shelf (COTS) 

software products are mindfully selected in order to improve system reliability, 

minimize development time, and reduce project risks. 

AirC2IS has a multi-layered architecture which ensures a flexible deployment to 

the target environment. The architecture is composed of well-defined standards-based 

services supported or provided by modern COTS products; hence, it is extendable and 

scalable. Although multiple COTS usage provides many benefits in terms of productivity, 

consistency and flexibility, it also brings some challenges such as harmonization 

of different COTS in a product and serving them in a layered architecture. 

The following section explains the AirC2IS layered architecture and the COTS 

usage. Section 3 summarizes the challenges of using multiple COTS within a layered 

architecture and explains how to overcome these challenges. The core components 

to harmonize the architectures are explained in Section 4. Finally, the last section 

concludes the paper. 

II. NATO AirC2IS architecture 

AirC2IS has a layered and service-oriented software architecture which 

is modular and composed of well-defined standards-based services supported or 

provided by modern COTS products. AirC2IS maximizes the use of state-of-theart 

COTS software products to make the development faster with mature, proven, 

stable and pre-tested building blocks. 

The AirC2IS will be composed of: 

• Set of AirC2 and TBMD mission applications (exposed to the user at application 

client and portal client) 

• Corresponding data and business services, and their management, 

• Powerful and efficient integration services, 

• Enabling or cross-cutting services for all above.

Chapter 1: Concepts and Solutions for Communications and Information Systems 

13 

A. Layered & SOA based architecture of AirC2IS 

The AirC2IS architecture is designed by taking into consideration newly 

introduced NATO CES framework [5] and SOA governance [4]. It is anticipated 

that after the delivery of AirC2IS, several services provided by this architecture 

will be seen as the first occurrence of the NATO CES envisaged capabilities. This 

is an important step to achieve service standardization and improve interoperability 

within the Bi-SC AIS environment (NATO enterprise). 

AirC2IS utilizes a layered architecture approach to support complex operational 

requirements with good maintainability, reusability, scalability, strength and 

security which is depicted at the Fig. 1: 

Figure 1. AirC2IS layered software architecture 

The layers of AirC2IS (Fig. 1) are defined as: 

• Presentation Layer provides application’s user interfaces. 

• Service/Integration Layer provides access to all the services and the external 

system information. 

• Business Layer provides the business logic/functionality of the application 

• Domain Layer provides visibility to the domain concepts, business processes 

and domain rules 

• Data Persistence Layer provides the interaction with the databases. 

• Cross-Cutting Layer provides the generic technical capabilities to all layers 

B. COTS usage in AirC2IS 

COTS selection criteria includes its correct and efficient implementation 

support to requirements and staying within the overall performance, usability,


and maintainability criteria provided for the project. In addition, extensibility and 

easy customizability of the chosen COTS product is a big plus for an enterprise 

level project. 

For instance, instead of developing a SOA-based framework within this project, 

AirC2IS enjoys the use of a world-wide accepted product, such as Microsoft’s 

BizTalk Server (MS-BT) 2010 framework [1] to develop SOA-based integration with 

external systems. For content management, collaboration and portal capabilities, 

SharePoint Portal [2] solution is being used. There are also a few other complex 

COTS products which have their own architectures. Therefore it is essential to also 

consider the major COTS products’ architectures to have a better understanding 

of the overall structure of the AirC2IS. 

Fig. 2 lays out the general architecture, and also “zooms in” the COTS products’ 

basic architecture as well. 

Figure 2. Software architecture utilizing COTS architecture 

III. Overcoming challenges of multiple COTS usage 

within a layered architecture 

Using frameworks and other reusable libraries helps reducing design and 

development efforts and increases the success of the final product. It also allows 

reserving scarce project resources for effective development of critical mission 

services. 

On the other hand, system needs to be designed carefully to build an integrated 

and easily manageable environment including such different components 

each have its own (and different) architecture.


15 

For instance Microsoft SharePoint is a full-blown system that has its own database 

schema, its own data, business and presentation layers. But AirC2IS needs to 

behave as one system for the user like reaching SharePoint content from application 

side or vice versa. Also, search system must search not only SharePoint content, but 

also mission data maintained by the application side. It is apparent that the system 

must provide some utilities to manage the system centrally. 

Having such different architectures inside one system, those components or 

systems are need to be included or developed with a modular approach and have 

a loosely coupled design. Basic principles followed in design of AirC2IS are: 

• Modular approach, loosely coupled design, 

• Separation of concerns, 

• Separation of mission functions, 

• Following open and industry standards. 

To achieve this, AirC2IS utilizes a SOA based modern architecture. First step 

is determining the decoupled components of the system like in Fig. 3. Next, it is 

necessary to clarify services and contracts for the integration of components. 

In this architecture, there are various COTS and modules to be harmonized 

into one system. A few of these architectural decisions will be specified in the following 

section. 

IV. Harmonizing independent architectures 

As shown in Fig. 3, AirC2IS composed of an integration system which is built 

on MS-BT, a portal system built on SharePoint Portal and application services built 

with Windows Communication Foundation (WCF) of .NET framework. Though 

all of them having different architectures of their own, they need to work like one 

system. For instance the system must have a centralized logging system, compatible 

exception handling capabilities, and centralized monitoring components. 

Figure 3. Modularizing AirC2IS 

AirC2IS architecture harmonizes all those components by providing decoupling 

interfaces between boundaries instead of forcing these architectures to 

change. These core components are explained in detail in the following sections.


A. Centralized logging 

From usage point of view, a system admin requires to keep all the system 

logs centrally view them through a central interface. Such a logging mechanism 

needs to behave in the same manner, with the same interfaces for different parts 

of the system such as client and server side application codes, integration module 

(including BizTalk capabilities) and SharePoint portal module. 

AirC2IS logging system (LOGS) provides necessary logging mechanisms 

for all these participants with the assistance and correct utilization of a collection 

of reusable components like Microsoft Enterprise Library (EntLib) [6] Logging Application 

Block which is designed by Microsoft Patterns and Practices team as a best 

practice implementation of an enterprise level logging system. Architecture of this 

centralized logging system supporting SOA logic is given in Fig. 4. 

Figure 4. AirC2IS logging system architecture 

Having a centralized logging architecture in such a system gives the system 

the benefit of managing all logs of the system from one location. General logging 

flow for AirC2IS components and the components in the figure are explained below: 

1. Logging Utility: Logging Utility is a utility for the Silverlight client which 

is responsible for caching Silverlight client logs for a specified size and 

sending them to Remote Logging Service. 

2. Remote Logging Service: Remote logging service is responsible for sending 

operational logs. Using this service, all operational logs are passed on to 

the LOGS architecture, giving the system the advantage of managing all 

logs from a single location.


17 

3. MSMQ: Microsoft Messaging Queue (MSMQ) [7] is a message queuing 

implementation provided by Microsoft in Windows operating systems 

which allows applications running on separate servers/processes to communicate 

in a failsafe manner. MSMQ stores the messages in its own store. 

The maximum limit of this store is configurable and this will be configured 

according to the performance of Log Storing Service, 

4. Log Storing Service: The log storing service is a local windows service for 

reading logs from MSMQ periodically and writing them to the Log database. 

5. AirC2IS Log & Audit DB: AirC2IS Log & Audit Database is an independent 

database for storing logs and audits. 

6. Log Management Service: Log Management Service is a service for viewing 

and managing logs located in AirC2IS Log & Audit DB. 

LOGS is composed of three main components at the server side Remote 

Logging Service, an MSMQ and Log Storing Service. The logging flow of LOGS 

can be seen in Fig. 5. 

Figure 5. Logging flow at the server side 

In Fig. 5, (1) Remote Logging Service passes operational logs into an MSMQ. 

Since AirC2IS provides a centralized logging architecture, MSMQ is located here to 

avoid concurrency and locking issues. (2) This MSMQ is configured so that it passes 

the logs to Log Storing Service periodically. (3) After these logs are read from 

the queue, they are written by the Log Storing Service to the log & audit database. 

Of course LOGS includes all the necessary capabilities expected from and 

enterprise level system like configurable logging levels or log categorization. With 

such a modular approach we have achieved to build a SOA based modular logging 

system that can be consumed centrally by AirC2IS applications, portal module 

and integration module. This design gives necessary flexibility while maintaining 

the system since all the logging behavior can be configured and managed centrally.


B. Centralized exception handling 

Another important utility required from an enterprise level architecture 

is having a centralized exception handling mechanism to catch all the exceptions 

occurred throughout the system. Since AirC2IS system has n-tier design, it is 

important to pass exceptions between tiers according to the predetermined rules. 

AirC2IS exception handling utility basically supports four important features; 

1. Handling exceptions according to the predetermined policies 

2. Replace the original exception (and message) if needed 

3. Logging all exceptions independent from the developer initiative 

4. Shielding of the service exceptions before returning to the client side to 

not allow an information leakage 

AirC2IS logging and exception handling mechanisms are totally decoupled 

from each other and developed as independent utilities. On the other hand, they 

can be fully integrated through clean interfaces. This design empowers SOA based 

approach of the overall system. Fig. 6 shows what happens when an exception 

occurs in a server side service. 

Figure 6. AirC2IS exception management and shielding approach 

Here also, AirC2IS follows best practices suggested by the Microsoft Patterns 

and Practices team’s Exception Handling Application Block. Having cautious customization 

and configuration of these libraries results in a more stable and easy 

maintainable infrastructure for the AirC2IS. 

C. Centralized enterprise monitoring 

The MS-BT Business Activity Monitoring (BAM) component is responsible 

for tracking of business data and processes. Activities and views can be created for 

monitoring business data and processes within MS-BT. 

Moreover, MS-BT has an ESB Toolkit Management Portal, which provides 

useful functionality for administering MS-BT applications, such as: 

• Graphical metrics 

• Repair and resubmit functionality 

• Alerting based on exception events


19 

• Auditing trails for repair and resubmit 

• Unified view of the .NET Exception data and BizTalk context properties 

• Historical views of exception data 

• Remote web-based access 

• Filtering of exceptions based on application 

• Managing publish & subscribe parameters 

Fig. 7 shows an example of a console report. 

Figure 7. ESB Management Console reports [3] 

V. Conclusion 

AirC2IS is big enterprise level system which includes different capabilities, 

architectures and products embedded inside. There are various COTS products included 

in the overall architecture responsible from different capabilities of the system. 

All of these COTS products have their own architecture which does not aware from 

the other products of the system. But, as AirC2IS, all these different components 

and systems need to work as one system in a harmonized manner. 

With a well-structured modular design and appropriate SOA approach, 

AirC2IS integrates different architectures and combine them for one big system. 

In addition, such architecture requires carefully designed infrastructural utilities 

and capabilities that need to be re-used by different systems and architectures.


References 

[1] http://msdn.microsoft.com/en-us/biztalk 

[2] http://msdn.microsoft.com/en-us/sharepoint/ 

[3] http://technet.microsoft.com/en-us/library/ff699654(BTS.70).aspx 

[4] OASIS Reference Model for Service Oriented Architecture 1.0, Committee Specification 

1, 2 August 2006 

[5] NATO Network Enabled Capability Feasibility Study (NNEC FS), vol. II, Version 2.0, 

October 2005, NATO Unclassified. 

[6] http://entlib.codeplex.com/ 

[7] http://msdn.microsoft.com/en-us/library/windows/desktop/ms711472(v=vs.85).aspx

Applying NAF for Performance Analysis: 

Performance Analysis of SOA Systems 

Using LQN Models 

Arkadiusz Wrzosk 

Military University of Technology, Warsaw, Poland, 

awrzosk@wat.edu.pl 

Abstract: Service Oriented Architecture (SOA) is a concept of architecture that supports interoperability 

which is a key factor to achieve network enabled capability. However, SOA principles have 

also negative impact on performance. Performance problems detected during the mission when 

the system is exploited can affect mission results. Late error correction in the software architecture 

can greatly increase costs. This paper describes the tools which can be used for design and performance 

evaluation of SOA systems. NATO Architecture Framework is used to document various 

views of architecture. Layered Queuing Networks are used to build a performance model of SOA 

system. An example of the system design and its performance model are presented to illustrate how 

described tools can be used for the performance analysis. 

Keywords: SOA; NAF; LQN; UML, performance; MARTE; SoaML 


Systems used during any mission led by NATO in collaboration with Nongovernmental 

organizations (NGO) create complex, distributed and heterogeneous 

environment. Network-enabled capability (NEC) require interoperability 

of the information systems provided by various mission members. The integration 

of heterogeneous systems can be time-consuming and expensive. Furthermore, 

the diversity of missions require from the used systems to be flexible and scalable. 

Described requirements force changes in the approach to system design. 

Service Oriented Architecture (SOA) is a concept of architecture that supports 

interoperability, scalability and flexibility of heterogeneous systems. SOA transforms 

architecture style of an application into a set of connected services (internal and 

external provided by nations), used when they are considered necessary. 

Very important aspect of the mission systems are time constraints in which 

they operate. Operational processes realized during mission use services provided 

by these systems. Furthermore, the existing network infrastructure is used to transmit 

data on mission field. Therefore, the services performance and the network


throughput have a direct impact on the operational processes and consequently on 

mission effects. Cost of removing performance problems detected during exploitation 

can be high, therefore, it is very important to evaluate SOA systems quality 

attributes during the design stage. 

In this paper the tools which can be used for performance evaluation of SOA 

system during the design stage are described. They allow to choose an architecture 

design which fulfills important non-functional requirements. System architecture 

is documented using standard notation, recognized in engineers environment, such 

as Unified Modeling Language (UML). Views from NATO Architecture Framework 

(NAF) are used to structure the specification of the system architecture. System 

models documented in NAF views are transformed into a performance model 

based on Layered Queuing Networks (LQN). 

The document is structured as follows. Section II presents work related to 

the system performance evaluation on the early development stages. Section III 

describes fundamental concepts such as SOA, software model, NAF and performance 

model. Section IV describes mapping between software and performance models. 

Section V presents an example the SOA model and a corresponding performance 

model. Finally, section VI concludes the paper. 

II. Related work 

Paper [1] describes the method for evaluation of quality attributes of a monolithic 

system that has its architecture documented using UML notation. Based 

on UML diagrams, annotated with extensions aggregated in UML profile „UML 

profile for Schedulability, Performance and Time” (SPT) [6], an LQN performance 

model is generated. Resultant model can be solved using a LQN solver (for example 

by the Layered Queuing Network Solver [18]). Similar approach is introduced 

in paper [2]. LQN model is generated from UML diagrams with annotations from 

the MARTE [7] profile. 

In work [5] the method for generating LQN model from the SOA specific 

models is presented. UML diagrams used to document architecture design contain 

description of workflows, components responsible for services realization, 

scenarios and distribution of software on resources. MARTE profile is used for 

models annotation. 

Paper [3] introduces the tool for architecture performance and scalability evaluation 

using discrete event simulation. Similarly to other approaches existing UML 

artifacts are used. Different models can be run simultaneously, which allow analysis 

of different alternative architectures. Simulation results of a single model in different 

configurations (for example with various workload) also can be compared. 

Authors of [8-11] concentrate on the services orchestration performance 

(composed from internal and provided external services) which is responsible for 

operational processes realization. Presented approaches allow to compare different


23 

sets of composite services and obtain optimal configuration from the performance 

point of view. 

III. Background 

System performance is determined by the way a system uses resources. Different 

implementations of the same functionality can have different computational 

complexity. In the performance domain three basic concepts can be distinguished: 

workload, resources and scenarios. Scenario describes the system’s behavior including 

demands for resources. Each scenario is executed with a frequency defined by 

a workload. Resources can represent software (passive resources – for example: 

buffer, critical section, database connection pool) or an underlying platform (active 

resources – for example: processor, disk, network). 

To conduct the system performance evaluation two questions should be answered: 

how the system will be documented and which performance model should 

be used. In the following subsections SOA concept is described including basic elements 

which should be documented allowing performance evaluation. Moreover, 

notations and framework used to document SOA architecture is outlined. Finally, 

the performance model is described. 

A. Service Oriented Architectures 

Service Oriented Architecture is a concept of an architecture that supports 

interoperability, scalability and flexibility of heterogeneous systems. SOA defines 

a ‘service’ concept which represents well defined fragment of an operational functionality. 

Services introduce new abstraction layer between operational logic and 

legacy systems used in organization increasing cohesion between them. SOA 

transforms architecture style of an application into a set of connected services used 

when they are considered necessary. 

Abstract view of SOA can be described using layered architecture. Fig. 1 depict 

high level view of layers [22]. 

Looking at layers presented in the diagram (Fig. 1), the most important 

is the identification of processes and business services used by consumers. An operational 

process describes how an organization achieves its goals. The processes 

layer allows to understand an operational domain which is the object of interest 

when the SOA architecture is defined. Furthermore, it allow to identify the process 

activities that should be supported by services. 

Services are described through well-defined interfaces. Interface definition 

is independent from an underlying platform on which the service implementation 

is running. This approach allows services, build on a heterogeneous 

systems, to interact in a uniform and universal manner. Two types of services 

can be defined:


• basic – provides essential functionality related to data processing in a new 

or a legacy systems. Usually these services create fundamental operational 

layer for the specific system or domain. An example of the basic service 

functionality could be saving the location of military unit. 

Figure 1. SOA layers 

• composite – operates on the higher level than basic services. The composite 

services have access to many different systems and usually are composed 

of basic services (they act as a controller). An example of a composite service 

can be a service which updates location of a military unit in several 

different systems.


25 

Software components implement functionality described by services and 

are responsible for quality of those services. They can implement new logic or 

an adapter to a legacy system. 

Legacy systems are monolithic systems supporting organization’s activities. 

Through a layered structure, SOA allows to integrate those systems using introduced 

integration techniques. 

Services and legacy systems operate on organization infrastructure. This 

layer includes physical resources, operating systems and virtual machines forming 

an execution environment for components and legacy systems. 

B. Software model 

An important element of a system description is a notation used to document 

an architecture design. SOA design is associated with services, components and 

legacy systems layers, but operational processes and infrastructure layers are also 

important for performance evaluation. The operational processes layer provides 

information about the system workload and scenarios which describe how the services 

are used. The infrastructure layer is included into design because it provides 

information about the underlying platform on which the SOA system operates. 

Language chosen to document the architecture of SOA systems is Unified 

Modeling Language [15]. It’s a normalized language which supports design, specification 

and documentation of artifacts created during information system development 

process. UML provides comfortable mechanisms which support extending 

language semantics. A set of created extensions is aggregated in a profile. UML 

notation is widely accepted and used. Fig. 2 depict which layers are modeled using 

the UML language. 

Figure 2. Notations for SOA modeling


Three profiles are used to document SOA architecture. The ‘Service oriented 

architecture Modeling Language’ (SoaML) [16] is a standard used to design a SOA 

solution that is independent from its implementation. The ‘Modeling and Analysis 

of Real-Time and Embedded Systems’ (MARTE) [17] profile supports model-based 

description of real time and embedded systems. It provides a set of annotations with 

are required to perform performance analysis. BPEL profile [20] is concerned with 

modeling an individual process components which will be deployed as automated 

processes. 

C. NATO Architecture Framework 

The NATO Architecture Framework (NAF) [12] supports structured approach 

to documenting architectures and manage their complexity. It provides the rules, 

guidance, and product descriptions for developing, presenting and communicating 

architectures. It facilitates understanding, comparing and integrating the architectures 

developed by NATO and Nations. 

NAF defines ‘views’ and ‘subviews’ that can be used to communicate the architecture 

information to a variety of a stakeholders. A view is defined as a set 

of subviews grouped by purpose. A subview is defined as a pattern from which 

to develop an individual products. Each product has a defined purpose, audience 

and the techniques for its creation and analysis. The system model documented 

in NAF subviews is a base for performance model generation. The subviews selected 

to document a SOA system architecture are depicted on Fig. 3. Additionally, 

mentioned subviews are required for system performance evaluation. 

Figure 3. NAF subviews for SOA


27 

The purpose of NSOV-4 Service Orchestration is to describe how services are 

used to support an operational processes. The services are used in conjunction to 

fulfill an objective that cannot be achieved by any of the services alone. Depending 

on how the services interaction is controlled we can distinguish an orchestration 

and a choreography. For documentation of such services, activity diagram and 

profiles: BPEL and MARTE are used. 

In a NSOV-2 Service Definitions subview services are defined in order to 

understand an operational domain in terms of services supporting the operational 

activities. A definition of service concentrates on the service identification, outcome, 

properties (such QoS), interfaces and policies. To document the service class 

diagram a SoaML profile is used. 

NSOV-5 Service Behavior subview contains detailed description of behavior 

and functionality of an individual service. For this purpose sequence diagrams 

with the MARTE profile are used. 

The purpose of the NSV-1 System Interface Description is to depict which 

and how systems collaborate in an operational domain. Term ‘system’ has a broad 

meaning and can denote a federation of systems (FoS), system of systems (SoS), 

subsystem or a software component. Furthermore, a ‘system’ can denote network 

components and other hardware. The subview can document distribution 

of software systems to the hardware nodes including connections between them. 

To document the resources and software distribution deployment diagrams and 

MARTE profile are used. 

The NSV-4 System Functionality Description subview describes systems 

in more details in terms of their structure and behavior. It’s used to identify and 

describe software components which are responsible for realization of functions 

defined by the services. To document internal structure of systems, components 

diagram, sequence diagram and MARTE profile are used. 

The NSV-12 Service Provision subview depicts which systems contribute to 

the provision of particular services. It provides traceability between the services, 

components and legacy systems layers. Class diagram is used to document this 

mapping. 

D. Performance model 

A performance model is an abstract representation of a system. It describes the system’s 

properties associated with a performance domain. It can be used to performance 

evaluation of a different architecture designs. The results of the analysis can be used 

to support improvement of the system design. This approach allows to detect the architecture 

design errors and lower a cost of the errors correction on late development 

stages or the system configuration. Many different and widely known performance 

models exist, for example: queuing networks (QN), stochastic Petri nets or stochastic 

process algebra. In this work the Layered Queuing Network model is used [2].


Figure 4. Example LQN graph 

LQN is a graph in which two types of nodes can be distinguished. First type is related 

to a software modeling. Software is modeled using ‘tasks’. Every task has a message 

queue where incoming requests are waiting for service. Each task has ‘entries’ which 

represent services provided by a task. An entry execution time can be specified using 

‘phases’ and more complex interactions can be modeled using ‘activities’. A second 

type of nodes represent an computational resources (processors). They are associated 

with tasks which use them when serving requests. A software and hardware node 

can be a single-server or a multi-server. This allows to model multithread tasks and 

multiprocessor servers. Nodes are connected with arcs. They denote service requests 

(send messages). There are three types of request: synchronous, asynchronous and 

forwarding [14]. Fig. 4 depict example of a LQN network. 

At the top of Fig. 4 is a node which describes a class of clients. Each client sends 

demands for two services e2 and e3 provided by the ‘web service’ task (rectangle). Each 

service has an execution time and demands for other services. In this case, the ‘web 

service’ query the ‘database’. Each software task operates on a hardware node (circle). 

The entry e2 was decomposed into three activities with two alternative paths. Each 

activity has an execution time demands and can require service from other entries. 

IV. Mapping NAF subviews to performance model 

The SOA system model is a base for a performance model generation. The structure 

of a LQN model is generated from the high-level SOA architecture documented 

using NAF subviews. The subviews NSOV-2, NSOV-4, NSV-1 and NSV-4 are used 

to create LQN tasks. This subviews contain entities such as: executable operational 

processes, composite and basic services and components responsible for service


29 

realization. LQN tasks for network components are also generated to allow evaluation 

of messages transmission time. The subview NSV-1 is also used to create 

computational resources (LQN processors). A system workload is created based 

on NSOV-4, NSOV-5 and NSV-4 subviews. Operational processes are generators 

of a system workload but they aren’t the only workload generators. Services and 

legacy systems can be loaded by other missions. A workload generated outside 

of a mission for which the SOA system is designed can be modeled using scenarios 

from the subviews mentioned above. Scenarios are documented in interaction 

diagrams in the subviews: NSOV-4, NSOV-5 and NSV-4. Finally, a service time for 

each entry and activity is computed from diagrams with annotations from MARTE 

profile. The subview NSV-12 is used to connect services, legacy systems and components 

layers. Some transformation rules from UML to LQN can be found in [1][21]. 

Fig. 5 describes the transformation algorithm. 

Figure 5. Transformation algorithm 

V. Case study 

In the case of study a sample SOA model documented using NAF is presented. 

Fig. 6-11 contains models described in NAF subviews. The above mentioned models 

are required to generate the LQN graph which is presented in Fig. 12. The main goal 

of the example is to show how the models from the NAF subviews are mapped to 

the LQN performance model. 

Suppose that the executable operational process presented on Fig. 6 is performed 

during the mission. It’s documented using UML activity diagram and two 

profiles: BPEL and MARTE. The process is initiated by the message with target


information. In the first step a request is processed. Next, request for evacuation 

of civilians from a threatened area is send to service provided by external organization. 

Finally, the request for fire on target is send. Process results are saved. Initiating events 

are generated according to closed stream described using the GAWorkloadEvent stereotype. 

Process steps which consume time are modeled using the PaStep stereotype. 

Some of the services can use other services to fulfill their functionality. 

The TargetMsgService sends information about the target to two other services: 

ISTARService and ArtilleryService. The TargetMsgService behavior and its interaction 

with other services is shown on Fig. 7. Requests which consume time and 

resources are modeled using the PaStep stereotype. 

Figure 6. Example NSOV-4 Operational Activity Model 

Figure 7. Example NSOV-5 Service Behaviour


31 

Figure 8. Example NSOV-2 Service Definitions 

Services are described through well-defined interfaces. An interface definition 

is an independent from the underlying platform on which a service implementation 

operates. Fig. 8 shows an example service definition. Class diagram 

with SoaML profile is used. The TargetMsgService provides two operations. 

To implement its functionality the services ISTARService and ArtilleryService 

are required. Fig. 7 describes the TargetMsgService behavior and depicts how 

the required services are used. 

A service is a concept which represents well defined fragment of an operational 

functionality so it is at a level above the technology details. Each 

functionality described by a service is implemented by software components or 

legacy systems which are responsible for quality of those services. Fig. 9 describes 

the software components as well as the provided and required service interfaces. 

The ISTARComponent is an adapter to the legacy system (ISTARSystem) and 

implements the service defined by the ISTARService interface. 

A component implements a set of operations. The behavior of methods describes 

scenario and can be specified using interaction diagrams. Fig. 10 presents 

the specification of the example method. Furthermore, methods have demands 

for resources which is modeled using MARTE profile. Requests which consume 

resources are modeled using the PaStep stereotype, while communicates send 

by network are stereotyped using the PaCommStep. 

Figure 9. Example NSV-12 Service Provision


Figure 10. Example NSV-4 System Functionality 

Systems are distributed on hardware systems. Distribution of software on 

the nodes is documented using deployment diagrams. Fig. 11 shows the example 

components and their distribution on the nodes. Two computational resources 

(GaExecHost) and one network component (GaCommHost) are specified. 

Figure 11. Example NSV-1 System Interface Description 

The structure of a LQN model is generated from the high-level SOA architecture 

documented using presented NAF subviews. The example performance 

model presented on Fig. 12 is generated from the system models described above. 

The prepared model can be solved using a LQN solver [18]. Performance evaluation 

results can be used to propose architecture design improvements.


33 

Figure 12. LQN graph 

Results of architecture evaluation, which performance model is presented on 

Fig. 13 are described below. For architecture evaluation only network throughput 

was modified, but more advanced analysis can also be made. Fig. 13 depict response 

times of operation TargetMsgService.addTarget for various number of clients and 

network throughput. The plot shows, that a network 50% faster, generate twice 

lower response times for various number of users. Evaluation results can be used 

to align network throughput which satisfy nonfunctional requirements. 

Presented example and its evaluation results show that performance analysis 

can support an architect in the decision making about the architecture during 

the design stage.


Figure 13. Response time depend on number of clients and network throughput 

VI. Conclusions 

This paper has presented an approach for performance evaluation of SOA 

systems used during NATO missions. The algorithm for generation LQN performance 

model from software models documented in NAF subviews was presented. 

The performance model can be used for performance analysis of different architecture 

designs and the results of the analysis can be used to support improvement 

of the system design. 

One of the biggest challenges is that the analysis require many different models 

on various levels of abstraction. It requires time and knowledge to design and annotate 

diagrams correctly. Systems realized according to SOA principles are usually 

large so performance analysis can be complex. Furthermore, software designers 

are not trained in the formalisms required by performance analysis. The software 

models must be annotated with information from the performance domain which 

may affect the readability of diagrams used to document system design.


35 

REFERENCES 

[1] D.C. Petriu, H. Shen, “Applying the UML Performance Profile: Graph Grammarbased 

Derivation of LQN Models from UML Specifications”, TOOLS ‘02 Proceedings 

of the 12th International Conference on Computer Performance Evaluation, Modelling 

Techniques and Tools, Springer-Verlag London, UK, 2002, pp. 159-177. 

[2] J. Babau, M. Blay-Fornarino, J. Champeau, “Model Driven Engineering for 

distributed Real-Time Systems”, ISTE Ltd and John Wiley & Sons Inc., 2010. 

[3] P.C. Brebner, “Performance Modeling for Service Oriented Architecture”, ICSE 

Companion ‘08 Companion of the 30th international conference on Software 

engineering, ACM New York, NY, USA, 2008. 

[4] C.U. Smith. L.G. Williams, “Performance Engineering of Software Systems”, IEEE 

Transactions on Software Engineering, vol. 19 Issue 7, July 1993, pp. 496. 

[5] M. Alhaj, D.C. Petriu, “Approach for generating performance models from 

UML models of SOA systems”, CASCON ‘10 Proceedings of the 2010 Conference 

of the Center for Advanced Studies on Collaborative Research IBM Corp. Riverton, 

NJ, USA, 2010, pp. 268-282. 

[6] Object Management Group, “UML profile for Schedulability, Performance and Time”, 

http://www.omg.org/technology/documents/ /profile_catalog.htm 

[7] Object Management Group, “UML Profile for Modeling and Analysis of Real-time 

and Embedded Systems (MARTE)”, http://www.omg.org/ /technology/documents/ 

profile_catalog.htm 

[8] A. D’Ambrogio, P. Boccirelli, “Model-driven Approach to Describe and Predict 

the Performance of Composite Services”, WOSP ‘07 Proceedings of the 6th international 

workshop on Software and performance, ACM, New York, USA, 2007, pp. 78-89. 

[9] A. Maduko, R. Jafri, J.A. Miller, “Modeling and Simulation of Quality of Service 

for Composition Web Services”, 7th World Multiconference on Systemics, Cybernetics 

and Informatics, 2003, pp. 420-425. 

[10] D. Rud, A. Schmietendorf, R. Dumke, “Performance Modeling of WS-BPEL-Based 

Web Service Compsition”, SCW ‘06 Proceedings of the IEEE Services Computing 

Workshops IEEE Computer Society Washington, DC, USA, 2006, pp. 140-147. 

[11] J. Grundy, J. Hosking, L. Li, N. Liu, “Performance Engineering of Service Composition”, 

SOSE ‘06 Proceedings of the 2006 international workshop on Service-oriented software 

engineering, ACM New York, NY, USA, 2006, pp. 26-32. 

[12] NAF v.3 Enabling NNEC for NATO, http://www.nhqc3s.nato.int/ /ARCHITECTURE/ 

docs/NAF_v3/ANNEX1.pdf 

[13] “Service-oriented modeling and architecture”, http://www.ibm.com/ /developerworks/ 

library/ws-soa-design1/ 

[14] G. Franks, P. Maly, M. Woodside, “Layered Queueing Network Solver and Simulator 

User Manual”, http://www.sce.carleton.ca/rads/lqns/ 

[15] Object Management Group, “Unified Modeling Language”, http://www.uml.org/ 

[16] Object Management Group, “Service oriented architecture Modeling Language”, 

http://www.omg.org/spec/SoaML/ 

[17] Layered Queuing Network Solver, http://www.sce.carleton.ca/rads/lqns/ 

[18] N.M. Josuttis, “SOA in Practice: The Art of Distributed System Design (Theory 

in Practice)”, O’Reilly Media, 2007.


[19] Model Driven Solutions, “Enterprise Service Oriented Architecture Using the OMG 

SoaML Standard”, http://www.omg.org/news/ /whitepapers/ 

[20] T. Gardner, “Mapping from UML to the Business Process Execution Language for 

Web Services (BPEL4WS) Web Services”, MDA Implementers’ Workshop Succeeding 

with Model Driven Systems, Orlando, USA, 2003. 

[21] D.C. Petriu, C. Shousha, A. Jalnapurkar, “Architecture Based Performance Analysis 

Applied to a Telecommunication Systems”, IEEE Transactions on Software Engineering, 

vol. 26 Issue 11, November 2000, IEEE Press Piscataway, NJ, USA, pp. 1049-1065. 

[22] U. Wahli, L. Ackerman, A. Di Bari, Building SOA Solutions Using the Rational SDP, 

Redbooks, 2007.

Openness in Military Systems 

Jessica Connah, Abigail Solomon, John McInnes, 

Olwen Worthington, Dale Chambers 

Defence Science and Technology Laboratory (Dstl), Salisbury, Wiltshire, England, 

www.dstl.gov.uk 

Abstract: Traditional approaches to military network procurement taken by government can lead to 

vender lock-in, reducing the potential for competition when the systems need refreshing or major 

upgrades, and also for through life maintenance requirements. One solution to these problems could 

be to require an open systems approach in military systems procurement, reducing single supplier 

issues through well defined architectures, interfaces and ‘open by design’ concepts. The paper presents 

a technical analysis of UK military systems procurement over the last few decades to provide context 

for the current open systems approach. The paper then explicitly discusses the potential benefits and 

risks of such an approach and finally explores how this may impact on air interface, network and 

security systems. Research into Open Systems Architecture (OSA) approaches from two Ministry 

of Defence (MOD) programs is reviewed; the Modular Open Systems Architecture (MOSA), and 

the Land Open Systems Architecture (LOSA), whose aim is to introduce openness within the land 

environment. The primary conclusions of the work which will be elaborated in the paper are; that 

openness is key to providing increased interoperability, flexibility and agility, and that benefits can be 

obtained from designing a degree of openness into all aspects of military networks, for example 

in security, air interfaces and waveforms. 

Keywords: open; open system; open system architecture; openness; military; MOD; networks; 

interoperability 


Where military capability is dependent on complex system technologies, 

UK defense has needed to invest heavily to sustain the advantage necessary for 

success in the battle space. The early costs of raising the technology boundary to 

the next level and exploiting this in new military equipment can be significant. 

Delivery times are often long; therefore the risk that the original capability requirement 

or technology opportunity has shifted increases. 

Once delivered, enhancements to bespoke military equipment can be expensive 

and often unaffordable, as the incumbent industrial supplier levers the Ministry 

© Crown copyright 2012. Published with the permission of the Defence Science and Technology Laboratory on 

behalf of the Controller of HMSO. Reference number DSTL/CP65717.


of Defence’s (MOD’s) ‘lock-in’ to the single provider of the original equipment. This 

vendor lock-in drives high support costs through unique component supply loops, 

while early selection of base technology drives early and expensive obsolescence. 

The MOD has, over the past decade, recognized the importance of moving to 

open systems in a series of policy documents [1], [2] and [3]. The latest document, 

“National Security Through Technology: Technology, Equipment, and Support for 

UK Defence and Security” has re-emphasized that the UK’s defense and security 

requirements should be provided through open competition in the domestic and 

global market, and through buying commercial products which use open standards 

[4]. Indeed, it states clearly that “science & technology spend will focus on 

modular approaches, based around packages of incremental development, that 

lend themselves to efficient and effective technology insertion, making use of open 

standards and architectures to fulfil our equipment needs”, replacing policy in [1] 

and [2]. 

The MOD has also published its System of Systems Approach (SOSA) rulebook 

[5], a shared, structured and managed resource for use in the acquisition 

of defense capability. SOSA offers nine design principles for decision makers to 

guide behaviors throughout the acquisition lifecycle and all nine have the potential 

to be met through the adoption of an open approach [6]. 

Open systems are defined in [4] as, “Systems which are based on publically 

known standard interfaces that allow anyone to use and communicate with equipment 

that adheres to the same standards”. There are a series of benefits that open 

systems have over closed systems which the defense domain seeks: 

• Shared research and development investment; 

• Competitive vendor options; 

• Interoperability compliance; 

• Simplified vulnerability evaluation; 

• Enhanced modelling and planning support; 

• Simplified extensibility and maintenance of equipment. 

There are also a number of barriers to the adoption of open systems which 

may deter commercial companies from adhering to open systems. These include: 

• Business models that do not support working with open systems; 

• Information sharing constraints. 

This paper addresses the benefits and risks that openness may present to 

the military communications community, and specifically covers open air interfaces, 

open network design and open security. Openness has been identified 

as an important consideration in a number of future MOD programs including 

the Land Environment Tactical Communication and Information Systems (LE Tac- 

CIS) project. The Modular Open Systems Architecture (MOSA), which has been 

seeking to introduce a systems approach in naval combat system procurement, and 

the Land Open Systems Architecture (LOSA), which aims to introduce openness 

within the land environment are two examples which are discussed in the paper.


39 

These projects have developed approaches to the use of open systems architectures 

that can be applied throughout the MOD. 

II. Context: The aspiration for openness in MOD systems 

The design and procurement of network equipment in the MOD has changed 

significantly over the decades. In the past, the MOD focussed on the functionality 

and capability required to fulfil a specific aim; this led to systems built on 

custom standards that performed the function they were designed for, but which 

were completely incompatible with other hardware or software which had not 

been specifically designed to interoperate. The support of these systems had to be 

managed by the MOD itself and could not be outsourced due to the knowledge 

of the systems only being contained within the MOD or specific partners. Systems 

such as these, and those made in commercial industry, which are designed to proprietary 

standards and do not interoperate with other hardware and software, are 

often called ‘closed systems’. 

This method of systems procurement could only be sustained with a large 

expert workforce within the MOD, and a large budget. Once the MOD’s funding 

started to decrease it became ever harder to compete on a cutting edge technological 

basis with commercial markets and hence it became less viable to design all military 

systems internally. The MOD therefore, in the more effective management of risk 

and delivery of programs, adopted a prime contractor model, outsourcing design 

and manufacture. This option enabled the MOD to choose off the shelf solutions, 

which was cheaper, but which allowed less flexibility. Defense suppliers often used 

proprietary technologies and solutions, and this has resulted in problems arising 

because different UK systems cannot interoperate, or in some cases even be operated 

in the same space due to conflicting technical requirements. Occasionally, 

the technical understanding of a particular system is tied up with the original 

supplier, meaning costly support contracts are required to ensure the equipment 

can be operated until it reaches out-of-service date. 

Most recently, ‘smart-procurement’ has loosely described an approach in which 

network design is treated as service delivery, with separate off the shelf products 

being integrated in a system of systems architecture. An acknowledged drawback to 

this approach is the continued lack of interoperability across the network (without 

custom-made gateways) and vendor lock-in for minor issues due to proprietary 

information within off the shelf technology. 

It is thought that the service delivery approach currently favoured for the MOD’s 

network procurement may be significantly improved by requiring openness from 

discrete network elements. Open protocols would reduce the burden of ensuring 

network wide interoperability, avoid vendor lock-in and provide a far greater 

understanding of the technology used within the MOD. Such an approach would 

also ensure that suppliers can be compared more effectively, and can be selected


based on service merit. This would enable the MOD to be a much more intelligent 

customer who is not tied in to particular vendors, with the ability to choose the most 

cost effective solution at every stage of the networks lifetime. 

The UK MOD is developing the next generation of tactical networks, and 

a key driver of this is the use of open architectures and standards. The approach 

taken is to define an architecture which is underpinned by open interfaces between 

encapsulated, heterogeneous systems. The LE TacCIS programme [7] is delivering 

this approach, attempting to deliver the transition from a current system of systems 

architecture within Command and Control Information Infrastructure (CCII) to 

next generation Land Environment Tactical CIS. 

III. Assessing the benefits and risks of open systems 

A. Benefits 

A key benefit of open systems to defense is that they enable interoperability, 

making both joint and coalition working easier. Interoperability is a key requirement 

for military communications systems, driven by top level strategies such 

as Network-Enabled Capability (NEC) and politically through increased coalition 

working in all major recent military operations. The need to strengthen partnerships 

through bilateral and multinational relationships is continually highlighted in toplevel 

MOD policy, most recently in the latest Strategy for Defence policy as part 

of “Military Task 3 – To succeed in other operations” [8]. Achieving both joint and 

coalition interoperability requires components which can be operated alongside, 

in conjunction or integrated with systems controlled by separate operators. In terms 

of communications systems, at the technology level this requires either compatible 

standard interfaces, which would be the optimal solution, or use of gateways, which 

can lead to bottlenecks, vulnerable points and communications delay. 

Making technical specifications available to a wider market audience enables 

open standard interfaces and promotes greater objective competition. This objectivity 

in comparing networking systems is critical to allowing intelligent decision making 

in procurement. A report by the national audit office, reviewing the procurement 

of the UK Bowman system, found that “Agile decision making must be underpinned 

by high quality information” [9]. Vendor lock-in emerges from limiting the technical 

knowledge of a system to one supplier, meaning costly support contracts are 

required to ensure the equipment can be operated until it reaches out-of-date service. 

A high level of interoperability would potentially support a modular approach to 

changing technological components based on mission requirements. 

It may be assumed that by using the well known Open Systems Interconnection 

(OSI) model that openness can be achieved by appropriately defined interfaces. 

In practice the OSI model only defines interactions between adjacent layers in a protocol 

and may not necessarily deliver the design intent across a dynamic system.


41 

One example would be a custom-made real-time transport protocol which works 

regardless of physical layer, but may not deliver the real-time intent of the protocol. 

Table I summarises the benefits of open systems. 

TABLE I. Benefits of Open Systems 

Benefit 

Standard Interfaces 

Security Assessment 

Network Design & Planning 

Spectrum Management 

Competition 

Increased Modularity 

Description 

Sharing data between separate technologies is possible by providing 

standard interfaces to manufacturers. 

Open standards allow the buyer to understand and better mitigate 

the risks. 

Planning wide area networks and managing loading is simplified 

if interfaces of different networks are open. 

Efficiently exploiting spatial reuse must be underpinned by information 

on interference characteristics. 

Proprietary advantages can be objectively compared between 

vendors. 

Modular systems can be bought that fit requirements and are 

cost effective. These can simply be replaced when required. 

B. Risks 

The adoption of open systems is thought to be likely to provide both technical 

and operational benefits, but a careful understanding of the risk is required to 

avoid compromise of operational security. 

There are a number of potential barriers to the adoption of open systems 

in defense. The shift to assessing and adopting a broad range of technologies will 

place greater burden on the system integrator, and this role has largely been filled 

by industry suppliers. This would be a highly complex task, requiring not only 

the detailed technical management of systems but also the evaluation of competing 

technologies and vendors for each new system component, and would require 

a trusted partner to fill this role. 

In defense, there are some cultural constraints to openness, based on how things 

have always been done; technical details of military systems are typically kept to 

a ‘need-to-know’ basis, partly to reduce the possibility of vulnerability discovery 

through a security-by-obscurity approach, and partly because Intellectual Property 

rights of supplying organisations must be protected. Often, the business models 

of contractors does not support the information sharing necessary for open systems; 

therefore a culture shift is essential to maximize the effectiveness the military achieves 

from off the shelf components. Public release of technical specifications may lead to 

an ‘arms race’ of vulnerability discovery and defensive patching; the military is likely 

to be an attractive target to a range of attackers. There are some situations where 

openness may never be wanted – for example, where equipment from foreign allies


is being used and must be protected for commercial reasons, or where legacy equipment 

with known vulnerabilities is required for an operation. War-time technical 

specifications (e.g. cryptographic algorithms) may be kept secret for national security 

reasons. The issue of not revealing too much about what we know about an attacker’s 

capability may also arise; for example, governments may choose to avoid disclosing 

that a certain attack has been uncovered to allow the attack’s duration and success to 

be monitored to learn about the capabilities of an adversary. 

IV. Applications of openness 

A. Open air interfaces 

There is a persistent aspiration within defense to exploit open air-interface 

standards developed by industry bodies, such as Wi-Fi developed by the IEEE [10], 

the Universal Mobile Telecommunications System (UMTS) developed by the 3 rd 

Generation Partnership Project (3GPP) [11] and the tactical data network, Link 16, 

which was developed by NATO under the Standardized Agreement (STANAG) 

framework [12]. 

For the specific scope of air-interfaces ‘openness’ may be defined in terms 

of system performance for various scenarios. Understanding true radio performance 

is critical to several core functions within the MOD including: 

• Defining acceptance criteria for systems procurement; 

• Aiding in mission planning for link and emission ranges; 

• Efficient spectrum allocation through spatial reuse; 

• Understanding impact of electronic warfare on links. 

The following is a list of objective criteria which could be used to create 

a standard evaluation approach, deriving metrics from non-intrusive lab testing: 

• Channel Equalization; 

• Link Performance; 

• Spectral Characteristics; 

• Packet Completion; 

• Signaling & Synchronization. 

B. Open network design 

Network design and planning is currently done on a program-by-program 

basis in the MOD, partly due to the lack of guaranteed interoperability between 

devices. It is not that there is a strict lack of confidence in network layer interoperability, 

but more fundamentally, there is no acknowledged way to consistently 

capture vital network statistics. 

The information required for network design diverges widely based on the user 

requirements; high level traffic loading analysis is required for strategic planning


43 

however does not require packet statistics, similarly the optimization of a tactical 

deployed network need not be concerned with network resources, but the actual 

performance of those resources at a packet level. This implies that to create a holistic 

network model solution, as much in-depth information must be obtained as possible. 

This ensures that the right information is available for the appropriate level 

of network design and analysis. 

Network layer equipment detail is only half the challenge, as traffic loading 

is equally important for accurate network analysis. This is often based on a network 

‘as-is’ and for accuracy will require levels of network monitoring not currently deployed 

in most tactical networks. In practice, estimation based on the information 

exchange requirements (IER) is a good approach for all but system-in-the-loop 

network optimization, as it allows the dynamics of various topology designs to be 

understood in context. 

C. Open security frameworks 

Military systems must be protected from a wide range of potential attackers 

as system failure could have dire consequences, potentially resulting in loss of life 

and mission failure. Standard military Security Operating Procedures (SyOPs), 

expressed as stringent requirements and strict orders, are often seen as an obstacle 

to open systems. 

While making systems more open may, if not done carefully, reduce security, 

it is important to consider whether open security mechanisms and standards can be 

developed and used in defense. This is particularly important when considering 

openness as a driver for interoperability; some standardization of protection mechanisms 

is needed to ensure interoperability is not prevented by security constraints. 

This can be complex, as security measures encompass people and processes as well 

as technology. 

Historically, a ‘security through obscurity’ approach has been taken to ensuring 

the security of defense systems, with details of technologies, procedures and even 

capabilities kept secret. Such an approach is a clear block to openness and interoperability 

with allies; interoperability can be achieved only through the disclosure 

of information to trusted partners, which restricts the degree of interoperability 

achievable and rules out any working with less trusted parties. 

Significant progress has been made towards establishing public standards 

for security mechanisms through the involvement of organisations such as the US 

National Institute of Standards and Technology (NIST), and it is more widely accepted 

that leaving technical specifications undisclosed does not protect against 

motivated attackers using techniques such as reverse engineering. 

This is seen most strongly in the field of cryptographic research, where much 

work is carried out to analyse widely-used cryptographic algorithms, and the openness 

of a technical specification is viewed as a positive endorsement of security.


Through standardization, access to ‘best practice’ is possible, and wide use of a public 

standard is an endorsement of that technology. Even if the details of a system’s 

technical operation is known, it cannot be compromised due to the strength of, 

and confidence in, protection mechanisms within the system. This can lead to 

system owners adopting a more sensible risk posture; instead of trying to develop 

costly, custom-made security solutions, a posture of adopting open standards 

and technologies may result in more thought being given to appropriate levels 

of security – resulting in a move to a ‘risk balanced’ approach, which is based on 

careful analysis of the threat, rather than a ‘protect against everything’ mentality 

which is financially inefficient and increasingly more difficult to justify. Openness 

as a posture may also be a deterrent to some attackers as it demonstrates confidence 

in your protection mechanisms. Particular security mechanisms can be adopted 

to deter would-be attackers, for example if an attacker knows they will be traced 

then they may be less likely to attack. 

Whilst there are clear benefits from using standardized and interoperable security 

mechanisms, public disclosure of a security mechanism is still seen as a risk 

to security: attackers are given an awareness of how the system works, without 

requiring the effort involved in reverse-engineering which decreases the skill level 

needed for basic attack attempts. There is also a concern that successful attacks 

against a public standard may not be disclosed. 

Whilst a more open and standards-based approach to security can enable 

interoperability, the increased information disclosure has a risk of making 

it easier to identify attack vectors against a system and reducing the level of skill 

needed to attack a system. Moving from a small number of trusted suppliers 

to a potentially global market for providing security mechanisms will result 

in a wider range of available technical options, but may also require a different 

stance to be taken with respect to trust in sourcing components and provenance 

of software and hardware. 

D. Technical case studies: MOSA, GVA and LOSA 

This paper will now outline the MOD case studies which refined the principles 

for developing open systems which have been stated above. 

MOSA has delivered a technical architecture, an enterprise model and a migration 

strategy and has progressed issues such as the management of Intellectual 

Property Rights (IPR), designing for modular test and acceptance and designing 

for modular certification and accreditation. 

MOSA aimed to provide a standardized structure for flexibly assembling 

combat system components to provide an overall combat capability using looselycoupled, 

non-proprietary, published interfaces. The fundamental characteristic 

of MOSA is that combat systems will be constructed of replaceable modules i.e. 

components will be upgradeable and interchangeable.


45 

The specific objectives of the MOSA program were to: 

• Reduce whole life cost as current combat systems and delivery and sustainment 

approaches are increasingly unaffordable; 

• Deliver combat agility to provide new capabilities and counter new threats 

and to do so rapidly; 

• Deliver acquisition agility to exploit a broader industrial supply base, avoid 

vendor lock-in and field new technologies as they become available; 

• Sustain capability through platform life, including countering technological 

obsolescence and enabling platform life extension; 

• Exploit the opportunities offered by COTS, modularity and openness; 

• Foster a common understanding and industrial openness to the benefit 

of the MOD in performing its mission and also to benefit industry. 

The MOSA architecture was developed by a consortium of seven industry 

companies which are major UK combat system experts. The architecting process, 

illustrated in Fig. 1, is generic and can be applied to systems in other domains with different 

functional and non-functional requirements. It describes the process that yielded 

a complete architectural description of the functionality of multiple applications, 

software infrastructure and hardware infrastructure, using suitable open standards. 

From the functional decomposition of the system, the key interfaces were defined. 

Figure 1. MOSA Architecting Process 

MOSA has provided the following benefits to the MOD: 

• Improved maintenance through component and interface commonality; 

• Cheaper and quicker updates and technology insertion through modular 

decoupled design; 

• Increased re-use of software, potential for reduced duplication;


• Increased operational availability through greater flexibility in repair and 

upgrade; 

• Reduced reliance on specialized test equipment; 

• Reduced risk of obsolescence through design (technology can be refreshed 

more quickly). 

From a project-level perspective, MOSA was successful because: 

• The work was performed as a true joint MOD/Industry effort, with collaboration 

central to the consortium dynamic. There was no division between 

the MOD and Industry and this allowed free and open discussions and all 

participants to share successes equally; 

• In assembling the consortium, great effort was taken to ensure that individual 

participants were the best people from each organization. The participants 

had to have the best skills, experiences and influence available, over and 

above a keenness to develop such skills, to ensure that no single participant 

could dominate; 

• The use of consortium-wide peer review gave everybody a voice. Supported 

by a MOD-led governance regime to kick in where any difference 

or disagreement occurred, the approach reinforced buy-in to all aspects 

of the architecture. 

The Generic Vehicle Architecture (GVA) and Defence Standard (Def Stan) 

23-09 [13] provides for the development of all future vehicles using a single, logically 

connected, cohesive and coherent architecture while enabling field command to 

derive the best logistically from its military assets. It also sets the stage for a more 

competitive procurement process for future vehicle development that has been 

validated by industry. 

LOSA provides an architecture in which common features for GVA, and 

on-going development for similar standards for Generic Soldier Architectures 

(GSA) and Generic Base Architectures (GBA) can enable better interoperability 

and coherency between the three platform types within the operational context 

of the Multi-Role Brigade. 

Chief of Materiel Land (COM(L)) has chosen an architectural approach 

based on the LOSA architecture to manage and govern the acquisition and support 

activities of Defense Equipment and Support (DE&S). The Land force capability 

provided to Brigades, Battle groups and Companies will be governed by the MOSA 

principles. Delivery of coherent force elements is based on the integration/interoperability 

of systems within a deployed brigade, which places the brigade as a system 

of systems, and places military doctrine at its foundation. 

V. Future MOD direction 

Current UK tactical communications systems provide voice and data capability 

on the battlefield. The main element of this system is the Bowman and Common


47 

Battlefield Application Toolset (ComBAT), Infrastructure & Platform (BCIP), but 

also includes LE TacCIS. 

A Transformation Program has been established to bring a more coherent 

approach to supporting LE TacCIS and to do things better and more cost effectively. 

This will be implemented under the Change and Successor programs but 

in the interim continuing support and sustainment is needed for the presently inservice 

BCIP and other LE TacCIS equipment. This Legacy Sustainment Program 

will need to cover the period from April 2013 to March 2016 and it is proposed to 

use this program to start the process of improving the way in which support and 

sustainment is undertaken. 

BOWMAN and its successor will benefit from the introduction of openness, 

but first a way must be found to remove or lessen the proprietary nature of BOW- 

MAN as it is today. To progress to open systems, the MOD will need an effective 

engagement strategy with industry, particularly the current manufacturer. 

The MOD must work collaboratively with the current supplier to move to open 

standards, engaging the supplier by articulating the potential risk to their future 

business of preserving a system which the MOD cannot afford to maintain or 

improve, and by the potential revenue sources of fulfilling a systems integrator 

role and the potential for new markets. The benefits of openness should not be 

exclusive to the MOD if industry is to follow. Industry manufacturers may not 

wish to participate in transitioning to open standards whereas the MOD may not 

be able to support the future cost. Future requirements may need to be defined 

for the future LE TacCIS Successor program that cannot be met without making 

the system more open. 

The transition to openness requires an effective Governance Framework for 

Defense encapsulating Maritime, Land and Air environments. This framework must 

have the authority, directions and guidance functions, including financial control, 

and be compliant with strategic doctrine. The LOSA project is effectively a governance 

framework which provides guidance, direction and policy, and it can be 

use to arbitrate between architectural proponents. The MOD should make use 

of previous investment by talking to both the MOSA consortium and the LOSA 

owner in COM(L) for their guidance. 

Acknowledgment 

The authors would like to acknowledge Dr Stuart Farquhar and Dr Chris Williams 

for providing in-depth expertise in MOD radio networking procurement, 

and Prof. Bob Madahar for his numerous constructive review comments.


References 

[1] Ministry of Defence, “Defence Industrial Strategy”, Cm 6697, 2005. 

[2] Ministry of Defence, “Defence Technology Strategy”, 2006. 

[3] Ministry of Defence, “Innovation Strategy”, 2007. 

[4] Ministry of Defence, “National Security Through Technology: Technology Equipment 

and Support for UK Defence and Security”, White Paper Cm8278, 2012. 

[5] Ministry of Defence (2011) The Systems of Systems Approach web page. [Online]. 

Available: http://www.aof.dii.r.mil.uk/aofcontent/tactical/sosa/content/sosa_rulebook. 

htm 

[6] Loughborough University (2011) SOSA Community Forum web page. [Online]. 

Available: http://hdl.handle.net/2134/8828 

[7] Lt Col A. Coulston, “LE TacCIS Strategy – Industry Release 1.0”, 2011, internal. 

[8] Ministry of Defence, “The Strategy for Defence”, DMC 00307 11/12, 2011. 

[9] National Audit Office, “Delivering digital tactical communications through 

the Bowman CIP programme”, HC 1050 Session 2005-2006, ISBN: 0102942307. 

[10] IEEE (2012) Standards association 802.11 standard web page. [Online]. Available. 

http://standards.ieee.org/findstds/standard/802.11-2012.html 

[11] 3GPP (2012) UMTS specification web page. [Online]. Available. http://www.3gpp. 

org/article/umts 

[12] NATO (2012) NATO STANAG 5516 web page. [Online]. Available: http://engineers. 

ihs.com/document/abstract/PBQYIBAAAAAAAAAA 

[13] Ministry of Defence Defence Standard 23-09, “Generic Vehicle Architecture (GVA)”, 

Issue 1, 2010.

The Concept of Integration Tool for the Civil 

and Military Service Cooperation During 

Emergency Response Operations 

Łukasz Apiecionek, Tomasz Kosowski, Henryk Kruszyński, 

Marek Piotrowski, Robert Palka 

Research & Development Department, 

TELDAT Sp. J., Bydgoszcz, Poland, 

{lapiecionek, tkosowski, hkruszynski, mpiotrowski, rpalka}@teldat.com.pl 

Abstract: Civil-Military Co-operation is tool which allows achieving common aims by forces designated 

originally for different purposes. The most common example of such cooperation are emergency 

response operations, conducted, for example, during natural disasters. Despite the obvious need for 

the right tool which could support simultaneously soldiers and civilians, one can see that usually, 

in Poland, means of communications and methods of operations for sharing the information are 

created ad hoc, according to situation and given resources. In given examples of emergency response 

plans one can find description of using only cell and stationary phones for communication [1]. 

Instant collection and dissemination of information, efficient collaboration and common emergency 

situational awareness are factors needed in order to secure effective cooperation with both military 

and civilian organizations. This can be achieved only by study of NATO doctrines and concepts, 

such as NNEC [2-4], EU NEC [5] or CIMIC [6], and newest technology capabilities, regarding both 

hardware and software. 

Based on that study, a specially designed information system can be introduced that is scalable, flexible, 

interoperable and extendable. Crisis Management System Jasmine is a solution for army and 

other civilian forces requirements, which highly increases awareness and speed of decision process. 

Described in the article solution can be used as a support for different operations managed and 

executed both on the field and stationary posts. 

Keywords: Command and Control Information Systems, NNEC, CIMIC, EXPEDITIONARY OPE- 

RATIONS, Web Portal, Web Services, operational level, emergency response operations 


Civil-Military Co-operation is tool which allows achieving common aims by 

forces designated originally for different purposes. The most common example 

of such cooperation are emergency response operations, conducted, for example, 

during natural disasters. Despite the obvious need for the right tool which could 

support simultaneously soldiers and civilians, one can see that usually, in Poland,


ways of communications and methods of operations for sharing the information 

are created ad hoc, according to situation and given resources. In given examples 

of emergency response plans one can find description of using only cell and 

stationary phones for communication [1]. Instant collection and dissemination 

of information, efficient collaboration and common emergency situational awareness 

are factors needed in order to secure effective cooperation with both military 

and civilian organizations. This can be achieved only by study of NATO doctrines 

and concepts, such as NNEC [2] [3] [4], EU NEC [5] or CIMIC [6], and newest 

technology capabilities, regarding both hardware and software. 

II. Collaboration of different types of crisis management units 

during natural disasters in Poland [7-8] 

Collaboration of different types of response forces during natural disasters, 

combined and joint engagements is regulated as crisis management, which is understood 

primarily as an activity of public administration: 

• Crisis prevention. 

• Preparing to take control over crisis situations through planned actions. 

• Responding in the event of an emergency. 

• Removing the effects of crisis. 

• Reconstruction of resources and critical infrastructure. 

• Cooperation during joined and combined engagements. 

In Poland, there are several administrative levels, which must share information: 

country, state, county, municipality. Their tasks are: 

• Preparation of crisis management or combined, joint engagements plans. 

• Preparation of structures used in emergency or other situations. 

• Preparation and maintenance of teams necessary to perform tasks included 

in the plan for management. 

• Maintaining the databases needed in the process of management. 

• Preparation of solutions in the case of the destruction or disruption of critical 

infrastructure. 

• Ensuring consistency between the management plans and other plans 

drawn up in this regard by the competent public authorities. 

• Evaluation and forecasting of threats (real and potential). 

• Surveillance, monitoring and decision function both during performing 

missions and planning. 

On each of the levels of information, management process can be proceed 

in two main situations: 

• to monitor the situation when no events of a crisis or other emergency 

happen, 

• to response in case of any emergency.


51 

During an emergency situation there is a need to generate reports at a specified 

interval. In these reports two groups of information can be distinguished: about 

important events and actions of special units and about rescue – for example fire 

fighting ones. Frequently they are statistical in nature, however, in some cases, 

they may contain certain elements in more details. Reports should be accessible 

in accordance with established security policies for all units working together 

within the different departments: military and police, fire, medical services, and 

organized to support the civilians. 

Rescue teams are a separate core of emergency response, their activities are 

focused on actions in the field, where on the basis of given orders they are planning 

their tasks. They also need to collect all kind of information which is forwarded 

according to data flow structure. 

III. Concept of realization 

Described ways of collaboration impose directed implementation of solution. 

Many people and organisations need to collaborate at different levels and share 

common information. 

Implementation should be flexible and have clear, consistent architecture 

from business point of view. Furthermore it should be capable and ready for future 

expansion. It should contain independent services which are responsible for 

different topics and areas in defined communities of interests. Shared information 

should be exchanged with established and acceptable workflow. 

Moreover system should be able to connect to multiple sources and gain various 

data from different interfaces. It is not so important from civilian point of view, 

however, this feature is a must for military troops and their need of cooperation 

with forces from other nations, using other systems of C3IS and derivative class. 

Besides flexible data management, software users will need strong social collaboration. 

All these conditions implicate usage of Service Oriented Architecture 

in the design and production stage. 

Service Oriented Architecture is concept promoted by NATO Network 

Enabled Capability [2] (Fig. 1) and EU Network Enabled Capability [5] pointed 

as right one for military command systems. Although crisis management solution 

can not be defined as strictly military, however mentioned principles are appropriate 

in all information management systems. Main assumption of NNEC and EU NEC 

is modularity of business services for greater flexibility. Software systems are built 

from components with defined interfaces, which interior is undefined from business 

point of view. Every component represents service with defined scope of action. 

Furthermore, it is assumed that already existing and fielded software components 

of JASMINE System [9-10] (Fig. 2) will be used. They will be implemented 

on both the server, individual workstation and other, dedicated devices sides to 

extend capabilities and functionalities of the Web Portal and devices.


Figure 1. The flow of the information in the NNEC model [2] 

Figure 2. JASMINE System 

The system contains many nodes and each of them can be dedicated to different 

tasks. That means, that both hardware and software should be carefully selected 

to complement each other. It is possible to identify, in general (Fig. 3):


53 

• nodes of groups of people acting directly with consequences of disasters 

or designed plans, 

• nodes which are responsible for planning and giving the orders to nodes 

lower in hierarchy. 

Figure 3. Nodes structure in crisis management 

Because the most important thing in this type of information management 

systems is fast and reliable data delivery, proper communication medium should 

be selected. Such medium has to assure good quality and, usually, bandwidth. 

Among all kinds of radio means there should be pointed out that because of commonness, 

great coverage and possibility to easily add mobile ad hoc points, good 

option are cellular networks (for example Code Division Multiple Access – CDMA 

technology [11]). 

Groups of people should be able to use mobile hardware designed to resist difficult 

weather conditions and physical damage in spite of incidental falls. Hardware 

should be equipped with support for preselected communication medium. That 

is why in Crisis Management JASMINE System there exist two types of mobile terminals, 

equipped with CDMA modems: T1000 and T4 (which is the smaller one). 

Furthermore, some users will be able to use dedicated device called Rescuer TAG, 

which is capable to send messages, about position of different accidents, to the system. 

Technical specification of dedicated hardware equipment (Fig. 4) includes many 

features. The most important ones are low weight, small LCD, touchable screens,


CDMA, WIFI and Bluetooth support. They contain built in camera or two, depending 

on version. They have the possibility to work long on battery and be able to 

work under heavy conditions. They were also tested for falling from 1 m height 

and they are able to withstand it (even when they are switched on). 

Figure 4. Tactical Terminals: T4, T1000 and Rescuer Tag 

Stationary nodes on different administrative levels are equipped with dedicated, 

ruggedized servers. Servers should be also built in mobile manner. 

Mobile terminals require additional equipment – designed for touchable 

sceen applications. Software and servers should provide information to other 

nodes, with some kind of SOA interface, it assures that functionalities can be 

quickly expanded. The most compatible, with this idea, solution, seems to be 

based on WebServices. 

The more granular the components (the more pieces), the more they can be 

reused. When functions in a system are made into stand-alone services that can be 

accessed separately, they are beneficial to several parties. This architecture also 

provides a way for consumers of services, such as web-based applications, which 

are the most common and known example of using SOA, to be aware of available 

SOA-based services. 

The best solution for desired needs is a Web based server that can be used to 

customize portals and content management sites for collaboration. It should be 

versatile in number of features: 

• management of content: capabilities for managing various files types, 

audio, video and images, support for terms and keywords, content organizer, 

ability to define content types and re-use them across site,


55 

• application integration: possibility to use services like Web 2.0 [12] blogs 

and wikis, 

• social computing: like blogs and wikis, rich member profiles, tagging and 

comments, activity feeds, people search, workspaces, 

• business intelligence: possibility to use scorecards, dashboards and selfservice 

analysis functionality. 

Users use the workstations that run Web browsers and additional software 

components that allow them to take advantage of the functionality offered by 

the Crisis Management JASMINE System. 

The same analysis has been performed for software dedicated to mobile terminals. 

The best choice leads to using JASMINE software components to create 

applications designed for common database and communication infrastructure. 

Web Portal consists of different components responsible for data presentation, 

database storage, services that automate user work as well as other components 

of the system. 

Crisis Management System Web Portal JASMINE is a platform designed for 

collaboration and working with groups of files which allows concurrent cooperation 

on documents and their exchange between different organisational units or 

users. The system includes a set of services that leverages the power of the engine 

and integrates them with the JASMINE system components used in software part 

of Crisis Management System. Thus creates a platform on which different units 

of various types can work regardless of number of functional groups. 

On workstations, software components have an ability of connecting directly 

to system native data sources and provide user with functions capable of data presentation 

and manipulation. Furthermore, in the context of other data sources on 

the server, native ways of replicating data between other command posts are used. 

In addition, software components, which work directly on files allow users 

to manipulate them on workstations, while the outcome of their work is stored on 

the server as files or in database. 

IV. System functionalities 

Crisis Management System design has been based on previous experiences 

with very well tested and flexible JASMINE System. It uses existing components 

regarding infrastructure of communication and database, what means that it is 

able to exchange data over different of military protocols. 

Crisis Management System Web Portal JASMINE is a portal with many 

subpages connecting with various services. This is the basement for work of all 

forces involved in emergency situations or combined engagements. We can distinguish 

user modules specialized in user-friendly service of organizational and 

individual cells – which are part of the functional structure of crisis management 

network.


System supports different dedicated modules responsible for wide area of interests. 

Each module was designed to fulfil needs of unit dealing with one kind of tasks: 

• Video Streaming Web Part (Fig. 5, part 1): possibility to receive video 

streams from rescuers or unmanned aerial vehicles, 

• Web Operational Client (Fig. 5, part 2): supports the process of coordinating 

the work of all of the staff regarding operational data, plans of emergencies, 

provision of maps and other topographic documents, the daily operations, 

situation map, 

• Mail Web Part (Fig. 5, part 3): possibility to edit, receive and send mails 

to predefined contacts from Contacts Manager, ability to create multiple 

inboxes and automatic filters for incoming messages, 

• Contacts Manager Web Part (Fig. 5, part 4): possibility to manage all 

contacts, used in sending and receiving messages, documents and files, 

contacts can represent both individuals and logical units, 

• Calendar Web Part (Fig. 5, part 5): possibility to create and manage tasks 

scheduled for time and date and assigned to individuals and units, 

• Collaboration Web Part (Fig. 5, part 6): supports creating, editing and 

managing documents of all kinds, with the possibility to collaborate within 

group of individuals and units, ability to use templates and generate 

reports in many forms, 

• Documents View Web Part (Fig. 5, part 7): supports viewing and navigating 

documents of all Microsoft Office kinds, 

• File Explorer (Fig. 5, part 8): ability to manage files within Web Portal, 

sending to recipients, 

• Message Communication Web Part: possibility to send and receive text 

messages using own protocol and JCHAT, XMPP, 

• Documents Exchange Web Part: ability to send all documents, prepared 

in other Web Parts, with the help of different protocols. 

All modules should allow to work with the formalized documents that are created 

from predefined templates. Each module will have a typical set of the documents 

templates characteristic for its job. It enables to work through a web browser with 

the following types of MS Office documents: MS Word, MS Excel, MS PowerPoint. 

A. Information sharing and dissemination 

Portal functionality, beyond the storage of files, provides an implementation 

of the documents relevant access policy, archiving, sharing management information, 

business processes and publishing content. Portal fully integrates with 

the operating system. Documents can be easily managed from a file manager built 

into the operating system (Explorer) or from File Explorer Web Part. Documents 

in the portal can also be viewed directly from the operating system.


57 

Crisis Management System Web Portal JASMINE allows coordination 

of information between multiple types of databases through integration with 

JASMINE System. 

Figure 5. Web Portal JASMINE – main page 

B. Communication among users 

Crisis Management System allows communication between users in different 

levels, specialties and affiliation. Methods of communication are different for 

various purposes and depend on demand. They include: 

• Instant text messaging – communication via text messaging available via 

the Internet or via a web browser application (including JCHAT, XMPP 

protocols). 

• E-mail – communication using e-mail. 

• Video – communication using video image coupled with the transmission 

of voice (videoconference). As for voice chat would be possible with one 

or more people. 

• Forums – communication using forums or newsgroups.


V. Practical implementation 

In current paragraph there will be described imaginary example of Crisis Management 

System practical implementation (Fig. 6). It has to be assumed that exist 

few nodes in system. We have stationary nodes with dedicated Crisis Management 

System Web Portal Jasmine servers, each dedicated for different administrative level: 

• country one, where all main decisions and general planning takes place, 

• county node, where all information from given area is collected and analyzed, 

• the same goes for level of district and municipality, but areas of responsibility 

are smaller, 

• nodes located in military forces command post, 

• nodes located in fire fighters command post. 

Figure 6. Example – situation presenting cooperation during crisis management


59 

Furthermore there are many terminals T4 and T1000, handed out to people 

divided into groups. Each group leader receives T4, the bigger version of mobile 

equipment, which can be mounted in vehicle. Others receive either smaller version 

– T1000 or Rescuer Tag. The first phase relies on plans preparations. Country 

node, during this process, sends messages to nodes located lower in hierarchy with 

orders to fulfil local plans for crisis situations. Nodes in local areas receive message 

and, according to templates, start to fill in their smaller versions of bigger plan. 

Next they send drafts to country node, which combines documents altogether. 

Stage two starts when flood begins. Troops data is being sent to dangerous 

areas, where they collect information and insert on map operational symbols 

representing localization of different accidents. Operational crisis view is shared 

between all nodes and troops. Furthermore they send each other (between groups) 

text messages which describe current situation and status. These messages are 

being used by local areas county and other nodes to generate reports which are 

next being forwarded to country node. Country node displays current view and 

combines it with all text information, gathered from bigger surface. It decides, 

according to previously created plans, that it is time to ask for help additional 

forces and sends email to fire fighting troops and request documents to police. 

Special forces are coming to designated areas and decide to call emergency – 

flying vehicle to evacuate most injured civilians. Aircraft arrives, which can be 

seen on the map, takes survivors and, according to route drawn on map, returns 

to base via safest path. 

VI. Summary 

For many years till now, NATO is constantly developing many doctrines 

and concepts that describe effective collaboration within information organisations 

and with the outside world. It is very important that all rules are taken 

into account during planning and execution phase of all tasks resulting from 

civil-military cooperation. 

Considering all aspects presented in the article, described system, based on 

components of JASMINE, altogether with dedicated hardware and Crisis Management 

System Web Portal Jasmine fulfils all needs regarding efficiency, information 

quality and collaboration. Furthermore, using proven and common communication 

technology, it assures its reliability. Everything described as part of Crisis Management 

System proves that technologies such as Service Oriented Architecture, Web 

Services, Web Portals are crucial to ensure system scalability, flexibility, interoperability 

and future development. 

Crisis Management System JASMINE is dedicated information system that 

meets all essential requirements of every level nodes dealing with natural disasters. 

It is a right tool for right people to secure collaboration of unit’s sections and groups 

as well as cooperation within civilian, military and other, special organizations.


References 

[1] “Miejski plan reagowania kryzysowego. Plan główny. Załącznik nr 6.4”, Ośrodek 

koordynacyjno-informacyjny ochrony przeciwpowodziowej. Regionalny 

zarząd gospodarki wodnej w Krakowie. http://oki.krakow.rzgw.gov.pl/ 

Content%5CEdukacja%5Cpdf_ogr_skutkow%5CLPSOPiP_miasto_Krakow%5C6. 

Zalaczniki%5C6.4_Miejski_plan_reagowania_kryzysowego.pdf 

[2] ISSC NATO Open Systems Working Group, Allied Data Publication 34 (ADatP-34) 

NATO. 

[3] Maj. Yavuz Fildis, J. Troy Turner, NATO Network Enabled Capability (NNEC) 

Data Strategy, 2005. 

[4] P. Copeland, M. Winkler, Technical note 1197 Analysis of Nato Communications 

standards for the NNEC, 2006. 

[5] EXTRACT FROM THE NEC VISION EU NEC VISION REPORT, www.eda.europa. 

eu/WebUtils/downloadfile.aspxFileID=1152 

[6] AJP-9, NATO CIVIL-MILITARY CO-OPERATION (CIMIC) DOCTRINE, 2003. 

[7] „Ustawa z dnia 26 kwietnia 2007 r. o zarządzaniu kryzysowym” (Dz.U. z 2007 r. nr 89, 

poz. 590, z późn. zm.), 2007. 

[8] „Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 31 lipca 

2009 r. w sprawie organizacji i funkcjonowania centrów powiadamiania ratunkowego 

i wojewódzkich centrów powiadamiania ratunkowego” (Dz.U. 2009 nr 130 

poz. 1073), 2009. 

[9] W. Zawadzki, „JASMIN wkracza do armii”, Nowa Technika Wojskowa nr 5/2007. 

[10] H. Kruszynski, „Sieciocentryczna platforma teleinformatyczna”, Bellona, Ministerstwo 

Obrony Narodowej, nr 2/2011. 

[11] J. Bannister, P. Mather, S. Coope, „Convergence Technologies for 3G Networks: 

Ip, Umts, Egprs and Atm”, 2004. 

[12] T. O’Reilly, „What Is Web 2.0. Design Patterns and Business Models for the Next 

Generation of Software”, http://oreilly.com/web2/archive/what-is-web-20.html, 2005.

CFBLNet: A Coalition Capability Enabling Network 

Edgar Harmsen, Syvert Maesel, Fred Jordan, Rob Goode, 

Einar Thorsen, Jan-Willem Smaal 

Cyber Defence and Assured Information Assurance Sharing, 

NII Communication Infrastructure Services, NATO Communications and Information Agency, 

The Hague, The Hague, the Netherlands, 

{Edgar.Harmsen, Syvert.Maesel, Frederic.Jordan, Rob.Goode, 

Einar.Thorsen, Jan-Willem.Smaal}@ncia.nato.int 

Abstract: CFBLNet federates the facilities of mission partners to support distributed test and interoperability 

assessment of mission systems in a multinational environment prior to operational 

deployment. Many significant Initiatives have been supported and contributed to coalition success, 

notably ISAF training missions. CFBLNet membership is open to all NATO Nations and mission 

partners of which five are presently members and is growing further. 

Keywords: CFBLNet; C4ISR; RDT&A; federation; coalition, cyber defence; testing; exercise; training 


This paper introduces the operational and cost saving benefits that nations 

can rapidly achieve by using CFBLNet for the preparation and transition to operation 

of their C4ISR capabilities. This paper provides essential information for 

decision makers at National MODs who are responsible for preparing Command, 

Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance 

(C4ISR) for multinational operations, addressing both ‘train as you fight’ and 

‘coalition interoperability’ validation. The CFBLNet supports the entire spectrum 

of ‘Smart Defence’ and is a potential model for future federated mission networks. 

The capability is available to the majority of the International Security Assistance 

Force (ISAF) mission partners today and in future accessible to new members. It reduces 

significantly the cost to each of the national participants through the mechanism 

of one capability being re-used by many partners. 

II. Background 

CFBLNet was established in 2001 and is currently open to 34 Mission partners. 

These mission partners are: all 28 NATO nations and Austria, Australia, Finland, 

New Zealand, Sweden and the NATO organisations. Operating as a true federa-


tion; no single nation owns the CFBLNet. Each member is responsible provisioning 

and operation for its own sites and systems. CFBLNet grew out of the need for 

persistent joint multinational and cost effective infrastructure for trial, assessment, 

testing, exercise and training. The capability allows for various national collaborations; 

e.g. CCEB, NATO, bilateral and multilateral. CFBLNet is accessible through 

sponsorship to additional partner nations, international organisations, industry 

and academia. 

Today CFBLNet recognizes over 234 sites globally which are participating 

in multiple initiatives throughout the year. 

CFBLNet operates under the CFBLNet charter, which establishes a common 

framework consisting of well-defined processes, security procedures and agreed 

technical standards. 

III. Current and potential operational benefits 

Every nation recognizes how difficult it is to maintain the multiple potential 

overlapping bilateral and multinational collaboration infrastructures. With its common 

framework, CFBLNet works as a coordinated capability while maintaining 

the required national and multinational security assurance.


63 

A. Advantages of the multinational federated infrastructure 

There are several benefits from the multinational federated infrastructure. 

Firstly, there is a potential for significant cost saving through sharing of resources 

for joint activities in the C4ISR domain. Secondly, the quality of products developed 

and tested in this way is improved by exposure and validation in a multinational 

environment. Thirdly, nations can reuse their national defence infrastructure 

assets to perform testing which faithfully replicates operational systems. Finally 

the infrastructure was designed from the start to support secure multinational 

interoperability testing; and is now tried and tested with a ten year track record. 

B. Recent examples of successes 

CFBLNet has hosted many significant and successful multinational C4ISR 

events, for example those listed in Table 1 below. 

USA 

NATO 

USA 

NATO 

USA 

USA 

GBR 

USA 

NATO 

AUS 

GBR 

USA 

Lead 

Initiative Acronym/Name 

CTE2 CIAV– Coalition Test and Evaluation Environment, 

Coalition Interoperability Assurance & Validation 

CWIX – Coalition Warrior Interoperability Exercise 

CWID – Coalition Warrior Interoperability Demonstration 

AMN Training Federation Unified Endeavor – series 

EC – Empire Challenge (ISR problem resolution for imagery exchange) 

GEMINI – GEoint Multi-domain ISR Net-Centric Initiatives as a permanent 

CCEB PKI – CCEB Public Key Infrastructure 

ACP 145 – Allied Command Protocol 145 (Coalition Military Messaging) 

NATO AITB – NATO ALT-DAMB Integrated Test Bed (Missile Defence of Europe) 

CDIFT – Coalition Distributed Information Fusion Test bed 

GPDN – Griffin Prototyping and Development Network 

CDEP – Coalition Distributed Engineering Plant (Radar in the loop) 

USA / NATO MAJIIC – Multi-Sensor Aerospace Ground Joint ISR Interoperability Test 

GBR 

GBR 

CAN 

GBR 

PTDLIOT – Partner Nation TDL Interoperability Test 

NTDLIOT – NATO Nation TDL Interoperability Test 

CF-JTEN – Canadian Forces JTEN (Teaming with other networks) 

GUST – Germany/United Kingdom Synthetic Training Trial 

NATO QoS & IPv6 – Quality of Service & Internet Protocol version 6 

USA 

SIGDM&S – Secure International Geographically Distributed Modeling & Sim


In addition CFBLNet has supported several key pre-deployment war fighter 

programs and activities, including; multinational connectivity for air picture; messaging 

services; collaboration; multi-level security initiatives; homeland defence and 

crisis response tools; ship-to-ship command and control; unmanned aerial vehicle 

imagery and situational awareness via enhanced tactical data link interoperability. 

Imagery and video systems proven on CFBLNet are currently supporting operations 

in Afghanistan and other missions. CFBLNet supported key second-tier war fighting 

objectives including on-line distributed war gaming and multinational training exercises. 

1) Some specific success stories include the following: 

CFBLNet supported the build, validation and verification of the NATO ALT- 

BMD program with high speed simulations. Its Integration Test Bed (ITB) is a high 

profile interoperability and requirements validation capability for the program and 

for NATO. The effectiveness of the ITB has been further enhanced by the turnkey 

solutions and capability offered by the CFBLNet. The existence of a test network 

with connections already in place to the majority of ALTBMD national labs and 

system sites facilitated the ITB connection to hardware-in-the-loop testing some 

9 months earlier than originally planned. 

Lessons-learned in live and unmanned Intelligence, Reconnaissance and 

Surveillance aircraft and satellite surveillance in Empire Challenge were applied 

immediately in support of ISAF – Afghanistan. 

The multinational training federation initiative focuses on providing high 

quality mission training with high grade federated modeling and simulation capability 

to the warfighter. In addition, it functions as a pre-deployment and staging 

platform to shorten the time to operation in theatre. 

An example: 

The ISAF Coalition forces joining the Afghanistan Mission Network (AMN) 

required at short notice a persistent test and evaluation infrastructure to perform 

Coalition Interoperability Assurance and Validation (CIAV) activities with regards 

to the national system joining the AMN. For this reason CFBLNet was requested to 

create Coalition Test and Evaluation Environment (CTE2). The goal of the coalition 

test and evaluation environment is to establish a distributed test network to support 

interoperability testing between the coalition applications and data interchanges. 

CFBLNet worked closely with the CTE2 community lead representatives to 

build the persistent CFBLNet CTE2 secure network community within weeks. This 

was achieved through supporting the initiative team with their request and coordinated 

through the CFBLNet secretariat, national lead representatives, network, 

security and initiative workgroups. After approval for execution from the CFBLNet 

Executive Group the initiative was scheduled. Once the sites and initiative security 

accreditation was accepted by the MSAB the CTE2 network community became 

operational and was ready for the first scheduled tests and evaluations.


65 

The participating coalition nations are able to bring accurate examples of their 

national mission CIS and C2 systems to the community thereby creating an accurate 

representation of the AMN for testing. From there the participants initiate interoperability 

testing with the tempo and priorities dictated by ISAF Joint Command, 

based on the Coalition Mission Thread and Information Exchange Requirement, all 

applications to be deployed on the operational network were assessed to identify capabilities 

and limitations, with associated operational impacts. The warfighter benefit 

achieved through the CTE2/CIAV initiative was that it allowed all applications to be 

tested on pre-deployment test network prior to operational deployment. All the interoperability 

issues and patches could be applied before they were introduced into 

the operational environment thus ensuring minimal impact to the operator. In addition 

and equally important to applications testing, the test environment is able to 

simulate the actual operational environment which consists of many nodes with 

multiple application configurations. At a fairly fast rate the CTE2/CIAV team fostered 

the incremental addition of appropriate service and coalition labs as enclave nodes 

to simulate the operational environment. The CTE2 community started initially 

with NATO, the UK and USA. Shortly afterwards Canada, Italy, France, Norway, 

Germany and the Netherlands joined. By adding sites that have national extensions 

to the AMN, the CTE2 provides the Warfighter with an operationally realistic test 

and evaluation environment to mitigate risk on the AMN. Between March 2010 

and July 2012, during 9 periods of 90 days validation cycles, 28 systems were tested 

of which 26 are currently fielded in ISAF.


CFBLNet was selected since it mimics the operational federated infrastructure 

of the AMN. Application issues are able to be resolved without affecting ongoing 

operations and CFBLNet is able to create the required community within a short 

time frame due to its network range within the participating nations and NATO. 

The resulting network architecture will help to redefine the way the mission partners 

support their operational forces and help them to identify the suite of mission 

partner applications required to successfully plan and execute missions. In addition 

persistent testing saves time and money since the network architecture does not 

have to be built each time a capability is to be tested on the AMN. 

C. Potential areas of expansion 

• CFBLNet provides the infrastructure to the significant group of initiatives 

which support the current mission network. Logically the infrastructure 

can serve seamlessly for multinational common development, interoperability, 

evaluation, validation, support and training infrastructure for future Federated 

Mission Networks. 

• Additional efficiency can be established by using Distributed Networked Battle 

Labs (DNBL) services over CFBLNet. 

• Several bi-lateral cyber defence initiatives are using CFBLNet. There is a growing 

potential for multinational NATO and coalition cyber defence initiatives 

to interconnect and strengthen their capabilities by using the trusted infrastructure. 

These could be supported by future value -added distributed cyber 

defence services providers (e.g. CDSEV-DNBL) 

IV. Value 

The CFBLNet community works with customers to identify the various ways 

in which investment in CFBLNet can both reduce total cost of Research, Development, 

Trial and Assessment (RDT&A), Testing, Exercise and Training and provide 

added value: 

A. Reduced costs 

• Infrastructure cost shared across many nations/organizations. 

• High bandwidth available on scheduled basis, and can throttle back to replicate 

operational limits. 

• Flexible options for national infrastructure. 

• Side benefit of multinational secure video conferencing.


67 

B. Rapid event stand-up 

• Standing infrastructure and support teams in 13 countries and NATO, with 

gateway to national training networks. 

• Potential access to the most current mission partner C4ISR applications 

baseline with CTE2 / CIAV. 

• Well-documented workflows for new stand-up. 

• Successfully supporting major events for over 10 years. 

C. Initiative risk reduction 

• Close ties with Multi-National Security Accreditation Board (MSAB). 

• Well practised at working with multinational security procedures – nationally 

cross certified. 

• Reduced initiative risk for timely crypto, security and accreditation community. 

• Community of multinational C4ISR and IA contacts. 

• Single point of contact for each nation/organization. 

• Web presence for information sharing. 

The network effect is visible in the CFBLNet environment: As more nations join, 

the cost per participant goes down, and at the same time the potential benefits goes up. 

Several members recognize the good practices of the federated model internally 

and achieved significant savings and efficiencies within their national environments. 

As an additional win, by connecting to the CFBLNet it easily extends the national 

capacity for bi-lateral and multilateral initiatives. 

CFBLNet supports the elements of Smart Defence which will enhance the investment 

in the short, medium and long term, rather than the ad-hoc, general 

expensive and time consuming solutions that provide limited functionality. 

V. Vision strategy and organisational structure 

A. Working vision 

CFBLNet is the provider of infrastructure for international Command, Control, 

Communications, Computers, Intelligence, Surveillance and Reconnaissance 

(C4ISR) research, development, trials, assessment, testing, validation and training to 

explore, promote, and confirm coalition/combined capabilities for the participants. 

B. Strategy 

The strategy of the CFBLNet community to achieve the vision is to focus on 

user-value, and to reach out to new partners. A third strand of user-driven evolution 

has recently been added.


CFBLNet has matured over the last ten years into a well-managed stable and 

cost-effective infrastructure with an efficient suite of fully documented working 

practices. As it reaches the next stage in its lifecycle, more energy can be devoted 

to customer-driven improvements and outreach to new mission partners. One 

easy performance metric for CFBLNet is the number of supported initiatives; but 

a more important aspect is user satisfaction with the services they use. 

Therefore CFBLNet is looking into applying additional measurements and 

metrics to evaluate the user satisfaction with the aim of continuous improvement. 

C. Organisational structure 

The governance and management structure of CFBLNet have proven to be 

effective way to represent the interests of the mission partners. CFBLNet has a threeperson 

Senior Steering Group and a three-person Executive Group. 

The NATO representation to the CFBLNet management team is provided 

by the NCIA. The NCIA General Manager is the NATO Senior Steering Group 

representative for CFBLNet through endorsement of NATO Secretary General. 

NCIA also provides the NATO representation at the Executive level. Finally NCIA 

as the NATO operational authority for CFBLNet provides the NATO and European 

CFBLNet Network Operation Centre (NOC) and NATO Point of Presence 

(PoP), as a cost effective central network hub for nations and NATO organisations 

to join CFBLNet. 

VI. NATO Communications and Information Agency 

The NCI Agency is part of the NATO Communication and Information Organisation 

(NCIO) and its mission is to strengthen the Alliance through connecting 

its forces, NCIA delivers secure, coherent, cost effective and interoperable communications 

and information systems and services in support of consultation, command 

& control and enabling intelligence, surveillance and reconnaissance capabilities, for 

NATO, where and when required. It includes IT support to the Alliances’ business 

processes (to include provision of IT shared services) to the NATO HQ, the Command 

Structure and NATO Agencies. NCIA is authorized by its Charter to provide 

technical advice, support and services to customers who are either NATO bodies 

or nations. 

As the potential legal framework of a multinational program, NCIA has established 

C4ISR Memorandum of Agreement (MOA) with a number of nations. 

The MOA is a framework agreement covering full cooperation on C4ISR activities, 

with the collaboration terms defined in advance. For the execution of a specific 

scope of work, the C4ISR MOA can be complemented by Technical Agreements 

describing the work and financial terms.


69 

In addition NCIA can act as a multi-national executive coordination agent 

in support of capability development in any area covered under the technical 

framework. The support can span from research contributions and correlation to 

procedure design and engineering and procurement. In this role, NCIA can also 

facilitate the discussion with the C4ISR operational community about the definition 

and establishment of maturity levels for the technical elements under investigation 

so as to provide prioritization and guidance for implementation. 

Finally, NCIA can support the set up and maintenance of a framework for 

sharing information about NATO, national and coalition research activities. 

VII. How to join 

Non-CCEB, NATO mission partners can request guest mission partner status 

via one of the CFBLNet core mission partners (CCEB, NATO, USA). 

NATO nations currently not active on CFBLNet can join seamlessly. 

When accepted as a CFBLNet member, nations can join through: 

• Notifying the CFBLNet secretariat 

• Establish a national CFBLNet PoP in their nation, 

• Link up to the nearest regional CFBLNet NOC 

• Subscribe to the shared service multinational CFBLNet project. 

CFBLNet strongly recommends re-using national available infrastructure to 

extend CFBLNet to national battle labs, exercise and training sites. 

VIII. Conclusion 

Real world examples have been given of how using the CFBLNet provides 

operational benefits and value to nations preparing for coalition operations. 

CFBLNet continues to evolve with a customer driven strategy to achieve its vision. 

Many nations are already engaged. As it grows with additional mission partners 

the value for all will continue to increase. The governance structure, coalition coordination 

and security accreditation procedures and processes have a proven track 

record. The current mission partners selected CFBLNet as their infrastructure for 

multinational C4ISR trial, assessment, testing, exercise and training. 

CFBLNet is proving its value for the ISAF coalition and NATO. Investing 

in CFBLNet is Smart, less money is spent, invested better, versus maintaining 

the legacy infrastructures for RDT&A, Testing, Exercise and Training. Many 

partners expanded the CFBLNet model nationally and created additional savings. 


The CFBLNet infrastructure is the product of many years of effort and investment 

by the mission partners, and the Authors would like to extend their thanks


to all those who have made this possible. Special thanks must go to David Wood, 

Tony DeSteffano, Tom Burns, Andrew Tape, Jim Rutups, Susan Kidd, Glen Wiggins, 

Bernie Yocum, and Russ Richards. 

References 

[1] Combined Federated Battle Labs Network, Publication 1, http://CFBLNet.info

Selected Aspects of Effective RCIED Jamming 

K. Wilgucki, R. Urban, G. Baranowski, P. Grądzki, P. Skarżyński 

Radiocommunication and Electronic Warfare Department, 

Military Communication Institiute (MCI), Zegrze Południowe, Poland, 

k.wilgucki@wil.waw.pl 

Abstract: In recent years it is observed an increasing number of attacks on convoy and military 

vehicles with the use of Improvised Explosive Devices (IED). It is difficult to counter these threats 

because explosive devices are detonated using varied, often non-standard methods. Bombs are fashioned 

from easily obtained materials and with continually developed detonator technologies. One 

of the popular technique of detonation is triggering explosion by radio signals. These devices are 

called radio controlled IED (RCIED). 

In this article were presented various aspects which influence on effectiveness RCIED countermeasure 

system. At the beginning an brief overview of the IED techniques and technologies were mentioned. 

Then basic jamming principles and specific to RCIED aspects were discussed. Taking into consideration 

this problems and limitations, own RCIED jamming system conception was also described. 

At the end an analysis of capability of planned system and short summary was presented. 

Keywords: RCIED, spectrum monitoring, jamming 


Detection and RCIED jamming is conducted to ensure the safety of the soldiers 

involved in the stabilization missions abroad. Improvised explosive devices are used 

to destroy manpower and opponent military equipment by various organizations 

and terrorist forces. Wide use of IED is a main reason of heavy casualties among 

Coalition Forces in Iraq and Afghanistan [2]. Reducing this threat is one of priority 

to ensure safety of soldiers during ISAF missions. 

Mitigation of an IED detonation is a very complex task, because of continuous 

improvement and modification of such weapon and frequent tactics shift. It requires 

sophisticated detection and countermeasure systems. Explosive devices can be detonated 

using varied, often non-standard methods, including remote radio controlled 

devices. The element of surprise is very important for insurgents, therefore IEDs are still 

changing to circumvent the electronic countermeasures. Effective jamming of RCIED 

is very difficult because the detection and reaction time to the threat must be short. 

In this article different aspects of effective countermeasure system against 

RCIED threats were discussed. There were mentioned basic jamming principles


and problems in ensuring effective work of radio-frequency (RF) jammer. Moreover 

description of designed RCIED jamming system conception was presented. 

II. IED technology 

An IED is a homemade bomb, constructed and deployed in improvised manner 

incorporating destructive, lethal, noxious, pyrotechnic or incendiary chemicals 

and designed to destroy or incapacitate personnel or vehicles. In principle, any 

explosive weapon not originated from an industrial production line may be classified 

as an IED [1][5]. 

Historically, there is nothing new about IEDs which have been used in terrorist 

actions for a long time or in unconventional warfare by guerrillas during World 

War II. Recently wide use of IEDs is a main threat for Coalition Forces in Afghanistan. 

IEDs are extremely diverse in design, and may contain many types of initiators, 

detonators, penetrators, and explosive loads. This kind of devices is very effective 

as they are made of elements that are easily available at low cost. Generally IED 

consists of five components: a switch/trigger (activator), an initiator (fuse), container 

(body), charge (explosive filler), and a power source (battery) if applicable. IEDs 

can be produced in different sizes, functioning methods, containers, and delivery 

methods. IEDs can utilize commercial or military explosives, homemade explosives, 

or ordnance components. IEDs are triggered by various methods, including 

radio remote control, infra-red or magnetic triggers, pressure-sensitive bars or trip 

wires [3]. However, now there is a shift to more sophisticated detonation devices, 

such as high-powered cordless phones or GSM handsets. 

IEDs can be divided into three main categories, depending on the explosion 

initiation: 

• Victim Operated Devices – triggered by victims movement or pressure; 

• Timed – triggered with the use of different kinds of timers; 

• Command Operated – triggered by pulling out a safety pin using gossamerlike 

wires/ropes, by generating an electric pulse over command wire or by 

sending a trigger command over radio transmitter. 

RCIED are classified to the Command Operated group, where the trigger 

command is send by a radio transmitter to a hidden bomb attached to a receiver 

linked to an electrical firing circuit. For this purpose, as radio transmitter can be 

used a broad range of equipment from household gadget like a key fob car alarm 

switch, remote controlled toys or a wireless doorbell buzzer to more sophisticated 

pagers, CBs, cellular phones, modified HF/VHF/UHF transceivers and satellite 

phones. Frequency range used by these devices is very diverse. RCIED triggers use 

mainly commercial frequency bands listed in [1]. 

The simplest method that can prevent the activation of RCIED is disrupting RC 

triggers by blocking the radio signal. For this purpose jamming techniques are 

used. Effective jamming of the whole frequency range used by RCIED is practically


73 

impossible and meaningless, because it would block own radio links. Therefore 

it is, necessary to provide a selective distortion emission, based on information 

obtained from the electromagnetic spectrum monitoring. 

III. Jamming principles and techniques 

In this chapter we discuss basic techniques and parameters of jamming signal. 

In order to disrupt radio signals there are applied devices which ensure appropriate 

parameter values of jamming signals. The major parameter determining the degree 

to which jamming will be successful is jamming (J) to signal (S) ratio JSR, described 

by the general formula shown below [5] 

JSR[dBm] = ERP J – ERP S – L J + L S + G RJ – G R (1) 

ERP J – effective radiated power of jamming station in dBm; 

ERP S – effective radiated power of transmitter signal in dBm; 

L J – propagation loss from jamming station in dB; 

– propagation loss from transmitter signal in dB; 

L S 

G RJ 

G R 

– jammed receiver antenna gain in the direction of jamming station in dBi; 

– jammed receiver antenna gain in the direction of transmitter station in dBi. 

The minimum value of JSR is dependent on the signal type which is jammed, 

signal propagation and jamming technique. 

Jammer designers can use various techniques of jamming. All techniques 

have their own advantages and disadvantages and application each of them is directly 

associated with type of jammed signal. The basic techniques include: noise 

jamming, tone jamming, swept jamming, pulse jamming, follower jamming and 

smart jamming [3]. 

A. Noise jamming 

Noise jamming is based on jamming carrier signal which is modulated with 

a random (Gaussian) noise waveform. This technique causes disruption of communication 

between transmitter and receiver by inserting high level noise. A bandwidth 

of jamming signal can have different width. Depending on the bandwidth occupied 

by noise jamming signal, it can be distinguished the following types of signals: 

broadband noise (BBN), partial-band noise (PBN) and narrowband noise (NBN). 

BBN places noise energy inside entire bandwidth used by the communication 

system which is planned to jam. Generally BBN jamming signals fills the channel 

capacity. If the noise power is raised by inserting BBN signals into the channel, 

the signal to noise decrease and according to Shannon theorem, channel capacity 

also decrease [4]. 

PBN places noise energy inside multiple channels indicated to disrupt. 

The channels may be contiguous or noncontiguous.


In the case of NBN all jamming energy is placed into single channel, where 

activity of a communication system was detected. 

B. Tone jamming 

The next mentioned technique is tone jamming. In this type of jamming one 

or several tones are placed in the spectrum. When there is used only one tone, 

only one frequency is disrupted. If multi tones are applied, the tones are placed at 

previously chosen frequencies. 

C. Swept jamming 

Swept jamming technique is similar to broadband or partial-band noise 

jamming. Jamming can be realized by using narrow tone signal or PBN signal. 

In this technique relatively narrowband signal is sweeping across part of spectrum. 

As a result of this, at any instant of time, only part of interesting band is jammed. 

D. Pulse jamming 

Pulse jamming is similar to partial band noise jamming. The main factor 

of pulse jamming is so called duty cycle, which means how long the jammer is switch 

on relative to switch off. The results of jamming strictly depend on the peak power 

and value of duty cycle. 

E. Smart jamming 

Smart jamming exploits weak sides of particular network, such as e.g. GSM 

or UMTS. Technique is based on assault on vulnerabilities e.g.: error correction 

checksums, messages related with acknowledgements, synchronization channels, 

time slots. Identification of a network type and synchronization in time are crucial 

for successful jamming. Known methods of attack include among others: station 

overloading, preventing positive call initiation, preventing from achieving connectivity, 

forged calls to the subscribers, disrupting communications by introducing 

errors into checksums, or distortions in messages related with acknowledgements. 

In this type of a jamming, the knowledge of transmission protocol is the key issue. 

F. Following jamming. 

Following jamming is usually applied against frequency hopping transmission. 

Such jammer search for emissions and when the signal is detected, it is jammed. 

The jammer follows carrier frequency changes of transmitted signal and continues 

jamming.


75 

A coarse model for jamming effective range, that should be workable in any 

situation for the most of the world, is presented in [6]. Maximum effective range 

is given by 

where necessary jamming power P J is 

(2) 

P t – effective power output by the enemy transmitter; 

H J – elevation of jamming antenna above sea level; 

H t – elevation of enemy transmitter antenna above sea level; 

D J – jammer to receiver link distance in km; 

D t – enemy transmitter to receiver link distance in km; 

K – jammer tuning accuracy: 2 (for FM in VHF), 3 (for CW or AM in VHF); 

n – terrain and ground conductivity factor: 

5 – very rough terrain, poor conductivity; 

4 – moderately rough terrain, fair to good conductivity; 

3 – rolling hills, good conductivity; 

2 – level terrain, good conductivity. 

IV. Aspects of effective RCIED jamming 

As it was already mentioned, the trigger for RCIED can be both a mobile phone 

and modified remote control device for a child’s toy or other easily and cheaply 

available electronic gadget (fig. 1). All of those transmission systems can be jammed 

by suitable transmitters that can provide some protection around a vehicle or a patrol. 

The size of the protection zone depends on the JSR – relation of the jammer’s 

power to transmitted power of the device used to trigger the IED (1). 

Radio jamming not only prevents the remote detonation of RCIEDs but also 

obstructs the communication channels of terrorist or riot organizers. Unfortunately 

it can have influence on our own radio communications. 

Therefore it is important to design jammers which can leave ‘windows’ to 

enable friendly communications. Such intelligent, working in a reactive mode, jamming 

sets deployed on mobile platforms have already a few implementations, e.g. 

the Crew Duke [10] used by the U.S. Army. 

RCIED jamming is different from typical electronic warfare involving actions 

taken to impair the effectiveness of hostile electronic devices, equipment or systems. 

In military receiving equipment, in contrast to RCIEDs, are implemented ECCM 

(3)


(Electronic Counter-Countermeasures) mechanisms which attempt to reduce or 

eliminate the effect of electronic jamming. In such case response time of jamming 

system can be longer, because usually the transmitted information does not directly 

affect on destroying equipment and killing people. 

Figure 1. RCIED jamming 

In order to provide effective protection against RCIED, the response to 

the emerging radio signals must be immediate and effective. Hence, there is no 

possibility of using sophisticated methods of signals detection and identification 

which are time consuming. Precise and fast response is needed. Duration of jamming 

transmission is dependent on the speed of a vehicle, which in a few dozen 

seconds could leave dangerous zone. 

If the jammer starts too late it might not protect against the signal that triggers 

the explosion. On the other hand a threat of an initiating signal is temporary 

because a convoy moves and passes possible place of IED installation. Then it is 

possible to switch off the jammer and continue searching for threats. Due to 

the fact that technical details and vulnerabilities of public transmission systems 

are known, it is not necessary to transmit continuously jamming signal. Jammer 

can disturb at least one third of the jammed signal in time or frequency domain to 

be effective [4]. It follows that only part of the time could be used for effective 

jamming, and remaining time can be utilized for target acquisition in different 

frequency bands. 

Moreover, military jamming systems are more complex than RCIED protection 

systems and with the exception of air platforms, mainly designed to work from 

a static outposts. In contrast, RCIED jamming systems are mounted on vehicles


77 

and work in constant motion. This affect on reducing the system power supply and 

as a result decreases protection zone. 

Significant impact on the effectiveness of jamming has type of devices used 

to trigger RCIED. It is easier to neutralize RCIEDs based on commercial solutions 

because there is knowledge of signals, their frequency, modulation which allows 

to define range of jamming in advance. A disadvantage is the unpredictability 

of the trigger method and a great variety of solutions. Easy access to such technology 

and low cost cause difficulties in monitoring such market to eliminate bomb 

planters. More sophisticated solutions to trigger RCIED, which use for example 

spread spectrum or multiband emissions, sometimes on unusual frequency ranges, 

are more difficult to detect and effectively jam. 

In article [1] possible transmission systems are mentioned which can be used 

to initiate ignition of main charge of an RCIED. Every transmission system has its 

own vulnerability to jamming. From documentation, measurements and experiments 

it can be assessed two timing parameters: maximum time to start jamming 

(delay time) and required duration of a jamming transmission to successfully block 

receiver. Maximum delay time is in the worst case less than 100 ms, what imposes 

requirements on the speed of threat detection. Required jamming duration to efficiently 

jam in a synchronized manner, the desired signal is varying from several 

μs to several dozen ms. Other way, 1÷30% of jammed signal duration is required 

depending on the transmission system. 

Analyzing possibilities for RCIED jamming system it is necessary to consider 

such aspects as: 

A. Receiver/detector capabilieties: 

• receiver tuning time (speed of synthesizer) and its accuracy; 

• dynamic range, required more than 90 dB; 

• resistance to high voltage on the input of a receiver (levels greater than +30 dBm); 

• sensitivity, should be close to requirements for a GSM handset at a much wider 

bandwidth; 

• tuning/switching/setting time of preselectors; 

• frequency range for searching a suspected signals; 

• quality A/D converters, required 16 bit resolution; 

• using appropriate time-frequency transform with matched resolution in time 

and frequency; 

• threat identification algorithm, required FPGA FFT implementation with 

DSP support; 

• time for frequency range analysis, shorter than maximum delay time to start 

jamming.


B. Jammer capabilieties: 

• tuning time of an upconverter, required less than 1 ms; 

• reaction time (memory access, switching time between waveforms) of an exciter; 

• D/A converters quality, required 16 bit resolution; 

• power amplifier, resistant to high temperature; 

• utilization of switched RF filters on the amplifier output for protection of friendly 

communications systems; 

• selective jamming, required time synchronization and exact frequency channel 

matching. 

C. Propagation, terrain type and fading influence: 

• jammer antenna height, placement and its impact on protection range; 

• RCIED antenna placement and its impact on jamming effectiveness in fading 

environment [7]; 

• ground conductivity factor, unfavorable in dry rough terrain; 

• link budget (including height, gain of antennas and effective radiated power). 

V. RCIED jamming system conception 

Taking into consideration previously discussed aspects, a concept of automated, 

self-contained RCIED jamming system is based on guidelines: 

• simultaneous multi-band spectrum monitoring and simultaneous multi-band 

reactive and barrage jamming of detected signals; 

• simultaneous multi-band detection, classification and measurement of signal 

parameters using programmable FPGA hardware and DSP support; 

• utilization of filter block for protection of friendly forces communications; 

• cooperation of multiple RCIED jamming devices in a network; 

• user programmable interface for frequency preservation and a jam planning; 

• limited dimensions and weight that allow installation on various types of vehicles. 

At MCI counter RCIED solution is developed which consists following stages: 

1. designing and developing receiver block and validation of its performance 

and accuracy; 

2. designing and developing transmitter block and its integration with a receiver 

block and a controller; 

3. integration and testing also in a cooperative sensor/jammer network. 

Previously effective data processing algorithms for target acquisition and 

identification were developed. It was done using data from commercial wideband


79 

receiver R&S EM510/550. Currently final solution is developed on DSP/FPGA 

board which cooperates with wideband fast tuning receiver. 

RCIED jamming system model will have one receiving (two band) and one 

transmitting (three band) antenna (Fig. 2). A receiving block is composed of two 

tuners intended for constant spectrum monitoring over multiple frequency band. 

Tuners, with wide-band IF filters and DSP/FPGA board perform discrimination and 

identification of signals [1][9]. After detection, jamming is started on a frequency 

band, where the trigger signal was detected. It is performed by the jammer block, 

consisted of three exciters (Fig. 3), amplifiers and two sets of collocation filters. 

Jamming signals are transmitted in frequency bands: 20÷500 MHz, 500÷1000 MHz, 

1÷6 GHz, as a: 

• single tone sweep or narrowband noise sweep; 

• narrowband or wideband barrage noise; 

• prepared signals from a controller’s memory. 

Figure 2. Scheme of reconnaissance-jamming system model 

Figure 3. Scheme of exciter (jammer) model


User interface of the jammer enables to program frequency bands for jamming 

and friendly communication. Controller of the counter RCIED jamming 

system is responsible for programming a jammer block in a reactive jamming 

mode. Jamming decision is taken based on data from tuners. Expected emission 

identification parameters: 

• emission detection range – several km (depending on the radiated power 

of trigger transmitter); 

• scan time of frequency range 26 MHz ÷2,6 GHz below 50 ms; 

• frequency resolution: better than 25 kHz for VHF and 100 kHz for UHF; 

• maximum reaction delay between detected incoming signal and jamming 

transmission beginning should be below 100 ms. 

VI. Summary 

In this paper some aspects which influence on detection and jamming parts 

of RCIED countermeasure system was discussed. A conception of a model RCIED 

jamming system was proposed to overcome some of the pointed difficulties. Results 

from counter RCIED project would be taken into account in newly developed applications 

and EW systems created in MCI. 

Limitations which arise from specific IED operation and profile of mobile 

jamming sets result in a lot of restrictions that have influenced on construction 

of C-RCIED devices, detection and jamming methods. Compact size and restricted 

power source cause that the device provides a limited area of protection. Mobility 

of a vehicle and diversity of possible signals sources cause inability of exploitation 

more sophisticated methods for emission detection and identification in order to 

provide faster response to possible threat. Placing the receiver near the transmitter 

impairs the effectiveness of detection of hostile transmissions. 

To improve detection and jamming performance, it is planned creation 

a cooperative network of several receivers and jammers placed apart. Such system 

allows to mitigate an effect of hiding small signals in interference phenomenon and 

noise background and could combat effect of fading, caused by ground reflections. 

Transmitters working in a network can attack the same emissions (extend coverage) 

or react to different frequencies simultaneously combating multi-frequency triggering. 

Receivers which scan in a network can achieve higher probability of detection 

(cooperative detection) or faster scanning rate in case of independent scanning 

adjacent frequency ranges. Physical separation of receivers from transmitters (one 

vehicle perform scanning other jamming) lead to better sensitivity and extend 

range of detection. For data transmission between network elements, nonstandard 

wireless connections or infrared technology should be used.


81 

REFERENCES 

[1] K. Wilgucki, R. Urban, G. Baranowski, P. Grądzki, P. Skarżyński, „Automated 

protection system against RCIED”, MCC2011. 

[2] https://www.jieddo.dod.mil/content/docs/JIEDDO_2010_Annual_Report_U.pdf 

[3] Improvised Explosive Device Defeat FMI 3-34.119/MCIP 3-17.01. 

[4] R.A. Poisel, “Modern Communications Jamming Principles and Techniques”, Second 

Edition, Artech House, Inc., 2011. 

[5] D.L. Adamy, “Tactical Battlefield Communications Electronic Warfare”, Artech House, 

Inc., 2009 pp. 251-306. 

[6] A. Graham, “Communications, Radar and Electronic Warfare”, John Willey & Sons, 

Inc., 2011, pp. 137-144, 357-363. 

[7] M. Dapper, J.S.Wells, T. Schwaillie, L. Huon, “RF propagation in short range 

sensor communications”. 

[8] B. Piette, “VHF/UHF Filters and Multicouplers”, John Willey & Sons, Inc., 2010. 

[9] G. Baranowski, R. Urban, K. Wilgucki, „Detekcja emisji FH na podstawie analizy 

czasowo-częstotliwościowej widma”, Przegląd Telekomunikacyjny, 8-9/2011. 

[10] http://srcinc.com/uploadedFiles/src/what-we-do/CREW_Duke.pdf

Advanced Road Traffic Service Demonstrator 

Marek Małowidzki, Przemysław Bereziński, 

Tomasz Dalecki, Michał Mazur 

Military Communication Institute, Zegrze, Poland, 

{m.malowidzki, p.berezinski, t.dalecki, m.mazur}@wil.waw.pl 

Abstract: We propose a software architecture for an advanced routing service demonstrator, a key 

component of the traffic subsystem in Insigma 1 . We discuss novel capabilities that are designed to 

fulfill Insigma’s specific requirements. We also describe the approach taken to decompose the complex 

problem of finding optimal routes into a number of manageable entities. Preliminary conclusions 

from our development are presented. 

Keywords: road traffic, routing, route prediction, Open Street Map (OSM) 


The Insigma project is aiming at the development of an intelligent information 

system for global monitoring, detection and identification of threats. The system 

collects data from various kinds of sensors, cameras, and users, and processes 

the data to identify threats and notify appropriate public services. One of Insigma’s 

tasks is road traffic optimization and control, which includes streetlights, information 

boards, and route planning. 

In the paper, we discuss the architecture of a demonstrator of our routing 

service. The service includes most features that could be found in similar solutions; 

additionally, a number of advanced and forward-looking capabilities are 

being developed, some of them are unique and specific to Insigma. While there 

are a number of mature, commercial solutions available (with Google Maps [15] 

as a premier example), we believe it would be interesting and instructive to have 

a look at a large, complex, open-source based development – its assumptions, design 

decisions, and conclusions. 

The paper is organized as follows: First, we overview requirements placed on 

the routing service that stem from Insigma’s goals. Then, we present the service architecture, 

discussing each component in detail. Finally, we state the current state of work 

and future work. We end the paper with overview of related work and conclusions. 

1 

The work has been co-financed by the European Regional Development Fund under the Innovative Economy 

Operational Program, INSIGMA project no. POIG.01.01.02-00-062/09.


II. Routing service capabilities 

The main goal of the routing service is computing “optimal” routes (optimal 

– according to specified criteria), taking into account both static (the map) and 

dynamic (traffic intensity, weather conditions, threats, etc.) data. The fact that our 

routing service is a key component of Insigma dictates a requirement for the service 

to implement a number of additional functions, which include: 

• Planning dedicated routes for privileged vehicles (police, fire brigade, 

ambulances, other special-purpose vehicles); 

• Taking into account traffic prediction for longer routes (as traffic conditions 

may change during the drive); also, route prediction (computing routes 

with drive starting at some time in the future); 

• A number of public security related options: planning of “safe” routes (bypassing 

dangerous places), additional route computation modes (as manyto-one, 

which allows e.g. to compute the optimal route from the nearest 

hospital to the place of accident). This requires a dynamic map containing 

data about threats (of various types). 

• Support for traffic load-balancing: calculation of alternative routes. Such 

a function is currently available e.g. in Google Maps. However, in Insigma, 

the routing service will be closely coordinated with traffic monitoring and 

control, and alternative routes will allow to evenly distribute traffic. 

III. Architecture 

Insigma’s traffic subsystem architecture is shown in Fig. 1. Its main components 

include the client (described in section X), the route server (discussed throughout 

the paper) and the traffic warehouse, containing historical traffic data and supporting 

traffic prediction. 

Figure 1. Insigma’s traffic subsystem architecture 

During the early phase of the project, a number of specific, unrelated APIs 

have been defined. The APIs have been based on different programming models and


85 

employed incompatible data types; their integration would be extremely complex. 

Thus, for our routing service, we have decided to divide the server into a number 

of separate elements, each offering a compact API and performing a well-defined 

task. As a result, the server is composed of the following components (refer to Fig. 2): 

• Input/output, a component responsible for handling messages for clients, 

providing security (if necessary) and dealing with quality-of-service issues 

(also – if necessary); 

• Database, containing the static map and dynamic data (section IV); 

• Graph builder, responsible for transforming map data into a graph (section V); 

• Adapter(s), computing graph weights (section VI); 

• Algorithm(s), performing route optimizations (section VII); 

• Finally, dispatcher, managing the above-mentioned elements (section VIII). 

Figure 2. The route server’s internal architucture 

The server is implemented in the Microsoft .NET framework environment. 

The software architecture is organized around a number of interfaces (with each 

component having its dedicated interface(s)) and components (classes contained 

in .NET assemblies) that implement these interfaces and may be easily replaced 

for research or testing purposes. For example, adapters and algorithms (see sections 

VI and VII) are dynamically loaded according to the server’s configuration. 

In the following sections, we describe each of the server’s components in detail. 

IV. The Database: Static Map and Dynamic Data 

We have selected the OpenStreetMap [8] project as our source of static maps. 

OSM provides free geographic data for the whole world. The data may be encoded 

in XML or stored in a PostGIS [14] database (with conversion performed


by osm2pgsql [12]). OSM maps are supported by popular rendering software, such 

as OpenLayers [9]; the rendering process is sufficiently flexible for most applications. 

Unfortunately, OSM maps in their default format (and taking into account 

their content) are not suitable for route computation. First, the data lack majority 

of important information about roads. Second, while there are some proposals 

of crossroads modeling, the maps do not contain any reasonable definitions. In addition, 

OSM elements representing ways may be arbitrarily long and span a number 

of crossroads (which makes building a graph harder). Summarizing, the OSM data 

in their default form need a lot of work on restructuring and adjustment. 

Taking the above into account, necessary extensions have been designed 

as a joint work of teams at the AGH University of Science and Technology and 

the Military Communication Institute. A number of additional PostGIS tables and 

dedicated conversion software has been developed in order to supplement and 

restructure the original OSM data. 

The main OSM tables include nodes, ways and way_nodes (specifying both 

roads and contours) and node_tags/way_tags, containing parameter values for 

nodes and ways, respectively. Our main extension tables are as follows (see Fig. 3): 

• way_segments – a way segment is a part of a single way and connects two 

crossroads; 

• lanes – a table modeling one-directional lanes, possible multiple, of a way. 

Lanes start and end at way segments and in places where an important 

road parameter changes (e.g., a speed limit road sign is located). 

• crossroads – basically, a crossroad is a container for turns (see below); 

• turns, turn_vias – turns define rules for changing way segments at crossroads. 

For complex crossroads, shortcuts are defined in the form of additional way 

segments gathered in the turn_vias table. 

• turn_properties, lane_properties – contain parameter values (a turn may 

be defined as forbidden by the traffic rules). 

Figure 3. Modeling of ways and crossroads in PostGIS


87 

The static map is supplemented with dynamic data related to current traffic 

situation (cameras observing queue lengths at crossroads and sensors estimating 

average speed); in future, dynamic data will also contain other important information, 

as weather conditions or Insigma-specific security events and threats. 

V. Graph builder 

The main task of the graph builder is to construct a directed graph, containing 

static (map of roads and crossroads) and dynamic (current traffic and other 

dynamic data) parameters describing its edges. The complete graph is returned 

in a single step: A client could influence the graph, supplying problem parameters 

(including start, destination, and intermediate points), vehicle profile and some 

additional options, but there is no possibility of a gradual graph construction (this 

is a design decision which allows to make the interface simple). Note that graphs 

for privileged and non-privileged vehicles may significantly differ. 

The graph builder is responsible for graph reduction in case the routing points 

are sufficiently distant. While the neighborhood of the specified points contains 

a complete network of ways, more distant areas would only include main roads. 

A constructed graph is equipped with a handle to data warehouse (for traffic 

prediction) and needs an adapter to be configured before the graph is passed to 

an optimization algorithm. This is discussed in the next section. 

VI. Graph adapters 

The purpose of an adapter is the calculation of weights in graph edges. The calculation 

takes into account static and dynamic parameters that describe an edge 

(and a way it represents). The selection of parameters and their significance depends 

on a user’s request (route type, vehicle profile, etc.) and a routing algorithm. Generally, 

the dispatcher (see section VIII) selects an algorithm and an adapter, which, 

together, are expected to be able to solve the problem. Adapters are registered 

in the server for a specified task type. 

An example of a (somehow trivial) adapter could be a shortest path adapter, 

which simply uses way lengths as weights values. However, more advanced adapters 

would usually compose weights in a more complex way, taking into account 

a number of properties. For non-additive parameters, an adapter could use a vector 

of weights. 

As the weights include dynamic parameters (e.g., the current traffic intensity 

at a given way segment), they are functions of time. The adapter computes them 

when necessary and decides on a caching strategy (for weights that are expensive 

to compute, e.g., require a request to traffic data warehouse). 

Note that the “physical” graph structure is not altered by an adapter. However, 

in practice, the graph could be modified by weights values (e.g., a high weight value 

that practically eliminates a given way at a specified time).


Calculation of weights values by an adapter is a very important step, as it directly 

influences the result of route optimization. 

VII. Routing algorithms 

The role of an optimization algorithm is simply to find the best route given 

a weighted graph. Algorithms that do not support dynamic weight values, such 

as the classic Dijkstra [1], would only use the time value of 0 and thus work on 

a snapshot (of a graph at relative time 0). In contrast, time-aware algorithms provide 

predicted values of time as they “travel” across the graph. 

We distinguish two main problem categories: Those with additive weights and 

those with weights that are non-additive. In the former case, we believe that edge 

costs are represented as a scalar (i.e., a scalar function of time). In the latter case, 

a vector of weights is used. Algorithms that support independent edge weights 

have been considered for routing in telecommunication networks [2]. A practical 

example could be the work discussed in [4], with SAMCRA algorithm [2] (Self- 

Adaptive Multiple Constraints Routing Algorithm) computing paths with one weight 

representing used bandwidth and another one referring to a delay time. As a result, 

the optimal route fulfilled required spare bandwidth on all links and, at the same 

time, assured bounded (acceptably small) delay times for packets. 

Our approach assumes that a complete graph is built before optimization 

starts. However, there is a category of algorithms [citation needed] that construct 

the graph gradually as the calculation progresses. They use azimuth and distance 

to destination and exploit heuristics in order to find the solution. We believe that 

such an approach would require multiple queries to database, which would severely 

affect performance. In any case, this mode is not directly supported (by graph API); 

still, such algorithms could work in our demonstrator’s environment, building their 

graphs out of a complete graph returned by the graph builder. 

VIII. The Dispatcher 

The dispatcher’s task is to combine the activities of the other components. 

First, it identifies a set of algorithm-adapter pairs able to solve the problem defined 

by a client’s request, and selects a pair on the basis of some criteria (randomly 

in a simple case). Then, it builds a graph, configures the adapter for the graph, and 

asks the algorithm to compute the route. In case of failure, the dispatcher could 

repeat some or all of the steps (build a larger graph, select another algorithm, etc.). 

When the route is found, it is supplemented with geographical data (detailed route 

shape) and additional info (road signs, traffic situation, important events, etc.), and 

returned to the client. We would like to emphasize that the mapping of graph edges 

(composing the optimal route) back to ways is quite a complex task, e.g., shortcuts 

through crossroads need to be expanded to real, detailed tracks.


89 

A more advanced dispatcher could, for research purposes or even in production, 

if resources allow, start a number of parallel optimizations (each using a different 

algorithm), taking the result of the fastest algorithm (and canceling the rest). 

IX. Other components 

Our route server also supports a few typical services, such as auto-complete 

and geocoding, although its capabilities are not as advanced as in e.g. Google Maps. 

(As Insigma puts stress on innovation, it is not a goal to repeat features that are 

already widely available on the market.) Perhaps a novel idea is the option to specify 

routing points (start, destination, intermediates) in the form of a well-known location 

types (drugstore, hospital, etc.), with a type denoting all points of this type 

located within a considered area. 

Unfortunately, during the development we encountered a number of problems 

related to OSM (and the quality of open-source data). These problems include 

incomplete OSM map content for tested area, some errors and “mess” in the data 

(e.g., incorrect city borders, inconsistent naming), and, finally, poor performance 

(at least on a budget PC machines), which enforced pre-caching results (e.g., a list 

of cities in Poland for auto-completion) in files. A real-world deployment of our 

service would definitely require better map data. 

X. The Client 

The primary task of a client application is to generate a request for server and 

display its response (a route with additional information). In future, we plan to 

extend its functionality with GPS-based position tracking and route recalculation 

during the drive. 

The client is implemented in JavaScript and employs a number of related 

technologies: 

• User interface is built using jQuery Mobile [7], a popular library optimized 

for mobile web browsers; 

• Map display is based on OpenLayers [9]; 

• Communication with server utilizes Web Services with JSON as data encoding 

format; a high-level Ajax-based API has been developed for this 

purpose; 

• Finally, the geolocation API [5], provided by a browser (see [6] for an example), 

is required for location tracking (in case of a mobile terminal). 

The client has been tested on a PC (with Google Chrome or Firefox) and 

a mobile terminal (a Samsung tablet with Android 3.1 OS, running its default web 

browser – see Fig. 4). Performance and functionality are comparable in both cases.


Figure 4. Samsung tablet running our client 

XI. Current and future work 

The current work involves the development of various versions of the server’s 

main components and performing experiments that evaluate results in terms 

of correctness and performance. Besides new algorithms and adapters, we work on 

graph reduction. In addition, a simulator of traffic warehouse is being developed. 

We also plan to implement an advanced road traffic simulator that would cooperate 

with routing and traffic control Insigma’s components. The simulator will be 

used for carrying out complex experiments with integrated traffic management 

in a simulated town and assessing whether Insigma improves the overall performance 

of the town’s road system. 

XII. Related work 

In this section, we review a few selected works that concern various issues 

related with a successful routing service. 

The work described in [16] concerns traffic conditions prediction and alternative 

routes. The system architecture is presented and additional discussion about 

read network modeling, congestion data interpolation, and route computation 

is included. Lee’s algorithm [17] has been selected as it is time-aware (maintains 

time lapse as it travels along the graph); thus, predicted traffic intensity is taken 

into account. 

Reference [18] combines optimal routes and traffic intensity data obtained 

from simulation to enable more efficient planning of truck routes (their start time 

and order). The work in [19] discusses the vehicle navigation system supported by 

a framework that enables real-time traffic data collection and modeling. The authors 

of [21] propose a fast and efficient algorithm for computing alternative routes


91 

(which are paramount for traffic load balancing). Finally, reference [20] discusses 

the problem of fairness of alternative routes, from the perspective of drivers. 

We believe that Insigma’s routing service, in order to enable effective traffic 

management and control, will have to combine all the elements mentioned above 

in the cited works. 

XIII. Conclusions 

In the paper, we discuss the architecture of an advanced routing service that 

is one of key components in the Insigma project. The architecture has been designed 

in order to support novel features on one hand, and decompose the complex problem 

into a number of simple, manageable components on the other hand. These 

components may be easily replaced with more sophisticated versions, as the work 

develops. In future, we will be reporting how the development progresses. 

References 

[1] E.W. Dijkstra, “A note on Two Problems in Connexion with Graphs, Numerische 

mathematic”, 1, 269-271, 1959. 

[2] P. Van Mieghem and F.A. Kuipers, “Concepts of Exact Quality of Service Algorithms”, 

IEEE/ACM Transaction on Networking, vol. 12, no. 5, pp. 851-864, October 2004. 

[3] P. Van Mieghem, H. De Neve and F.A. Kuipers, “Hop-by-hop Quality of Service 

Routing”, Computer Networks, vol. 37. no 3-4, pp. 407-423, 2001. 

[4] W. Góralski et al., “On Dimensioning and Routing in the IP QoS System”, in Journal 

of Telecommunications and Information Technology 2011, nr 3, s. 21-28. 

[5] W3C, Geolocation API Specification. W3C Candidate Recommendation, 7 September 

2010. Available: 

[6] http://www.w3.org/TR/geolocation-API/ 

[7] Geolocation: http://html5demos.com/geo 

[8] jQuery Mobile: http://jquerymobile.com/ 

[9] OpenStreetMap: http://www.openstreetmap.org/ 

[10] OpenLayers: http://openlayers.org 

[11] Osmosis: http://wiki.openstreetmap.org/wiki/Osmosis 

[12] Mapnik: http://mapnik.org/ 

[13] Osm2pgsql: http://wiki.openstreetmap.org/wiki/Osm2pgsql 

[14] PostGIS: http://postgis.refractions.net/ 

[15] Google Maps Developer Documentation: https://developers.google.com/maps/ 

documentation/ 

[16] J. Fawcett, P. Robinson, “adaptive Routing for oad Traffic,” in IEEE Computer 

Graphics and Applications, May/June 2000. 

[17] C.Y. Lee, “An Algorithm for Path Connectivity and its Applications,” IRE Trans. on 

Electronic Computers, vol. 10, no. 3, Sept. 1961, pp. 346-365.


[18] O. Franzese, S. Joshi, “Traffic simulation application to plan real-time distribution 

routes”, in Proceedings of the 2002 Winter Simulation Conference. 

[19] S. Ying, Y. Yang, “Study on Vehicle Navigation System with Real-time Traffic 

Information,” 2008 International Conference on Computer Science and Software 

Engineering. 

[20] O. Jahn, R.H. Möhring, A.S. Schulz, N.E. Stier-Moses, “System-Optimal Routing 

of Traffic Flows with User Constraints in Networks with Congestion,” in OPERATIONS 

RESEARCH vol. 53, no. 4, July–August 2005. 

[21] D. Luxen, D. Schieferdecker, “Candidate Sets for Alternative Routes in Road 

Networks,” Experimental Algorithms – 11th International Symposium, SEA 2012, 

Bordeaux, France, June 7-9, 2012.

Modern Low Cost Aircraft Instruments 

Radek Bystricky 1 , Premysl Janu 2 

1 Department of Aerospace Electrical Systems 

2 Department of Radar Technology, Faculty of Military Technology, 

University of Defence, Brno, Czech Republic, 

{radek.bystricky, premysl.janu}@unob.cz 

Abstract: The usage of multifunction displays (MFD) in nowadays aircraft boards is about to increase. 

They are usually able to show a big number of relevant information at once, so their contribution 

cannot be denied. But it is hard to imagine that, in case of emergency (e.g., space disorientation), 

the pilot will browse between pages on the display. In this case, he immediately needs to know basic 

information about speed, altitude, etc. and will therefore rather rely on conventional gauges instruments. 

This paper therefore deals with the design and development of classical and especially cheap 

gauge instrument connected the on-board data bus. 

Keywords: MFD; aircraft instrument; CAN; CANaerospace; microcontroler, Time-triggered 


First we need to ask ourselves what must be an inexpensive aircraft instrument 

able to do, except that it must be accurate, reliable and rugged. It must be able to 

measure the flight parameter with sufficient accuracy at first. It is also advantageous 

if this flight parameter can be transmitted to other devices using some kind 

of a data bus. Finally, it must have sufficiently precise scale with a fine gauge step 

and be able to detect their own faults and report them. 

II. Hardware conception 

Our concept is based on the division of the device into individual components 

that can exist independent to the measured flight parameter. This concept is adopted 

from real instruments build by Czech company MESIT and used for example on 

the aircraft L159 ALCA, see Figure 1. But the concept itself is the only thing what 

ours instruments replicates [1]. The rest differs significantly. 

Basic components are: 

• Power block. 

• Signal processing block.


• Display block. 

• Data storage block. 

• BITE block. 

The first part of the conception is the power supply block [11], consisting 

mainly from the DC/DC converter allowing the device operation in a wide input 

voltage range (6-36 V) with 5 V output. This wide range allows the device to be 

used in many types of aircraft. It is able to provide a voltage spikes filtering and 

even independent voltage source with galvanic isolation for the purpose of the safe 

bus communication. This block is basically same for every instrument. 

Figure 1. Example of a gauge instrument from MESIT company 

Second mentioned part is the signal processing block [11]. For signal processing 

is necessary to divide them to several groups according to way of physical 

principle of quantity sensing (employed sensor) and according to way of its analyzing 

at measuring chain. Signals from sensors are impedance matched and eventually also 

separated. Anti-aliasing filter for suppression of unnecessary spectrum part follows. 

Figure 2. Example of a measurement blocks 

All signals are consequently normalized, thus DC offset is cut off. By amplification 

(attenuation) their magnitude is adapted to useful range of measuring 

converter. Afterwards precision is given by converter bit resolution.


95 

Each processing chain or group of chains represents particular modules which 

are designed like an intelligent sensors or on-board instruments connected to data 

bus. Modules of intelligent sensors are based on 8-bit microcontrollers Atmel AVR. 

More complex instruments, which carry out more complex signal processing like 

radio communication, are based on FPGAs if any. 

The signal processing block is essentially the only block that is different 

from instrument to instrument. The result of the signal acquisition is transmitted 

via CAN into the on-board system and since that moment can be used by other 

instruments. Figure 2 shows some examples of signal processing blocks that we 

recently created [16]. 

Third part of the instruments is the display block. Unlike conventional devices 

that use stepper motors for displaying the flight parameter, our prototype is equipped 

with a servo [2]. The main reason is with any doubt the price. 

Figure 3. Servomotor as a gauge instrument 

Servomechanism is driven by the microcontroller using a PWM (Pulse-width 

modulation). The position of the servomechanism is related to the pulse length, 

as shown the basic principle in Figure 3. The basic operational range of 180 degrees 

can be enlarged by a simple gear mechanism. The precision is theoretically 

limited only by a microcontroller timer/counter bit resolution. The precision for 

16 bit counter is: 

180 16 0.00275 (1) 

2 

This is sufficient precision to the show the flight parameter using a gauge. 

Microcontroller reads the instrument corresponding value e.g. RPM, from CAN 

and convert this information to the required length of the pulse [2]. What is more 

important, the microcontroller can apply different modification to the displayed 

signal e.g. linearization. The advantage is that the original signal still exists on 

the CAN unmodified. The measured flight parameter is displayed also in the form 

of number as a supplement, see Figure 1. The only thing that has to be modified


according to specific instrument is the scale, and of course the program running 

inside the microcontroller. 

The fourth part is the data storage block. It mainly serves to store measured 

flight data parameter into the memory card and thus could serve to two primary 

goals. Since this is in particular a very cheap instrument, we can basically assume 

that it will be primary used on board of ultra-light aircraft where no flight data 

recorder is present [3]. The flight data recorder in case of accident is thus the first 

possibility. The second possibility is to serve as flight documentation. Every piece 

written to the memory contains not only value but also a time stamp of the event. 

It’s easy than to read when some specific event occurred and its value, e.g. crossing 

the maximum of speed limit or G‐force. The memory is divided into two parts. 

One is permanent holding those specific events and the second part which is acting 

as an infinite loop erasing the oldest data, when the maximum capacity is reached. 

This part is still under development and at this moment presented by an SD memory 

card as can be seen in Figure 4. 

Figure 4. SD card storage evaluation board 

The last part is the BITE (Built In Test Equipment) block. This block is basically 

a second instrument integrated in one PCB (Printed circuit board), running at much 

lower speed, which checks out some of the functions of the whole instrument. In case 

that the instrument gives too different results then BITE, the instrument is disconnected 

and an error flag is transmitted into the system, keeping the rest of the system 

untouched by this error. In most cases this block could be the same for more instruments, 

but with different I/O ports connected, as well as the program running inside. 

Since the whole system is network (bus) based the network capability is the essence 

of the whole system 

III. Network capability 

The proposed instrument is integrated into the on-board aircraft electronic 

system, which acquires data from sensors and provides them to the NEC environment 

[6, 16]. The whole system consists of two control modules and individual 

modules providing aircraft and flight parameters.


97 

Data bus CAN [4, 6-9 and 16] for its simplicity, very effective diagnostic tools and 

because of the fact that many microcontrollers have a CAN driver integrated was used 

for mutual communication of individual modules. The bus CAN has specification 

for avionic systems by CANaerospace protocol that operates at the application layer 

of ISO/OSI reference model. The protocol is not already widely used, as is evidenced 

by only small number of projects in the Czech Republic and abroad (Ae270, SATS, 

V220 and V300 aircraft engines, SOFIA [6]), so this area is still under development. 

It is important for avionic systems that individual messages are sent and received 

in precisely defined instants, so that time-triggered method was chosen [7, 9 

and 16]. The basis of the method is a time schedule, which is defined by so called 

Cycle matrix [6, 7]. Complete designed on-board aircraft electronic system consists 

of the following parts. 

The NEC station as needed (asynchronously) sends messages with CAN ID 

selected from high-priority area of the CANaerospace protocol service messages, 

thus makes an interface between aircraft and ground station. There is a message, 

which makes master block to assign the communication schedule. There are also 

messages that tell the master unit to start or stop communication, i.e. reference 

message transmission. It also allows sending other messages of the node service 

protocol, which generally accelerate and make more precise the communication 

of individual modules (e.g. message for system baud rate reconfiguration). 

The MASTER receives important messages that the NEC station transmits 

and adequately reacts on them. It stops communication according previous Cycle 

matrix after the communication schedule assignment command reception, and 

ensures assignment messages transmission that include flight data messages CAN 

ID allocation in the new Cycle matrix. The number of assignment messages corresponds 

to the number of elements in the Cycle matrix. Subsequently it starts to 

periodically transmit reference message for the time synchronization of communication, 

which period determines the value set in the comparative timer register 

of its microcontroller, based on the number of Cycle matrix columns (time slots). 

It stops the synchronization message transmitting after communication end message 

reception. It resumes communication reference message transmission by communication 

start message reception. 

Individual modules fill predefined Cycle matrix with specific messages that 

provide to the system after assignment message reception. The nodules start to 

provide data to the system by synchronization messages reception. The time interval 

during which the module must send the message is defined by so called time slot. 

1 

tS 

nD d 

(2) 

bitrate 

where t S is time slot length, n D is bit number of the message (maximum number 

of stuff bits is supposed, thus bit number of the message is 135), d is time delimiter, 

the message to be send in order.


This time interval is set into the comparative timer register of the microcontroller. 

The message is sent only once in the time-triggered mode, no further 

arbitration is performed. 

Each row of the matrix is begun by synchronization message [6, 7], followed by 

the CAN ID that characterize the various flight parameters. Free frames reserved for 

asynchronous messages of the CANaerospace protocol can be found here. The time 

required for the matrix reconfiguration depends on its dimension, e.g. reconfiguration 

of the matrix with size of 10 x 6, takes 77.76 ms. This value is not critical. 

However, complete on-board aircraft electronic system provides far greater number 

of messages. For imagination, the time required for the Cycle matrix reconfiguration 

with maximum possible number of elements, which enables CANaerospace 

protocol specification [5], it is the matrix of size 256 x 256, is 1 min 25 s. This time, 

when the system does not provide any data, is quite critical and can have fatal consequences 

for flight safety. Maximal system bit rate reduces the value to 10.62 s. This 

time is also still quite critical, and therefore it is necessary to select a compromise 

among the transmission period of synchronous messages, the number of necessary 

broadcast messages and the number of elements in the Cycle matrix. In the case, 

that is impossible to avoid the number of elements of the Cycle matrix approaching 

to the possible maximum according to the CANaerospace specification, it is necessary 

to use some other reconfiguration algorithm of the Cycle matrix [6, 7 and 9]. 

IV. Mathematical analysis 

Certain parameters, which quantitatively express the level of communication 

over the bus is necessary to establish to evaluate the communication behavior on 

the bus. The most important parameters for the mathematical analysis of the bus 

behavior are bus capacity C CANAS and bus utilization U. To obtain these parameters 

is important to come out of the following values. 

The data frame length n D is considered for 11-bit identifier. It is possible to 

work with up to 2 11 messages, which is 2048 with 11-bit identifier. Such number 

of messages is excessively adequate for designed on-board aircraft electronic system. 

Data frame length n D in this case is given by: 

348N 

D 

 

nDround 

478N 

D 

5 

 

(3) 

 

where N D is number of data byte. 

Round function signifies cutting off the decimal part. Division by five in the argument 

of the function is due to the application of stuff bits insertion mechanism. 

Number of stuff bits is not possible or hardly ever to analytically determine. Inserting 

or not inserting of stuff bits depends on a combination of bits in the CAN 

identifier, data length control field, data field and CRC sequence [4, 6], when more 

than five bits of the same level must not follow, so here is the stuff bit inserted.


99 

In the case of CANaerospace protocol, when all 8 bytes of data are transmitted, 

mean length of the data frame 123 bits is taken in a count. The data frame length 

without bit stuffing mechanism application is 111 bits and in case of maximum 

bit stuffing is 135 bits. 

The duration of one bit transmission τ is defined by reciprocal value of bus 

bit rate according to the equation: 

1 

(4) 

bitrate 

The transmission message period is very important parameter for the following 

calculations. In this case it is transmission message period at hundred percent 

of bus utilization, thus when the messages are transmitted in close behind. For 

the transmission message period p U100% is defined equation: 

p 

U100% 

n (5) 

Hundred percent of bus utilization is supposed during the bus capacity calculation 

C CANAS , when the transmission message period is given by n D τ. The bus 

capacity determines the number of messages that is possible to send over the bus 

per second. Then the bus capacity is defined by: 

1 

CCANAS 

(6) 

p 

D 

U100% 

Maximum bus capacity reaches at the minimum data frame length and 

the maximum bit rate. The value of maximum bus capacity is the 8771 messages/s. 

The value of maximum bus capacity depends on the number of inserted complementary 

bits in the process of bit stuffing. The occurrence of these bits is very stochastic. 

Bus utilization by synchronous messages is defined by: 

U 

S 

M 

1 

nS 100 

(7) 

p 

i1 

where U S is bus utilization by synchronous messages, n S is frame length of synchronously 

transmitted message, p S is transmission period of synchronous message 

frames. 

The maximum bus utilization by synchronous messages is reached at the state 

of maximum bit rate 1 Mbit/s and at small transmission message period. 

Bus utilization by asynchronous messages is defined by: 

M 

S 

UAS nAS xAS 

100 

(8) 

i 

where U AS is bus utilization by asynchronous messages, n AS is frame length of asynchronously 

transmitted message, x AS is a number of asynchronous message transmitted 

frames.


The maximum bus utilization by asynchronous messages occurs at the low 

bit rate and at very frequent transmission of asynchronous messages. 

The CANaerospace specification according to Michael Stock [5] recommends 

bus utilization by synchronous messages from 80% to be prepared sufficient bus 

capacity for eventual transmission of CANaerospace asynchronous messages. Great 

bus utilization for asynchronous messages remains at long period of synchronous 

transmitted message and at low bus bit rate. Conversely when the bit rate is maximal 

and very small period of synchronous transmitted message, low bus utilization for 

asynchronous messages remains, so these parameters must be chosen with respect 

of CANaerospace specification recommendations 

V. Conclusion 

This hardware solution can gives us a unique instrument set able to communicate 

thought CAN, able to detect their own faults with the same accuracy as prestigious 

instrument for price of only few hundreds of euro (dollars). Since only one hardware 

block is different at each instrument it is also cheap to maintain it in perfect shape. 

Also the program running inside can be easily modified to fulfill any possible needs. 

Application of the bus CAN with CANaerospace protocol to the avionic systems 

is relatively new area. The bus CAN seem to be suitable for the implementation 

because of its simple way of communication and high quality of diagnostic tools. 

According to the mathematical analysis is evidenced, that the bus enables to provide 

high number of messages, which is important for aircraft electronic systems. 


The work presented in this paper has been supported by the Ministry of Defence 

of the Czech Republic (K206 Department development program “Complex 

aviation electronic system for unmanned aerial systems”). 

References 

[1] J. Cizmar, R. Jalovecky, “Development of a Digital Fuel Quantity Indicating System 

for Aircraft.”, In: Proceeding of the International Conference on Military Technologies 

„ICMT 2007“, Brno: Univerzita obrany, Brno, 2007, ISBN 978-80-7231-238-2. 

[2] R. Bystricky, “Dynamic system mathematical model of UAV helicopter.”, Brno, 

29.03.2010, Disertation thesis, University of Defence, Supervisor prof. Ing. Rudolf 

Jalovecky, CSc (in Czech). 

[3] R. Bystricky, J. Bajer, P. Janu, “Proposal of low cost flight data recorder for ultralight 

aircraft.”, In: Modern Safety Technologies In Transportation, Košice, Slovensko: 

Suprema Ltd., 2011, p. 54-59, ISSN 1338-5232, ISBN 978-80-970772-0-4.

Chapter 1: Concepts and Solutions for Communications and Information Systems 101 

[4] W. Voss, “A Comprehensible Guide to Controller Area Network.”, 2nd, Greenfield, 

Massachusetts, USA: Copperhill Technologies Corporation, 2005-2008, 152 s., ISBN 

978-0976511601. 

[5] M. Stock, “CANaerospace” [online], [cit. 2009-04-05], Available on: . 

[6] P. Janu, “Acquisition and data processing from on-board aircraft systems.”, Brno, 

31.08.2011, Disertation thesis, University of Defence, Supervisor prof. Ing. Rudolf 

Jalovecky, CSc (in Czech). 

[7] P. Janu, R. Bystricky, J. Bajer, “Proposal of a time-triggered avionic electrical 

subsystem using CANaerospace.”, In ICMT\’09: International Conference on Military 

Technologies 2009, 1st edition, Brno: [s.n.], 2009, Electronics Avionic Systems, 

p. 387-393, ISBN 9788072316496. 

[8] P. Janu, J. Parizek, “The canaerospace protocol contribution to the reliability and 

safety of the CAN.”, In: ICMT’11 – International Conference on Military Technologies 

2011, Brno: University of Defence, 2011, p. 657-663, ISBN 978-80-7231-787-5. 

[9] P. Janu, J. Bajer, “Dynamic time-slot assignment method applied on CAN with 

CANaerospace protocol during the aircraft phase of flight transitions.”, In: ICMT ’11 

– International Conference on Military Technologies 2011, Brno: University of Defence, 

2011, p. 619-625, ISBN 978-80-7231-787-5. 

[10] P. Janu, J. Parizek, “CAN Messages Transmission Diagnostic Analysis of Avionic 

System.”, Cybernetic Letters, 2011, no. 9, p. 1-9, ISSN 1802-3525. 

[11] P. Bajer, P. Janu, R. Jalovecky, “Controller Area Network based On-board 

Data Acquisition System on Military Aircraft.”, In: Concepts and Implementations 

for Innovative Military Communications and Information Technologies. Warsaw, 

Polska: Military University of Technology, 2010, p. 589-598, ISBN 978-83-61486-70-1. 

[12] J. Bajer, P. Janu, “Systematic proposal of aircraft electronic system with CANaerospace 

protocol.”, In: Military Communications and Information Systems Conference: MCC 

2009, Prague, Czech Republic: University of Defence, 2009, ISBN 978-80-7231-678-6. 

[13] J. Bajer, R. Bystricky, P. Janu, “Proposal of a time-triggered avionic electrical 

subsystem using CANaerospace.”, In: ICMT’09 International Conference on Military 

Technologies 2009, Brno, Czech Republic: University of Defence, 2009, ISBN 978-80- 

-7231-649-6. 

[14] D. Paret, “Multiplexed networks for embedded systems – CAN, LIN, FlexRay, Safeby- 

-Wire... Wiley.”, 2007, p. 418, ISBN 978-0-470-03416-3 (HB). 

[15] N. Navet, F. Simonot-lion, “Automotive Embedded Systems Handbook 

(Industrial Information Technology).”, [online], [cit. 2009-04-05], Available on: 

. 

[16] J. Bajer, P. Janu, R. Jalovecky, “Controller Area Network based On-board Data 

Acquisition System on Military Aircraft.” In Concepts and Implementation for 

Innovative Military Communications and Information Technologies. Warsaw, Poland: 

Military University of Technology, 2010, p. 589-598. ISBN 978-83-61486-70-1. 

[17] “ISO 11898-4:2004.” [online], [cit. 2009-06-30], Available on: .

Chapter 2 

Communications 

and Information Technology 

for Trusted Information Sharing

SOA in the CoNSIS Coalition Environment: 

Extending the WS-I Basic Profile for Using SOA 

in a Tactical Environment 

Hartmut Seifert 1 , Markus Franke 1 , Anne Diefenbach 2 , Peter Sevenich 2 

1 Dept. Networks and Architectures, Industrieanlagenbetriebsgesellschaft mbH, 

Ottobrunn, Germany, seifert@iabg.de 

2 Communication Systems Group, Fraunhofer FKIE, Wachtberg, Germany, 

anne.diefenbach@fkie.fraunhofer.de 

Abstract: This article describes the elements necessary to allow SOA based CCIS systems to operate 

in a mobile tactical environment. All elements which are mandatory to allow a SOA based implementation 

to react to limited bandwidth, jammed and temporarily unavailable network connections and 

to span a common information domain across various coalition partners are listed in comparison 

to the WS-I Basic Profile. 

Keywords: autarchy, non-hierarchical, fully distributed, SOAP-based security mechanisms, schema- 

-based compression, NNEC 


Future Command, Control and Intelligence Systems (CCIS) will not be developed 

from scratch anymore. Military operators are interested in specific military 

functionalities, and they do not care about how these functions communicate and 

cooperate with each other as long as a defined service level agreement is fulfilled. 

One approach to realize such a system is to base it upon a service oriented 

architecture (SOA), where military applications will use commonly available core 

services (like basic messaging or repository services) to provide their capabilities 

to human operators. 

This decomposition is originally derived from the NATO Network Enabled 

Capability (NNEC) feasibility study [1], where various steps are described to come 

from the current position of stove-pipe systems to a coalition wide shared services 

approach. 

The SOA paradigms, and the tools and frameworks developed to help implement 

them, are intended for use in fixed, broadband company networks. Web 

services, the technology commonly used to realize a SOA (and the one suggested


by NNEC), along with their numerous advantages also come with some disadvantages, 

such as a very large overhead. Military networks, however, often do 

not meet the conditions expected in civil company networks. Military networks 

in the tactical domain, especially mobile networks, suffer from low bandwidth, 

large delays, frequent disruption and the threat of jamming. Therefore, steps need 

to be taken to mitigate these disadvantages and ensure adequate performance. This 

paper takes the Web Services Interoperability (WS-I) Basic Profile [2], developed by 

an industry consortium to ensure interoperability between web services, and suggests 

several additions to be prescribed to web services in a military environment. 

The resulting architecture is described in principle and verified within a national 

implementation, the Reference Environment for Services “Referenzumgebung 

Dienste” (RuDi). 

RuDi was the German SOA framework used in the international project 

CoNSIS (Coalition Networks for Secure Information Sharing). Work in CoNSIS, 

performed in five distinct tasks, aimed to develop a comprehensive, federated 

environment comprising heterogeneous networks from different nations in which 

to securely share information. This article is based on work carried out in Task 2, 

the Information Services task, concerned with connecting SOA frameworks from 

different nations – namely Germany and Norway. 

II. Limitations for SOA in mobile systems 

A. Mobile Node Autarchy 

In battlefield scenarios, such as a convoy operation as assumed in the CoNSIS 

scenario, mobile units may become cut off from communication with an upper 

command level (e.g. HQ). In this case, the units still need to be able to complete 

the operation they were sent out on – which means that any necessary information 

or supporting routine must be available locally – in our scenario, within a convoy. 

The SOA framework must be set up in such a way as to be able to provide the required 

services to the users (consumers) with the best quality of service achievable under 

current conditions. In the most extreme case, this means that all critical services 

must be completely available within each node (e.g. vehicle within the convoy), 

as stipulated in [3]. 

B. Bandwidth limitations 

The communications within a mobile environment is the most limiting factor 

for SOA: Military communications are either radio based (traditional or ad-hoc 

radio networks) or supported by tactical satellite communications. In both cases, 

the available bandwidth is significantly lower than in backbone systems (from a couple 

of kilobits per second up to a lower megabits per second rate, which is shared

Chapter 2: Communications and Information Technology for Trusted... 

107 

between a number of nodes). In comparison to several hundred megabits per second 

up to a few gigabits per second for stationary systems, this is a severe limitation. 

To cope with these limitations, several optimizations are necessary within 

the WS-I Basic Profile: 

• Services should, where possible, be executed on local nodes. A remote invocation 

of services (e.g. within a portal) consumes too much bandwidth. 

• The main information exchange between military users is message oriented. 

For this purpose, a standard SOA service, a notification broker, is used to 

provide one or more users (consumers) with the same kind of information. 

To save bandwidth, the notification broker has to use the broadcast capability 

of radio networks to distribute the same information to a number of consumers 

in a multicast mode (necessary multicast extension to the notification broker). 

To enhance the performance further, it is recommended to distribute these 

multicast messages in simplex mode (without acknowledgement transfers 

from the recipients). This avoids unnecessary send/receive mode changes 

in the involved radio systems. 

• XML coding of messages within a SOA environment is not bandwidth efficient. 

To reduce the network load, message compression is required. To allow 

a maximum compression, the usage of schema-aware algorithms is highly 

recommended. Efficient XML Interchange (EXI) [4] is the W3C recommendation, 

and the more experimental mechanism XENIA [5] achieves compression 

results of about 97% of the original message size. 

• In a highly dynamic environment, service availability will change heavily over 

time. To provide users with the most recent service availability under current 

restrictions, service discovery mechanisms need to be able to cope with these 

frequent changes. CoNSIS uses WS-Discovery [6] with a few extensions, 

as described more fully in [7]. RuDi uses this protocol proactively to report 

periodically about the service availability in different nodes. However, as this 

service generates a significant load within the radio network, administrators 

have to carefully decide how to set the period of retransmission of WS- 

Discovery messages. 

C. Secure SOA in a coalition environment 

Obviously, a military network has to be secured to protect the confidentiality, 

integrity and authenticity of the data. Here too, the WS-I offers a profile to specify 

how the different web service security standards can be made to work together: 

the Basic Security Profile [8]. However, a military environment places more strident 

requirements on security than a civil one, and moreover the security measures 

usually need to be formally accredited. So web service security can only serve 

as an additional safeguard, superimposed on traditional, accredited measures. 

But SOA, with its highly distributed architecture, also introduces new challenges.


Within a single, national implementation of a SOA environment a hierarchical 

model with well-defined roles and access rules may work. In a coalition environment, 

the various information domains may overlap several technical domains (here 

used as a synonym for national domains). To operate within such an environment, 

the following assumptions are made: 

• The basic protection of information is being done at network level. Modern 

approaches like HAIPE 3.x or NINE 2.x are used to encrypt IP packets 

at the network layer (hopefully end-to-end, realistically within a single 

technical domain). 

• To protect messages individually, all information types and services are 

encapsulated within a SOAP message and protected individually on their 

route between the involved communication partners by their individual 

certificates. This allows a specific protection and encryption of SOAP messages, 

based on the individual conditions of the participating roles. In addition, 

these SOAP messages are enhanced by XML labels to allow label 

switching at any domain boundary between participating partners. This 

way, differently classified information domains can be interconnected. To 

support the exchange of protected information across domain boundaries, 

cross domain certification is required. 

III. Principles of RuDi realisation 

To cover the previous limitations, the German SOA environment in CoNSIS, 

RuDi, was specified and realized in a specific way. The design principles are introduced 

in this section. 

A. Principles for service access 

To get sufficient information about available services in a mobile node, each 

user (consumer) has to contact his local service registry. This registry informs 

the user under which conditions (including the bandwidth limitations to access 

a remote service) a service can be used. 

To generate and maintain the information on different radio links, methods like 

PPPoE [9] for the calculation on physical link conditions and multi-topology routing 

(MTR) [10] to manage end-to-end conditions within the radio network are used. 

Figure 1 shows that the principles of cross-domain service invocation as realized 

in CoNSIS are the same as with local service invocation. To invoke a service, 

a consumer first contacts their local service registry (part of the local SOA infrastructure) 

to find an appropriate provider. The registry lists all service providers 

available to consumers in their domain, no matter whether those providers are 

located in the same domain or different ones. To achieve this, synchronization 

between infrastructures across domains is mandatory. This can be realized either


109 

by a peer-to-peer synchronization (SyncD, for details see STANAG 5524 ed. E) or, 

more applicable for tactical domains, using WS-Discovery [6]. 

Figure 1. Service use across technical domains 

The above service registry is a standard UDDI v.3 with a schema extension for 

network conditions (add-on, optional, therefore compatible with standard UDDI 

as specified in the WS-I Basic Profile). 

B. Overcoming bandwidth limitations 

The handling of multicast information in an (ad-hoc) radio network is not 

simple. To avoid a larger group management behavior, within tactical radio networks 

Simple Multicast Forwarding (SMF) [11] is used. 

As various radio networks may be interconnected, it is necessary to provide 

a routing strategy which allows the integration of various link capabilities 

within a heterogeneous network overlay. Here the MTR approach [10] is used. 

It allows the end-to-end definition of a sequence of paths for a specific capability 

(e.g. for a minimum bandwidth between end nodes). The propagation of local link 

capabilities is here generated and provided by PPPoE [9]. If any radio systems do 

not support PPPoE (which is currently the case with most of the military radios 

in NATO), a PPPoE proxy or simple manual configuration may be used. 

Some core services were modified to be more bandwidth efficient. The 

WS-Notification [12] service for example, in which a broker distributes topic-sorted 

notifications published by one party to multiple subscribed consumers, now uses 

multicast to send out notifications if more than one consumer is subscribed to 

a topic. The broker will also no longer expect acknowledgements, nor will consumers 

send any. Apart from saving bandwidth, this also means that radios do not have 

to switch between sending and receiving mode as frequently.


To learn about published or available services from partners, WS-Discovery [6] 

is used. Based on the local policy, each domain will announce the services which are 

available for partners. WS-Discovery also uses multicast. When used in pro-active 

mode, each active WS-Discovery provider distributes available services periodically 

on a specific multicast address. This can induce a very heavy load indeed for radio 

networks, depending on the number of available services to be distributed and the period 

for re-transmission. Practical experience in the CoNSIS experiment at WTD 81 

in Greding in June 2012 has shown that the period, at least for land based systems, 

should not be in a range of a few seconds, but between 30 seconds and 1 minute [13]. 

Last but not least, XML, on which web services are based, is very verbose. 

In bandwidth constrained environments, exchanging larger XML messages will 

take a long time. This is a fundamental problem when using radios, independent 

of their type. 

The obvious solution is to use compression. As mentioned above in section 

II.B, the most efficient ones are those which are able to interpret the specific 

coding schema of the source itself. Based on this schema information, the original 

source can be compressed in a range of about 97% which makes an XML input 

more transferable in narrowband radio networks. In the case of XML structures, 

the underlying schema information (which is by definition identical between source 

and sink) can be retrieved both by the sender and the receiver from one common or 

various distributed repositories within the network. The only requirement in a coalition 

environment is that the same schema files are used on all communication 

sites. This is an aspect of mission pre-planning. 

The remaining question, then, is which compression algorithm to use. In CoN- 

SIS, RuDi implemented both GZIP and XENIA [5], as the most efficient algorithm. 

The Norwegian framework supported GZIP and EXI [4], the standard-based 

choice. The compromise then was to use GZIP in cross-nation communication, 

but of course this solution is not desirable. A recommendation of which algorithm 

to use is to be worked out. 

Please note that if using WS-Security [14] in combination with compression, 

the XML body of the relevant SOAP message must be compressed prior to their 

encryption. Otherwise compression is no longer possible. 

The last aspect in the area of radio networks is the change in end-to-end transport 

services: As the transmission time and link availability may vary tremendously 

within interconnected radio networks, CoNSIS has mainly given up the concept 

of using TCP as the principal transport protocol. Instead, CoNSIS is using SOAP 

directly over UDP. The original specification [15] allows only the transfer of one 

UDP packet, which means that the SOAP message must fit completely into one UDP 

frame. This is not the case in every military network, with the consequence that 

the UDP specification has to be enhanced to allow segmentation and re-assembly 

as well as the recovery of lost or erroneous UDP frames. RuDi achieved this by using 

a wireless session protocol [16]. This approach is called the reliable UDP protocol [17].


111 

C. Security considerations in a tactical environment 

Within a single, national implementation of a SOA environment a hierarchical 

model with well-defined roles and access rules may work. In a coalition environment, 

the various information domains may overlap various technical domains (which 

is used as a synonym for national domains). To operate within such an environment, 

the following assumptions are made: 

Usage of SOAP 

SOAP (Simple Object Access Protocol) is the basic element of web services. 

SOAP is a W3C protocol standard. It enables standardized communication between 

distributed applications and objects, particularly in the SOA/ESB environment. 

Web services use SOAP for information exchange purposes and HTTP as a medium 

of transport. In their basic form, both SOAP as communication protocol and 

HTTP as transport protocol do not support any security requirements. Instead, 

data is transmitted in plain text. HTTP is, therefore, usually employed via SSL 3.0 

and/or TSL 1.0 (HTTPS) to ensure the secure exchange of SOAP messages. 

In RuDi an additional “object protection” transmitted together with the original 

SOAP message is being implemented for information objects transmitted via SOAP. 

The OASIS standard WS-Security has established itself as the primary technology 

in this context. WS-Security defines how to use existing standards such as XML 

Encryption, XML Signature and X.509 certificates together. WS-Security is an essential 

enhancement of the SOAP standard. It is applied to fulfill the requirements 

with regard to message integrity, confidentiality, authenticity, and the authenticity 

and authority of the entities involved. It makes use of authentication and authorization 

based on SAML (Security Assertion Markup Language). 

The security architecture is probably the most problematic area for interoperability, 

as not only the used protocols are of interest, but the way how the security 

is handled on the sending and receiving side may differ. First results in CWIX 2012 

have shown that this area needs a deeper agreement between partners. 

Figure 2. IT security services of the SOA (ESB) infrastructure


The basic IT Security Architecture is based upon the RuDi Outline Concept 

Chapter 6.5.2 and Chapter 6.9.1 [18]. 

In the BI-SC AIS/NNEC SOA Implementation Guidance [19] NATO document, 

the layers depicted in Figure 3 are classified as IT security technology that 

RuDi is also based upon. 

Figure 3. Example of a layer-based security architecture 

The IT security architecture of the Reference Environment for Services is based 

on two components: 

• Elementary / basic protection (basic security of the classified Bundeswehr 

LAN on network level) 

Elementary protection: the Virtual Private Network (VPN) technology 

protects the transmitted information from undesired access by setting up 

a “tunnel” protected by powerful cryptographic mechanisms that is going 

through insecure networks. 

Basic protection: The encryption by means of HAIPE, NINE or SINA with 

its IPSec internet protocol is based on the network level. 

• Object protection (security on information level) 

Object protection is used to secure objects – information objects – by way 

of authentication, encryption, integrity securing and labeling (signature). 

Generally, the SOA framework is an addition to the existing elementary / 

basic protection, which it uses. The elementary / basic protection is not described 

and analyzed in any more detail in this document. 

RuDi implements object protection on the information level (application and 

web services) in the IT security architecture. 

Certificate / Key structure in RuDi 

Put in technical terms, an X.509 certificate is a data construct that includes a user’s 

public key, their personal data and a digital signature of the relevant certificate authority 

(CA). RuDi security is based upon certificates in accordance with the X.509 v3 

standard. Using a root certificate, every user is able to verify whether the information 

signed by means of these certificates and the following certificate chain is authentic.


113 

An OpenDS is used as directory for certificates. It is based on the ACP 133 [20] 

format (ed. C or D) in order to be smoothly interoperable in the NATO context. 

Figure 4 shows an example of the CA structure (grayed out boxes) and an extract 

of the respective (Sub) CA certificate store. 

In the example Mission RootCA Straussberg forms the highest-level Root CA 

(layer 1). The SubCAs for operations (missions, layer 2) that may be located on a stationary 

IT system in the home country are derived from this Root CA. 

Figure 4. CA structure and extract of certificate store


In the example the SubCA mission-A is derived from the central SubCAmission-A 

and, therefore, inherits its trust relationships. This means that the central 

SubCA-mission-A has a trust relationship with the central SubCA-mission-B 

in the example above. 

Further deployable and autonomous IT systems may exist in the theater of operations. 

These systems derived from the central SubCA-mission contain a separate 

SubCA. These SubCAs form the deployable SubCA mission of layer 4. 

Depending on the requirements of the theater of operations, mobile and 

autonomous IT systems (SubSubCAs) are distributed from the deployable SubCA 

mission and, if applicable, also from the central SubCA-mission. These IT systems 

(may) contain separate limited mobile SubCAs (layer 5). 

The establishment of trust relationships may be required independent of the CA 

layer. The example in Figure 4 illustrates the establishment of a trust relationship 

to a Greek SubCA in the mobile SubCA operation-1b. 

CA* and/or SubCA* are introduced due to the fact that technical domains are 

autonomous but not every technical domain of layer 5 automatically needs to have 

its own CA* or SubCA*. Like a CA or SubCA, the CA* and/or SubCA* receives 

a share of information from its respective higher-level CA. This CA* or SubCA* 

does, however, not form a CA or SubCA in organizational terms, but it remains 

assigned to its issuing CA or SubCA. 

Synchronizations used to compare changes in the trust relationship and 

in the revocation list are required due to the CA structure and the direct trust 

relationship. Figure 5 illustrates the synchronization relationships resulting from 

the CA structure and the direct trust relationships in the example in Figure 4. 

Figure 5. CA structure & trust synchronization relationships 

Details of the procedures to create and maintain the various certificates in RuDi 

are described in [18], chapter 3.


115 

SOA runtime security 

The SOA Runtime Security is concerned with all steps and capabilities of IT 

security during service use and comprises: 

• Authentication (checking the identity – identification); 

• Authorization (check of authorization – access authorization); 

• Encryption (digital encryption); 

• Signature (electronic signature/ identification). 

The definition of “addressing and identification” forms the basis of the SOA 

Runtime Security. 

For all considerations concerning IT security it has to be noted that the IT security 

mechanism is regarded across technical domains (see Figure 6). It must be ensured 

that the mechanism is the same, both domain-internally and externally, and that 

simplifications working only domain-internally are not being established too quickly. 

Figure 6. Federation and trust configuration 

This means that the transmitter and receiver instance may be located in different 

technical domains, each with its own SOA (ESB) infrastructure. 

IV. Conclusion 

While web services have come a long way in ensuring interoperability, the profiles 

written for use in civil systems are insufficient for use in tactical military 

networks. We have in this article introduced the areas which have been identified 

in CoNSIS as the areas in which further specifications are necessary. Solutions for 

these areas have been developed in the German national project Reference Environment 

for Services RuDi and are being verified in various field tests including


CoNSIS. Following the full analysis of the final CoNSIS field experimentation of June 

2012, if the proposed elements are proven mature they may be included in a profile 

for SOA in tactical networks to be recommended to NATO for standardization, to 

be included e.g. in STANAG 5524 (NISP) [21]. 

References 

[1] T. Buckman, “NATO network enabled capability feasibility study”, v2.0, NC3A, 

October 2005. 

[2] Web Services Interoperability Organisation, WS-I Basic Profile version 1.1, ISO/IEC 

29361:2008. 

[3] A. Diefenbach, M. Gerharz, S. Hunke, T. Lüke, and J. Tölle, Abschlussbericht 

SOA-Keimzelle Analyse Referenzarchitektur (SKAR), January 2010. 

[4] W3C, Efficient XML Interchange (EXI) Format 1.0, http://www.w3.org/TR/2011/ 

REC-exi-20110310/, March 2011. 

[5] Ch. Werner, “Xenia: Die smarte XML-Kompression aus Lübeck”, FOCUS MUL, 24. 

Jahrgang Heft 3, September 2007. 

[6] OASIS, Web Services Dynamic Discovery (WS-Discovery) version 1.1, http://docs. 

oasis-open.org/ws-dd/discovery/1.1/os/wsdd-discovery-1.1-spec-os.docx, July 2009. 

[7] T. Hafsøe Bloebaum and K. Lund, ”CoNSIS: Demonstration of SOA interoperability 

in heterogeneous tactical networks”, MCC 2012, Gdansk, Poland, in press. 

[8] Web Services Interoperability Organisation, WS-I Basic Security Profile 1.1, 

January 2010. 

[9] B. Berry, “PPP over Ethernet (PPPoE) extensions for credit flow and link metrics”, 

IETF RFC 5578, February 2010. 

[10] P. Psenak, “Multi-topology (MT) routing in OSPF”, IETF RFC 4915, June 2007. 

[11] J. Macker, “Simplified multicast forwarding”, IETF draft-ietf-manet-smf-14, March 

2012. 

[12] OASIS, Web Services Notification, consisting of WS-BaseNotification 1.3, 

WS-BrokeredNotification 1.3 and WS-Topics 1.3, October 2006. 

[13] CoNSIS-SC, CoNSIS final report, October 2012, unpublished. 

[14] OASIS, Web Services Security 1.1, February 2006. 

[15] xmlsoap.org, SOAP over UDP, September 2004. 

[16] Wireless Application Protocol Forum, Wireless Session Protocol specification, WAP- 

230-WSP, July 2001. 

[17] CoNSIS-SC, “Reliable UDP”, CoNSIS-DEU-Task1-DU-002.doc, November 2010. 

[18] M. Franke, H. Seifert, “IT security architecture”, IT-AmtBw, Project RuDi, 

E/IB1S/9A031/6F125, January 2012. 

[19] NATO, “BI-SC AIS/NNEC SOA implementation guidance”, final draft 1.0, December 

2009. 

[20] CCEB, Common Directory Services and Procedures, ACP 133(D), July 2009. 

[21] NATO, NATO Interoperability Standards and Profiles, ADatP-34(F), December 2011.

CoNSIS: Demonstration of SOA Interoperability 

in Heterogeneous Tactical Networks 

Trude H. Bloebaum, Ketil Lund 

Norwegian Defence Research Establishment (FFI), Kjeller, Norway, 

{trude-hafsoe.bloebaum, ketil.lund}@ffi.no 

Abstract: The Coalition Network for Secure Information Sharing (CoNSIS) conducted a large scale 

experiment in Germany in June 2012. During this experiment, multiple aspects of interoperability 

in the tactical domain were tested in practice. This paper presents the challenges faced by Task 2, 

which focuses on service orientation, and the use of Web services technology as a means to achieve 

interoperability between nations. Furthermore, it describes how these challenges were addressed 

by the different information infrastructures involved. We also present our experiences with several 

central Web service standards, and describe some lessons learned when it comes to utilizing these 

standards in tactical networks. 

Keywords: SOA; Web services;service discovery; publish/subscribe 


The Service-Oriented Architecture (SOA) concept, most commonly implemented 

as Web services, is seen as a key enabler for meeting the technical 

interoperability requirements needed to achieve the NATO Network Enabled 

Capabilities (NNEC) vision. Within NATO, Web services technology has been 

the focus of the Core Enterprise Services (CES) working group, which has defined 

a number of common infrastructure services as core enterprise services. 

Having a common understanding of how these services are to be implemented 

and used is critical when attempting to achieve interoperability across national 

and systems boundaries. An important part of the work towards achieving this 

common understanding is to utilize these services in experimentation, in which 

the candidate technologies are tested under conditions similar to those found 

in an operational network. 

The Coalition Network for Secure Information Sharing (CoNSIS) is a multinational 

group consisting of members from Germany, France, USA, and Norway, 

with participants from both research institutions and industry. The objectives of this 

group are to develop, implement, test, and demonstrate technologies and methods 

that will facilitate the partners’ abilities to share information and services securely


in ad-hoc coalitions, and between military and civil communication systems, 

within the communications constraints of mobile tactical forces. 

The group has focused on practical application of information infrastructure 

technologies in a network-of-networks, consisting of a variety of low capability 

network technologies. The work done within the CoNSIS group has been divided 

into a number of tasks, each focusing on a different aspect of interoperability issues. 

This paper focuses on the work done by Task 2, which, together with [1], covers 

the domain of SOA and its application in limited capacity networks. During June 

2012 CoNSIS conducted a large-scale experiment in Greding, Germany, in which all 

the different aspects of technical interoperability were tested; integrating the work 

of all the task groups of CoNSIS. 


For Task 2, the goal of the CoNSIS experimentation was to show that by using 

the Web service standards specified by the NNEC CES as interoperability enablers, 

independent implementations are able to interoperate with only the service 

specifications as a common reference. The reasoning behind focusing on standards 

as a means of achieving interoperability was that it enables us to evaluate not only 

the implementations used, but also the standards themselves. In other words, 

we can assess how suitable the standards specified in the NNEC CES are for use 

in tactical networks. 

A. SOA challenges 

Assessing Web services (and other SOA implementation approaches) through 

the use of standards based experimentation is not new; multiple other experiments 

covering several topics of Web service interoperability have been performed previously. 

One of the most recent of these was the “Making Services Interoperable” 

– experiment conducted by the NATO RTO IST-090 working group last year [2]. 

In this experiment, three different SOA-based information infrastructures were connected 

together and interoperability was achieved. This experiment does however 

differ from the CoNSIS experiment in multiple ways: 

• The CoNSIS experiment network was considerably more complex 

than the network used duing the IST-090 experiments. This added complexity 

meant larger fluctuations in the network conditions experienced 

by the Web service frameworks being used. 

• The IST-090 experiment focused on service invocation, while the CoNSIS 

experiment covers both service discovery and service invocation. 

• IST-090 managed to achieve interoperability between both Web service and 

Data Distribution Service (DDS) implementations of SOA, but this required 

the use of specialized gateways which only supported some service types.


119 

The CoNSIS experiments are limited to Web service based implementations 

only, which allows for a more generic approach to service interoperability. 

• The CoNSIS experiment was performed using an IPv6 network, while 

the IST-090 experiment was done on IPv4. This difference meant that 

there were additional challenges imposed on the CoNSIS experimentation 

as the support for IPv6 in pre-existing software and software development 

tools is limited. 

There were primarily two NNEC core services that we wanted to test with 

respect to interoperability, namely service discovery and publish/subscribe. In addition, 

we also saw the need for focusing on topics, which is a method for classifying 

information, and as such constitutes the intersection between service discovery and 

publish/subscribe. These three areas are further described in the following sections. 

B. Experimentation networks 

The CoNSIS land mobile part of the network consists of contributions from 

Germany and Norway. In addition to four German and four Norwegian mobile 

nodes located on military vehicles, there was also an NGO vehicle. However, this 

NGO vehicle was not used in the SOA experiments and will therefore not be further 

described in this paper. Fig. 1 shows the parts of the CoNSIS network that 

was being using during the SOA experiments. 

Figure 1. CoNSIS network, initial configuration 

Two different radio types were used. This is partly because Germany and 

Norway do not have the same radio systems, but also because different wireless


technologies, having different properties with regards to e.g., range, are needed. 

Together the two radio links form a heterogeneous network. Within the German part 

of the convoy the IABG HiMoNN radio was used, whereas the Kongsberg WM600 

radio was used within the Norwegian part of the convoy. To interconnect the two 

parts one German radio was placed on a Norwegian vehicle and one Norwegian radio 

was placed on a German vehicle. 

In addition to the vehicle nodes, one mobile network node was physically colocated 

with the deployable HQ network. This node connected the mobile network 

to the rest of the CoNSIS network, and was connected to mobile nodes terrestrial 

radio links as indicated. 

The eight vehicles formed two convoys, one German and one Norwegian. 

In the scenario, these two convoys were separated from the start, but at a later 

point in time, they merged into one large convoy. In addition, the network topology 

changed during the experiments, something that affected delay and available bandwidth. 

One such alternative topology is shown in Fig. 2. 

Figure 2. CONSIS network, alternative network topology 

Germany and Norway each provided implementations of selected parts 

of the NNEC CES, using Web services technology as their foundation. The two 

implementations were technologically quite different, as the German implementation, 

Referenzumgebung Dienste (RuDi) [1], is based on an Enterprise Service Bus 

(ESB), while the Norwegian solution consisted of multiple stand-alone components 

implementing the set of core services. 

In the experiment, the core services were used to provide a infrastructure for 

functional services providing three types of information:


121 

• Vehicle positions: Each vehicle reported its position (through a GPS-based 

positioning service) to the lead vehicle of its convoy. The lead vehicle then 

aggregated the positions of all convoy vehicles into a convoy Common 

Operational Picture (COP), which in turn was delivered to the HQ, where 

the two convoy COPs were aggregated into a full COP. This full COP 

was then distributed back to the vehicles. 

• Operational messages: This is a service for sending messages to other users. 

The messages can be of the types Alert, Warning, Information, and Command. 

File attachments are also possible. 

• Chat: This service provides ordinary chat functionality, based on chat rooms. 

All information types are distributed using WS-Notification, which is the Web 

service standard for Publish/Subscribe that is specified by the NNEC CES. Furthermore, 

all information types were distributed among all the vehicles as well 

as the HQ, as illustrated in Fig. 3. 

Figure 3. Information types and flows 

III. Service Discovery 

Service Discovery is the process of finding the services that are available 

in the network. NNEC CES has recommended the use of the registry based 

solution Universal Description, Discovery and Integration (UDDI) for this core 

service. However, when operating in a wireless network environment where node 

mobility and shifting network conditions can cause network partitions and loss 

of network connections, it is vital to use a service discovery mechanism that does not 

rely on the availability of any given node. In other words, we need a fully distributed 

service discovery mechanism [3]. The only standardized Web service discovery 

protocol that currently fulfills this requirement by operating in a distributed mode is 

WS-Discovery [4], which was utilized during the SOA experiments. 

WS-Discovery is designed for use in one of two modes: managed and ad hoc. 

In managed mode all nodes communicate through a discovery proxy, an entity


which performs the service discovery function of behalf of all the other nodes, and 

which communicates with the other nodes using unicast messages. This mechanism 

can be used to achieve interoperability between registry based service discovery 

mechanisms and WS-Discovery. 

In ad hoc mode, on the other hand, communication is fully distributed. 

Requests for service information are sent using multicast to a known address, 

and each node is responsible for answering requests from others about its own 

services. The ad hoc mode is intended to be used for local communication only, 

and the standard recommends limiting the scope of multicast messages by setting 

the time-to-live (TTL) field of the IPv4 header to 1, or by using a link-local multicast 

address for IPv6. 

The CoNSIS experiment consists of a number of ad hoc networks connected 

to each other using Multi-Topology Routers (MTRs) [5], forming a IPv6 based 

network-of-networks. The dynamic character of these networks implies that one 

cannot rely on a managed mode discovery proxy to remain available, meaning that 

the distributed ad hoc mode should be used. However, since this mode is limited to 

link local communication it will not provide the multi-network service discovery 

capability required in the CoNSIS experiments. In order to work around this issue, 

we decided to go against the recommendations in the standard, and allow the multicast 

discovery messages to travel across network boundaries by using a site-local 

IPv6 address, and increasing the Hop Limit in the IPv6 header. This solution works 

within a controlled network environment such as the one used during the CoNSIS 

experiments, but it is less than ideal for use in larger scale networks. That is because 

increasing the scope of the multicast messages might cause the messages to travel 

further than intended, and thus cause increased network load in networks where 

the messages are not needed. 

WS-Dicovery is a hybrid discovery protocol, meaning that it has both a proactive 

and a reactive element (see [3] for further details on the different types of discovery 

protocols). The proactive element consists of the HELLO and BYE messages nodes 

send out when they first make a new service available, and when they remove a service, 

respectively. Other nodes then store the information gathered from these proactive 

messages, allowing them to perform service discovery without having to actively query 

for information. This proactive mode works well under stable network conditions, 

since the likelihood of these messages reaching all other nodes is high. The CoNSIS 

network is however not stable, which means that many of these messages will be 

lost, rendering the proactive element of WS-Discovery unable to provide service 

information to all nodes. This means that one has to rely on the reactive element 

of WS-Discovery, the PROBE and PROBE MATCH messages. 

In this reactive mode a node that requires the use of a service will ask for 

services matching its needs by sending a PROBE message. This message is sent using 

multicast, and with the extended scope of multicast messages described above, 

the probe will reach all other nodes that it currently has a network connection to.


123 

Nodes offering a matching service send a unicast PROBE MATCH message back 

to the probe sender. Note that this reactive mode should be used sparingly in low 

capacity networks as it generates some network traffic. 

The flow of WS-Discovery multicast messages is illustrated in Fig. 4. Since 

we allowed the packets to flow across routers, a request sent by any one node 

in the network is received by all other nodes. If the message sent was a probe for 

available services, then all nodes that did offer a service matching the request would 

reply with a unicast message to the sender. 

Figure 4. WS-Discovery information flow 

On the German side, WS-Discovery was integrated into the RuDi system, and 

connected to the internal service registry. This meant that any announcement made 

on WS-Discovery would be added to the service registry, which in turn meant that 

the announced service could be invoked from within RuDi. This was done by allowing 

RuDi to periodically probe for information, but at a low enough frequency 

so as not to overload the network. On the Norwegian side, WS-Discovery was used 

as the only discovery mechanism. A self-contained WS-Discovery application 

was therefore used for announcing and searching for services, which made it possible 

to limit the amount of probes sent into the network by only probing when 

a new service was needed. 

As mentioned above, allowing the multicast packets to traverse routers is not 

an ideal solution. An alternative is to combine the managed and ad hoc modes 

in one deployment. When a WS-Discovery proxy announces its presence, all other 

nodes are asked to enter managed mode, relying on the proxy for service discovery. 

However, the WS-Discovery specification does not require the nodes to change to 

managed mode, and by allowing the majority of nodes to remain in ad hoc mode 

and at the same time keep a link local message scope, one can secure local service 

discovery without the risk of generating unneeded network traffic in other networks.


Combined with discovery proxies that function as relays between the networks, 

cross-network discovery can be achieved as well. 

Note that, even though the WS-Discovery specification does allow nodes to 

choose not to enter managed mode when receiving a message telling it to do so, 

it does not clearly state what the expected behavior of nodes is once the network 

consists of nodes in both modes simultaneously. This combination of modes 

is desirable when working with multiple interconnected mobile networks, and 

therefore a profile of how to use the WS-Discovery standard in this context should 

be developed by NATO for interoperability between nations. 

IV. Publish/Subscribe 

In the CoNSIS experiment the majority of the information exchanged was distributed 

according to the publish/subscribe paradigm. This means that instead 

of a node having to repeatedly check if there is new information, the node simply 

send a subscription request to the information provider, asking to be notified whenever 

new information is available (see Fig. 5). Using Publish/Subscribe instead 

of the Request/Response paradigm has several advantages: The network traffic 

is reduced, since the client doesn’t have to send periodic requests; the server load 

is reduced, since there are fewer requests to process; and the client will potentially 

receive new data sooner, although this is dependent on the request frequency 

in a Request/Response setting (which in turn will affect network and server load). 

Figure 5. Request/Response versus Publish/Subscribe 

WS-Notification [6] is an OASIS standard and consists of a group of specifications 

that enable Publish/Subscribe-based communication between Web services. 

It comprises WS-BaseNotification, WS-BrokeredNotification and WS-Topics. While 

WS-BaseNotification defines which interfaces consumers (clients) and producers


125 

(servers) should expose, WS-BrokeredNotification introduces the concept of a message 

broker, an intermediary node which decouples consumers and publishers, and 

relieves producers from several tasks associated with Publish/Subscribe. NNEC CES 

specifies WS-Notification as the standard to be used for Publish/Subscribe in NATO. 

The notifications are normally always of the same type, independent of the actual 

information that is delivered (i.e., the payload of the notification). When 

a client wants to subscribe to a specific type of data, it therefore expresses the type 

of information it is interested in by including a topic in the subscription request. 

For WS-Notification, the WS-Topics standard specifies how such topics should 

be expressed. It also defines three topic expression dialects, to allow for expression 

topics of different complexity. This use of topic dialects means that one can express 

a number of different topic structures within the same standard, including define 

one’s own dialect for handling topics. This topic handling scheme is flexible, but 

the added complexity using such topics means that one needs to agree not only 

on which topics to use, but also which dialect they want to use to express topics 

before communication is possible. 

One added complexity when using WS-Notification in a limited capacity 

network it that the standard is designed to use unicast message transmission only. 

That means that, even when multiple nodes in the same network want the same 

information, WS-Notification will send one unicast message to each recipient 

rather than send one multicast message that reaches all recipients. In radio based 

networks, where the transmission medium is shared, there is a potential for a significant 

reduction in network load by switching from unicast to multicast. Note 

that making such as switch will require further functionality to be implemented 

into WS-Notification, namely the ability to manage multicast group memberships. 

A. Norwegian infrastructure 

The Norwegian infrastructure used during the CoNSIS experiments consists 

of a number of internally developed components. The core of the infrastructure 

is an implementation of the core features of WS-BaseNotification and WS- 

BrokeredNotification. This Java implementation has support for subscribing and 

unsubscribing, as well as for receiving and sending notifications. While not being 

a full implementation of the WS-Notification standard, this light-weight solution 

is well suited for use in test environments like the CoNSIS network. During 

the experiments all the Norwegian units were running a notification broker, and 

all clients and services on a node subscribed to, respectively delivered notifications 

to, its local broker. Between nodes, the brokers subscribe to each other. 

Web services, including WS-Notification, normally relies on HTTP over TCP 

for message delivery, meaning that it is necessary to establish an end-to-end TCP 

connection between client and service. In the CoNSIS network this means that 

TCP connections in many cases would have to be established across several radio


networks with unstable links and often very high delays. To enable standards-based 

Web services over such connections, we used our Delay and Disruption Tolerant 

SOAP Proxy (DSProxy) [7]. These proxies constitute a middleware that hides network 

delay and disruptions from the applications and also compresses all traffic, 

allowing XML to be sent over low bandwidth connections. 

B. German infrastructure 

The German infrastructure consists of a complete SOA environment, RuDi, 

covering a range of functionality in addition to the aspects described here. For 

a more elaborate description of RuDi, including the German national security 

experiments conducted during CoNSIS, refer to [1]. 

In order to connect the Norwegian and German infrastructures together, ensuring 

reliable message delivery in an unstable environment, the DSProxy was used. 

RuDi supports the use of multiple transport protocols at the same time, and by 

including the DSProxy as one of these transport options, connectivity between 

the Norwegian and German infrastructures was achieved. 

C. Experiment information flow 

In addition to these infrastructure components, each vehicle had a GPS component 

that reads the vehicle’s position from a GPS, creates an NFFI message, and 

delivers this as a notification to the local broker. Furthermore, there was a component 

for creating Operational Messages, and delivering these as notifications to the local 

broker. There was also a chat component, which both subscribed to, and delivered 

notifications to, the local broker. Next, there was an aggregator function that subscribed 

to the position of each vehicle, and then combined all vehicle positions into 

one NFFI message which was then delivered to the local broker as a notification. 

Finally, there was a viewer application, which subscribed to NFFI tracks and Operational 

Messages from its local broker, and displayed them on a map (see Fig. 6). 

Figure 6. The viewer component


127 

As mentioned earlier, the COP was built in two steps, with the lead vehicle 

of each convoy building a convoy COP by subscribing to the positioning service 

of each vehicle, and then the HQ building the full COP by combining the two vehicle 

COPs. This is illustrated in Fig. 7, and represents the initial flow of position 

information. 

Figure 7. Initial configuration of flow position information 

Later in the scenario, the two convoys merged into one. However, since 

the communication between the two convoy elements was done via the HQ, 

information flow between them was prone to disruptions and delays even when 

the two convoy elements were traveling together. In order to improve upon this 

situation, and take advantage of the higher capacity network connections now 

available within the convoy, we then changed the information flow: The two lead 

vehicles stopped subscribing to the full COP from the HQ, and instead started 

subscribing to each other’s vehicle COPs. The full COP could then be built locally 

at each lead vehicle, and then distributed to the other vehicles in the convoy 

(see Fig. 8). Due to the flexibility of WS-Notification this change in information 

flow was easily performed, with the added benefit of both an improved response 

time for positional updates within the convoy, and less traffic load on the narrow 

reach-back links. 

Thus, because the notification interface is the same, regardless of information 

type, any subscriber can subscribe to and receive notifications from 

any broker, as long as the business logic behind is able to parse the payload 

of the notification.


Figure 8. Flow of position information after merging of convoys 

V. Topic handling 

All Publish/Subscribe systems require a mechanism for describing content 

of interest, and WS-Notification uses topics for this purpose. A topic is a way of classifying 

content into logical channels, and topics are usually organized into hierarchies. 

Thus, the highest level topic, the root topic, represents the most general classification, 

and then an arbitrary number of subtopic levels refine this classification. 

This organization of information flows based on topics is fundamentally different 

from the Request/Response paradigm: When looking for a Request/Response 

service you are interested in a service with a particular interface. This is because that 

interface is the only aspect of the service that is known to the consumer, and thus 

represents the only interface that consumer is about to invoke. The service description 

for a service, the WSDL file, does not contain information about the actual 

content provided by the service. 

For Publish/Subscribe, on the other hand, all services are equal with respect to 

the actual interface, and you need information about the content the service offers 

in order to distinguish between content providers. A consequence of this transition 

from Request/Response to Publish/Subscribe is that traditional service discovery 

becomes less useful. This is because all Publish/Subscribe endpoints will appear 

as the same service type, generating a need for additional meta-information about 

services, namely the topics. This shift in interest from service types to information 

types makes topic discovery an important issue when dealing with WS-Notification. 

In [8] we have described how WS-Discovery can be used to distribute information 

about which topics a service covers, while at the same time remaining backwards 

compatible with the WS-Discovery standard. As a preparation for the CoNSIS 

experiment, initial testing with topic discovery was performed at the Coalition 

Warrior Interoperability Experiment (CWIX), where WS-Discovery with topic 

support was tested by multiple partners. During this initial testing, as well as during


129 

the CoNSIS experiment execution, we discovered that while this approach provides 

enough information for nodes to be able to distinguish between the content offered 

by the different providers, certain extra functionality is desirable. 

In particular for notification brokers (as described in the previous section), 

which can serve many nodes and offer information on many different topics, it would 

be very useful to be able to query the broker itself about topics: For instance, which 

topics a broker currently provides notifications on, which topics it knows about (i.e., 

has seen at some point), and if and when it has last seen notifications on a given topic. 

One challenge when working with topic based information exchange is that 

it requires all the involved parties to have prior knowledge about how topics are 

organized. In order for an information consumer to get the information it desires, 

it needs to know in advance which topic to request from the broker. In the CoN- 

SIS experiment we were working with two partners, making a priori distribution 

of topic information possible. We decided that a client normally needs information 

following a given schema, and we therefore chose to have a 1:1 relationship 

between root topic and the XML Schema of the information in question. Thus, we 

had the root topics “nffi”, “OpMsg” and “Chat”. However, in other contexts, other 

classifications may be better suited. 

In general, for larger scale implementations of topics, it is necessary to utilize 

a common information model that describes how topics are organized. This means 

that NATO should be the driving force behind such a model, which would then be 

used by all member nations. 

VI. Conclusion 

Performing practical experiments with the technologies that will form 

the foundation of future operational networks is vital to ensure that these technologies 

will be capable of meeting the interoperability requirements of complex 

operations. During the CoNSIS experiment we had the opportunity to test Web 

services in a complex network, allowing us to verify that Web services can be 

used as an interoperability enabler also in limited capacity tactical network. Using 

the Web service standards as the common reference between nations made 

interoperability possible, but there is a need for further development and profiling 

of standards in order for them to fully support the interoperability challenges 

faced by the nations. 

Due to the potential performance benefits of using the Publish/Subscribe paradigm 

in tactical networks, use of the WS-Notification standard is recommended. To 

be able take full advantage of the benefits of Publish/Subscribe however, multicast 

support for notification should be implemented. In addition, topic handling must 

be addressed, preferably by introducing a NATO recommendation addressing 

both the issue of incompatibilities between different topic expression dialects, and 

containing a common topic vocabulary and structure.


References 

[1] H. Seifert, M. Franke, “SOA in the CoNSIS coalition environment”, IEEE MCC, 

Gdansk, Poland, 2012, in press. 

[2] F.T. Johnsen, T.H. Bloebaum, L. Schenkles, J. Śliwa, P. Caban, “SOA over 

disadvantaged grids experiment and demonstrator”, IEEE MCC, Gdansk, Poland, 2012, 

in press. 

[3] F.T. Johnsen, T. Hafsøe, M. Skjegstad, ”Web services and service discovery in military 

networks”, 14 th ICCRTS, Washington D.C, US, June 2009. 

[4] V. Modi, D. Kemp (eds.), “Web services dynamic discovery (wsdiscovery) version 1.1,” 

http://docs.oasis-open.org/ws-dd/discovery/1.1/wsdd-discovery-1.1-spec.pdf, July 

2009. 

[5] M. Hauge, J. Andersson, M. Brose, J. Sander, “Multi-topology routing for QoS 

support in the CoNSIS convoy MANET”, IEEE MCC, Gdansk, Poland, 2012, in press. 

[6] OASIS, Web services Notification TC, http://www.oasis-open.org/committees/tc_home. 

phpwg_abbrev=wsn 

[7] K. Lund, E. Skjervold, F.T. Johnsen, T. Hafsøe, A. Eggen, ”Robust web services 

in heterogeneous military networks”, IEEE Communications Magazine, October 2010. 

[8] F.T. Johnsen, T.H. Bloebaum, “Topic discovery for publish/subscribe web services”, 

IEEE IWCMC, Limassol, Cyprus, August 2012, in press.

Protected and Controlled Communication 

Between Military and Civilian Networks 

Anders Fongen 

Norwegian Defence Research Establishment, Norway, anders.fongen@ffi.no 

Abstract: The controlled and protected communication between civilian and military computer nodes 

is the objective of this paper. The release of unclassified military information to Non-Governmental 

Organizations (NGOs) may improve the safety and effectiveness of their operations. The information 

exchange must meet several requirements though, related to military tactics, the impartial status 

of the NGO and international jus in bello. The paper proposes a framework that both protects communication 

and controls the access to information resources. A prototype based on the framework 

has been built and was evaluated during the CoNSIS experiment in June 2012. 

Keywords: CiMi, Identity management, Authentication 


The presence of non-governmental organizations (NGOs) in a war zone 

is frequently seen, and their operations may be safer and more efficient through 

communication with military forces. Military information about safe routes, road 

conditions and observations regarding the situation for the population may be sent 

to the NGOs. Positions and movements of NGO vehicles and personnel may be 

sent to the military forces in order to avoid inadvertent attacks.[1] 

The information exchange must not blur the impartial status of the NGOs 

and must not weaken the protection of NGOs by international laws of war. NGO 

equipment must never convey or relay military information, and never provide 

information of value for the military operation. The NGO should not possess 

military hardware or participate in proprietary military communication protocols. 

From these perspectives, the detailed control of the information exchange 

becomes an essential property. In this paper, the proposed technical elements 

of interconnection, protection and control will be described and discussed. 

The contribution of this paper is a separation and control framework for 

the “minimal” interconnection of networks, where only selected and essential 

services are allowed to cross the CiMi interface. The framework relies to a large 

extent on the Identity Management system previously presented in [2], but leverages 

that system into an enterprise context where additional technologies like


IPSec and the XMPP protocol complements the Identity Management and offers 

a more “hardened” system. Besides, the discussion of requirements set on behalf 

of impartial and civilian NGOs has not been observed previously in the context 

of computing security research. 

The remainder of the paper is organized as follows: The next section articulates 

the technical non-functional requirements of the interconnection, followed 

by Section III where the proposed system configuration is described. Section IV 

gives a general introduction of Identity Management services, which are central to 

the proposed solution framework. Sections V-VII present the IdM prototype used 

for the evaluation experiment. Section VIII gives a brief presentation of the mechanisms 

bridging the IdM service invocation environment with the classified SOA 

environment. Section IX presents a set of problems related to the unconventional 

use of COTS products. Section X presents the experimental environment in which 

the framework was evaluated, and the paper finishes with a section containing 

some concluding remarks. 

II. Technical requirements 

The functional requirements for a Civilian-Military (CiMi) communication 

arrangement may be expressed in the following manner: 

A. COTS equipment and protocols 

The NGO should avoid the use of military communication equipment from reasons 

of impartiality and cost. A laptop computer or a smartphone is able to communicate 

over aWiFi link or a cellphone connection. Where possible, public communication 

service should be used, even though the military end of the connection would also 

need to link to a similar service. For longer ranges in environments without a communication 

service, civilian radio equipment with computer interface may be used. 

B. Protection of communication channel 

The CiMi connection must be a black network, i.e. it can run through any 

unprotected link. This supports the utilization of public network services or private 

radio links without any link crypto requirements. 

The end-to-end connection (possibly spanning several different links) must 

be protected with cryptographic equipment/software which is available for nonmilitary 

use, i.e.an IPSec tunnel protected with AES.


133 

C. Robustness of separation (fail-close) 

The separation of the NGO and the military equipment should have the failclose 

property (also called fail-safe). Fail-close means that in the event of a failure, 

system security should be preferred before connectivity. Any filtering or control 

mechanism should operate in a deny-allow order where the default action is to 

deny service. 

D. Authentication of participants 

Participants in the communication should be fully identified before or during 

the service. Authentication is the basis for resource control and auditing, and 

normally requires a registry of users and services where their identity is associated 

with the necessary credentials. Authentication across the CiMi interface should not 

require that the identities are registered on both sides: A Cross Domain mechanism 

should be in place where a trust relation between the registration authorities should 

allow mutual authentication across the interface without the need for multiple 

registration of identities. 

E. Role-based access control 

Since authentication does not require local registration of an identity, (cf. 

previous section) the decision to allow or deny participation in the service transaction 

cannot rely on the identity, but rather on roles or attributes associated with 

the identity. Role Based Access Control [3] should be the basis for the access control 

decisions, which enables the owner of a service to reserve its use for clients which 

possess certain roles. RBAC preserves the autonomy of domains and let them define 

and enforce their own independent security policies. 

F. Confidentiality labeling 

In the classification hierarchy found in military information management 

there is a need to decide if information kept in classified systems can be released 

for use on lower classification levels and even released to an NGO. One approach to 

achieve this is by means of confidentiality labels. They are cryptographically bound 

to the information object and can be automatically inspected by a guard. The guard 

is situated between networks of different classification levels and transfers object 

from high to low classification based on the confidentiality label and a transfer 

policy. The guard provides an isolation between two military networks and adds 

to the separation between the unclassified military network and the NGO.


III. The prototype configuration 

For an experimental evaluation of these principles (cf. Section X) a prototype 

was developed with the following services in mind: 

A. Protected service invocation 

A client in the NGO network should be able to invoke a positioning service 

in the classified network, and to receive the GPS coordinates of a mobile military 

unit. The service requires mutual cross domain authentication across the CiMi 

interface, role based access control decisions, and data inspection by the guard 

in order for the invocation to succeed. 

B. Secure chat 

The mobile client may write text messages to other users on a chat client 

program. The chat messages must be protected in the same manner as service 

invocation messages using the same cryptographic mechanisms. There is no need 

for end-to-end authentication, and a simple authentication mechanism provided 

by the chat server is sufficient. The chat message service covers users connected 

to the NGO network or the unclassified military network, but the chat server will 

reside in the military network. 

C. Configuration details 

Figure 1 outlines the structure of the prototype. It consists of the following 

actors: 

• An Android smartphone, acting as an NGO terminal for chat and protected 

service invocation. 

• A chat server for the XMPP chat protocol. This server will forward both 

chat messages and service invocation messages. 

• Two Identity Providers (IdP), one for the NGO domain and one for the military 

domain. They provide identity information for authentication operations. 

The details of the IdP will be explained in Section IV. 

• An application server, residing in the military domain, hosts application 

services or proxies for Web Services. 

• A SOAP guard, which connects the military classified and unclassified 

networks. It ensures that only correctly labeled data is passed from the classified 

to the unclassified part. 

• Other chat clients which use the XMPP protocol. They are connected to 

the XMPP server.


135 

The XMPP protocol is used for the transport of chat messages as well as messages 

for the protected service invocation. Clients or services need to connect (and 

log in to) the server in order to participate in any of the two services. The XMPP 

chat server is the only connection between the NGO nodes and the military nodes, 

and there is no IP route between the two networks. The figure also shows that 

connections outside the physical control of a wired military network is protected 

with IPSec tunnels. 

Figure 1. Outline of the experimental prototype for the demonstration of CiMi communication 

IV. Introduction to identity management 

(Most of the text in the following 4 sections are previously published in [2]). 

Identity Management (IdM) are collection of services and procedures for maintaining 

subject information (key pair, roles) and to issue credentials for the purpose 

of authentication, message protection and access control. From the client perspective, 

the credentials issued by the IdM services enables it to access many services 

inside a community under the protection of mutual authentication and encryption. 

From the server perspective, IdM enables it to offer credentials to clients in order 

to provide mutual authentication. 

The arrangement of an IdM resembles the Public Key Infrastructure (PKI), 

in the sense that a Certificate Authority (CA) can issue public key certificates which 

binds an identity to a public key in a way that can be validated by a relying party. 

The binding is made by the CA’s signature using a well known and trusted key.


The role of the CA, called trusted third party, is widely used when making arrangements 

between parties that have never met before. 

The traditional organization of a PKI is to issue public key certificates with 

a long lifetime, typically 1 year. In the event that the key need to be invalidated before 

expiration, it need to be revoked. Revocation information needs to be disseminated 

to all relying parties in the form of revocation lists or online status providers. There 

are two main reasons why a traditional PKI is not a viable solution for identity 

management: First, the distribution of revocation information is costly in terms 

of bandwidth and connectivity requirements, and secondly because the public 

key certificate does not contain information about the subject necessary to make 

access control decisions. 

The requirements of an IdM (distinct to the requirements of a PKI) should be: 

• The IdM should issue short term credentials so that distribution of revocation 

info becomes unnecessary. 

• The IdM should include role/attribute information about a subject to support 

access control decisions etc. 

The decision to avoid distribution of revocation information is based on 

a comprehensive study of scalability properties in commercial PKI implementations 

[4]. The conclusion of that study is that short lived credentials generate less 

network traffic, have less connectivity demands, scales better and make the validation 

operation more intuitive. 

A. Federated identity management 

Several federated IdM schemes have been developed, some of which offer 

single sign on (SSO) for web clients [5], [6], [7]. The SSO protocols exploits the redirection 

mechanism of HTTP in combination with cookies and POST-data so that 

an Identity Provider (IdP) can authenticate the client once and then repeatedly 

issue credentials for services within the federation. This arrangement requires IdP 

invocation for each “login” operation, and does not offer mutual authentication, i.e., 

no service authentication. 

In the situation where the client is an application program (rather than a web 

browser), there are more opportunities for the client to take actively part in the protocol 

operations, e.g., by checking service credentials, contacting the IdP for 

the retrieval of own credentials, caching those credentials etc. The research efforts 

presented in this paper assume that the clients enjoy the freedom of custom programming. 

The usual meaning of the word “federated” is that several servers share their 

trust in a common IdP for subject management and authentication. It does not 

necessarily imply any trust relationship between independent IdPs so that they 

can authenticate each others’ clients. For the following discussion, we will call 

the group of clients and services which put their trust in the same IdP as a com-


137 

munity of interest (COI). A trust relation between independent IdPs is called 

a cross-COI relation. 

B. Mobile and federated IdM requirements 

An essential property of an IdM is its ability to integrate with other components 

for management of personnel and equipment. 

• An IdM should be able to use resources from the existing PKI (keys, certificates, 

revocation info) and offer its services to different platforms, with different 

presentation syntax and for different use cases. 

• An IdM should also be able to tie trust relations with other IdMs in order to 

provide accommodation for guests and roaming clients. 

• An IdM should support protocol operations for mutual authentication. 

For IdM used in mobile systems, there are requirements related to the resource 

constraints found in these systems: 

• A IdM for mobile operations must use the minimum number of protocol 

operations, use small PDU sizes and must allow the use of caches. 

C. The relation between IdM and access control 

Services can enforce access control on the basis of the identity of an authenticated 

client, or based on roles or attributes associated with the client. For 

the purpose of the accommodation of roaming users, it is absolutely necessary to 

make access control decisions based on roles/attributes, not identity. Identity based 

access control requires that all roaming clients are registered into the guest IdM, 

which is an unscalable solution. 

The principles of Role/Attribute Based Access Control (RBAC/ABAC) are well 

investigated [3]. The names and meaning of the roles/attributes that are used to 

make access decisions must be coordinated as a part of an IdM trust relationship. 

For that reasons, the number of roles/attributes used for access control needs to 

be kept low. 

It is the obvious responsibility of an IdM to manage the roles/attributes 

of a subject, some of which may enter into access control decisions, others be used 

by the service to adapt the user interface etc. The presence of subject attributes 

is the main functional difference between IdM credentials and X.509 public key 

certificates. 

V. The GISMO IDM architecture 

For the purpose of authenticated service provisioning in military tactical 

networks (meaning wireless, mobile, multi-hop, multicarrier networks), an Identity


Management system has been developed under the project name “GISMO” (General 

Information Security for Mobile Operation). The system has been previously 

presented in [8], [9], so its properties are only briefly listed here: 

Subject Distinguished Name 

Subject Public Key 

Subject Attributes 

Valid from−to 

Issuer Distinguished Name 

Issuer Public Key 

Issuer’s Signature 

Figure 3. The structure of the Identity Statement 

• It uses short lived Identity Statements containing the subject’s public key and 

subject attributes. No revocation scheme is necessary. Identity Statements are 

issued by an Identity Provider (IdP). 

• Cross COI relations are represented by ordinary identity statements issued 

from one IdP to another. 

• IdPs can issue Guest Identity Statements when presented with an Identity Statement 

issued by an IdP with with which it has a Cross COI relation. A guest identity 

statement contains the same information, but is signed by a different IdP. 

• Authentication takes place either through a signature in the service request, 

or through the encryption of the service response. 

• It supports Role/Attribute Based Access Control (RBAC/ABAC) through 

the subject attributes. 

• Employs, but encapsulates an existing PKI. Clients never see X.509 certificates 

or revocation info. 

• Identity Statements are cached and re-used during its lifetime. An IdP is invoked 

to issue Identity Statements, not to verify authenticity. 

• There is loose coupling between IdP and services/clients, and between COIs. 

Very little redundant registration is necessary. 

Figure 2 illustrates the concepts and components of the GISMO IdM. Identity 

establishment, key generation and key certification happens in the (existing) PKI. 

Related to a CA (Certificate Authority) domain there are several Communities 

of Interest (COI) with one IdP common to all members of that community. 

The IdP issues signed Identity Statements. The structure of the Identity Statement 

is shown in Figure 3. 

Members of a COI only trust the signature of their IdP, so an Identity Statement 

(signed by the IdP) is not valid outside the COI unless there exists a cross-COI 

Identity Statement which links the signature of the foreign IdP to the trusted IdP. 

More on that later.


139 

A. Cross COI relationships 

Any client will likely be a member of several COIs, reflecting the diverse tasks 

and responsibilities of a worker or a soldier. It is not convenient to manage the client’s 

key pairs, attributes etc. in every COI. Most of them will naturally belong to 

one COI, e.g., their national military unit or the employing department, and could 

be regarded as “guests” in other COIs. 

The ability to authenticate across COI borders is believed to be an essential 

requirement for a modern IdM. In the GISMO IdM, this problem has been solved 

by the use of Guest Identity Statements. One IdP can issue a Guest Identity Statement 

if presented for an Identity Statement issued by an IdP with which it has a trust 

relationship. The trust relationship is represented by a pair of cross-COI Identity 

Statements issued from one IdP to the other. 

During invocation of a service in the foreign COI, the client presents the Guest 

Identity Statement as a part of the authentication process. 

Figure 4 shows the interaction between the client and the IdPs during the issuance 

of identity statements. Please observe that the cross-COI identity statements 

are issued asynchronously with regard to the client operations, but handed back 

to the client during issuance of a guest identity statement. Abbreviations used 

in the figure are explained in Table I. 

Figure 2. The functional components of a federated IdM. Observe that the IdP serves one single 

COI, and the trust relations are formed between COIs, not domains. Key management 

is handled by the PKI whereas the attribute management is done by the IdPs on the COI level


Table 1. Abbreviations used in the figures 

Figure 4. The identity statement issuing protocol. The IdP of COI A, termed IdP a , issues a “native” 

identity statement to the client, which is given to IdP b , which in turn issues a guest identity statement. 

The term PKIa denotes a set of certificate validation services in COI a 

VI. Service invocation 

IdP operations and service invocations are using serialized Java objects (called 

POJO) as PDUs which opens up interesting opportunities: The client may simply 

send a parameter object to the server containing the parameter values, and the class 

of the object identifies the service method. This arrangement eliminates the need for 

a separate scheme for service addressing and also eliminates the need for separate 

stub/skeleton compilation. 

In the server, a single service endpoint hosts all services. This is possible 

since we do not address the service through a URL, but through association with 

the parameter class. The service point is a “dispatcher” service, and the serialized 

parameter object included in the request operation controls the dispatching 

process. The services are loaded dynamically from a JAR file repository at servlet 

startup and deployed through class introspection, no configuration file editing 

is necessary. Consequently, the deployment of services requires less configuration 

than e.g. ordinary Java servlets.


141 

A. Authentication dependent on server state space 

The authentication mechanisms assure the identities of the client and service 

during service invocation. Many different authentication protocols can be incorporated 

into GISMO IdM as long as they employ a public key pair corresponding 

to the information in the Identity Statement. It is also a requirement that the authentication 

can be piggybacked on the service request and should not generate 

separate PDUs. Two protocols have been implemented in GISMO IdM: 

1. In those cases where the request must be authenticated before the service 

execution, a replay protection must be in place. Replay protection requires 

the server to remember past requests (by their Nonce) for a while, so a clock 

synchronization scheme and a non-volatile stable storage must be in place 

(since past requests must be be remembered also across server incarnations). 

These requirements are rather costly. 

2. In the case of a stateless service, where the execution of a service request 

does not alter the state of the service, replay protection is not necessary. 

A request should be signed by the client in order to protect the integrity 

of the message, but no Nonce for request replay protection is included. 

The response is encrypted with the client’s public key, making it useless for 

everyone but the holder of the private key. To a stateless server, replayed 

requests are not a threat and protection is not needed. Requests still need 

a Nonce for reasons of response replay protection, but that does not increase 

the state space in the server. 

Figures 5 and 6 shows the two variants as an interaction diagram. The interactions 

shown with dotted lines are related to IdP operations and discussed in more 

detail in Figure 4. 

B. Authentication during Identity Statement Issuance 

For privacy protection, authentication also takes place during Identity Statement 

issue operations. The client simply signs the request with its private key. 

If the requested Identity Statement contains the corresponding public key the client 

is regarded as authenticated. For replay attack protection, the response is encrypted 

with the public key of the client, which also serve to protect the potential privacy 

of the subject attributes.


Figure 5. The authentication protocol for the stateful service. Both the request and response are 

signed with the sender’s private key as a part of authentication process. A timestamp, a nonce 

and the server’s name is included for replay protection 

Figure 6. The authentication protocol for the stateless service. Requests are not reply protected since 

this is not considered as a threat, but the response need to be protected for reasons of response replay 

and information compromise. For the sake of integrity protection, the request is signed. The encryption 

of the response is a part of the authentication scheme, not a privacy measure


143 

VII. Messaging protocols 

In a wired private network where capacity and reliability suffice, and there exist 

IP routes between the nodes that wish to communicate, the HTTP protocol works 

just fine for IdP operations and service invocations. For mobile networks this is not 

necessarily the case: they are slow, unreliable and consists of several partitions connected 

with application level gateways (from reasons of security and traffic control). 

In the context of this experimental study of the GISMO IdM, an XMPP (eXtensible 

Messaging and Presence Protocol) network was already in place for chat 

communication. Through the XMPP routers (working as application gateways) 

otherwise isolated networks (where no IP route exists between them) can exchange 

chat messages. 

A. Service provision by mobile units 

A messaging system creates reachable endpoints for nodes which are disconnected 

at the IP layer. Nodes which reside behind a NAT unit or a firewall are unreachable 

from the outside world at the IP layer, yet a messaging system can send them 

messages. Through the XMPP protocol a mobile node can receive service requests 

just like any other service provider. The prototype system uses a very simple service 

container (not a servlet), which is easily portable to a mobile Android based unit. 

B. Access to SOAP based web services 

The service invocation mechanisms offered by GISMO IdM employs serialized 

Java objects (POJO) for its protocol data units. On the other hand, there may be 

existing Web Services based on SOAP messages that clients wish to invoke. 

In order to invoke SOAP services, proxies can be built that translates between 

POJO and SOAP services. This approach has been studied and tested, and represents 

an attractive approach. A service which takes the parameter values and passes them 

to a precompiled web services stub (generated by the WSDL compiler). The return 

value from the stub is passed back to the caller of the POJO service. Example code 

lines required for this function are shown below: 

public class MainClass { 

public Serializable service(WeatherRequest wr, 

Properties props) { 

try { 

Weather w = new Weather(); 

String result = w.getWeatherSoap(). 

getWeather(wr.town); 

return result; 

} catch (Exception e) { return e; } 

} 

}


This option is also attractive since it gives the developer control over service 

aggregation and orchestration. One service call to a POJO service need not be passed 

on as one single web service invocation. Many individual calls may be made, and 

they may be sequenced or tested in any manner. Aggregated operations are useful 

because they potentially reduce the network traffic to and from the mobile unit, 

which is likely to be connected through a disadvantaged link. The proxy can even 

cache results for subsequent service calls. 

There is a problem related to signature values. Equivalent POJO and SOAP 

messages will have different signature values, and the integrity of the message signature 

is broken during a conversion. The proxy can sign the converted object using 

its own private key, which would require that the service accepts that the proxy 

vouches for the original client in the authentication phase. 

VIII. SOAP guard and confidentiality labeling 

As can be seen in Figure 1, a SOAP guard connects military networks of different 

classification levels as an application gateway in the form of an HTTP proxy. 

It relies on confidentiality labels that are bound to information object in a form that 

can be inspected and validated by the guard in order to make decisions whether to 

allow objects to be transferred from a high to a low classified network. The transport 

may be initiated by a client on the low side as an HTTP operation (e.g. a Web Services 

request), in which case the response will need a label in order to pass through. 

The request will need to be labeled if it is initiated on the high side. 

The format requirements of the label is expressed in a proposed NATO standard 

for information labeling [10], and describes the structure of the label, the signature 

and the binding mechanism. 

The proposed standard does not mandate the validation of labels, but implies 

that there must be a PKI-type certificate validation process in order to trust 

the validity of a label. 

Nor does the NATO standard set requirements to the labeling process. In order 

to provide a trusted label, the process of creating and attaching a label must be robust 

against attacks from malware etc, and should be executed with high assurance. 

IX. Challenges and potential problems 

This section reports some of the technological problems that were observed 

during the configuration and pre-testing of the experimental set-up: 

A. Android client and IPSec 

The IPSec client on the Android platform is a basic implementation for 

connection to Microsoft IPSec services, which means that it only supports IPv4,


145 

IKEv1 keying protocol and relies on the use of L2TP and PPP protocols on top 

of the IPSec connection. The entire CoNSIS experiment was based on the use 

of IPv6, but the Android link required a different configuration. There is general 

support for IPv6 in Android, but the kernel is not able to manually set the IPv6 

address of an interface, which makes a tunneling arrangement infeasible. 

The Android IPSec appeared to to use an inactivity timer to disconnect an idle 

link. This was not welcome over an XMPP connection that carried infrequent 

messages. 

B. XMPP as a messaging service 

Although XMPP messages can carry any data and connect to any client, 

it was not ideal as a message service. The XMPP standard has chat messages 

in mind, and mechanisms related to presence, file transfer, avatars, rosters etc. 

were prominently implemented in the XMPP server. In particular, the facility to 

store messages that could not be delivered due to offline clients were not welcome 

in a messaging system used for request/response traffic. The final choice of XMPP 

server (OpenFire) offered an option to discard such packet, which improved its 

utility greatly. This server also offered centrally managed rosters, which relieved 

the client from creating the rosters themselves. 

The XMPP standard offers extensions for PubSub communication (XEP-0060), 

which is potentially a good candidate for the transportation of service invocation 

messages. OpenFire implements the PubSub extension, but without any administrative 

tools (management of nodes and subscriptions etc.). Without such tools, 

experimentation on PubSub messages becomes very tedious. 

The XMPP connections rely on stable IP routes in the network. For purposes 

of chat application in tactical networks, studies has been conducted to distribute 

message through diffusion or gossip techniques [11]. Future experiments could 

possibly pursue those opportunities. 

C. Android network routing 

Although Android has several networking interfaces (WiFi and 3G) and 

contains a Linux kernel, it does not appear to offer routing to these interfaces. 

All network traffic is sent to the WiFi adapter if the link is up, otherwise the 3G 

service is used. One initial idea was that the Android unit could access NGO resources 

(i.e. the Identity Provider) over a 3G connection and military resources 

over the WiFi/IPSec connection. 

Without that option, the NGO resources (the IdP) had to be placed in the military 

network (as seen on Figure 1). This was far from an ideal situation and was not 

intended in the early experiment design.


X. The CoNSIS evaluation 

The background for the efforts presented in this paper is the collaboration 

program called “Coalition Network Secure Information Sharing” (CoNSIS), with 

participation of military and industrial scientists from Germany, France, USA and 

Norway. The program was operational from 2010 and its objective is “to develop, 

implement, test and demonstrate technologies and methods that will facilitate 

the participants’ abilities to share information and services securely in ad-hoc 

coalitions, and between military and civil communication systems, within the communications 

constraints of mobile tactical forces”. 

Another objective of CoNSIS is that “The participants intend to utilize, to 

the maximum extent possible, commercial standards to minimize interoperability 

difficulties. Only those elements of the technical architecture which are not available 

from the open market will be investigated, and potentially developed.” 

The main deliverance of the CoNSIS program is a technical test and demonstration 

which took place in Greding, Germany, during June 2012. During this demonstration, 

communication spanned vehicles from several countries and a number 

of national headquarters, using different radio systems and security technologies to 

access services and to exchange information. The technology experiment presented 

in this paper is only one of large set of experiments which took place. 

XI. Conclusion 

This part of the CoNSIS experiment was conducted with the intention to study 

a range of security technologies for the separation of military and civilian networks, 

and to study how commercial mobile units (a waterproof Android smartphone) 

could be employed inside that security framework. 

Most of the technologies (StrongSwan IPSec, serialized Java objects, homemade 

IdM, SOAP Guard) were working well. The use of Android was a bit overambitious, 

in the sense that IPv6, IPSec and network routing was implemented 

in a rather basic fashion. 

The Android unit turned out to offer excellent portability of existing Java SE 

sources, and the XMPP stack was directly ported to Android without the need for 

any corrections. The low price, availability of development tools and the existence 

of waterproof Android units is promising for the future use of mobile COTS units 

in tactical networks.


147 

REFERENCES 

[1] R.M. Zich, “Warfighters and humanitarians: Integrating technology to save lives,” 

1997. [Online]. Available: http://www.globalsecurity.org/military/library/report/1997/ 

Zich.htm [Retrieved Apr 30, 2012] 

[2] A. Fongen, “Federated identity management for android,” in SECURWARE 2011. 

Nice, France: IARIA, July 2011. 

[3] R. Sandhu, D. Ferraiolo, R. Kuhn, “The NIST model for role-based access control: 

towards a unified standard,” in RBAC ’00: Proceedings of the fifth ACM workshop 

on Role-based access control. New York, NY, USA: ACM, 2000, pp. 47-63. 

[4] A. Fongen, “Optimization of a public key infrastructure,” in IEEE MILCOM, Baltimore, 

MD, USA, Nov. 2011. 

[5] “Shibboleth.”[Online]. Available http://shibboleth.internet2.edu/ [retrieved November 9, 

2010] 

[6] “OpenID.” [Online]. Available: http://openid.net/ [retrieved November 9, 2010] 

[7] “The Libery Alliance.” [Online]. Available: http://www.projectliberty.org/ [retrieved 

November 9, 2010] 

[8] A. Fongen, “Identity management without revocation,” in SECURWARE 2010. Mestre, 

Italy: IARIA, July 2010. 

[9] A. Fongen, “Architecture patterns for a ubiquitous identity management system,” 

in ICONS 2011. Saint Maartens: IARIA, Jan. 2011. 

[10] S. Oudkerk, I. Bryant, A. Eggen, R. Haakseth, “A proposal for an xml confidentiality 

label syntax and binding of metadata to data obejcts,” in NATO RTO Information 

Technology Panel Symposium, Information Assurance and Cyber Defence, Antalya, 

Tyrkia, 2010. 

[11] M. Skjegstad, K. Lund, E. Skjervold, F.T. Johnsen, “Distributed chat in dynamic 

networks,” in IEEE MILCOM, Baltimore, MD, USA, Nov. 2011.

Use of Cross Domain Guards for CoNSIS 

Network Management 

Philipp Steinmetz 

Cyber Defense, Fraunhofer FKIE, Wachtberg, Germany, 

philipp.steinmetz@fkie.fraunhofer.de 

Abstract: This paper discusses filtering of messages sent from a classified to an unclassified network 

using a cross domain guard. We discuss how we can use such a guard within the network architecture 

designed in the CoNSIS (Coalition Networks for Secure Information Sharing) project for use 

in future coalition operations. A guard design is presented which enforces that only XML messages 

conforming to a specific format may pass the guard. It also limits the message rate based on message 

size and the resulting possible covert channel. We can use this guard design for low data rate 

applications which have to communicate across networks of different classification. We also discuss 

a proxy device located in the unclassified network to reduce the required amount of communication 

between classified and unclassified network. 

Keywords: Information Security; Computer networks 


Protecting confidential information while at the same time reaping the benefits 

of networked systems is an important goal. Traditionally military computer 

networks containing sensitive data have been protected by physically separating 

them from other systems. This complicates or prevents many important applications 

for which data has to pass from a classified to an unclassified system. Cross 

Domain Guards have been developed to allow a controlled exchange of information 

between systems of different classifications while filtering confidential information. 

The focus of this paper is on looking into the intended behavior of guards. While 

the actual implementation of guards is not the focus of the paper, we keep in mind 

that composing them from small building blocks which interact in a simple fashion 

is helpful for secure implementation. 

II. The CoNSIS project 

The CoNSIS (Coalition Networks for Secure Information Sharing) project is a joint 

effort of France, Germany, Norway and USA. The focus is on designing network


architectures and protocols for future coalition operations. The work is distributed 

among five tasks. The author participates in Task 3 which is responsible for security. 

The overall architecture [3] contains many elements of the Protected Core 

Networking (PCN) concept, but it is not identical. In CoNSIS several Colored 

Enclaves (CEs) are each connected to a Transport Network (TN) (Figure 1). 

The TN consists of several Transport Network Segments (TNSes). The CEs may 

contain unencrypted classified data. They are assumed to be physically protected 

from unauthorized access. Each one is run by a nation participating in the coalition. 

Figure 1. A CoNSIS network 

The TNSes are either run by a nation or by the coalition. The TN they form 

is an unclassified network with focus on availability without confidentiality protection. 

This means that classified data transmitted from one CE to another has to be 

encrypted before it reaches the TN. This is achieved by placing IPsec devices between 

each CE and the TN which encrypt all traffic leaving a CE and decrypt the incoming 

traffic. Message confidentiality depends on correct installation of the IPsec devices 

and protecting the CEs from unauthorized physical access. 

III. Multilevel security and cross domain guards 

Protecting classified information from unauthorized disclosure is among the most 

important goals in information processing in military applications. Strict separation 

of devices handling information of different degrees of confidentiality is often used to 

achieve this. For example, a user employs both a Secret and an Unclassified workstation 

not connected to each other for handling data of each classification. 

Such complete separation also prevents desirable flows of information between 

the systems. Full replication of hardware also means higher weight and greater 

power consumption, which can be problematic for mobile units.


151 

Multilevel Security deals with handling data of several classifications on 

the same device according to some set of rules. One well-known rule set is Bell- 

LaPadula (BLP) [2]. Each information object has a specific classification and each 

user has a clearance for access to data up to a specific maximum classification. 

BLP enforces that no data can be transmitted to a user with insufficient clearance. 

This is achieved by two rules. The first rule enforces that a user may not read data 

without having sufficient clearance. The second one prevents users from writing 

data to objects with a lower classification than their own clearance. This prevents 

data leaks by malicious software executed by a user with a high clearance. 

This strict rule set does not provide mechanisms for releasing or downgrading 

data which is no longer considered confidential or had its confidential parts 

removed. Often, some downgrading mechanism has to be implemented and exempt 

from the BLP rules for practical reasons. In [1] Rushby introduces the concept 

of a separation kernel. Such a separation kernel restricts the interaction of processes 

on a machine to specifically allowed communication. It allows a system to 

behave like a distributed system with specified connections but runs on a single 

piece of hardware. The motivation for this is using a separation kernel for providing 

reliable separation of processes and using specialized code to enforce policy by 

message filtering and verifying the correct behavior of each individually. 

There are several applications such as safety-critical real-time systems which 

are required to behave deterministically without being influenced by other processes. 

Rushby explicitly names filtering data which has to bypass an encryption 

device as an application. 

We design a downgrading mechanism based on a separation kernel. One 

partition contains the classified data (red), one contains the unclassified data 

(black) and a third contains the downgrading mechanism filtering the data (Cross 

Domain Guard). The separation kernel enforces that no data flows directly from 

red to black but has to go through the guard first. This means that only the separation 

kernel and the guard have to be trusted. Weaknesses in other code cannot be 

exploited to circumvent the guard. 

IV. Steganography and covert channels 

The main task of a Cross Domain Guard is to enforce a policy on the traffic 

flowing through it. It has to prevent the unwanted release of classified information. 

The obvious part of this task is to prevent accidental or malicious 

transmission of classified information which is transmitted as application 

data and properly marked or otherwise recognizable as classified. A guard 

identifies the data by searching it for “dirty words” such as “secret”, validation 

against an XML schema, which describes the format of messages intended to 

pass the guard, or some fails or some other mechanism inspecting the message 

payload which may flag the message as classified.


Apart from this more subtle ways of data transmission have to be taken into 

account. Steganography is the art of hiding information inside other information 

in order to conceal the existence of the hidden message altogether. An overview 

of relevant definitions can be found in [5]. A well-known example is replacing 

the least significant bit of color information of pixels in an image file with the embedded 

message. A human observer is unlikely to notice the difference, but evading 

detection through statistical analysis will require more advanced techniques. 

Anderson explains several mechanisms in [6]. 

Covert channels are a related topic. They are used to transmit data from 

an object with a high classification (High) to one with a low classification (Low). 

In [6] a covert channel is defined as a mechanism not intended for communication 

which can be abused to communicate information from High to Low. In [7] 

the components of a covert channel, different examples and countermeasures are 

explained. A covert channel consists of a data variable and two synchronization 

variables, one sender-receiver (s-r) and one receiver-sender (r-s) synchronization 

variable. The first two variables are properties of the system which can be set by 

High and read by Low. The last one can be set by Low and read by High (Figure 2). 

High sets the data variable to a state representing the information to be transmitted. 

In the simplest case one of two states representing either 1 or 0 is set. High then 

uses the s-r variable to indicate that data can be received. Low reads the data variable 

and uses the r-s variable to inform High that it has received data. This process 

is repeated until all data has been transmitted. 

Figure 2. Covert channel components (see [7]) 

When a common time reference is used for instead of the synchronization 

variables, the channel is called a timing channel otherwise it is called a storage 

channel. Properties of shared resources can be used as variables. A simple example 

is a hard disk shared by High and Low with access control mechanisms in place 

to prevent Low from reading files owned by High. High can allocate almost all


153 

remaining disk space and then allocate the rest to represent a 1 or deallocate some 

space to represent a 0. Low can now try to allocate space and determine whether 

it fails or not. They can then repeat this synchronized by the system clock. 

Both steganography and covert channels can be used by malicious software 

in a classified network to send classified data to an unclassified network through 

a guard. Guard design has to take limiting covert channels to acceptable values 

into account. Acceptable values depend on the environment a guard is used in. 

As noted in [7], the risk of espionage by sending classified satellite images via a low 

data rate covert channel without being detected is low due to the large file sizes, 

while an encryption key vulnerable to transmission by covert channel is a serious 

problem unless the covert channel bandwidth is almost nonexistent. 

V. A guard for management data 

The CoNSIS architecture is designed to prevent unencrypted classified data 

from leaking to the TN by encrypting all data which leaves a CE and only accepting 

data originating from other CEs into a CE. Since the TN is a means to transport 

data and the users working on classified data operate inside the CEs, the fact that 

messages cannot be exchanged between a device in the TN and one in a CE does 

not pose a problem to regular applications. 

If we preclude all exchange of unencrypted data between TN and CE, we limit 

our options regarding network management. The management has to happen 

inside the TN. If instead we allow management data to be exchanged between 

TN and CE, users inside a CE can receive status information on the transport 

network and manage transport network segments if they are authorized to. This 

provides the users inside the CEs with the ability to adapt their transmission 

behavior to the available resources and manage the transport network according 

to their priorities. While devices connected to the TN could be physically 

located in reach of a CE user, this would mean manual control by the user and 

hardware replication. 

Passing messages between CE and TN means that these messages bypass 

the IPsec device and pass a filter to remove unwanted messages. 

Messages from CE to TN 

• must have legitimate management message syntax, 

• must not contain classified information and 

• must not allow transmission of classified information through covert 

channels. 

Messages from TN to CE 

• must not introduce malicious code. 

One has to balance the degree to which these goals are accomplished and 

the limitations enforced on legitimate traffic. This paper focuses on filtering messages 

from CE to TN using a guard.


VI. Structure of a guard 

The guard is designed as a sequence of filters running on a separation kernel. 

A message from CE to TN has to pass all filters before being released to the transport 

network. Each filter is installed on a partition of its own to minimize the size of each 

piece of critical code. We assume that XML is used for the management messages. 

The first filter validates the XML messages against a schema of legitimate 

messages. The second filter enforces additional constraints to limit the possible 

transmission of classified data through a sequence of messages of valid format. 

The last filter minimizes covert channels in packet headers. Figure 3 shows the guard 

components. We now discuss the properties of these components. 

Figure 3. Guard components 

The intended behavior of the first filter is specified by a schema file which 

is determined by the syntax of the legitimate messages. The last filter needs to 

overwrite packet header fields usable for covert channels. Reference [4] contains 

an overview of TCP and IP header fields usable for covert channels. The last filter 

is also responsible for limiting timing channels by forwarding incoming messages 

at regular intervals. The next chapter discusses the second filter. 

VII. A filter for delaying messages 

The second filter forwards and in some cases delays messages in an effort to 

minimize potential misuse of messages of legitimate format containing classified 

information hidden with steganographic mechanisms. While enforcing this security 

requirement, legitimate traffic needs to be delayed as little as possible. A simple 

version of such a filter limits the message rate by queuing them and forwarding 

them at fixed intervals. When the legitimate message rate is set, the expected rate 

in regular operation and the acceptable covert channel capacity have to be taken 

into account.


155 

Depending on the application more complex requirements can be enforced by 

the filter such as setting individual message rates for each message type depending on 

their expected rate. If different message types have varying size, the acceptable message 

rate can be replaced with an acceptable payload bit rate. As an example, we 

can assume that there are two message types, message type A has no parameters 

and message type B has a 10 bit parameter. Sending a type A message transmits 

1 bit, sending a type B message transmits 11 bits. If we assume a malicious sender 

in the enclave, this is the maximum amount of classified information that can be 

encoded in the messages themselves. We then define a bit counter which is increased 

according to the acceptable bit rate and decreased according to the covert 

channel capacity (CCcap) when a message is sent. If the counter would be reduced 

to less than zero, the message is delayed (Figure 4). We set a maximum value for 

the counter to prevent a burst of malicious messages following a long period 

of regular operation. This setting has to take the expected bursts in legitimate traffic 

into account. The bit counter and the filter queue are checked at regular intervals. 

If the bit counter value is sufficient for the first message in the queue, the message 

is forwarded and the bit counter is adjusted. 

Figure 4. Bit counter 

The advantage of applying a guard containing such a filter is the fact that we do 

not need to make assumptions about the validity of messages. We can just assume 

that each and every message may have been sent by an attacker using every bit to 

covertly send messages. Then we enforce a maximum data rate on this covert channel 

using the mechanisms above. No knowledge of steganographic mechanisms that 

may have been applied is necessary. This only works if the message rate in normal 

operation is low. If the message rate is high, we have the choice between two unacceptable 

scenarios. We either set a low acceptable covert channel data rate, which 

will dramatically slow down legitimate traffic or we set a high acceptable covert 

channel data rate and thereby give up on covert channel mitigation. 

Depending on data available to the guard additional filter rules can be enforced. 

If, for example, there is a known set of routers management messages are 

sent to, we can keep a list of legitimate IP addresses and block messages to other 

destinations. If the relevant data is static and provided by a trusted mechanism,


e.g. a protected configuration interface of the guard, it can be considered a configurable 

part of the first filter, the XML schema filter. 

VIII. Error handling, audit and other mechanisms 

We can install an anomaly detection mechanism to detect unusual sequences 

of messages. A sequence of messages switching a setting in a router back and forth 

or similar occurrences may be suspicious. In such cases an alarm can be raised. 

In order to prevent additional guard complexity we suggest that such a device is not 

integrated in the guard itself, but the guard and the anomaly detection mechanism 

are installed in sequence. Figure 5 shows the guard and the anomaly detection 

mechanism. 

Figure 5. Guard and additional mechanisms 

We assume that error messages and other logging data are sent from the components 

generating them to an audit component within the guard via unidirectional 

links (Figure 3). Only authorized administrators may access the component 

through a physically protected interface. This simplifies development by minimizing 

the information flow. 

Unidirectional flow of messages through the filter means that we cannot 

explicitly notify a sender, if an internal buffer is full. In order to prevent legitimate 

messages from being silently discarded, we can prepend an additional buffer to 

the filter. It is not part of the trusted guard device. This external buffer forwards 

messages to the filter at the same rate as the guard does. Unlike the buffer inside 

the guard it can notify senders when it is full. Figure 5 shows the position of the external 

buffer. 

IX. Interaction with cryptographic protection mechanisms 

In our example, network management, we assume that the management 

messages are not particularly confidential and may be sent in the clear. If we use 

a guard for filtering of encrypted messages, we assume that the guard has access 

to the decryption key. 

If messages are signed to prove their authenticity to the intended recipient 

in the transport network, we have to prevent subliminal channels – data hidden


157 

in the signature. This can be achieved through choice of signature algorithm. 

While for example DSA (Digital Signature Algorithm) allows the signer to choose 

a parameter influencing the signature, RSA signatures are deterministic which 

prevents a subliminal channel [6]. 

The text above discusses signatures used by applications to ensure integrity 

and authenticity. There are concepts in which a signature is applied to a message 

by a trusted device to label it as releasable. Then a guard releases the message 

if it has been signed by an authorized entity. These concepts are out of scope of this 

paper. The focus of this paper is on determining whether to release messages or not 

based on their content. A signature by the sender in the enclave is not considered 

sufficient for message release to the transport network in our scenario. 

X. A management proxy 

Minimizing the amount of legitimate messages passing the guard increases 

the difficulty of covertly passing classified information through them. If there are 

typical patterns in the messages that should pass, it can be helpful to install a proxy 

device in the transport network which expands messages to sets of messages. If, for 

example, a message has to be sent to all routers controlled by the administrator 

in the enclave, a single message can be sent to the proxy which instructs it to generate 

all these messages instead of generating all messages in the enclave. 

Depending on the application different “strategy” messages to the proxy and 

its reaction when receiving them can be defined before deploying the system. 

The reaction may be more complex than just forwarding the message to multiple 

recipients. The goal is to identify the information that needs to be transmitted to 

the transport network and send the least amount of bits necessary to represent 

this information. This way we can set the guard to a low allowed bit rate while 

maintaining functionality. 

In a scenario without flow of information from the TN to the CE installing 

such a proxy basically allows us to compress the messages from the CE to the TN. 

If, without a proxy, messages are also sent from the TN to the CE, it can be possible 

to reduce the number of messages passing through the guard in both directions. 

This is the case when the proxy can take care of message exchanges without further 

information from within the CE. If, for example, several devices report their status 

and receive an acknowledgement (ACK) in return (Figure 6), we can use a proxy. 

Instead of each status message passing the guard to the CE and each acknowledgement 

passing it to the TN, we can do each exchange between device and proxy 

within the TN and send one aggregated status message to the CE (Figure 7). In both 

figures “Guard” represents the whole set of mechanisms shown in Figure 5. 

For some applications such proxies may exist for efficiency reasons anyway. 

In that case we just have to choose where they should be placed to minimize 

cross domain traffic. For other applications proxies may not be considered


advantageous in general because of increased complexity, delay or other reasons. 

Here we can analyze whether the expected decrease in cross domain traffic is worth 

introducing a proxy or not. 

Figure 6. Information flow through a guard 

Figure 7. Information flow through a guard with proxy 

XI. Related work 

Several products for cross domain filtering exist. One application is controlling 

the settings of an integrated radio and crypto device which encrypts all user 

data before transmitting it. If a computer containing classified data is connected to 

the device, commands sent from the computer to the radio component, e.g. setting 

the frequency, have to bypass the encryption component. Filter products are available, 

which make sure that only specific commands may bypass it. 

There are also similar guard products for filtering IP network traffic crossing 

a boundary between two security domains. They use filters specific to protocol and 

application. Usually they offer customers to define filters according to their needs 

without mentioning details in promotional material.


159 

We are not aware of a common format to specify the desired behavior of a guard 

beyond definition of the message format for example by an XML schema language. 

We intend to look into ways to represent more complex requirements such as message 

rate dependent on message properties. 

XII. Summary and future work 

This paper examined how messages can be passed from a classified to an unclassified 

network in a CoNSIS network with minimal risk of leaking classified 

data. The introduction was followed by an overview of the CoNSIS architecture 

and general information on Multilevel Security. Then we described a guard for 

filtering data sent from a classified to an unclassified network for low message 

rate scenarios. It consists of a series of filters running on a separation kernel. 

Then we discussed effects of use of cryptographic protection of messages. This 

was followed by the concept of a proxy device in the unclassified network to 

limit the amount of messages having to pass the guard. Finally we provided some 

pointers to related work. 

Future work includes defining the behavior of a guard and a proxy with respect 

to a specific application such as a network management protocol. As mentioned 

in the related work section, choosing a clear representation of complex requirements 

regarding guard behavior is also a part of future work. 

References 

[1] J. Rushby, “The Design and Verification of Secure Systems,” in Eighth ACM Symposium 

on Operating System Principles (SOSP), Asilomar, CA, 1981. 

[2] L.J. La Padula and D.E. Bell, “Secure Computer Systems: A Mathematical Model,” 

The MITRE Corporation, Bedford, MA, USA, 1973. 

[3] CoNSIS, “System and Experimentation Architectures v1.0,” 2011. 

[4] S.J. Murdoch and S. Lewis, “Embedding Covert Channels into TCP/IP,” in Information 

Hiding: 7th International Workshop, volume 3727 of LNCS, Barcelona, Spain, Springer, 

2005. 

[5] B. Pfitzmann, “Information Hiding Terminology – Results of an Informal Plenary 

Meeting and Additional Proposals,” in Proceedings of the First International Workshop 

on Information Hiding, Springer-Verlag, 1996. 

[6] R. Anderson, Security Engineering: A Guide to Building Dependable Distributed 

Systems – 2nd ed., Wiley, 2008. 

[7] V. Gligor, “A Guide to Understanding Covert Channel Analysis of Trusted Systems,” 

National Security Agency, Ft. George G. Meade, MD, USA, 1993.

The CoNSIS Approaches to Network Management 

and Monitoring 

Christoph Barz 1 , Anne Diefenbach 1 , Fatih Abut 1 , 

Matthias Wilmes 1 , Peter Sevenich 1 , Pierre Simon 2 , Norbert Bret 2 

1 Communication Systems Group, Fraunhofer FKIE, Wachtberg, Germany, 

christoph.barz@fkie.fraunhofer.de 

2 Cogisys, Pertuis, France, pierre.simon@cogisys.fr 

Abstract: Secure information exchange is a key success factor for military operations. International 

coalition missions are especially challenging because of heterogeneous communication and C2IS 

equipment. The international project CoNSIS is targeted to fill in technical gaps regarding interoperability 

which occur in a reference scenario, consisting of a multinational convoy of military 

and non-governmental vehicles. The convoy forms an ad-hoc radio network and shares a common 

operational picture with an international headquarter mainly via a satellite link. This paper addresses 

network management challenges and technical solutions for this federated scenario. Both the core 

network interconnecting different national headquarters with an international headquarter as well 

as the ad-hoc radio network of the convoy are addressed in a single, seamless concept. In June 2012, 

field tests with the convoy were carried out in order to evaluate the different technical solutions. 

Keywords: network management; measurement architecture; federation; protected core networking; 

service level agreements 


CoNSIS – Coalition Networks for Secure Information Sharing – is an international 

project with France, Norway, Germany and the US currently participating. 

Based on the work done in INSC – Interoperable Networks for Secure Communications 

– it aims to work towards Network Enabled Capability (NEC). Heterogeneous 

networks from different nations are to be connected and form a federated 

environment in which to securely share information. CoNSIS concentrates on 

wireless networks in the tactical domain, but also considers deployed high speed 

networks as well as communication in-between. On the higher network layers, 

it places emphasis on a service-oriented architecture as stipulated in the NNEC 

Feasibility Study [1]. 

Work in CoNSIS is performed in five distinct groups. Task 1 is concerned 

with communication services. Task 2 is responsible for the integration of the SOA 

frameworks of the different nations. Task 3 is concerned with security, and task 4


with network management. Task 5 is responsible for the overall architecture and 

a field test scenario (see below) which serves as golden thread for all technical developments. 

The project concludes its first phase with the field tests in June 2012. 

This paper will concentrate on the work done in the network management task. 

The CoNSIS scenario as depicted in Figure 1 is set in a country torn by civil war. 

International coalition troops are deployed in the country to stabilize the situation, 

protect the population and initiate the peace process. Larger cities are controlled 

by coalition forces, but the situation outside the cities is still unstable. Convoys 

and advanced outposts are constantly at risk of attack. The coalition troops have 

established an international headquarter (HQ) which has fixed network connections 

to several national headquarters. There are also naval forces from different nations 

patrolling the waters around the conflict area. The naval vessels form a wireless 

ad-hoc network and are connected to the other forces via satellite. There is also 

a backup HF radio connection. 

In this situation, a natural disaster occurs in a part of the country not controlled 

by the coalition forces. The coalition decides to aid in disaster relief efforts 

by escorting the vehicles of a Non-Governmental humanitarian Organization 

(NGO) to the disaster site and secure the area. The military vehicles are connected 

by different broadband military radio technologies operating mainly in the UHF 

frequency spectrum, forming another ad-hoc network. As with the naval vessels, 

communication with the headquarters is ensured via satellite technology installed 

on a few specifically equipped vehicles. The NGO vehicles are also connected to 

the military convoy by terrestrial radio. Shortly after setting out, the convoy is joined 

by a second group of military vehicles from another nation. This group uses radios 

not compatible with the convoy’s, but a few vehicles in both groups have radios 

with compatible waveforms to bridge the communication between the two groups. 

Following a reorganization of the network in the wireless domain, they now form 

a comprehensive ad-hoc network. 

Figure 1. The CoNSIS network


163 

Making its way to the disaster area, the radio communication within the newly 

combined convoy is suddenly disrupted by a radio jammer. Satellite communication 

remains unaffected. The jamming is recognized, reported to the headquarters, and 

finally eliminated by an air strike. 

The remainder of this paper is organized as follows. Section II will introduce 

related work which has been incorporated in the CoNSIS management concept. 

Section III will on this basis describe the CoNSIS management concepts, while 

section IV and V detail the test setup and the network management experiments 

performed in the field test. 

II. Related work 

The CoNSIS reference model consists of a core network to which user domains 

are connected via IPsec crypto devices. The core network itself is composed 

of a number of interworking networks operated by different administrative authorities. 

Figure 2 shows the main elements of the CoNSIS architecture. 

Figure 2. Administrative Domains 

This architecture is close to the Protected Core Network (PCN) [2] approach. 

A. Protected Core Networking 

In the PCN concept, secure red networks are represented by the Coloured 

Clouds (CCs), while the unprotected black network represents the Protected 

Core. PCN now requires the existence of certain distinguished nodes, the E-nodes, 

in the black network, which ensure availability and offer reliable transport to the CCs. 

These routers may be clustered to Protected Core Segments (PCSs) which together 

form the PCN. There are certain functionalities like traffic concealment that are


associated with the E-nodes. In addition, the PCN concept defines interfaces between 

different PCS and between PCS and the Coloured Clouds. 

The CoNSIS network architecture is based on this concept, but the two reference 

models are not identical. In particular, CoNSIS administrative domains are 

not assumed to have exactly the same functions as PCSs regarding e.g. security 

protection and the management of SLAs. The administrative domains interwork via 

interfaces which are not supposed to have the same features as the PCS-1 interface. 

Likewise, the generic interface between CoNSIS user domains and the core network 

is not necessarily compliant with the PCS-2 interface. 

In order to reflect the above-mentioned divergence, objects of the CoNSIS 

reference model are given names intentionally different from their PCN counterparts 

(see Figure 3): 

• The core network (counterpart of the PCN protected core) is referred to 

as the Transport Network (TN). 

• The TN is a collection of interworking Transport Network Segments 

(TNS) (counterpart of PCSs), each TNS being defined as a set of network 

elements under a single administrative authority. A segment administered 

by a national authority is referred to as an N-TNS while a segment administered 

by the coalition is a C-TNS. 

• User domains are referred to as Coloured Enclaves (CE) (counterparts 

of coloured clouds), separated from the TNS by IPSec. A CE can be embedded 

within another CE; in that case it is called an Inner Coloured 

Enclave (ICE). 

Figure 3. Network Segments and Colored Enclaves


165 

B. Federated sharing of management data 

The TN with its individually-administered TNSs poses a challenge to management 

because there is no single authority to determine how, where and when the network 

should be monitored, and some nations may hesitate to reveal their network structure. 

This situation is similar to civil federated networks, such as research networks administered 

by different organizations. For these, there is a monitoring framework available. 

PerfSONAR [3] is a network performance monitoring framework that is developed 

by an international consortium from the research and education community. 

GÉANT (Europe), ESnet, Internet 2 (USA) and RNP (Brazil) offer their customers 

advanced inter-domain QoS services. Delivering end-to-end QoS in a hierarchical 

multi-provider structure results in challenges similar to the ones occurring in a coalition 

network. The perfSONAR framework is an infrastructure for network performance 

monitoring, making it easier to solve end-to-end performance problems on 

paths crossing several networks. 

PerfSONAR uses a service-oriented architecture. The SOAP and XML based 

messages between the different service types are standardized by the Network Measurement 

Working Group of the Open Grid Forum. There is already a variety of service 

implementations available. In addition, the open, standardized interfaces allow for 

an integration of additional measurement tools, including existing solutions like 

Cacti [12]. PerfSONAR is already deployed at many National Research and Education 

Networks (NREN) around the world. 

The PerfSONAR multi-domain monitoring (MDM) service allows crossdomain 

performance monitoring with standardized metrics. The perfSONAR 

infrastructure consists of a User Interface Layer, a Web Service Layer, and a Measurement 

Layer. There are already several visualization tool implementations that are 

designed for different scenarios. At the Service Layer, the following Web services 

have been implemented: 

• Lookup WS – allows the discovery of available services and information 

sources 

• Authentication WS – provides authentication for clients and protects 

privacy 

• Measurement Archive WS – is a family of WS that allow access to measurement 

data from different sources (e.g. databases, files, etc.) 

• Measurement Point WS – allows integration of measurement tools and 

publishing the collected data in Measurement Archives 

Depending on the measurement tools used, packet based measurements with 

IPv4, IPv6 and different QoS configurations are supported. In addition to the WS 

presented above, a Transformation WS has been defined but not implemented yet. 

For further information, a compact survey of the perfSONAR features is presented 

in [4]. An overview of the perfSONAR architecture can be found in [5] and [7].


III. CoNSIS management concepts 

As mentioned in section II.B, the concept of a Transport Network consisting 

of Transport Network Segments which are managed under the administrative authority 

of different countries can be conceived as a multi-provider network. In general, 

the challenges of delivering end-to-end inter-provider QoS that were addressed 

in the network research community (e.g. [8]) also apply to the context of coalition 

networks. In addition to the standard information hiding requirements of network 

providers, special security considerations regarding the Coloured Enclaves have to 

be addressed when sharing monitoring data and managing the Transport Network 

Segments for military use. The general challenges that were identified in [8] are: 

• Common service definitions for all administrative domains 

• Common performance metrics to support end-to-end SLAs 

Common service definitions are already addressed by CoNSIS task 1 in [11] 

(DSCP/Application Requirements). Without this standardisation a meaningful 

end-to-end service is hard to obtain. 

Common performance metrics must be used if performance information 

needs to be concatenated across the different providers. This does not only include 

the definition of the metrics themselves, but also the definition of common aggregation 

periods for samples and the use of reference times. Concatenation of measurements 

of different network segments enables a scalable approach to the control 

of end-to-end SLAs. This can be achieved by sectioning the network into multiple 

measurement segments, allowing the reuse of these measurements for different 

end-to-end paths. Note that the segmentation of the Transport Network already 

induces measurement segments. A framework for the concatenation of performance 

metrics [13][14] has been under development by the IETF. 

Multi-provider/multi-segment QoS paths result in the need for mechanisms 

to allocate budgets for different network impairments (e.g. delay, jitter, …) that are 

defined on an end-to-end basis along the path to the different network segments 

which are separate administrative domains. Here, approaches include a static, 

a dynamic and a hybrid allocation of the acceptable end-to-end impairments. 

In the static approach, the maximum number of Transport Network Segments 

could be assumed in the path. The impairments are then equally distributed between 

these segments. However, this approach is less efficient and may rule out 

possible inter-TNS paths. The dynamic negotiation approach is most efficient but 

requires signalling between the TNSs. In the hybrid approach, all impairments 

are shared equally only with segments on the path. Thus, it does not support 

situations in which only an unequal distribution of impairments would result 

in an acceptable SLA. 

This leads to the discussion of provider/segment interconnection models for 

dynamic QoS negotiation. Here, a hierarchical third party model (e.g. realized by 

the NATO in the form of NATO service classes) can be envisioned, as well as a co-


167 

operative model. To respect the autonomy of the different countries managing 

the Transport Network Segments as well as for resilience reasons, the distributed 

cooperative negotiation model in combination with a centralized definition of common 

service classes and performance metrics seems to be the most appropriate 

solution. In addition, a distributed approach may be more resilient to outages. 

Here, knowledge of the E-Node topology might be beneficial for assessing the endto-end 

connectivity and for finding an impairment allocation. 

A similar challenge may arise within Transport TNSs if they are also organized 

as overlay networks. Links between E-Nodes may be realized by several lower layer 

links by one or more independent providers. If these providers do not offer common 

NATO service classes the next better national service classes have to be chosen. 

As described in section II, the management and monitoring architecture 

is defined for coalition networks on the basis of TNSs and Technical Management 

Areas (TMAs) within the TNSs. As depicted in the following sections, the concept 

comprises three different interfaces related to monitoring (see Figure 4). Other 

management interfaces regarding configuration management are still to be defined 

in detail. However, Figure 5 and the description MI 4 and MI 5 provide first suggestions 

regarding a configuration architecture. 

Figure 4. Refined Performance Monitoring Architecture 

MI 1: The network monitoring interface MI 1 specifies the communication 

between measurement points and measurement archives and is national concern.


It might be either based on standard network management protocols like SNMP, 

a proprietary solution or based on a standardized Web service interface. The latter 

case should be preferred. For existing tools a wrapper to encapsulate implementation 

specific communication has to be implemented. 

MI 2 is used to transport monitoring information from measurement archives 

in the TMAs to the corresponding measurement archives in the national 

CEs. A transformation service can be used to transform raw measurement data 

into a format that can be shared between the different CEs. Task 3 will provide 

the transfer channel for the national monitoring data. Ways to accomplish this 

without compromising the confidentiality of red data are discussed in [6]. 

MI 3 specifies the communication for distributing measurement and monitoring 

information between the CEs. A lookup service is responsible for advertising 

available measurements and to make the results available to search queries. The service 

will be based on SOA. Details of the monitoring Web service definitions will 

be part of a task 2 document. Task 2 is responsible to provide the monitoring UI. 

Figure 5. SLA Negotiation and Configuration Architecture 

MI 4 specifies an SLA negotiation/agreement interface between an Overall 

Coalition Manager and the different TNS Managers. This multi-domain QoS negotiation 

mechanism will work via bilateral communication between the Overall 

Coalition Manager and the Local TNS Managers. The communication resources 

are under the authority of the local TNS Managers which act as a “management 

decision point”. [9] presents a similar approach. 

MI 5 specifies a configuration interface between the local TNS Managers and 

the Technical Management Areas under their administration. It is assumed that 

each TMA has special configuration management tools that might be proprietary. 

The TNS Manager will act as “management enforcement points”. MI 5 should 

comprise high level technology agnostic configuration commands that need to be


169 

translated into a technology specific configuration by the appropriate configuration 

management tools. 

IV. CoNSIS field test setup 

Experimentation in CoNSIS has a strong focus on the mobile part of the network, 

i.e. the convoy. It consists of three parts: NGO vehicles, Norwegian military 

vehicles (the original convoy), and German military vehicles (which join the convoy 

in phase 2). The German vehicles use three different types of radio, HiMoNN (IABG), 

FlexNet-4 (Rockwell Collins) and Harris radios. The Norwegian part uses Kongsberg 

WM600 radios and the NGOs commercial WLAN. None of these radio types are 

interoperable, which is why one Kongsberg radio is passed to the German convoy 

and one FlexNet-4 to the Norwegian one. In addition, at least one German and 

one Norwegian vehicle have a satellite connection. All UHF military radios in our 

scenario perform ad-hoc routing within their technology domain, which normally 

cannot be deactivated and provides no information about the internal topology. 

In addition, multi topology routing is not supported so far. Thus, these incompatible 

technologies need to be tied together in an overlay network with multi topology 

routing [10] support to cope for the heterogeneity of the different technologies. To 

overcome these limitations, a liaison with COALWND, the interoperable coalition 

wideband networking waveform for military radios under development, is planned 

to eliminate the need for a second layer of routing. 

Jammer detection is usually done by dedicated, strategically placed units. 

In CoNSIS, there is an experimental option of the jammed systems doing the detection 

themselves. To detect a jamming incident locally, information from different 

network layers must be correlated, which requires a cross-layer information 

architecture. Besides reporting the incident to the international headquarter, local 

measures may be taken to circumvent the jamming, such as changing frequency 

or modulation or reconfiguring the routing. 

V. CoNSIS management experiments 

Not all of the concepts described above can be realized in the CoNSIS field test. 

However, there are several experiments which will lay the foundations and serve 

as proof-of-concept: 

A. Core network experiments 

1) MA-Basic: Maintain a common network picture 

Purpose: Show how monitoring information can be shared between the HQs 

of the different nations regarding the network state within the different non-mobile


ASs and on the inter-ASs links/tunnels. The experiment helps to identify problems 

within the TNSs and the inter-TNS links. 

Test setup: PerfSONAR measurement archives collecting SNMP information 

from core TNS routers within each AS are installed as depicted in Figure 6. 

Figure 6. PerfSONAR SNMP Interface Statistic Queries 

In addition, measurement archives collecting Iperf and OWAMP measurements 

from the inter-TNS links are installed. The information will be 

archived so the experiment also supports an offline analysis also regarding 

other experiments. 

Walkthrough: Deployment and activation of the service is performed 

prior to the experiment. All nations can access the information via a Web based 

client during the whole experiment. All information is stored in local measurement 

archives. If necessary, measurement archives have to be cleared before 

the experimentation so there is be enough storage capacity. In regular intervals 

the archives were backed up. 

Prerequisites and special requirements: For autonomy reasons, PerfSONAR 

Measurement Archives (and a Lookup Service) were installed in every AS participating 

in the measurements (see Figure 7). Participating nations set up one 

or more virtual machines. In addition, an NTP server was needed to synchronize 

the measurements.


171 

Findings: Sharing monitoring data between the different TNSs worked well 

in general. The performance of intra- and inter-TNS links in the non-mobile 

part of the network was accessible. Some performance issues querying data from 

within the US TNS will be analyzed as future work. 

Figure 7. PerfSONAR Measurement Metadata Exchange 

2) MA-SOA: Provide access to PerfSONAR data via the SOA architecture 

Purpose: Access to OWAMP data stored by PerfSONAR in a MA via 

a standard Web service as utilized in the CoNSIS SOA architecture. One application 

is the provision of data for generating technical profiles (see experiment 

4) in this section). 

Test setup: A SOA service acts as consumer to the PerfSONAR OWAMP 

measurement archives of the different nations. In turn, it offers access to the latest 

packet loss rate in a queried TNS for a queried class of service. 

One particular client application that uses the data is the technical profile 

process in one or several TNSs. The communication is based on SOAP messages 

(standard Web service). 

Walkthrough: The client process queries the information needed to generate 

a technical profile from the SOA service. This will be packet loss rates on various 

links and tunnels. The SOA service determines the archives holding the relevant


information and retrieves the data. The retrieved data is processed and the packet 

loss rate is forwarded to the client. 

Prerequisites and special requirements: The SOA service needs to be available 

in the TNS part of the network (not in the CEs). It does not use WS-Discovery 

but is statically configured. 

3) Measurement Probes: Assess the usability and trustworthiness 

of various measurement probes 

Purpose: Determine how and to what extent software probes can be used 

in a tactical network to provide measurement information. 

Because they require in-depth investigation and comprehensive procedures, 

tests of this series were actually performed before the field experimentations described 

in this article, but on the same testbed and with the same technical means. 

They paved the way for the use of appropriate measurement tools during the field 

tests themselves. 

Test setup: A broad array of measurement tools were tested, including Iperf, 

Internet2 OWAMP and Cisco IP SLAs which turned out to be the best ones. 

Software probes have a special interest in a tactical environment for the obvious 

reason that they do not imply additional hardware and thus have no detrimental 

effect on the compactness of deployed assets. Conversely, they have the downside 

of providing results with a lower precision, and of requiring active test flows 

(i.e. specific measurement packets) which may be a source of overhead. 

The precision and trustworthiness of software probes was assessed whenever 

needed by comparing the results they supply with those provided by hardware 

measurement tools such as Smartbit or Ipanema whose performances in terms 

of accuracy are acknowledged. 

Findings: The major lessons learnt through the tests concern the precautions 

a network operator should take when using software probes, the precision 

that can be expected in measurements, and the consistency of results supplied by 

probes of different types. 

Overall, all three above-mentioned software tools proved to be usable and 

to provide valuable information as long as they are operated in an appropriate 

environment and within their normal range. It was indeed an important discovery 

that each measurement probe has a range (e.g. of data rates, of number of packets 

per second) within which it will work properly, but beyond which it may supply 

erroneous, incomplete or inconsistent data. The recommendation is thus that 

a network operator should only use measurement devices whose range of valid 

operation has been duly tested prior to deployment. 

It was also shown that, with appropriate procedures, the overhead due to active 

measurement flows could be kept under control and remains marginal as compared 

to user traffic, even in a narrow-bandwidth network.


173 

Finally, special care must be taken when conducting active measurements 

in IP systems which implement such mechanisms as weighted fair queuing (WFQ). 

As WFQ creates a dissymmetry in the treatment of flows even if they belong to 

the same class of service, it may result in active test flows experiencing a different 

quality of service than the user flows they are intended to represent, and thus lead 

to erroneous conclusions in network performance monitoring. This is but one more 

illustration of the well known principle that measurements cannot be performed 

in total ignorance of the system they apply to. 

Another important finding is that a given probe will provide results which 

are consistent with themselves, but not always as consistent with those of other 

probes. For example, Internet2 OWAMP used in two different segments of a network 

will indicate jitter values which can directly be compared together, and so 

will Iperf, but the measurements supplied by the two tools may not be consistent 

with one another. This bias which may exist between two different probes is no 

serious hindrance per se since a theoretical study leads to the conclusion that 

high precision in the measurements conducted in an IP network is not needed 

and should not be sought. However, when comparisons are made between measured 

values within a network, or when measurements are composed in space or 

in time, the same type of tool should be used throughout the system. PerfSO- 

NAR and its message format provides the means to distinguish measurements 

of different tools. 

4) Technical Profiles: Use measurement results to automatically update 

the description of network capabilities 

Purpose: A technical profile is a data set which describes the current capabilities 

of a TNS (e.g. the quality of service it is able to support, whether it is subject to 

sudden major alterations due to e.g. high mobility, jamming). This data set is intended 

to be communicated to users or adjacent networks so they will optimize 

the way they use the services of the relevant TNS. 

Technical profiles were studied under the task 1 of CoNSIS (communication 

services), but an important aspect of their definition is that they should be kept 

up to date automatically so as to actually reflect the current transport conditions 

prevailing in a TNS. One essential way to update a technical profile is of course to 

use the results of measurements conducted according to the methods and procedures 

recommended by task 4. 

Test setup: Host A is a Web server, host B is a web client. They are located 

in two different colored enclaves respectively connected to TNS 1 and TNS 4. 

The technical profiles of these two TNSs are held by their respective Network 

Management Systems (NMSs). They are kept up to date thanks to measurements 

periodically performed by probes deployed throughout the two networks.


Figure 8. Technical profile repositories and user systems which will use these technical profiles 

Walkthrough: When technical profile mechanisms are not enabled and when 

traffic conditions in TNS 4 are adverse, it takes an unacceptable time for host B to 

download a HTML page from host A. 

When technical profile mechanisms are enabled, measurements permanently 

conducted in all TNSs allow the detection of a degradation of transport conditions 

(in this case a high packet loss rate in TNS 4), and this situation is reflected 

in the relevant technical profiles. 

Whenever it receives a request from host B, host A first determines which 

TNSs will be traversed by the data flow it is about to send to the Web client. Then 

it fetches the technical profiles of TNSs 1 and 4 and composes them to find out that 

the path will be affected by a high packet loss rate. 

Knowing this information, it decides to send to host B a HTML page with 

skimmed contents (i.e. with lower-resolution pictures). The time it takes for host B 

to download the page returns to an acceptable value. 

At the end of this test, the best compromise has been automatically discovered 

to ensure end-to-end quality of service in the presence of degraded transport 

conditions detected through measurements. 

Prerequisites and special requirements: Interface MI 2, as described in section 

III of this article, is required to convey to the colored domain information 

pertinent to the black networks.


175 

D. Experiments regarding the convoy 

1) SNMP-Mob: Extend the common operational picture to the convoy 

– SNMP 

Purpose: Collect SNMP-based information from the mobile domain. 

Test setup: A PerfSONAR SNMP measurement archive is installed on the border 

router of the mobile domain. Data about interface/tunnel statistics is requested 

from the mobile MTR routers that have a direct SAT connection to the border 

router of the mobile domain. 

Figure 9. SNMP Interface Statistics Queries in the Wireless Domain 

Walkthrough: Periodic queries via SNMP from the measurement archive 

co-located with the border router of the mobile domain are performed. This data 

can be accessed via the PerfSONAR framework. 

Prerequisites and special requirements: SNMP data is fetched remotely 

via the satellite links. This has to be taken into account by experiments related to 

the convoy part of the network. The impact on the satellite links is supposed to be 

not relevant. 

Findings: Throughput from the mobile domain was extracted without overloading 

the mobile links. Because of the full mesh of overlay tunnels for every radio 

technology, it was even possible to identify traffic to/from different nodes just using 

interface statistics. The results also clearly showed when nodes were isolated. 

Follow-up measurement samples need to be interpreted accordingly. However, 

identifying the cause (limited transmission range vs. jamming) will only be possible 

by correlating this data with cross layer information like the noise level.


2) OSPF-Topo: Monitoring of the OSPF topology of the mobile domain 

Purpose: Providing real time information about the communication status 

and connectivity within the convoy with minimal/no communication overhead 

to the mobile components OSPF domain. This includes the terrestrial radio links 

as well as the satellite links to the HQ. 

Test setup: The OSPFv2 MIB of the non-mobile MTR located at the Multi 

National Deployed HQ is queried via SNMP by a software tool running also 

in the HQ. The OSPFv3 MIB is not yet supported by the MTR implementation 

based on Vyatta Linux. The information provided consists of a snapshot of the Links 

State Database of the MTR and thus provides a local view of the OSPFv2 topology 

of the mobile domain. 

Walkthrough: The OSPFv2 Link State Information was shown on a computer 

located at the Multi National Deployed HQ and continuously provided information 

regarding the communication status of the convoy to the other experiments. 

In addition, a packet capturing process was started at the MTR in the HQ to 

allow for an offline analysis of the Routing Protocol behavior (OSPFv2 and OSPFv3) 

in the post processing of the experiments. 

Prerequisites and special requirements: Remote access to the MTR is needed. 

3) Jammer-Basic: Cooperative detection of the jammer 

Purpose: Show that the detection of a jammer is possible within the convoy 

with cross-layer information aggregation of data from the radios. 

Test setup: A cross-layer framework called CRAWLER [15][16] was installed 

on two dedicated routers equipped with WIFI cards. One of the nodes was located 

in a German military vehicle. The other node is located at an NGO vehicle. 

Walkthrough: The CRAWLER framework needed to be installed and configured 

on both ends of the communication. The connection between the German 

military vehicle and the German NGO vehicle was established. Special jamming 

equipment was placed between both nodes. In addition, plausibility checks 

of cross-layer information were performed via the CRAWLER framework. Thus, 

the presence of a possible jamming incident was detected based on this local information. 

Prerequisites and special requirements: Jamming equipment for WIFI 

as well as a military and an NGO vehicle equipped with WIFI devices connected 

to the black part of the network and as well as the CRAWLER service. No dynamic 

routing was performed on this link.


177 

4) Jammer-Notification: Automated notification of the HQ by the 

CRAWLER application via the Operational Message Service (OMS) 

Purpose: Provided by task 2, the Operational Message Service (OMS) is a notification-based 

service intended to distribute commands, information, warnings 

and alerts. By using the OMS to raise the alarm about a suspected jamming incident, 

two purposes are answered: One, the OMS is notification-enabled and allows any 

interested party to subscribe to the alerts, without the necessity of setting up any new 

information structures or configurations; and two, it is a good example of a taskcomprehensive 

test. Note: Since the OMS provider and the notification broker 

are located in the red network and CRAWLER in the black, a cross domain guard 

was needed to allow for a controlled forwarding of the message. 

Test setup: The CRAWLER application includes a WS-Notification client 

with a publish method set up for the Operational Message Service to send an alert 

about a detected potential jamming attack to a WS-Notification broker. The German 

portable Command and Control Information System (C2IS) subscribed to 

alerts of this kind and was capable of displaying the jamming incident at the geographic 

location in the GUI. 

Walkthrough: Upon the detection of a potential jamming incident an alert 

was sent via Operational Message Service. Subscribers, namely the German portable 

C2IS system, received the alert and processed it. The content eas displayed 

in the C2IS GUI. 

VI. Conclusions and future work 

In this paper, we introduce both challenges and technical solutions for federated 

network management with special requirements regarding security and information 

hiding, as well as addressing the wireless and core domains. Building on the Protected 

Core Networking concept, we showed how a well established framework 

PerfSONAR for sharing network performance measurements between different 

research networks can be extended and applied to the CoNSIS scenario. In addition, 

we presented the first prototype of an architecture that can use the performance 

measurements to adjust SLAs between the different nations of the coalition. 

The paper concludes with details about the experiments performed within 

the CoNSIS field tests. These tests lay the foundations and serve as proof-ofconcept. 

The results will set the agenda for the second phase of the CoNSIS project. 


This work has been performed within the CoNSIS project.


References 

[1] NATO Network Enabled Capability Feasibility Study Executive Summary v. 2.0, 

October 2005. 

[2] G. Hallingstad and S. Oudkerk, “Protected core networking: an architectural 

approach to secure and flexible communications”, Communications Magazine, IEEE, 

2008, 46, pp. 35-41. 

[3] PerfSONAR Homepage (last accessed May 24, 2012). 

[4] perfSONAR MDM release 3.0 – Product Brief. 

[5] Instantiating a Global Network Measurement Framework http://acs.lbl.gov/~tierney/ 

papers/perfsonar-LBNL-report.pdf. 

[6] P. Steinmetz, “Use of Cross Domain Guards for CoNSIS network management“, 

MCC 2012, Gdansk, Poland, in press. 

[7] PerfSONAR: A Service Oriented Architecture for Multi-domain Network Monitoring. 

[8] P. Jacobs and B. Davie, “Technical challenges in the delivery of interprovider QoS”, 

Communication Magazine, IEEE, vol. 43, no. 6, 2005, pp. 112-118. 

[9] D. Duda et al., “The QoS Policy Agreement System for Federation of Communications 

and Information Systems”, MCC 2011, Amsterdam, The Netherlands, Oct. 2011. 

[10] M. Hauge, M.A. Brose, J. Sander, and J. Andersson, “Multi-topology routing 

for improved network resource utilization in mobile tactical networks,” Military 

Communications Conference, 2010 – MILCOM 2010, pp. 2223-2228, Oct. 31 2010- 

Nov. 3 2010. 

[11] M. Hauge, CoNSIS Task 1, “QoS-classes for the CoNSIS test and demonstration 

architecture”. 

[12] “Cacti – The Complete RRDTool-based Graphing Solution”, http://www.cacti.net/ 

(last accessed June 13, 2012). 

[13] A. Morton and S. Van den Berghe, “Framework for Metric Composition”, December 

2009, . 

[14] A. Morton and E.Stephan, “Spacial Composition of Metrics”, IETF-RFC6049 

January 2011. 

[15] I. Aktas, J. Otten, F. Schmidt, and K. Wehrle, “Towards a Flexible and Versatile 

Cross-Layer-Coordination Architecture,” Proceedings of the 29th International 

Conference on Computer Communications (INFOCOM 2010), pp. 1-5, March 2010. 

[16] I. Aktas, F. Schmidt, M.H. Alizai, T. Drüner, and K. Wehrle, “CRAWLER: 

An Experimentation Architecture for System Monitoring and Cross-Layer- 

Coordination,” Proceedings of the 13th International Symposium on a World 

of Wireless, Mobile and MultimediaNetworks (WoWMoM ’12), pp. 1-9, June 2012, 

in press.

Multi-Topology Routing for QoS Support 

in the CoNSIS Convoy MANET 

Mariann Hauge 1 , Jon Andersson 2 , Margrete A. Brose 1 , Jostein Sander 1 

1 Norwegian Defence Research Establishment (FFI), Kjeller, Norway, 

{Mariann.Hauge, Margrete-Allern.Brose, Jostein.Sander}@ffi.no 

2 Thales Norway AS, Oslo, Norway, Jon.Andersson@thalesgroup.com 

Abstract: This paper shows how Multi-Topology (MT) routing is used to maintain three different 

network topologies in the heterogeneous land mobile network architecture used in the Coalition 

Network for Secure Information Sharing (CoNSIS) project. The topologies are each associated with 

one or more quality of service (QoS) classes to provide differentiated QoS in this disadvantaged grid. 

A proposal for how to connect a Multi-Topology routing protocol to adjacent Single-Topology (ST) 

interior gateway protocols and exterior gateway protocols is also given. 

Keywords: multi-topology routing; QoS; admission control; MANET; OSPF; IPv6) 


In a coalition operation the participating nations will typically bring their 

national radio equipment into the theater. Usually the equipment will comprise 

of a wide selection of brands and technologies, depicting the normally long lifetime 

of radio systems. These radios will most likely not be compatible on the air, 

and if they are, they will not have compatible security solutions, management or 

services for the end user. The main goal of the multinational Coalition Network 

for Secure Information Sharing (CoNSIS) project is to solve these interoperability 

issues. CoNSIS proposes solutions to improve interoperability in all the above 

mentioned areas. This paper presents the Multi-Topology routing concept as used 

by CoNSIS to provide differentiated QoS in the land mobile network that utilizes 

many different transmission technologies for internal communication as well 

as reach-back to the deployed headquarters. 

To provide a reliable network for different operation types and in varying 

terrains, a tactical mobile network infrastructure must consist of a variety of wireless 

network types, e.g., long-range communication for reach-back connections 

The authors have copy right of all figures in the paper “Multi-Topology Routing for QoS Support in the CoNSIS 

Convoy MANET”.


and a higher bandwidth network for local communication. A single transmission 

technology, e.g. a VHF network, will not be able to support all communication 

types and bandwidth requirements. In CoNSIS we assume that the different nations 

participating in a coalition operation bring their national tactical networks 

to the battlefield. Thus there may be a large number of different, non-compatible 

radio systems present in the mission network. The aim of CoNSIS is to be able to 

combine all available radio systems in an operation to provide an efficient, common 

network for coalition use. This gives the operator a single entry point to the complete 

heterogeneous coalition network, the network will be better utilized, and 

multiple transmission technologies and routing paths will also improve the network 

reliability by providing alternative routing paths during e.g. jamming attempts. 

The resulting coalition network will consist of radios which have large variations 

in capabilities and transmission range. Thus it is challenging to administer, admit, 

and route traffic flows in these networks. 

In a mobile tactical network there will in most cases be limited capacity. It is 

therefore crucial to support prioritization of operation critical traffic. It is also 

desirable to use the tactical network in the most optimal manner and thus make 

sure that only traffic that has a high chance of reaching the destination is admitted 

into the network. One way to increase the network throughput is to take advantage 

of parallel paths in the heterogeneous network and efficiently exploit all 

bandwidth resources. 

Since the transmission means used in tactical networks have large variations 

in capabilities, CoNSIS find it advantageous to define multiple routing topologies 

in the network to support different QoS-classes. These topologies are then used 

to ensure that data packets are only forwarded on topologies with sufficient capabilities 

to support the requirements of the dataflow. We combine Multi-Topology 

(MT) routing [1-2] and traditional DiffServ-like [3-4] mechanisms to utilize all 

available transmission means in the tactical network and increase the robustness 

of the network. In [5] we have presented our findings when using this technique 

on an isolated test bed network in our lab. The QoS architecture with MT support 

has also been utilized by the Web services admission control broker in [6]. The SW 

for the MT-router has been extensively modified for the CoNSIS project, and in this 

paper we describe how this solution is used in the land mobile CoNSIS network 

and how we have solved the interaction between a network running MT-routing 

and adjacent networks running non-MT capable domains. 

The rest of the paper is organized as follows: In Section II we give a brief 

background presenting the CoNSIS project. We point the reader to related work 

in Section III. In Section IV we describe the Multi-Topology routing solution 

and the mechanisms proposed to connect a Multi-Topology routing domain with 

a Single-Topology routing domain. The QoS architecture is explained in Section V. 

In Section VI we discuss the use of MT in the land mobile network in the CoNSIS 

network architecture, and finally we give a short conclusion in Section VII.


181 


As stated in the CoNSIS memorandum of understanding (MoU): “The objective 

of the project is to design, implement, test and demonstrate technologies, methods 

and architectures for the secure sharing of information and services between 

nations in ad-hoc coalitions, and between military systems and civil systems for 

Civilian Military Cooperation, e.g. with Non-Governmental Organizations (NGOs), 

within the communications constraints of mobile tactical forces.” 

The work is organized in five tasks: 

• Task 1, Communication Services 

• Task 2, Information and Integration Services (SOA) 

• Task 3, Security 

• Task 4, Management 

• Task 5, Architecture, Test and Demonstration Coordination 

The technique described in this article represents some of the work that 

has been performed in Task 1, Communication Services. In this task our concern 

has been to provide a transparent network and information infrastructure 

(NII), based on and harmonized with IP technology. The focus of this task is to 

demonstrate solutions that will work within the communications constraints and 

dynamic topology imposed by the highly mobile tactical networks. The proposed 

mechanisms should support IPv6. 

All figures and information presented in the remainder of this document 

focuses on the challenges as seen by the Communication Services task. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 1. This figure shows all network elements that participate in the CoNSIS scenario. 

N/C-TNS stand for National/Coalition-Transport Network Segment


CoNSIS has defined a scenario that takes place in a country torn by civil war. 

An international coalition is involved in this conflict to protect civilians and initiate 

the peace process. The coalition has a land based component, a naval component and 

an air based component. Fig. 1 shows all elements that is included in the CoNSIS 

network architecture and participates in the scenario. 

Task 1 has proposed to use Multi-Topology routing to provide some admission 

control and differentiated services in the land mobile network component in Fig. 1. 

This network segment will be connected to the other segments (including the Multi 

National Deployed HQ) via an exterior gateway protocol. In the CoNSIS scenario 

the land mobile component represents a military convoy that is tasked to escort 

a group of NGO vehicles to an area where there has been a natural disaster. This 

convoy will be played in the ongoing CoNSIS field test. The network deployment 

planned for the convoy in the field test will be used to exemplify the use of MT 

routing in CoNSIS. 

III. Related work 

During the last 10 years a lot of research has been done to achieve predictable 

QoS in mobile ad hoc networks (MANET). This is a difficult task due to the agile 

changes in the network topology, and the fluctuating channel quality in such 

networks. Much focus has been put in the area of QoS-routing. QoS-routing aims 

to find a route which provides the required service quality for a specific traffic type. 

This can be done using routing metrics based on parameters like delay, data rate, 

signal to noise ratio, route stability, etc. These protocols must be combined with 

a resource manager and a traffic classifier (e.g., DiffServ-like classification) to support 

end-to-end QoS in the network. Two survey papers [7-8] give a comprehensive 

overview of many of the available QoS-routing proposals. 

Most of the QoS protocols covered in the two survey papers discover a single 

path that supports a certain QoS requirement. This QoS requirement can be 

described by one parameter (e.g., maximum bottle neck data rate), or by several 

parameters (e.g., maximum bottle neck data rate and lowest end-to-end delay). 

Some protocols also maintain multiple paths to the destination for the purpose 

of e.g., load balancing, fault tolerance, higher aggregated bandwidth and reduced 

route discovery latency after link breaks. In [9] important multipath protocols 

are covered. In [10-13] multipath is established explicitly for QoS support. Some 

of these also make a point of combining DiffServ and multipath routing. 

However, most of the QoS-routing schemes, and all the mentioned multipath 

protocols are reactive routing protocols. We believe proactive protocols will be 

necessary in tactical MANETs to reduce the routing response time and increase 

the predictability of the network availability. We also think it is beneficial to store 

several routes with different characteristics to support separate QoS requirements.


183 

This is important for a heterogeneous wireless network that is established with 

radios that utilize different transmission technologies. 

The MT supported QoS architecture is based on the proposal presented 

in [14] and further studied in [5]. It is a simple but powerful scheme with 

a proactive routing protocol that maintains multiple topologies in the routing 

domain and consequently provides multiple paths from source to destination. 

Each topology/path is associated with a single or multiple QoS-class(es). Similar 

ideas (based on a very different routing scheme) are presented in [15]. In this 

reference, network information is maintained proactively, and different paths 

for the required QoS-classes can be calculated with different metrics based on 

a single routing database. 

In [16] MT-routing is combined with a dynamic topology and traffic pattern 

analysis tool to provide a flexible load balancing solution and in [17] MT-routing 

is utilized in a satellite network both for fault tolerance and for traffic separation 

of traffic having different QoS requirements. Both of these papers exploit a similar 

technique as the one presented in this paper however our focus is to support 

admission control and efficient resource utilization in a very heterogeneous 

military mobile ad hoc network. 

IV. Multi-Topology routing architecture 

A. Multi-Topology routing 

A traditional link state routing protocol maintains one routing table with 

one entry for “the best route” to all destinations in a network domain (or several 

of the best routes for load balancing purposes). The best route is calculated based 

on the chosen metric (e.g., shortest path first (SPF) or lowest cost, where the cost 

parameter can be established based on any set of link parameters). 

A Multi-Topology routing (MT-routing) protocol maintains several topologies 

within the network domain at the cost of a few extra bytes in the routing packets. 

Each topology spans a subset of the physical topology. A shortest path first calculation 

(other metrics can be used if available) is performed for each topology 

to discover the best routes within the topology. The cost of one link can be set 

different for the different topologies. Only the links belonging to the actual topology 

are included in the calculation. The results of the SPF calculation are stored 

in one forwarding table for each topology. In Fig. 1 we show a network where three 

topologies are defined on the physical topology. A number of topologies can be 

defined on a single physical link. All the physical links in the domain must be part 

of the default topology. The default topology is used for routing traffic and ensures 

that routing information is flooded to the whole network. All link advertisements 

are stored in a link state database. The calculation of the forwarding table for each 

topology is based on the information in this database.


Figure 2. This figure shows a network with three different topologies 

During network configuration, topologies can be tailored to represent many 

different purposes. MT is used for the following cases in CoNSIS: 

• Topologies can be created that has sufficient (maximum) resources to support 

a certain QoS-class, or multiple QoS-classes. 

• A specific topology can be created to be used for transit traffic through 

the network. 

MT-routing is a very useful tool that can be used to solve many situations 

where a certain end-to-end behavior is needed in tactical networks. This comes at 

the cost of a more complex network configuration. For more details about the MTrouting 

operation, please consult [5]. 

B. Interaction between a multi-topology routing domain and a single 

topology routing domain 

The MT-routing draft and RFC [1-2] both describe interaction with Single- 

Topology (ST) routers through the default topology (designated table 0 in MT). 

We do not view this approach as suitable for a mobile military network. The main reasons 

are: 

• The default topology covers the entire network and does not take into account 

transmission characteristics for the respective links. 

• For IPv6 the routing protocol load would be close to doubled, since the layout 

structure of the MT Link state advertisements (LSAs) are incompatible 

with standard IPv6 OSPF. In order to obtain compatibility with ST routers, 

the MT capable router has to transmit both encodings. 

Furthermore is it not described how to import routing information from an adjacent 

ST-routing protocol into the MT-routing protocol, without using the default


185 

topology. This can be regarded as a weakness in the specification, since it will only 

be the high capacity topologies of the MT domain that are usable for connection 

with external ST networks. The default topology normally does not have the ability 

to differentiate on traffic. In the CoNSIS project we wanted to have the interaction 

both between the MT-routing protocol and an exterior gateway protocol (EGP) 

as well as an interior gateway protocol (IGP). 

First we consider the task of importing and redistributing routing information 

from an adjacent ST-routing protocol into the MT-routing protocol. Most ST-routing 

protocols maintain routing information in the main forwarding table (known as table 

0 or default topology in MT). To avoid conflicts the default topology should not 

be used by the MT-routing protocol when MT-routing is used for QoS purposes. 

According to RFC [2] tables 32 to 127 are reserved for development, experimental 

and proprietary features and can be used for our purposes. 

The adjacent network information that we want to redistribute in the 

MT-network can have very different characteristics, it can be a homogeneous radio 

network with a certain characteristics or it can be a deployed network with a different 

typical characteristic. The radio network we might want to import into one 

or more specific topologies, whereas the deployed network should be imported 

into all topologies. For this reason we wanted to make a very flexible solution that 

allowed us to specify network import into (none or) any number of topologies. This 

involves both redistribution of the adjacent ST protocol information into the different 

topologies, and a copy of the ST routing information made available to the MT 

forwarding tables. Since redistribution only provides the routing information to 

neighboring nodes and not to the unit itself, this has to be a copy. 

If several networks are connected to the same gateway router and we do not 

want to redistribute the information from these protocols to the same topologies, 

then these networks must use different routing protocols, if not the router will not 

be able to identify the routes made available from the one network from the routes 

made available from the other network. It should be possible to use route-maps 

for each topology to limit the visibility when using the same routing protocol. 1 

Next we consider the task of making routing information from 

the MT-routing protocol available for adjacent networks. Here we would also like 

to have the same flexible solution of providing information from (none or) any 

number of topologies to the ST-routing protocol. In practice this means to provide 

the union of the routes available in the relevant MT topologies to the ST-routing 

protocol. This was not straight forward to implement (partly because of overlapping 

routes) in the open source routing environment used for the implementation 

(the SW platform is described in chapter VI). Thus the solution we implemented 

1 

In the case of interfacing BGP, route-maps could possibly use e.g. “match peer x.x.x.x” or “match as-path”. 

This has not been investigated further.


was to provide routing information from 0 or 1 (any of the available topologies) 

topologies to the adjacent network. 2 

One should be careful not to import routing information into different topologies 

than the one that is exported to the same network. If this is the case there 

will be asymmetry in the network information and some traffic will only be able to 

flow one way. In a QoS architecture this could be solved with a policy saying for 

example that the non MT-networks should be given the same, or more routing 

information than what is available in the MT-network. Traffic with QoS-tag that 

cannot be supported by the current MT-network topology will then be dropped 

at the entry point to the disadvantaged mobile MT-network. 

As a special case we gave the interaction between the MT-routing protocol 

and BGP [18] some extra thought. Providing the routing information in one topology 

for redistribution in BGP limits the visibility of the MT-network for BGP 

connected networks. Thus this method can be used to provide a topology for 

transit traffic through the MT-network and make the complete MT-network only 

available for local traffic. 

V. QoS architecture 

The CoNSIS QoS architecture for the network layer divides the QoS operations 

in two functional entities: 

• One entity that supervises the resource management. This mechanism 

is needed at the ingress of the network. 

• One entity that handles network congestion, packet forwarding and packet 

prioritizing required by the different dataflows. This mechanism is needed 

in all forwarding elements in the network. 

The resource management entity decides if a new traffic flow can be supported 

by the network. This mechanism must identify the network resources required by 

the flow associated with a specific QoS-class. If there are enough network resources 

available, the session will be admitted. Thus, there is a need for a resource management 

mechanism that attempts to estimate the available capacity of the network. 

If mechanisms are available to support resource reservation, this will be done by 

the resource manager. 

The prerequisites for admittance of a session may change after a session is admitted. 

A session of very high importance may try to access a fully loaded network. 

Then, pre-emption of a low importance session may be required. Similarly, due to 

node mobility, jamming, etc., the network capacity may change over time. This must 

be acted on by the resource manager. 

Short term network congestion due to fluctuations in the radio channel capacities 

and temporary overload of the network must be handled by the forwarding 

2 

Changes would be required to OSPF/ZEBRA in order to support multiple topologies to the adjacent networks. 

This is left for future work.


187 

component of the network routers. This component must also tailor packet queues 

and packet scheduling to effectuate the delay requirements of the packet’s QoSclass, 

and the military priority of the packet. In overload situations this mechanism 

makes sure that the important traffic is prioritized by the network at the expense 

of less important traffic which might then experience a very high packet loss due 

to queue overflow. 

For this architecture a set of QoS-classes must be defined that describe the network 

requirements (in terms of data rate, jitter, delay, reliability, etc.) needed by 

the dataflow labeled with the specific QoS-class. The traffic flows must be tagged 

with this information. 

In CoNSIS we propose to use MT routing to support the entity that supervises 

the resource management of the network. In the MT supported QoS architecture, 

we configure and maintain several network topologies that each spans a subset 

of the physical topology. Each topology has its own forwarding table that is used 

to forward packets classified as belonging to that specific topology. If a destination 

address is not available in the forwarding table associated with the QoS-class, then 

no path exists in the network where the specific QoS-class is allowed to be transported. 

Thus the flow should not be admitted to the network. Traffic is stopped at 

the network edge and not (in a worst-case scenario) forwarded through the entire 

network just to find that the last hop to the destination is a link not able to support 

the flow’s QoS requirements. 

When there is a route to the destination in the correct topology and the traffic 

flow is admitted to the network, the DiffServ mechanisms come into play. A queue 

hierarchy and packet scheduling mechanism prioritizes the sequence of transmitted 

packets on each interface. For each network interface we also define a traffic shaper, 

whose purpose is to keep the traffic transmitted on e.g. the wireless network below 

a certain threshold, to avoid network congestion. We use queue and scheduling 

tools to tailor the queue to the requirements of the associated QoS-class, and to 

implement packet scheduling for traffic priorities. Queue length, head/tail drop 

and drop-precedence are important queue parameters, while the packet scheduler 

could be designed for a strict priority scheme or a situation with more fairness 

in the scheduling process. 

It should be noted that in the current version of the MT-routing protocol we 

build topologies based on static predefined network/link characteristics. In future 

work we want to investigate if dynamic parameters representing the real time resource 

situation for the links can be incorporated efficiently with the MT-routing 

protocol to better support the resource management mechanism in the mobile 

tactical network. Alternatively, a possible solution could be to use the proactive 

MT-mechanisms as a first check if a flow can be admitted to the network and use 

a reactive probing technique to check the real-time resource situation on the MT path 

before the flow is actually admitted.


VI. CoNSIS convoy test network 

A. Multi-Topology routing SW 

We have implemented 3 the Multi-Topology support for OSPFv3 and OSPFv2, 

as well as MANET OSPFv3 (MDR) [19] into the Vyatta [20] Linux distribution. 

This is based on the Quagga [21] open source routing application running on 

a Debian system with Linux kernel 2.6.37 (ATOW). The MANET OSPFv3 base 

protocol was fetched from [22]. The router implementation allows easy configuration 

of OSPFv2-MT and OSPFv3-MT information. Metrics can be setup for each 

topology on each interface. The Linux platform is set up to utilize multiple forwarding 

tables and Quagga’s interface towards forwarding tables in Linux has been 

adjusted to allow the use of multiple routing tables. In addition to OSPFv2-MT and 

OSPFv3-MT routing, the implementation also supports configuration of static MTroutes. 

A flexible import and redistribution of routes from other routing protocols 

is supported, as well as customized export of MT-routes to the main routing table to 

make the routes available to other routing protocols. 

Due to experienced instabilities in the MANET OSPFv3-MT protocol we will 

use OSPFv3-MT in the CoNSIS field experiment. 

It should also be noted that the expanded encoding of the OSPF Options described 

in the draft [1] is in conflict with bits allocated by OSPF Link-Local signaling 

[23]. Link-Local Signaling is also part of the MANET OSPFv3 implementation. 

B. The CoNSIS convoy platforms 

The land mobile network component in the CoNSIS network architecture 

is represented by a multinational convoy in the scenario and in the field test. 

The network consists of a German (Nation 1) and a Norwegian (Nation 2) convoy 

segment. Each segment consists of four mobile nodes. The convoy network is connected 

to a multi-national deployed headquarter (Fig. 3). The NGO vehicles also 

have a network connection to the military convoy, however this connection is not 

visible in Fig. 3 since this network is not allowed to be part of the unprotected coalition 

transport network. Traffic is sent to/from the NGO segment via application 

gateways handled by other CoNSIS task groups. 

The Convoy network consists of five different radio networks. It is therefore 

a highly heterogeneous MANET. Table I give some details of the radios that will 

be utilized in the planned CoNSIS experiment. The network is used for internal 

convoy communication and reach-back to the deployed headquarters. 

3 

The implementation is done by Thales Norway AS


189 

Table I. Radios used in the CoNSIS Convoy test network 

Nation 1 

SatCom 

Nation 1 

UHF Network1 

Nation 1 

VHF Network 

Nation 1 

UHF Network2 

Nation 2 

UHF Network 

Radio Type 

Thrane &Thrane 

BGAN Ex. 727 

IABG 

HiMoNN 

Harris 

RF-7800S 

Rockwell Collins 

FlexNet-Four 

Kongsberg 

WM600 

a) The data rates are approximate values 

Number of radios 

in the network 

unknown 

Shared channel 

data rate a 

384 kb/s 

6 11 Mb/s 

5 64 kb/s 

3 1 Mb/s 

6 920 kb/s 

The different transmission technologies present in the planned experimental 

network have substantially different characteristics when it comes to e.g., transmission 

delay, transmission range and data rate. Given the heterogeneous network 

as described above, the end-to-end network capacity could change from a relatively 

high data rate of several Mb/s to a few tens of Kb/s when a node moves from 

UHF coverage to a path that includes one or more VHF and/or SatCom on the move 

links. This large variation in available data rate is difficult to handle for the resource 

management entity. In such a scenario it is also important that the network is able to 

prioritize the mission critical data traffic in overload situations. 

Figure 3. The land mobile network in CoNSIS


In the CoNSIS network architecture for the land mobile network we interconnect 

the different links and networks present in the network with an OSPFv3-MT 

routing protocol in one flat routing domain. This allows full dynamics in the network. 

To demonstrate the use of multiple topologies for QoS purposes we define 

three topologies in the CoNSIS convoy network: 

• A high data rate topology 

• A low data rate topology 

• A low delay topology 

Table II shows how the different radio networks in the CoNSIS convoy network 

are associated with the three defined topologies. All radio networks also participate 

in the default topology. 

Radio Type 

Table II. The use of the radio networks in the topologies 

Low data 

rate topology 

High data 

rate topology 

Low delay 

topology 

Nation 1 SatCom X – – 

Nation 1 UHF Network1 X X X 

Nation 1 VHF Network X – X 

Nation 1 UHF Network2 X X X 

Nation 2 UHF Network X X X 

The low data rate topology includes all links. The high data rate links are also 

included in this topology to increase connectivity and network robustness; however, 

the topology cannot guarantee more than a low data rate capacity. The best 

path within each topology is calculated based on the MT-cost parameter for each 

link between source and destination. The UHF networks are given low cost whereas 

the SatCom and the VHF networks are given a very high cost. We set the same 

cost for all topologies but acknowledge that it could be beneficial in some cases 

to use different cost for different topologies and thereby prioritize the utilization 

of the network types differently for different traffic types. 

Fig. 4 exemplifies a radio topology where Nation2’s portion of the convoy 

is driving into a terrain with difficult channel propagation conditions for Nation2’s 

UHF radio. Table III shows the routing table for the three topologies for all the vehicles 

in Nation2 for the radio connectivity represented in the figure. 

In the MT supported QoS architecture we require that all traffic in the network 

is tagged with the appropriate QoS-tag. We choose to use the traffic 

class field in the IPv6 header, to mark the packets. We use this field to encode 

the QoS-class (named Service-based Class (SBC) in [24]), and traffic priority 

(IP Military Precedence Level (IP MPL)) as suggested in [24]. Fig. 5 shows 

the chosen format.


191 

Figure 4. Network connectivity in terrain with difficult radio propagation 

for Nation 2’s UHF network 

Table III. Routes a available in the three different routing tables in the vehicles 

of Nation 2 in Fig. 4 

Nation 2 vehicle no. Low data rate topology High data rate topology Low delay topology 

1 All vehicles All Nation 1 vehicles All except Nation2:3 

2 All vehicles Nation2:4 All except Nation2:3 

3 All vehicles – – 

4 All vehicles Nation2:2 All except Nation2:3 

a) The destinations are represented as follows in the table: Vehicle no. 3 in Nation2 is written 

as Nation2:3. 

 

 

 

 

 

 

 

 

 

 

 

Figure 5. Suggested use of the IPv6 traffic class field 

For the CoNSIS QoS architecture we decided that there should not be a fixed 

association between a traffic type and a SBC and IP MPL. We believe that it is wise to 

allow network planners of an operation to define the SBC for a service. E.g., in some 

operations it might be important to provide frequent high resolution images, while


other operations would rather spend the data-rate on other services. In such a setting, 

an application (service) can be tagged with one SBC in one operation and 

another SBC in the next. Nevertheless we created an example list of services and 

signaling traffic for the CoNSIS experiment and associated these with the SBC and 

IP MPL as shown in table IV. Table V then shows how some selected services from 

table IV are associated with the topologies created for the experiment. 

NETR 

SBC 

Service 

Network 

Infrastructure 

Table IV. CoNSIS services mapped to SBCs 

One example of mapping between 

CoNSIS services and the SBC 

– Routing (e.g. OSPFv3-MT, BGP, OLSR) 

– Management, ICMP Error Messages 

– TIBER Auto detection of classified enclaves 

DSCP 

CS6 110000 

OAM 

Network 

Management 

– Security management CS2 010000 

SIG-T Call Signaling 

– VoIP signaling 

– Notification Management Service 

CS5 101000 

– Service Discovery Service 

F 101010 

VOICE Voice 

P 101100 

– MELPe R EF 101110 

F AF41 100010 

VIDEO VTC 

P AF42 100100 

R AF43 100110 

STREAMING 

F AF31 011010 

Streaming 

P AF32 011100 

media 

R AF33 011110 

– Operational Alarm Messages 

F AF21 010010 

Low latency – NFFI Blue Force Tracking Service 

LDELAY 

data 

– Chat Application P AF22 010100 

– Network Services (e.g. DNS, DHCP) R AF23 010110 

– Image messaging service F AF11 001010 

BULK Bulk 

P AF12 001100 

R AF13 001110 

NORM Best effort Other applications BE 000000 

For the low data rate interfaces we choose to configure a strict priority queue 

with no fairness in the packet scheduling. This ensures that the highest priority 

traffic types are given enough resources. For the high data rate interfaces we use 

the hierarchical token bucket (HTB) queuing structure for Linux, and associate 

a share of the shaping bandwidth to each of the QoS-classes. This supports traffic


193 

priority but also provides some fairness in the packet scheduling. QoS-classes that 

need low delay are set up with short queues, as are QoS-classes with periodic traffic 

where it is important to always get the most recent message. 

Table V. The link between selected services and the defined network topologies 

CoNSIS service 

Low data 

rate topology 

High data 

rate topology 

Low delay 

topology 

NFFI Service (AF21) X – – 

Chat application (AF22) X – – 

VoIP (MELPe 2400) (EF) – – X 

Image msg. service (AF11) – X – 

The ip6tables functionality in Linux is used to mark MT-routing traffic 

with the correct QoS-class. All user traffic in the CoNSIS network is encrypted 

by IPSec solutions, thus the user traffic must be marked with the correct QoS-class 

by the source. This marking is also used to associate the QoS-classes with the forwarding 

table for the correct topology. The Linux traffic control (tc) tool is used to 

setup the queuing and scheduling mechanisms. 

E. Tests to be performed during the CoNSIS experiment 

To further explain the use of MT-routing in the CoNSIS convoy network we 

will here briefly describe the three tests we plan to perform during the CoNSIS 

experiment to demonstrate the functionality of the MT supported QoS architecture. 

The experiment is being performed at the time of writing, thus results are not yet 

available. All vehicles referred to by number belong to Nation2 unless otherwise 

specified. 

1) Demonstrate seamless mobility in a heterogeneous wireless network 

In this test we show how link breaks in a mobile military network can be overcome 

via routes utilizing the different radio networks/link technologies in a coalition 

tactical network. The test starts with full connectivity (Fig. 3) and traffic among 

all Nation2 nodes. Vehicles 2 and 4 then move together such that these no longer 

have Nation2 UHF connectivity with the remaining Nation2’s vehicles. The internal 

traffic for Nation2 will still be flowing among all nodes, but now via the Nation1’s 

UHF and VHF networks. Next vehicle 3 moves so that it loses all Nation2 UHF 

connectivity, but since it has a Nation1 SatCom terminal, the internal traffic will 

still be flowing among all Nation2 vehicles. See Fig. 4 for the final network connectivity 

situation.


2) Test the use of multiple topologies for QoS purposes 

In this test we want to show how topologies can be used to provide different 

paths for different traffic classes, and also to block traffic at the source for flows that 

cannot be supported by the current network. The test will be run both for the high 

data rate topology and for the low delay topology. The test for the high data rate 

topologi is explained here. The test starts with full connectivity (Fig. 3) and traffic 

flow from vehicle 1 on both the low data rate topology and the high data rate 

topology to all other Nation2 vehicles, and traffic flow on both the low data rate 

topology and the high data rate topology from vehicle 2 to vehicles 3 and 4. Vehicle 

3 then moves away to lose Nation2 UHF connection, but it still has a Nation1 

SatCom connection (Fig. 6). Vehicle 3 will now only receive traffic from vehicle 

1 and vehicle 2 on the low data rate topology. Next, vehicle 2 and vehicle 4 move 

together to lose Nation2’s UHF connectivity to the remaining Nation2’s vehicles. 

Vehicle 4 will now only receive traffic on the low data rate topology from Vehicle 

1, but it will still receiver traffic on both topologies from Vehicle 2. See Fig. 6 for 

the final network connectivity situation. The faded (grey) network links does not 

participate in the high data rate topology. 

Figure 6. Network connectivity for the final stage of the “MT for QoS purposes” test. 

The grey network links does not participate in the high data rate topology 

3) Limiting convoy network visibility for adjacent networks 

In this test we demonstrate how multiple routing topologies can be used to 

control the routes that are advertized in adjacent networks. A topology can be 

created that holds links/routes that can be made available for transit traffic or for 

external traffic. Only these routes will then be made available for an exterior gate-


195 

way protocol to provide to adjacent networks. For simplicity we will use the high 

data rate topology to represent this transit topology. A separate topology could 

very well have been created for this purpose. Also since we have only one gateway 

between the convoy and the deployed HQ we cannot support transit traffic. Instead 

we show how traffic from external networks is only allowed to use the chosen topology. 

We start with full connectivity (Fig. 3) and traffic flowing from vehicle 1 

to all other Nation2 vehicles and from the Deployed HQ to all Nation2 vehicles. 

Vehicle 3 then moves away to lose Nation2 UHF connectivity, but still has Nation1 

SatCom connection (Fig. 6). Vehicle 3 will now still receive traffic from vehicle 1, 

but no longer from the Deployed HQ, since there is no longer a route to vehicle 3 

in the topology made available for the exterior gateway protocol. Vehicle 3 will not 

be visible in the routing tables in the Deployed HQ. All other Nation2 vehicles will 

still receive traffic from the HQ. 

VII. Conclusion 

In this paper we show how Multi-Topology (MT) routing can aid the design 

of end-to-end QoS support in the land mobile network defined in the CoNSIS 

network architecture. The MT-routing protocol builds topologies based on static 

link characteristics that are valid at all times. We see the use of multiple topologies 

paired with a DiffServ-like architecture as a simple but powerful tool to dynamically 

block traffic at the source for flows that cannot be supported by the current network 

topology, and thereby improve the QoS and available capacity for admitted traffic. 

We have also suggested a very flexible interaction between MT supported 

network domains and Single-Topology (ST) routing domains. 

Multiple topologies can also be used to support load balancing on a QoS-class 

basis (i.e., different QoS-classes are transmitted on partly or fully disjoint paths). 

Since this QoS architecture operates based on the code in the IPv6 traffic class 

field, the only requirement to the IP encryption device placed between the issuing 

application and the wireless transport network is that the encrypted tunnel must 

inherit the QoS tag of the data packet. 

Additional resource management mechanisms based on e.g., polling techniques 

[25] can be combined with the MT supported QoS architecture to incorporate 

dynamic changes in e.g., channel quality and traffic load to further improve 

the scheme for admission control purposes. The resource mechanism must be executed 

for all defined topologies. 


We would like to acknowledge the Norwegian Army’s weapon school represented 

by LtCol. A.B. Enger and Maj. M. Gjellerud for the initiative to develop 

a router demonstrator for QoS experimentation in tactical networks.


We also want to acknowledge all CoNSIS Task 1 participants, and especially 

Maximilian List and Martin Zeller from IABG mbH for fruitful discussions and 

very skilled network configuration. 

References 

[1] S. Mirtorabi and A. Roy, “Multi-Topology routing in OSPFv3 (MT-OSPFv3).” 

draft-ietf-ospf-mt-ospfv3-03.txt (work in progress), July 2007. 

[2] P. Psenak, S. Mirtorabi, A. Roy, L. Nguyen, and P. Pillay-Esnault, “Multi- 

-Topology (MT) routing in OSPF.” RFC 4915, June 2007. 

[3] S. Blake et al., “An architecture for differentiated serv.” RFC2475, 1998. 

[4] D. Grossman, “New terminology and clarifications for diffserv.” RFC 3260, 2002. 

[5] M. Hauge, J. Andersson, M.A. Brose, and J. Sander, “Multi-topologyrouting 

for improved network resource utilization in mobile tactical networks,” MILCOM, 

San Jose, CA, USA, 2010. 

[6] F.T. Johnsen, T. Hafsoe, M. Hauge, O. Kolbu, “Cross-layer Quality of Service based 

admission control for Web services,” HeterWMN, pp. 315-320, Houston, TX, USA, 

Dec. 2011. 

[7] L. Hanzo-II and R. Tafazolli, “A survey of QoS routing solutions for mobile as hoc 

networks.” COMST, vol. 9, no. 2, pp. 50-70, 2007. 

[8] R. Asokan, “A review of Quality of Service (QoS) routing protocols for mobile Ad 

hoc networks.” ICWCSC, Chennai, India, 2010. 

[9] N.S. Kulkarni, I. Gupta, and B. Raman, “On demand routing protocols for mobile 

ad hoc networks: A review.” IACC, Patiala, India, 2009. 

[10] P. Jeon and G. Kesidis, “Pheromone-aided robust multipath and multipriority routing 

in wireless MANETs.” PE-WASUN, pp. 106-113, Montreal, Quebec, Canada, 2005. 

[11] L. Xuefei and L. Cuthbert, “Multipath QoS routing of supporting DiffServ in mobile 

ad hoc networks.” SNPD/SAWN, pp. 308-313, Baltimore, MD, USA, 2005. 

[12] S. Venkatasubramanian and N.P. Gopalan, “A QoS-based robust multipath routing 

protocol for mobile ad hoc networks.” AH-ICI, pp. 1-7, Kathmandu, Nepal, 2009. 

[13] L. Chengyong, L. Kezhong, and L. Layuan, “Research of QoS-aware routing 

protocol with load balancing for mobile ad hoc networks.” WiCOM, pp. 1-5, Dalian, 

China, 2008. 

[14] A.F. Hansen, T. Cicic, and P.E. Engelstad, “Profiles and Multi-Topology Routing 

in Highly Heterogeneous Ad Hoc Networks,” INFOCOM, Poster and Demo session, 

Barcelona, Spain, April 2006. 

[15] J.A. Stine and G. de Veciana, “A paradigm for quality-of-service in wireless 

ad hoc networks using synchronous signaling and node states.” J-SAC, vol. 22, no. 7, 

pp. 1301-1321, Sept. 2004. 

[16] S. Bae and T.R. Henderson, “Traffic Engineering with OSPF Multi-Topology 

Routing,” MILCOM, Orlando, FL, USA, October 2007.


197 

[17] X. Gou, H. Yan, F. Yi, G. Long, and Q. Wu, “Modeling and simulation of small 

satellite constellation networking using multi-topology routing,” ICCASM, vol. 12, 

pp. 143-147, Taiyuan Shanxi, China, October 2010. 

[18] Y. Rekhter, T. Li and S. Hares (Ed.’s). “A Border Gateway Protocol 4 (BGP-4)” RFC 

4271, Jan. 2006. 

[19] R. Ogier and P. Spagnolo, “Mobile ad hoc network (MANET) extension of OSPF 

using CDS flooding.” RFC 5614, Aug. 2009. 

[20] Vyatta, http://www.vyatta.com 

[21] Quagga Routing Suite, http://www.quagga.net 

[22] OSPFv3 MANET MDR, Boeing, http://cs.itd.nrl.navy.mil/work/ospf-manet/ 

[23] A. Zinin, A. Roy, L. Nguyen, B. Friedman and D. Yeung, “Ospf Link-Local Signaling” 

RFC 5613, Aug. 2009. 

[24] R.M. van Selm, G. Szabo, R. van Engelshoven, and R. Goode, Ip QoS standardisation 

fo the NII, RD-2933, NC3A,(Nato Unclassified), Apr. 2010. 

[25] A. Mohammad, O. Brewer, and A. Ayyagari, “Bandwidth estimation for network 

quality of service management.” MILCOM, Orlando, FL, USA, 2007.

Chapter 3 

Information Technology 

for Interoperability and Decision 

Support Enhancement

Mathematical Foundations of Interoperability 

and Composability 

Andreas Tolk 

Old Dominion University, Norfolk, Virginia, USA, atolk@odu.edu 

Abstract: Based on the success stories of many engineering solutions, interoperability is often seen 

as something that can be worked into a system after the fact. If two systems shall exchange information 

with each other, system and software engineers are engaged to make these systems interoperable, often 

using interface and protocol standards. Recent research results in relevant domains of mathematics, 

in particular model theory and algorithmic information theory, show that such bottom-up engineering 

approaches are limited for model-based applications. Such applications do not only require 

the interoperability of implementations but also the composability of underlying conceptualizations. 

As more and more applications in the Military Communications and Information Systems domains 

are model-based applications, such as decision support systems and alternative course of action 

analyses tools, these topics become increasingly relevant and may lead to a paradigm shift how we 

look at federating our systems in support of international operations. 

Introduction 

The paper shares lessons-learned from interoperability work conducted in support 

of integrating command and control systems with modeling and simulation 

systems. It introduces the Levels of Conceptual Interoperability Model (LCIM) 

as the current support method for interoperability engineering. It proposes the use 

of more formal approaches utilizing the mathematical foundations of Model Theory 

for future system developments based on interoperability design. 

The underlying idea of most military interoperability efforts – even if new 

forms of standards like those developed for the sematic web are applied – is still 

to connect two already developed and often operational systems by engineering 

interoperability. We are enabling information exchange solutions after the fact by 

defining interfaces and protocols. This is the same idea that already supported 

message exchange mechanisms as well as data replication mechanism: the participating 

two systems exchange information via pre-defined interfaces. The systems 

themselves don’t have to be modified as long as they are able to support the standard 

interfaces. The underlying interoperability definition is captured by the IEEE as follows: 

“Interoperability is the ability of two or more systems or components to exchange


information and to use the information that has been exchanged.” In many cases, 

this approach works quite well, in particular for database driven system. If these 

systems can exchange information and integrate the data into the databases, we are 

successful and interoperable. Many other information technology systems follow 

the same paradigm: if we can exchange information and use it, we can support 

a common task in real operations, but is this enough for model-based systems 

This raises the follow-up questions “What are model-based systems” and 

“Why should the Command and Control (C2) community care” Model-based 

systems are systems that do not use the real systems as there referent but conceptualizations 

thereof as the basis for their specification or the representation 

of the specification. They use models that are formal representations of task-driven 

purposeful simplifications of abstractions of a perception of reality. In this sense, 

many tools the C2 community is interested in turn out to be model-based systems. 

In particular simulation systems are model-based, as they are executing models 

over time. The C2 community utilizes simulation systems for training, for testing, 

and increasingly for operational support. Simulation systems provide an emerging 

training environment, that can provide a realistic testing environment, and they 

can help to evaluate alternative course of action and provide the means for mission 

rehearsal. The importance of model-based C2 support is increasing, so it becomes 

pivotal to understand what makes them special. We will show that these systems 

require not only agreeing on format and meaning, but also on the use of data to 

be exchanged. As such, we need to agree on all three elements of semiotics: syntax, 

semantics, and pragmatics. 

To make the necessary points, this white paper is divided into two parts. 

The first part describes lessons-learned from interoperability work conducted by 

the research team leading to the LCIM. The second part recommends the application 

of formal methods grounded in mathematical model theory. 

This white paper has been written to complement the keynote for the symposium 

in magazine style. For more information, the interested reader is referred 

to the academic publications listed at the end of this paper. 

Lessons learned from interoperability projects: 

The levels of conceptual interoperability model 

The current paradigm regarding interoperability can be best characterised 

as interoperability engineering. Two systems that were developed independently from 

each other but that share a common application case are presented to the engineer 

with the requirement to make them interoperable. This can be systems provided 

by two military services that shall conduct a joint operation as well as two nations 

that conduct a combined operation. 

The main assumption behind this paradigm is that as both systems are developed 

in support of a common view of reality, namely the common operation they

Chapter 3: Information Technology for Interoperability and Decision... 

203 

shall support, the systems are both based on the same part of reality. Following 

the definition giving in the introduction, the models the systems are using are purposeful 

abstractions and simplification of their perception of this common reality. 

The resulting implementations should therefore be similar enough to be alignable by 

designing a common technical infrastructure that supports mediation between 

the different viewpoints. This view is also supported by the IEEE definition cited 

earlier in this white paper: two systems can be made interoperable if we can mediate 

the data used in both systems to each other to use them in the respective system. 

In order to gain a better understanding of the theoretical underpinnings 

of interoperation between two federate simulation systems the Levels of Conceptual 

Interoperability Model (LCIM) was developed. This model and its layers allow 

clearly distinguishing between the three governing concepts of interoperation: 

• Integratability contends with the physical/technical realms of connections 

between systems, which include hardware and firmware, protocols, networks, 

etc. 

• Interoperability contends with the software and implementation details of interoperations; 

this includes exchange of data elements via interfaces, the use 

of middleware, mapping to common information exchange models, etc. 

• Composability contends with the alignment of issues on the modelling 

level. The underlying models are purposeful abstractions of reality used 

for the conceptualization being implemented by the resulting systems. 

For meaningful interoperation of two systems, all three governing concepts 

are necessary: we need compatible infrastructures, interoperable implementations, 

and composable models. In particular the third concept of composability has been 

neglected by interoperability standards so far. The LCIM defines several layers 

of interoperation to address particular challenges. It can be used descriptively (what 

has been accomplished) as well as prescriptively (what needs to be accomplished). 

These levels are defined as follows: 

• If systems are stand-alone applications with no interconnection, there 

is obviously no interoperability. 

• The technical layer deals with infrastructure and network challenges, enabling 

systems to exchange carriers of information. This is the domain of integratability; 

a communication protocol to exchange signals exists. 

• The syntactic layer deals with challenges to interpret and structure the information 

to form symbols within protocols. This layer belongs to the domain 

of interoperability; common symbols – like the use of Unicode or ANSI 

code – are identified. 

• The semantic layer provides a common understanding of the information 

exchange. On this level, the pieces of information that can be composed to 

objects, messages, and other higher structures are identified. This level also 

support interoperability: it introduces common terms to tag structures that 

represent tags that are used to name functions, variables, and constants.


• The pragmatic layer recognizes the patterns in which data are organized for 

the information exchange, which are in particular the inputs and outputs 

of procedures and methods to be called. This is the context in which data 

are exchanged as applicable information. These groups are often referred 

to as (business) objects. This is the highest level still supporting the realm 

interoperability; the relations between functions and there input and output 

parameters are captured. 

• The dynamic layer recognizes various system states, including the possibility 

for agile and adaptive systems. The same business object exchanged with 

different systems can trigger very different reactions. It is also possible that 

the same information sent to the same system at different times can trigger 

different responses. This level is the first level in the realm of composability, 

as it requires the alignment of assumptions and constraints. 

• Finally, general assumptions, constraints, and simplifications need to be captured. 

This happens in the conceptual layer. Here, we capture the abstractions 

and simplifications of the perception of reality that constraint the model. 

The following figure shows the levels and their relation to the governing 

interoperation concepts. 

Figure 1. Levels of Conceptual Interoperability Model 

This model already implies that more than data mediation is needed to support 

composability. The context needed to support meaningful use of information to be 

exchanged must address the higher levels of interoperation as well. 

Interoperability design 

The main idea behind most interoperability engineering approaches was the requirement 

that the original systems that shall contribute to a distributed application


205 

shall not be modified. This also explains the focus on data mediation and providing 

middleware solutions to integrate such systems in support of a common operation. 

However, the LCIM shows that this cannot be sufficient. The context of the information 

exchange setting the intended use is as important as the information itself. 

While the LCIM already shows the need for better aligned of the systems holistically, 

model theory can be used to proof the necessity. 

Model theory is a branch of mathematics that deals with the interpretation 

of formal languages using set-theoretic structures. The topic of research is the equivalency 

of interpretations in different formal languages. In other words, model 

theory is the study of the interpretation of languages and how truth is interpreted 

within the language. The underlying questions are: How can we ensure that truth 

is consistently represented, and what does this mean for the formal languages 

It seems to be logical to think about formal languages when talking about 

implementations, as programs are written in computer languages, and computer 

languages are formal languages. However, we use artifacts such as the Unified Modeling 

Language (UML) or the System Modeling Language (SysML) for the modeling 

phase, and they can be interpreted as formal languages as well. Collections 

like the NATO Architecture Framework that are based on a common repository 

storing all artifacts and diagrams are formal languages as well. In order for requirements 

to make sense, they need to be verifiable, which normally happens in form 

of measuring something. SysML defines the requirement diagram and the parametrics 

diagram to deal with these tasks systematically; architecture framework tools 

support the annotation of functions with acceptance test metrics as well. However, 

if we can measure it, we can express it in a formal language. Finally, validation and 

verification ensure the equivalency of transformations between different views 

of the model, which can be expressed formally. If we therefore can show the applicability 

of model theory to the tasks of semantic interoperability, we can hope for 

a new unifying approach that embraces requirements, modeling, implementation, 

and validation and verification. Therefore, model theory becomes the unifying 

theory that brings systems engineering, modeling and simulation, and validation 

and verification together and builds a formal basis to meaningfully and unambiguously 

discuss interoperability. 

In order to understand the applicability of model theory as the foundation 

for a common interoperability theory, several definitions are necessary. We start 

with definitions for a language, universe and interpretation building the structure 

of the language, and finally sentences built and understood in this language. 

• Definition 1: A language L is a set consisting of logical symbols including 

constant symbols, function symbols, and relational symbols. 

• Definition 2: A structure for a language L is an ordered pair . 

A is a set of symbols. Rn is a relation defined over A such that (a 1 , …, a n )Rn 

if and only if a function f exists that fulfills f(a 1 , …, a n-1 ) = a n . The set part 

A is called the universe of a language, as they describe everything that can be


evaluated. The relation Rn is the interpretation. Combining universe and 

interpretation results in the model of the language. 

• Definition 3: A sentence σ is an assertion that can be assigned the Boolean value 

true or false. A language is generated by a set of its elementary sentences 

and using its logical operators. 

These three initial definitions give us the tools to understand what an interpretation 

of truth is in model theory. Clearly distinguishing between the language, 

the model of the language, and the interpretation of truth within the model of the languages 

helps to better address interoperability challenges. The next set of definitions 

allows for an unambiguous representation of truth using these constructs. 

• Definition 4: Let Σ be a set of sentences. U is a model of Σ whenever U⊩σ 

for each σΣ. This is written as U⊩Σ. Σ is satisfiable if and only if there 

is a structure U for which U⊩Σ. 

• Definition 5: A theory T is a set of sentences. If T is a theory and σ is a sentence 

then we write T⊩σ whenever we have that for all U we can show that 

if U⊩T then U⊩σ. We define σ to be a consequence of T. A theory is defined 

to be closed whenever it contains all consequences. 

• Definition 6: If U is a model of L then we define the theory of the model 

U, named ThU, as the set of all sentences of L which are true in U, or 

ThU={σL: U⊩σ}. 

• Definition 7: If ΣT fulfills that Σ⊩σ for every σT, in other words Σ⊩T, 

then Σ is a set of axioms of the theory T. 

Requirement sets, models, and simulation are all formal languages that shall 

express the same truth. Using model theory, this can now be captured that sentences 

of each model must be satisfiable under all other models, or we have different 

versions of truth at the same time in our distributed application. In order for two 

systems to be interoperable they have represent the same theory of the common 

model. What is true in one interpretation shall be true in an alternative interpretation. 

If something is wrong in one interpretation, it shall be wrong in the others 

as well. If this is not the case, we will run in mistakes and ambiguities when such 

systems are executed side by side. 

We need to significantly broaden our understanding of data: in model theory, 

everything in the universe of a language is a datum. As such, all of them need to be 

taken into consideration as metadata within the future interoperability theory. This 

vision of interoperability as enabling the consistent representation of truth in two 

interoperable systems cannot be reached by the current standards, as they only 

address syntactic and semantic issues, but they do not even touch the pragmatic 

domain of interoperation. 

As a first step, the research team described the LCIM formally to allow for addressing 

all aspects of semiotics in a consistent way. This actually allows extending 

the LCIM towards and Interoperability Maturity Model. Using symbols and the interpretation 

of these symbols mapping them to appropriate domains, the following


207 

table shows the formal definition of the LCIM levels. We define domains with sets 

of labels for input and output data defining the semantic context, and domains 

of sets of function names and sets of system state names to provide the pragmatic 

context. The conceptual domain is represented as constraints over all sets. 

Table 1. Formal definition of the LCIM 

LCIM Level Formal Representation Required 1 

Technical Level 

No formal representation 

Syntactical Level 

Σ* Set of Symbols 

I* Set of Inputs 

Semantic Level 

O* Set of Outputs 

Δ* Set of Domains (I,O) 

Pragmatic Level 

F* Set of Functions 

Δ* Set of Domains (F) 

Dynamic Level 

S* Set of States 

Δ* Set of Domains (S) 

Conceptual Level 

Constraints on (Σ*, Δ*, I*, O*, F*, S*) 

1 LCIM levels accumulate the formal representation required 

Summary 

The application of mathematical principles shows that we reached the limits 

of interoperability engineering. Whenever two systems have been developed 

independently from each other, they are likely based on different abstractions 

and simplifications of different perceptions of reality designed to answer different 

questions and support different tasks. As such, their scope, resolution, and structure 

of resulting concepts differ. This results in different interpretations of truth 

in both systems. The alignment challenges for the concepts and the harmonization 

challenges for the processes reside on the conceptual level and cannot be solved by 

technical means. No infrastructure can make two conceptually different systems 

interoperable. However, interoperability maturity matrixes can provide metrics 

that help to engineer context specific solutions which can be applied for intelligent 

agents support such tasks as well. 

To address this problem in the future, new approaches and a paradigm shift 

are needed. Interoperability design based on solid mathematical foundations 

is the future. First applications have proven the feasibility and applicability of this 

approach, but we are just at the beginning to understand the deeper implications 

for interoperability of our operational systems.



This work is based on the foundational contributions in the domain of interoperability 

and model theory by Dr Saikou Y. Diallo, Dr Robert D. King, Dr Jose J. 

Padilla, Dr Charles D. Turnitsa, and Dr Heber Herencia-Zapana. 

References 

[1] A. Tolk, “Interoperability and Composability,” in J.A. Sokolowski and C.M. Banks 

(Eds): Modeling and Simulation Fundamentals: Theoretical Underpinnings and Practical 

Domains, John Wiley, pp. 403-433, 2010. 

[2] A. Tolk, “Standards for Distributed Simulation,” in A. Tolk (Ed.): Engineering Principles 

of Combat Modeling and Distributed Simulation, John Wiley, pp. 209-241, 2012. 

[3] A. Tolk, L.J. Bair, S.Y. Diallo, “Supporting Network Enabled Capability by Extending 

the Levels of Conceptual Interoperability Model to an Interoperability Maturity 

Model,” Journal of Defense Modeling and Simulation (JDMS), doi:10.1177/ 

1548512911428457, 2011. 

[4] A. Tolk, S.Y. Diallo, C.D. Turnitsa, L.S. Winters, “Composable M&S Web Services 

for Net-centric Applications,” Journal for Defense Modeling & Simulation (JDMS), 3(1) 

27-44, 2006. 

[5] S.Y. Diallo, A. Tolk, J. Graff, A. Barraco, “Using the Levels of Conceptual 

Interoperability Model and Model-based Data Engineering to develop a Modular 

Interoperability Framework,” Winter Simulation Conference, Phoenix, AZ, pp. 2571-2581, 

December 2012. 

[6] S.Y. Diallo, H. Herencia-Zapana, J.J. Padilla, A. Tolk, “Understanding 

Interoperability,” Spring Simulation Multi-Conference, Emerging M&S Applications 

in Industry and Academia (EAIA’11), SCS, Boston, MA, April 2011, pp. 84-91. 

[7] A. Tolk, S.Y. Diallo, J.J. Padilla, and C.D. Turnitsa, “How is M&S Interoperability 

different from other Interoperability Domains” Spring Simulation Interoperability 

Workshop, Boston, MA, pp. 12-20, April 2011. 

[8] A. Tolk, Saikou Y. Diallo, Jose J. Padilla, “Semiotics, Entropy, and Interoperability 

of Simulation Systems – Mathematical Foundations of M&S Standardization,” Winter 

Simulation Conference, Berlin, Germany, December 2012.

Semantic Interoperability by Means 

of Computer Languages 

Ľubomír Dedera 

Department of Informatics, Armed Forces Academy of Gen. M.R. Štefánik, 

Liptovský Mikuláš, Slovakia, Lubomir.Dedera@aos.sk 

Abstract: In this paper we introduce computer language syntax and semantic processing techniques 

as a means to achieve semantic interoperability in the selected areas of command and control systems. 

Specifically we focus on the topic of domain-specific languages in the area of military command and 

control systems, where we present how separation of concrete and abstract syntax and semantics 

can help design languages with multilingual support that are exploitable in integration of national 

command and control systems and deployment in multinational environment. 

Keywords: computer languages; domain-specific languages; syntax; semantics; command and control 

system 


In order to bring the idea of computer languages (CLs) in command and 

control (C2) systems closer, first let us look at probably the best known group 

of CLs – “classical” programming languages. 

The role of high-level programming languages (PLs) (like C, Java, Lisp, Prolog) 

is widely known not only in the technical community. They play inevitable role 

in the process of software development. A programming language is an artificial 

computer language designated to express computations that can be performed by 

a machine. PLs can be used to create programs that control the behavior of a machine, 

to express algorithms precisely, or as a mode of human communication [1]. 

Most PLs describe computation in an imperative style, i.e. as a sequence of commands 

and support object-oriented paradigm of programming (OOP). However, 

there are PLs supporting declarative programming paradigms such as functional 

(Lisp) or logical (Prolog) paradigms. 

Most PLs belong to the group of general-purpose programming languages. 

It means that they can be used to code software applications for many various application 

domains. Typically they are Turing-complete; loosely speaking, according 

to the Church-Turing Thesis it means that they are capable of describing solutions 

of all algorithmically solvable problems.


Another family of computer languages, which will be in focus of our attention, 

is the family of domain-specific languages. Domain-specific languages (DSLs) are 

computer languages designed for a specific class of problems and for particular application 

domains [2], [3]. They can be dedicated to a particular problem domain, 

a particular problem representation technique or a particular solution technique. 

The basic idea behind DSLs is to offer means which would allow expressing solutions 

in the idioms and at the abstraction level of the problem domain. The consequence 

is that domain experts (or qualified users) can express, validate or modify 

solutions described in a particular DSL. They might be designed with the intention 

to be [3], [4]: 

• Programming languages dedicated for a particular problem domain, or 

• Specification languages dedicated for a particular problem domain. 

DSLs can have both textual and graphical (visual diagrams) forms. The latter 

one is popular due to an increasing number of supporting tools for its creation (e.g. 

Generic Eclipse Modeling System, or Microsoft Visual Studio DSL); the former 

one usually brings higher productivity. DSLs can be classified as either internal or 

external. Internal DSLs are only extensions of existing general-purpose computer 

languages. They are sets of functions, data structures, and conventions applied to 

existing languages, such as C++ or Java. On the contrary, external DSLs are independent 

languages that have been entirely designed for their specific purpose. 

Generally, a DSL “program” can be viewed as a text file, which is then interpreted 

(or compiled) by the corresponding engine or subsystem. The great advantage 

of properly-designed DSLs is that they are both: 

• Human-readable and understandable (in comparison with, for example, 

XML-based languages, which are also sometimes considered to be humanreadable), 

and 

• Machine-processible, since they have formally defined syntax and semantics. 

DSLs are primarily used in software engineering where they can help overcome 

the gap between the worlds of domain experts and implementers of software 

systems. Their design and implementation are challenging tasks since they require 

expert knowledge of both the problem domain and the area of computer languages, 

language processors, compilers, and interpreters. 

CLs (DSLs) have promising potential to be utilized within modern C2 systems. 

This potential comes from the fact that military application domains have established 

their own terminology with quite formal syntax and semantics [5] as well 

as a standardized way of information exchange [6]. Currently probably the most 

significant initiative within NATO connected with the utilization of artificial CLs 

is a series of projects and activities connected with the development of the Coalition 

Battle Management Language (C-BML) [7], [8], [9], [10]. The objective was to “define 

an unambiguous language to describe a commander’s intent, to be understood by 

both live forces and automated systems, for simulated and real world operations. 

The resulting language is intended to be applicable not only to simulation systems,


211 

but also to operational command and control systems, and robotic systems” [7]. 

The language developed on the basis of Command and Control Lexical Grammar 

(C2LG) with a GUI editor [8], [9] is an XML-based one and a series of experiments 

and demonstrations has been undergone with the aim to prove that C-BML 

is a promising tool for the exchange of orders and reports between individual C2 

systems and constructive simulators [10]. Since the author of this contribution 

has not been involved in the aforementioned projects, in the rest of the paper we 

will try for an “independent” view of the topic. 

We consider DSLs to be a supplementary technology that could be used together 

with the mainstream ontology and semantic web technologies. In the case 

of C2 systems we see the following areas of utilization of DSLs: 

• Specification and modeling tools in the process of development of C2 

systems, and 

• Subsystems of C2 systems themselves. 

In this paper we will consider the latter possibility of utilization. A DSL subsystem 

can be incorporated into the architecture of a C2 system (Fig. 1). The DSL 

subsystem is used by the User Interface and/or System Integration Interface subsystems 

and its role is to process inputs in the form of documents prepared in the DSL. 

These documents can have both textual and graphic forms containing, for example, 

observed and human-processed information about the battlespace awareness and 

knowledge that can influence the Common Operational Picture (COP), or they 

could also contain direct commands that could be processed by the Executive 

Control Subsystem, which could disseminate them to the appropriate entities. 

Figure 1. Elements of an architecture of a C2 system that are interesting from a DSLs point of view 


Multinational character of military units and operations as well as C2 systems 

integration challenges leads us to the idea of DSLs with multilingual support. With 

multilingual support we mean DSLs with different syntax, but with mutually related 

semantic processing [11], [12]: At first sight, a language used e.g. in a U.S. system 

would seem to be different than that in a Slovak system, but the tasks that can be 

described by language constructions in both systems would probably be very similar. 

Similarly, in the case of C2 system integration an XML-based language would 

be preferred (as in the case of [10]). On the other hand, analogically as the great 

majority of programming languages is not XML-based, when the primary target 

of the language is a human, an XML-based language probably would not be 

the preferred choice. 

Now let us look at the syntactical and semantic aspects of CLs, bearing in mind 

multilingual character of DSLs. 

II. Syntax, semantics, and processing of computer languages 

In order to be able to be processed by machines CLs need to have exactly 

and unambiguously specified their syntax and semantics. Syntax of CLs is usually 

specified by means of context-free grammars (CFGs) or from CFGs derived 

Backus-Naur forms (BNFs) [2], [13], [14], [15]. 

A context-free grammar is a 4-tuple 

G = (N, T, P, S), (1) 

where N is a finite set of non-terminal characters (or variables), T is a finite set 

of terminal characters (or terminals), S, SÎN is the starting symbol of the grammar 

from which each derivation starts, and P is a finite set of productions (or rewriting 

rules) of the form 

B → α, (2) 

where BÎN is the left-hand side and αÎ(NÈT) * is the right-hand side of the production. 

When designing a DSL with multilingual support, it seems to be rational to 

separate its abstract syntax from its concrete syntaxes. For example, if we need two 

language representations, we will use a common abstract syntax and two concrete 

syntaxes. Both abstract and concrete syntaxes can be expressed using CFGs (1) and 

in both cases syntax of individual productions has to be designed with respect to 

semantic processing of the productions. 

The grammar expressing abstract syntax is not intended to be directly used 

by the parser, therefore it does not have to be unambiguous nor deterministic 

context-free of a specified type. It should define elements, or concepts, that make 

up a language (regardless of the concrete form of the language) and the rules for 

composition of these elements [12]. When designing an abstract syntax of a lan-


213 

guage, a good starting point is to create a domain model of the language [2], [16]. 

The grammar expressing concrete syntax should come out of the one describing 

abstract syntax and should mainly populate it with concrete lexical elements and 

specifics of the concrete language representation. Lexical elements (i.e. terminal 

symbols of the CFG) are usually simple enough to be described by means of regular 

expressions and recognized by finite-state automata [13], [15]. The grammar 

describing the concrete syntax is directly used by the parser. Therefore, when designing 

concrete syntax of a particular CL, it is necessary to cope with the following 

challenges at the same time: 

• The concrete syntax should be based on natural language constructions 

commonly used in the particular context in the problem domain; otherwise 

there would be a high risk that the users would refuse to use the DSL. 

For that reason, the knowledge of the problem domain is very important. 

• In order to be parseable, the CFG should be a deterministic context-free 

grammar of a type corresponding to the particular type of parser used (most 

often, LL(1) or LALR(1)). This requirement is connected with the unambiguousness 

of the language generated by the CFG (although there are 

parsing techniques that are able to cope with “controlled ambiguousness” 

of the language being processed [13]) as well as the computational complexity 

of the process of parsing: an arbitrary context-free language can be 

parsed in O(n 3 ) time [15], but in the case of above mentioned deterministic 

context-free grammars this time-complexity can be reduced to O(n), where 

n represents the length of the language sentence being parsed. 

Generally, there are two main strategies of parsing CLs – top-down, where 

the parse tree of the given input is constructed from the root towards the leaves 

and bottom-up, where the parse tree is constructed in the opposite direction 

[2], [13], [17]. A typical type of top-down parser is a LL(1) parser, which 

is supported by the ANTLR (ANother Tool for Language Recognition) or JavaCC 

parser generators. Most commonly-used bottom-up parsers are LALR(1) parsers, 

which are supported by Yacc/Bison parser generators. In general, bottom-up parsing 

techniques are more powerful than the top-down ones in the sense of the class 

of recognized languages [13]. 

For the reason of semantic processing we can populate the right-hand sides 

of the productions (2) with semantic action symbols. Semantic action symbols play 

an important role in the CL subsystem architecture (Fig. 2). The parser component 

(e.g. of LALR(1) type) is the central controlling unit of the whole CL subsystem. 

It uses the lexical analyzer to recognize lexical elements from the input. When 

the parser comes across a semantic action symbol (while processing a particular 

production or its part), it calls the corresponding semantic routine. Mutual communication 

among semantic routines can be implemented by means of a semantic 

stack maintained by the parser. Concrete techniques for implementing a semantic 

stack depend on the type of parser [13].


Figure 2. Component architecture of the CL subsystem 

III. Example of utilization of abstract and concrete syntax 

and semantics 

To demonstrate the concepts of DSLs with multilingual support in the environment 

of C2 systems, let us consider a simple DSL, in which we want to express 

the following (abstract) concepts: 

• Sequence of commands, where each command could be either move or 

destroy command; 

• Move command – instructing a particular object to move its location to 

particular coordinates; 

• Destroy command – instructing a particular weapon system to destroy 

a target at particular coordinates; 

• An object could be either a weapon system or a (military) unit; 

• Unit, weapon system and coordinates could be lexical elements (depicted 

in bold). 

The domain model of the language (Fig. 3) can be expressed using a UML 

class diagram with generalization and aggregation relationships. 

Consecutively the abstract syntax of the language can be expressed with 

a CFG with the following productions (including semantic action symbols – their 

identifiers start with #): 

1. → 

2. → ε 

3. → 

4. → 

5. → #process_move 

6. → #process_destroy 

7. → 

8. → 

9. → unit #process_unit


215 

10. → weapon_system #process_weapon_system 

11. → coordinates #process_coordinates 

Figure 3. Domain model of the DSL (Source: Author) 

Now let us turn to the concrete syntaxes. In Language Representation 1 

(e.g. U.S.) we require: 

• Commands finished with semicolons (;); 

• Concrete syntax of the move command is move to ; 

• Concrete syntax of the destroy command is destroy by 

. 

These concrete language requirements can be fulfilled using the following 

productions: 

1. → ; 

5. → move to #process_move 

6. → destroy by 

#process_destroy


In Language Representation 2 (Slovak) we require: 

• Commands finished with dots (.); 

• Concrete syntax of the move command is Presuň do ; 

• Concrete syntax of the destroy command is Znič zbraňou 

cieľ . 

Similarly, these concrete language requirements can be fulfilled using the following 

productions: 

1. → . 

5. → Presuň do #process_ 

move 

6. → Znič zbraňou cieľ 

#process_destroy 

The aim of semantic processing is to properly interpret language constructs 

that are recognized by the parser. Of course, semantic meaning of the corresponding 

language constructs in both language representations should be the same and 

the aim is also to utilize language-independently as much of the semantic processing 

as possible. Lexical elements (in our example, key words, identifiers of military 

units and weapon systems and GPS coordinates) might be language-dependent 

and that is why a separate lexical analyzer has to be constructed for each language 

representation. Another aspect that must be taken into account during lexical as well 

as semantic processing comes from different naming conventions, measurement 

units, data formats and representations, etc. 

For example, in our grammars describing concrete syntaxes we can derive 

the following semantically equivalent language constructs: 

• move Platoon 1 to N49˚4'1,21'' E19˚35'53,62''; destroy N49˚5'3,2'' 

E19˚34'33,12'' by Tank 1; 

• Presuň Čata 1 do 49˚4‘1,21‘‘N 19˚35‘53,62‘‘E. Znič zbraňou Tank 1 cieľ 

49˚5‘3,2‘‘N 19˚34‘33,12‘‘E. 

For the majority of the semantic routines it is necessary to pass some data 

(called semantic attributes) to other semantic routines. For example, the semantic 

routine #process_coordinates needs to pass the GPS coordinates recognized 

by the lexical analyzer to the semantic routines #process_move or 

#process_destroy. This task can be accomplished using a semantic stack [13]. 

A semantic stack is a second stack maintained by the parser which contains semantic 

records associated with the terminals and variables of productions being 

parsed. Each semantic record can contain arbitrary information (semantic attributes) 

that needs to be passed between individual semantic routines. The semantic 

records associated with the variables of individual productions are depicted 

in the pseudocode of semantic routines in the same way as the corresponding 

, but using the Courier font. Next follows the description 

of semantic routines:


217 

#process_move 

{ 

Call the Executive Control Subsystem 

to process the move command 

instructing the object to 

move to the coordinates 

; 

} 

#process_destroy 

{ 

Call the Executive Control Subsystem 

to process the destroy command 

instructing the weapon system 

to 

destroy the target at the 

coordinates ; 

} 

#process_unit 

{ 

← unit recognized by the 

lexical analyzer; 

} 

#process_weapon_system 

{ 

← weapon system 

recognized by the 

lexical analyzer; 

} 

#process_coordinates 

{ 

← coordinates 

recognized by the lexical analyzer; 

} 

The common abstract syntax tree of the above mentioned language constructs 

(i.e. independent of a concrete language representation) is depicted 

in Fig. 4, the parse tree for the Language Representation 1 is in Fig. 5. In both 

figures the flow of semantic attributes during semantic processing is depicted. 

We would like to point out that the semantic information contained in the semantic 

attributes (.object_type, .unit_type, .coordinates, etc.) 

is in a unified (canonical) form regardless of the concrete language representation 

used. To demonstrate the power of the presented language processing techniques 

we intentionally used different formats of GPS coordinates and different order 

of “weapon system” and “target” clauses in the individual language representations 

in the examples of language constructs.


Figure 4. Abstract syntax tree, with the flow of semantic attributes 

Figure 5. Parse tree for a concrete language representation, with the flow of semantic attributes 

IV. Conclusion 

The aim of this paper was to introduce computer language syntax and semantic 

processing techniques as a means to achieve semantic interoperability in the selected 

areas of C2 systems. We tried to point out the parallels between PLs and DSLs exploitable 

in military information systems regarding their syntactical and semantic 

processing. The role of a trained military commander in relation to a DSL can be 

analogical to the role of a computer programmer in relation to a programming 

language. Other aspects of utilizing CLs within the military domain are connected 

with the NNEC and system integration challenges [18], [19], [20]. In this paper we 

also tried to introduce the notion of DSLs with multilingual support in the context 

of C2 systems. Due to national information systems integration and interoperability


219 

challenges we find it interesting to study and design DSLs with different concrete 

syntaxes, but with mutually related semantic processing; from this point of view, 

C-BML [10] can be viewed as one language representation suitable for a particular 

purpose (system integration) and JC3IEDM [6] as a basis for structure of the semantic 

information being processed. The principles of language design and processing 

presented in this paper could lead to the design of the whole family of “BMLs”, each 

tailored for particular audience or purpose, together with their language processors. 

Considering the principles C-BML has been designed on (e.g. 5 Ws concepts [8]) this 

goal seems to be achievable. The goal can be accomplished by utilizing an abstract 

syntax of the language and defining the great majority of semantic processing on it: 

this approach can lead to faster development of DSL subsystems within information 

systems. We have tried to give a simple example of designing a DSL with an abstract 

syntax and two concrete syntaxes based on the domain model of the language. 

The grammar described in the example was designed for demonstration purposes 

only and should not be considered as a result of deeper research in this area. 

References 

[1] R.W. Sebesta, Concepts of Programming Languages (9th Edition), Addison Wesley, 

Boston, 2009. 

[2] M. Fowler, Domain-Specific Languages, Addison-Wesley Professional, Boston, 2010. 

[3] A. Deursen, P. Klint, and J. Visser, “Domain-specific languages: an annotated 

bibliography,” SIGPLAN Notices, vol. 35, no. 6, 2000, pp. 26-36. 

[4] A. Kleppe, Software Language Engineering: Creating Domain-Specific Languages 

using Metamodels, Addison-Wesley Professional, Boston, 2008. 

[5] NATO STANAG 2014: Formats for Orders and Designation of Timings, Locations 

and Boundaries, North Atlantic Treaty Organisation, 2000. 

[6] NATO STANAG 5525: Joint C3 Information Exchange Data Model – JC3IEDM, 

North Atlantic Treaty Organisation, 2007. 

[7] C. Blais, M.R. Hieb, and K. Galvin, “Coalition battle management language (C-BML) 

study group report,” 05F-SIW-041, Fall Simulation Interoperability Workshop 2005, 

Orlando, FL, September 2005. 

[8] U. Schade and M.R. Hieb, “Formalizing battle management language: A Grammar 

for Specifying Orders,” Spring Simulation Interoperability Workshop, Huntsville, 

Alabama, April 2006. 

[9] K. Rein, U. Schade, and M.R. Hieb, “Battle management language (BML) as an enabler,” 

IEEE International Conference on Communications, ICC 2009, Dresden, Germany, 

June 2009. 

[10] K. Heffner, A. Brook, N. de Reus, L. Khimeche, O.M. Mevassvik, M. Pullen, 

U. Schade, J. Simonsen, and R. Gomez-Veiga, “NATO MSG-048 C-BML final report 

summary,” 2010 Fall Simulation Interoperability Workshop (Paper 10F-SIW-039), 

September 2010, Orlando, FL.


[11] Ľ. Dedera, “Domain-specific languages for command and control systems,” Science 

& Military, no. 1, vol. 5, 2010, pp. 40-46. 

[12] J. Porubän, M. Sabo, J. Kollár, and M. Mernik, “Abstract syntax driven language 

development: defining language semantics through aspects,” FML ‘10: Proceedings 

of the International Workshop on Formalization of Modeling Languages, Maribor, 

Slovenija, 2010. 

[13] J. Fisher and R.J. LeBlanc, Crafting a Compiler with C, Benjamin – Cummings 

Publishing Co., New York, 1992. 

[14] N. Chomsky, Aspects of the Theory of Syntax, The Massachusetts Institute 

of Technology, 1965. 

[15] M. Sipser, Introduction to the Theory of Computation, Thomson Course Technology, 

2nd edition, 2006. 

[16] M. Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, Boston, 

2003. 

[17] D. Jurafsky and J.H. Martin, Speech and Language Processing, Upper Saddle River, 

NJ: Pearson Education, 2nd Edition, Chapter 13 “Syntactic Parsing”, 2009. 

[18] D.S. Alberts, J.J. Garstka, and F.P. Stein, Network Centric Warfare: Developing 

and Leveraging Information Superiority, CCRP, 2000. 

[19] J. Baráth and M. Harakaľ, “Nové prístupy v hodnotení systémov riadenia a velenia 

v prostredí NNEC = New approaches to evaluating command and control systems 

in NNEC environment,” Science & Military, no. 2, vol. 3, 2008, pp. 40-43, in Slovak. 

[20] M. Turčaník, “New trends in modeling and simulation in military applications,” KIT 

2011 – Communication and Information Technologies: 6th International Scientific 

Conference, October 2011, Tatranské Zruby, Slovakia.

Semantic Model for Context – Aware Service 

Provision in Disadvantaged Network Environment 

Joanna Śliwa 

C4I Systems Department, Military Communication Institute, Zegrze, Poland, 

j.sliwa@wil.waw.pl 

Abstract: The use of ontologies can facilitate many processes in C4I systems. They can be used 

to provide unambiguous description of data sent among systems as well as automate realization 

of services in dynamic NEC environment. The use of ontologies has been also proposed in the area 

of mobile computing, where the ability to react to dynamic changes of the environment with minimal 

human intervention is a fundamental requirement. A common element in the architecture of ubiquitous 

applications is a proxy, an element in charge of executing a number of content adaptations on 

behalf of one or several client applications running on mobile devices. These adaptations are triggered 

by specific conditions involving the mobile devices on which the applications execute. The article 

describes proposal of the semantic model for context – aware service provision in disadvantaged 

environment that is used to dynamically select adaptation actions performed on SOAP messages 

flowing from the service to the client entity. 

Keywords: adaptation, AFRO, ontology 


Modern coalition operations are conducted in a dynamic environment, usually 

with unanticipated partners and irregular adversaries. In order to act successfully 

they need technical support that gives modularity and flexibility in connecting heterogeneous 

systems of cooperating allies. To support such co-operation in the NATO 

community, the Service Oriented Architectures (SOAs) [1] are recommended 

as the crucial Network Enabled Capability (NEC) enabler [2-4]. 

The most mature implementation of SOA, recommended by NATO and widely 

applied in the commercial sector, are Web Services (WS) [5]. WSs are described by 

a wide range of standards that deal with different aspects of their realization, transport, 

orchestration, semantics, etc. They provide the means to build a very flexible 

environment that is able to dynamically link different system components to each 

other. These standards are based on the eXtensible Markup Language (XML) and 

have been designed to operate in high bandwidth links. XML gained wide acceptance 

and became very popular for the reason that it solves many interoperability


problems, is human- and machine-readable and facilitates the development of frameworks 

for software integration, independent of the programming language. Nevertheless 

it undoubtedly adds significant overhead, both in terms of necessary 

computation power and consumption of network resources while being transported. 

In the military domain the challenge is therefore to apply SOA in low bandwidth 

tactical communications systems, which usually cope with high error rates and 

frequent disruptions. Such networks are usually referred to as disadvantaged ones. 

Figure 1. Client – server relations in military network 

The services at the first stage of the Networking and Information Infrastructure 

(NII) [2] development are mainly located on high echelons of command – 

strategic and operational. They are used for planning purposes and provide good 

basis for creating situational awareness and self–synchronization of cooperating 

forces. However information in the system is being exchanged vertically and 

horizontally among mission participants in order to fulfil their tasks, act faster 

and make reliable decisions (see Figure 1). Users at the lowest command levels 

need in particular information about the location and status of their and allied 

forces as well as about the enemy ones. This information from the Force Tracking 

Systems is available at the operational level but not always accessible for the lower 

level commanders. They are usually located in tactical communication systems 

that use radio communications with scarce network resources in terms of high 

delay, error rate, and limited bandwidth. What is more, they are equipped with 

mobile terminals that have limited computational and software resources as well 

as limited battery power. That makes it difficult to provide the user with the same 

service functionality as provided to the users at operational and strategic command 

levels. The tactical user is very often not able to receive nor process a big amount 

of data. The solution that this article focuses on is therefore to enable the client to 

use the service in a limited way (with limited number of information provided or 

provided by a different mechanism) and adapt the service provision mechanism 

to the client’s software and hardware possibilities.


223 

II. Context-aware service provision 

Context – aware applications refer to a general class of mobile systems that 

can sense their physical environment, and adapt their behaviour accordingly. They 

derive from the ubiquitous (or pervasive) computing concept that was presented 

in 1991 by Mark Weiser [7] who set its foundation. This concept developed for 

the commercial applications began the new field of interest of many researchers 

where the area of context-aware applications became an important part. 

In context – aware service provision it is generally important where the client 

is, what are his actions/duties, what terminal is he using, what resources are nearby, 

etc. [8]. In many applications the most important aspect is location but this can be 

extended to include different characteristics (user actions, device, surrounding environment, 

etc.). Context recognition allows users to take full advantage of the local 

capabilities within a given environment, and be able to seamlessly roam between 

several environments, choose different services, even as the defined context change. 

The idea of context – aware service provision was used in the development 

of the Adaptation Framework for Web Service provision in disadvantaged environment 

(AFRO). It is aimed at improving successability of SOAP web services 

invocation in tactical environment, which is characterized by dynamic changes 

in throughput, error rate and delay. Successful service invocation in this case 

is understood as the possibility to deliver response message requested by the client 

from the target service. 

AFRO follows the assumption that in order for a web service to function 

more efficiently it is necessary to minimize the amount of data transmitted to 

the user. The actual traffic flow related to web services’ interactions is burdened 

with the XML overhead which greatly limits communication link goodput. It is 

highly recommended therefore: 

• to improve encoding efficiency, i.e. enhancing the ratio of the user data to 

the management data in the SOAP message, and 

• to reduce the number of unnecessary data (or data that cannot be consumed) 

to the users of degraded networks. 

Limiting the size of traffic flow to the users of wireless networks will improve 

the successability of web service calls and will support users with information 

crucial for their operation in the battlefield. 

Message adaptation actions can be therefore twofold: 

• lossless – e.g. actions that improve message encoding enabling the consumer’s 

side to decode it without losing any of the data and without the transport 

protocol change (e.g. HTTP to MMHS), and 

• lossy – cutting out information that the user agrees to be filtered out. 

Selection of appropriate adaptation action is not a trivial task and needs to be 

based on several types of information. First of all, adaptation does not have to be 

performed when the connections are stable, network has high bandwidth, acceptable


delay, no losses, and therefore, does not provide limitations for web service provision. 

The information about the network state is important in order not to spoil 

time on unnecessary actions. 

The second important aspect is necessity to take into account users’ preferences 

in terms of adaptation. They will be included in, so called, user profile, 

within which the user will state his adaptation preferences, and device profile, which 

defines his terminal’s software and hardware possibilities. This set of information 

is necessary for selecting the actions that would meet the user intentions and, at 

the same time, would not make it impossible for the user terminal to receive and 

decode the message. This results from the fact that when the message is received 

at the user terminal it is firstly processed by the software libraries installed on it. 

Existence of particular software libraries implies therefore possibility of particular 

message encoding actions. Additionally, terminal information can help in parameterizing 

images and video streams that would be directed to the user working 

on a particular device. 

Such an approach makes it necessary to provide a mechanism for provisioning 

and then efficiently using information about the user, his terminal, the network and 

service invoked. This problem has been defined as the need to identify the context 

of the service call. It has been proposed in the form of ontology that allows to clearly 

define parameters of entities taking part in the information distribution process and 

then, on the basis of the set of rules and the rule engine, efficiently support the decision 

process enabling to take adaptation actions improving service successability. 

On the basis of previous considerations the architecture of the Adaptation 

Framework for Web Service Provision (AFRO) has been proposed (see Figure 2). 

It bases on the Decision Support Engine that uses information about the context 

of the service call as the input data, and, on the basis of ontology rules, defines 

the adaptation actions to be triggered on the SOAP body and SOAP attachments by 

the Adaptation engine. Such a modified SOAP message has smaller size than the original 

one and as such, is sent to the requester. 

The ontology proposed and the rule engine strongly support dynamic selection 

of adaptation actions appropriate for the user. They are used by the Decision 

Support Engine that returns in response a set of actions. These actions derive from 

the Proxy functionality. They can be embedded (e.g. take the form of the Adaptation 

engine, see Figure 2) or, taking different approach, distributed. The latter one can be 

implemented using SOA services orchestration. After the Proxy selects appropriate 

actions for the user, it searches for the services that will provide appropriate 

mediation (will carry out the action). 

Whatever approach to Proxy implementation one can take, the application 

of the Decision Support Algorithm and the proposed adaptation ontology (AAO) 

will supply him with the dynamic selection of actions to be taken. 

It is also assumed that the Proxy will make use of information provided by 

external element – Network Monitoring Element that will support it with informa-


225 

tion about currently observed network performance on the link to the user. This 

performance information (in terms of throughput, delay and error rate) will be 

used by the decision support algorithm. In case the network is categorized as disadvantaged, 

the Proxy will make the modifications stronger, decreasing the amount 

of information that is sent to the user (in terms of image modifications), however 

making it more probable to be transferred to the consumer. 

Figure 2. AFRO architecture framework 

A. Reflecting user requirements 

One of the elements of the proposed Method is context of the service call. 

In case of the AFRO proxy it is perceived as a collection of information: 

• about the user: What modifications of the SOAP messages’ content is the user 

willing to accept What device is he using as his end terminal What access 

network is he using 

• the device: What are the characteristics of the device hardware (resolution 

of the screen, CPU frequency) What are the characteristics of the device 

software (operating system, supported libraries) 

• the service: What is the service description 

• and underlining network: What is the network type What is the current 

link performance 

The reason for the dynamic adaptation to be based on the pre-distributed 

information is that the user – from the point of view of his activities – may not 

wish the mechanism to modify contents of the message and modify the attachment 

(resize, compress, decrease colour depth). In order for the non-standard XML 

encoding to be used at the receiver, the device must be equipped with appropriate 

libraries. It is very often an issue in mobile devices that use limited operating systems


and limited set of libraries and do not support software implementations regularly 

used in laptops or PCs. The environment the adaptation framework is to be used 

in assumes utilization of mobile hand-held devices the configuration of which 

(software and hardware) is important in terms of successful web services adaptation. 

The context of the service call has been modelled semantically with the Web 

Ontology Language (OWL DL [9]), which is the most powerful ontology description 

language and promising in terms of further processing, rule enforcement and 

inference [10]. 

The context information has static and dynamic elements. It generally consists 

of: user context (adaptation preferences – static), device profile (static), service 

context (QoS profile – static), network context (Link performance – dynamic). 

B. Application of rules 

For the purpose of selecting the adaptation actions the decision engine uses 

the AFRO Adaptation Ontology (AAO) describing all the actions that can be taken 

by the proxy, reflecting the user preferences. In order to make use of the adaptation 

ontology a set of rules has been defined. Rules are important in OWL to state facts 

about instances of classes. 

The rules in AFRO define requirements for particular actions based on information 

that are provided in the context of the service call. They have been defined 

using the Semantic Web Rule Language (SWRL) [11], combining sublanguages 

of the OWL DL and Lite with those of the Rule Markup Language. OWL Full constructs, 

such as classes, property values, are not supported by this language so that 

it does not support direct reasoning about classes or properties. It is not possible 

to write a rule that, for example, deduces some new knowledge based on the fact 

that one class is a direct subclass of another. For the same reason, RDF (Resource 

Description Framework) [12], RDFS (RDF Schema), or OWL constructs such 

as owl:Class or owl:DatatypeProperty, cannot be used in rules. 

Figure 3. Entering instances to AAO


227 

Figure Labels: Use 8 point Times New Roman for Figure labels. This is because 

the OWL is based on the Open World Assumption (OWA) that states that anything 

might be true unless it can be proven false. Open World Assumption states therefore 

that everything we don’t know is undefined. This is contradictory to the Closed 

World Assumption that refers to “everything we don’t know is false”. That is why 

according to OWA we cannot specify that a fact f(x,y) can be true when x and y 

are instances and there are other properties or facts defined. In order to provide 

additional facts to ontology, that will add e.g. available actions to be performed for 

particular call, the rules are proposed. 

C. Gathering context data 

AFRO proxy can work in the request – response mode which resembles 

the situation when the user invokes the target service through the AFRO proxy and 

publish – subscribe mode – when the user subscribes to data flowing from the target 

service. In both cases before the actual service data will be distributed, the static 

context information should be pre-distributed to the AFRO proxy (see Figure 3). 

The dynamic elements of the context should be gathered at run time by agent 

entities and forwarded to the proxy. In this case they relate to the current link 

performance. 

The architecture of the AFRO Proxy assumes support for dynamically selecting 

web service adaptation actions in run time. It assumes the SOAP body and 

SOAP attachment adaptations that limit the size of SOAP messages. The actions 

taken by the Proxy can be internally implemented, or can be served according to 

SOA concept, by external entities. AFRO Proxy architecture enables to add additional 

plugins that can be used for further actions. What is more, since the “heart” 

of the method is the decision support engine that bases on ontology, a set of rules 

and the rule engine, it can be easily used in the process of services composition, 

that would make use of particular services as adaptation actions, and would send 

adapted messages in return. 

Figure 4. AFRO upper ontology


III. AFRO adaptation ontology (AAO) 

Semantic model of the service call context is the main subject of this article. 

It should reflect all the elements of the web service call, which can be used in the decision-making 

process to select appropriate adaptations. It must characterize static 

elements that can be defined before service call is executed, as well as dynamic elements 

that depend on the type of request, type of response and temporary network 

performance parameters. 

Among many known methods of context modelling, semantic description using 

ontologies gives the most satisfactory results [10]. In general, ontology describes 

formally a domain of discourse. In the computer engineering, ontologies are usually 

employed to provide semantic interoperability among cooperating systems and 

increase the level of automatic reaction to events (e.g. sent/received information). 

In this article, ontology is used to define the context of the service call, making 

it possible to further process it and make decisions about the adaptation actions. 

For the purpose of the AFRO proxy the context has been defined using the most 

well-known and semantically rich languages, i.e. RDF, RDFS and OWL (Web 

Ontology Language). The context is created based on User profile, Device profile, 

Network profile and Service profile. AAO was developed according to the IOEM 

ontology engineering ontology [14]. 

These four entities are connected by the AAO upper ontology (see Figure 4). 

According to this ontology the User is connected to the infrastructure by particular 

Network and uses as its end terminal particular Device. It invokes the Service. These 

four entities form the context of the service call. Every User has a set of prohibited 

and preferred Actions. They can be set at the initial stage of gathering user data 

(the user may indicate them directly) or automatically selected by the ontology 

rules on the basis of information about the Device. 

This upper ontology presents relationships among the main entities of the model. 

Behind the User, Network and Device there are defined profiles that describe 

their main characteristics. 

The information about the User and his device, received by the AFRO Proxy, 

after being analysed, is saved in the AFRO Adaptation Ontology (AAO) instances. 

The User and Device profiles are therefore used to unambiguously express user preferences 

in terms of adaptation actions and express his device limitations. AAO enables 

to express the Display limitations, CPU frequency limitations, list unsupported MIME 

types [13] (e.g. particular formats of images or video) and encoding mechanisms. 

After the user logs in, his every request is perceived as a Service call. On 

the basis of rules defined in the Proxy, appropriate adaptation actions are selected. 

An exemplary rule defining the ChangeResolutionAction as preferred for 

the user when his device has low CPU is as follows: 

uses(x, y)^hasHWlimitations(y, z)^LowCPU(z) -> 

hasPreferredAction(x, ChangeResolutionAction)


229 

The Action class is divided into two subclasses: SOAPAdaptationAction 

and AttachmentAdaptationAction. They allow for creating different actions that 

the Proxy can provide (or can invoke in an external entity). 

A. Network state determination 

Network state is determined on the basis of information received from external 

entity – Network Monitoring Element. It is assumed that this element will monitor 

the link to the user at supply the AFRO Proxy with information about the current 

link performance in terms of currently observed Throughput, Packet Error Rate 

(PER) and Delay of packets transmission. This information will be checked whenever 

the decision process is to be performed. 

Preliminary researches that have been carried out in [16] proved that web 

services efficiency is decreased in particular ranges of values of these three QoS 

parameters. On the basis of obtained results there have been defined three levels 

of the network state, i.e. “very good”, “constrained” and “degraded” network state 

defined in the following way: 

• Degraded network state level is when PER ≥ 10% or delay ≥ 300 ms or 

throughput


• Class: DecreaseColourDepth, superclass: AttachementAdaptation, individuals: 

DecreaseColourDepthAction, comment: Decreases colour depth 

of the images, 

• Class: DecreaseQuality, superclass: AttachementAdaptation, individuals: 

DecreaseQualityAction, comment: Changes quality of the JPEG images 

increasing their compression ratio, 

• Class: DiscardAttachment, superclass: AttachementAdaptation, individuals: 

DiscardAttachmentAction, comment: Discards attachment from the message. 

The adaptation actions can be LosselessAdaptationActions and 

LossyAdaptationActions. The lossless are e.g. compression or binary 

coding of SOAP messages. Lossy would be e.g. filtering of SOAP messages and all 

Attachment Adaptation Actions. 

The AttachmentAdaptationActions are the actions that can manipulate 

the SOAP attachments. In this article there has been considered example 

of JPEG image modifications, but other actions can be defined for further purpose 

of using the AAO. In the image adaptation actions one can find therefore decrease 

colour depth action, compression action and decrease image quality action. These 

are all lossy adaptations that result in decreasing the level of information that is then 

transferred to the client. 

The adaptation ontology can be further expanded as additional components 

reflecting actions available in the AFRO proxy will be introduced. 

C. Rules supporting the decision process 

The TBox statements define properties about entities, however they cannot 

define conditional statements, e.g. If a Student studies Maths then he is a Maths 

Student. For this purpose it is recommended to use rules and rule engine that allow 

for adding certain facts to the knowledge base on the basis of existing axioms. 

Rules are of the form of an implication between an antecedent (body) and 

consequent (head). Their meaning can be read as: whenever the conditions specified 

in the antecedent hold, then the conditions specified in the consequent must 

also hold. In relatively informal “human readable” format: 

antecedent (body) → consequent (head). 

Both the antecedent (body) and consequent (head) may consist of zero or more 

atoms. An empty antecedent is treated as trivially true (i.e. satisfied by every interpretation), 

so the consequent must also be satisfied by every interpretation. 

When a consequent is empty, it is treated as trivially false (i.e. not satisfied by any 

interpretation), so the antecedent must also not be satisfied by any interpretation. 

When both antecedent and consequent are conjunctions of 1 – n atoms the rule 

takes the following form: a1 ^ ... ^ an. Variables are indicated using the standard


231 

convention of prefixing them with a question mark (e.g. x). Using this syntax, there 

can be defines a rule asserting that if a parent (x2) has a child (x1) and a brother 

(x3), the brother is an uncle to the child, i.e.: 

hasParent(x1,x2) ^ hasBrother(x2,x3) → hasUncle(x1,x3) 

The rules can be defined using a few formal languages, e.g. Jess rule language, 

JessML, RuleML (Rule Markup Language), SWRL (Semantic Web Rule Language). 

Due to the easiness of defining and processing rules in SWRL, this language has been 

selected to be used in the article. It uses the human-readable syntax as presented 

above together with the abstract and XML syntax. 

The AAO ontology has been enriched with the set of rules that enable to define 

actions that can be performed by the Proxy. The use of rules automates the decision 

process. Moreover, since the rules are not hard-coded, the semantic programming 

tools enable to easily define additional rules or modify existing ones. 

Practical tests of the adaptation actions proposed for the AFRO proof of concept 

[16] was the basis for defining decision rules for adaptation decision support 

algorithm that would match user preferences and suit best to available network 

resources. On the basis of the context of the service call and the set of rules additional 

axioms of available adaptation actions are added to the Knowledge Base. 

For instance, if the user’s device has limited display properties, the Proxy should 

decrease Colour depth of the image attachment: 

uses(x, y)^hasDisplayProperties(y, z)^Limited(z)-> 

hasPreferredAction(x, DecreaseColourDepthAction) 

Taking into account user device limitations there have been defined the following 

adaptation rules: 

Rule 1 – Discard PDF; Description: If the user device does not support 

particular format of the MIME attachment (e.g. PDF), the attachment should be 

discarded. Rule content: 

uses(x, y)^hasMIMETypeUnsupported(y, z)^ UnSupportedApplication- 

PDF (z) -> hasPreferredAction(x, DiscardPDF) 

Rule 2 – Discard GIF; Description: If the user device does not support particular 

format of the MIME attachment (e.g. GIF image), the attachment should 

be discarded. Rule content: 

uses(x, y)^hasMIMETypeUnsupported(y, z)^ UnSupportedImageGIF (z) 

-> hasPreferredAction(x, DiscardGIF) 

Rule 3 – Discard JPEG; Description: If the user device does not support particular 

format of the MIME attachment (e.g. JPEG image), the attachment should 


uses(x, y)^hasMIMETypeUnsupported(y, z)^ UnSupportedImageJPEG 

(z) -> hasPreferredAction(x, DiscardJPEG)


Rule 4 – Discard PNG; Description: If the user device does not support particular 

format of the MIME attachment (e.g. PNG image), the attachment should 


uses(x, y)^hasMIMETypeUnsupported(y, z)^ UnSupportedImagePNG (z) 

-> hasPreferredAction(x, DiscardPNG) 

Rule 5 – Discard TIFF; Description: If the user device does not support particular 

format of the MIME attachment (e.g. TIFF image), the attachment should 


uses(x, y)^hasMIMETypeUnsupported(y, z)^ UnSupportedImageTIFF 

(z) -> hasPreferredAction(x, DiscardTIFF) 

Rule 6 – lowCPU; Description: If the user device has CPU with frequency 

lower than 1000 MHz it is a low performance CPU, utilization of which will result 

in high image processing times. If the image attachment has higher resolution 

than the device display, it should be resized. Rule content: 

uses(x, y)^hasHWlimitations(y, z)^LowCPU(z) -> 

hasPreferredAction(x, ChangeResolutionAction) 

Rule 7 – Binary; Description: If the user device has display unit that enables 

to visualize only binary colours (e.g. black-white), the attached image will be displayed 

only in binary colour depth. The image attachment, before being sent should 

therefore have the colour depth set to binary. Rule content: 

uses(x, y)^hasDisplayLimitations(y, z)^Binary(z) -> 


Rule 8 – GreyColour; Description: If the user device has display unit that enables 

to visualize only grey scale, the attached image will be displayed only in grey 

scale. The image attachment, before being sent should therefore have the colour 

depth set to grey scale. Rule content: 

uses(x, y)^hasDisplayLimitations(y, z)^Grayscale(z)-> 


Rule 9 – LimitedColour; Description: If the user device has display unit that 

enables to visualize only limited amount of colours, the image attachment, before 

being sent should therefore have the colour depth decreased appropriately. Rule 

content: 

uses(x, y)^hasDisplayLimitations(y, z)^Limited(z)-> 


Rule 10 – DecreaseQuality; Description: The images, when compressed appropriately, 

do not decrease their readability significantly. When sent to mobile 

devices’ users they should be compressed. Rule content: 

User(x)->hasPreferredAction(x, DecreaseQualityAction)


233 

Rule 11 – GZIP; Description: If the user terminal has the GZIP compression 

support, the GZIP compression is possible to be performed. Rule content: 

uses(x, y)^supportsEncoding(y, z)^SupportsGZIP(z)-> 

hasPreferredAction(x, GZIPcompressAction) 

Rule 12 – EXI; Description: If the user terminal has the EXI encoding support, 

the EXI encoding is possible to be performed. Rule content: 

uses(x, y)^supportsEncoding(y, z)^SupportsEXI(z) -> 

hasPreferredAction(x, EXIencodeAction) 

Rule 13 – FI; Description: If the user terminal has the FI encoding support, 

the FI encoding is possible to be performed. Rule content: 

uses(x, y)^supportsEncoding(y, z)^SupportsFI(z)-> 

hasPreferredAction(x, FIencodeAction) 

IV. Validation 

Ontology evaluation is a process aimed at validation and verification of an ontology 

in terms of its scope, consistency and expressiveness [14]. 

The scope of the AFRO adaptation ontology (AAO) has been set up by 

the problem it was designed to solve. It is aimed at supporting the dynamic selection 

of adaptation actions taken on the SOAP messages exchanged between the web 

service client and server. It defines: 

• entities that take part in the service invocation as classes (User, Device, 

Network, Service, Action class), 

• relationships among entities as object properties (connects isConnectedBy, 

hasAdaptationPreferences, hasDeviceProperties, hasPreferredAction, 

hasProhibitedAction, usedBy uses, hasNetworkType, isInvokedBy 

invokes), 

• characteristics of entities as data type properties (userName, deviceName, 

qualityValue, resolutionValue, colourDepthValue). 

The TBox ontology model describes relationships among defined entities. 

On its basis knowledge about the service call context (defined in ABox entries) 

is collected. After each user registers to the proxy, the knowledge about the user 

preferred, prohibited actions and his device properties are saved in ABox entries. 

This allows to set the Initial Service Call Context (ISCC). After the network state 

is checked, the final AFRO defined actions set (ADA) is created. 

The AAO is the basis for running the decision support algorithm and setting 

the actions that should be performed by the AFRO Proxy. 

Ontology rules defined for the purpose of selecting the actions take into account 

the following cases: 

• the terminal does not support particular file format → the attachment 

is discarded (rule 1-5),


• the terminal supports particular encoding techniques → the encoding actions 

is added to the list of preferred (rule 11-13), 

• the terminal has too low CPU frequency (processing power) → big images 

will be difficult to be processed – change image resolution (rule 6), 

• the terminal has limited colour display – decrease colour depth (rule 7-9), 

• the terminal is connected by disadvantaged network link (general rule – 

true for all cases) – decrease quality (rule 10). 

Moreover, the preferred and prohibited actions that the user defined are also 

taken into account. They may derive from the role of the user and his duties at 

the battlefield. 

The AAO defines all entities that are necessary to take appropriate adaptation 

decision and enables to automatically select appropriate adaptation actions. Its 

scope covers the required level of detail in describing the entities and relationships 

among them taken in the initial phase of ontology development. It covers so called 

competency questions [14] defined for the purpose of AAO. Additionally, the set 

of rules monitor all basic terminal characteristics that may influence usability 

of messages delivered to the user. 

The second ontology evaluation step consists in checking the ontology consistency. 

According to [17] ontology is consistent (also called satisfiable) when it does 

not contain a contradiction. The lack of contradiction can be defined in either 

semantic or syntactic terms. The syntactic definition states that a theory is consistent 

if there is no formula P such that both P and its negation are provable from 

the axioms of the theory under its associated deductive system. 

The ontology model that contains formal definitions of classes, properties 

and individuals allows inferring new knowledge from knowledge that is already 

present. The fact that it is based on formal description logic makes it prone to 

logical reasoning and enables to infer knowledge from existing facts 1 and axioms 2 . 

The aao.owl model has been verified in the Protegè 3.4.6 using the Pellet 1.5.2 

reasoner for consistency on the machine with following configuration: Processor: 

Intel Core i7 (2 cores 2,8 GHz each); RAM: 6 GB; Operating System: Windows 7 

(64 bit). The consistency check on this machine was successful. AAO has been 

proven consistent. 

V. Summary 

This article presents semantic description of the service call context defined 

for the purpose of the Adaptation Framework For Web Services Provision (AFRO). 

1 

2 

“Fact states information about a particular individual, in the form of classes that the individual belongs to 

plus properties and values of that individual” [18]. 

“Axioms are used to associate class and property identifiers with either partial or complete specifications 

of their characteristics, and to give other information about classes and properties. Axioms used to be called 

definitions, but they are not all definitions in the common sense of the term and thus a more neutral name 

has been chosen.”[18].


235 

AFRO defines a mechanism for effective web services invocation in tactical 

networks that are considered disadvantaged in terms of available throughput, 

delay and error rate. Its implementation, in the form of AFRO Proxy, performs 

so called adaptation actions, which are modifications of the SOAP XML messages 

by changing their encoding to more efficient or cutting out information 

that are accepted to be removed by the service requester. With these actions, 

the sizes of messages are significantly diminished making them better tailored 

to the tactical networks. 

AFRO provides dynamic selection of adaptation actions to be triggered by 

the Proxy on the basis of user preferences and his terminal limitations. It takes 

advantage of the fact that limited capabilities of the user’s device makes it impossible 

to receive by or process some pieces of data. It is therefore necessary to 

conserve network resources not sending the data that is not going to be consumed 

by the user. 

The AFRO Adaptation Ontology (AAO) semantically models the user preferences 

in terms of the adaptation actions, his device possibilities and limitations 

as well as current network connection performance. This allows to unambiguously 

describe the service call context and, on the basis of ontology rules, provide 

adaptation actions tailored to particular user, his device and current network 

performance. 

It is assumed that the AFRO Proxy will cooperate with an external element 

that is able to assess the current network performance on the link that the user 

employs to invoke web service. This link will be the bottleneck for communications 

with the user. On the basis of information about currently available throughput, 

delay and packet error rate on that link the proposed in the article network 

state classification algorithm classifies the network as very good, constrained or 

degraded. 

The proposed AFRO architecture can be exemplified by the implementation 

in the web service Proxy that has a web service interface and follows SOA fundamental 

assumption of loosely – coupled entities. The user can therefore discover 

the existence of the AFRO Proxy in the service registry, and subscribe to it, when 

necessary. Additionally, the modular architecture of the Proxy enables it to be 

enhanced with service orchestration module. 

AFRO adaptation ontology (AAO) defines all entities that are necessary to 

take appropriate adaptation decision and enables to automatically select appropriate 

adaptation actions. Its scope covers the required level of detail in describing 

the entities and relationships among them. Additionally, the set of rules reflects all 

basic terminal characteristics that may influence usability of messages delivered to 

the user. It is used to build Knowledge Base about the users, their terminals and 

networks they are connected by in order to dynamically and automatically define 

the actions that the AFRO Proxy needs to take in particular network performance 

conditions. For the purpose of network state classification there has been proposed


an algorithm that bases on information that would be received from an external 

Network Monitoring Element. 

There has been proven that the proposed AAO model is semantically and 

syntactically correct and consistent. Reasoning over it provides the possibility to 

support the adaptation actions decisions taking into account the user preferences 

deriving from his role and limitations of his terminal. The SWRL rules defined for 

AFRO strongly support the automatic process of defining the preferred actions. 

The proposed adaptation mechanism gives promising effects for low level 

commanders located at the battlefield, which can be supplied with information 

generally available on high command levels which, up to now, were very rarely 

distributed to tactical networks. 

References 

[1] J.A. Estefan, K. Laskey, F.G. McCabe, D. Thornton, Reference Architecture 

Foundation for Service Oriented Architecture, Version 1.0, OASIS Committee Draft 

02, 14 October 2009. 

[2] M. Booth, T. Buckman et al, NATO Network Enabled Feasibility Study Volume II: 

Detailed Report Covering a Strategy and Roadmap for Realizing an NNEC Networking 

and Information Infrastructure, version 2.0”, NATO C3 Agency, June 2005. 

[3] NATO Architecture Framework (NAF) version 3.0, June 2007. 

[4] NATO C3 System Interoperability Directive (NID), AC/322-D(2004)0001(INV) 

Annex C. 

[5] J. Busch, An investigation into deploying web services, TN – 1229, NC3A, December 

2007. 

[6] R. Faucher, R. Ladysz, D. Miller, S. Musman, S. Raparla, D. Smith, Guidance on 

Proxy Servers for the Tactical Edge, The MITRE Corporation, MITRE TECHNICAL 

REPORT no. 060175, September 2006. 

[7] M. Weiser, The computer for the 21st century, Scientific American, (1991), 265(3): 

94-104. 

[8] J.P. Sousa and D. Garlan, (2002). Aura: An architectural framework for user mobility 

in ubiquitous computing environments, In Proceedings of 3rd IEEE/IFIP Conference 

on Software Architecture. 

[9] P.F. Patel-Schneider, I. Horrocks, OWL Web Ontology Language Semantics and 

Abstract Syntax Section 2. Abstract Syntax, http://www.w3.org/TR/owl-semantics/ 

syntax.html 

[10] Strang et al., A context modelling survey, Workshop On Advanced Context 

Modelling, Reasoning And Management Associated With The Sixth International 

Conference On Ubiquitous Computing (Ubicomp4), Nottingham/UK. 

[11] I. Horrocks et al., SWRL: A Semantic Web Rule Language. Combining OWL and 

RuleML, W3C Member Submission 21 May 2004, http://www.w3.org/Submission/ 

SWRL/


237 

[12] O. Lassila, R.R. Swic, Resource Description Framework (RDF) Model and Syntax 

Specification, W3C Proposed Recommendation 5 January 1999, http://www.w3.org/ 

TR/PR-rdf-syntax. 

[13] N. Freed, N. Borenstein, RFC2046 Multipurpose Internet Mail Extensions (MIME) 

Part Two: Media Types, http://www.ietf.org/rfc/rfc2046.txtnumber=2046. 

[14] J. Sliwa, K. Gleba, W. Chmiel, P. Szwed, A. Glowacz, IOEM – ontology engineering 

methodology for large systems, Lecture Notes in Computer Science, vol. 6922. 

[15] C. Kiss, Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 2.0, 

W3C Working Draft 30 April 2007, http://www.w3.org/TR/2007/WD-CCPP- 

-struct-vocab2-20070430/ 

[16] J. Śliwa, T. Podlasek, M. Amanowicz, Web Services Efficiency in Disadvantaged 

Environment, JTIT 2010. 

[17] A. Tarski, Introduction to Logic and to the Methodology of Deductive Sciences, 

Second Edition, Dover Publications, Inc., New York 1946, ISBN 0-486-28462-X. 

[18] P.F. Patel-Schneider, I. Horrocks, OWL Web Ontology Language Semantics and 

Abstract Syntax Section 2. Abstract Syntax, http://www.w3.org/TR/owl-semantics/ 

syntax.html

Run-Time Ontology on the Basis of Event 

Notification Service 

Kamil Gleba, Joanna Śliwa, Damian Duda, 

Joanna Głowacka, Piotr Pyda 

C4I Systems Department, Military Communication Institute, Zegrze, Poland, 

{k.gleba, j.sliwa, d.duda, j.glowacka, p.pyda}@wil.waw.pl 

Abstract: Ontology is a term deriving from philosophy but lately very often used in the context 

of knowledge management. Ontologies help to provide unambiguous definitions of terms, relationships 

among them and deliver human-like understanding of knowledge to IT systems. Going even further, 

they can automate some of the processes giving the opportunity to get rid of “the man in the loop”. 

The paper presents the INSIGMA event run-time ontology that is used by the Event Notification 

Service (ENS) to automate the process of notifying public safety services about the dangers related 

to the traffic and accidents on the roads. Special attention is paid to the ontology content, event notification 

service and the reasoning module that is responsible for inferring knowledge on the basis 

of the T-Box and A-box ontology statements. 

Keywords: ontology; run-time ontology; event notification service; OWL; reasoning; domain model 


Ontologies [1,2] are mainly well–formed hierarchical descriptions of the domain 

of knowledge that have their roots in philosophy. While very much appreciated 

in the knowledge management and logics, they are also getting more and more 

important in the information systems domain where they are used to perform 

certain tasks in the system. In this case they are called run-time ontologies. 

Run-time ontology is applied during the system operation and usually 

helps to deliver certain functionality. It is not only developed to describe the domain 

of knowledge in the philosophical manner but to build a model enabling 

to derive additional information and perform reasoning. This was also the case 

in the INSIGMA project that is supported by the funds from European Ministry 

of Regional Development within one the Polish National Strategic Reference Frameworks 

– Innovative Economy. It is carried out by four Polish academic, research 

and commercial bodies: AGH – consortium leader, MCI, MUT and WSTKT. 

Work has been co-financed by the European Regional Development Fund under the Innovative Economy 

Operational Programme, INSIGMA project no.POIG.01.01.0200-062/09.


INSIGMA stands for Intelligent System for Global Monitoring Detection and 

Identification of Threats. The main objective of the project is to develop a complex 

monitoring system that will allow to identify objects in the monitored environment 

and, based on the stored information and advanced algorithms, identify threats 

related to both the traffic and suspicious behaviour of people. The system can be 

also used for traffic management and route planning for individual users and for 

the public safety services. The route planning will take into account also dynamic 

complex parameters that provide the possibility to select the route in special circumstances, 

e.g. after a road accident or a natural disaster, in difficult weather 

conditions, etc. 

One of the major novelties of the INSIGMA project is application of ontologies. 

They are used to describe all the elements of the system, model entities 

describing logical and physical elements, data collected by sensors, as well as dependencies 

among them. This all is to support efficiency of information retrieval 

in such a complex information system. However provision of a set of well-formed 

ontologies has additional advantage. It allows to deliver knowledge on the basis 

of the reasoning process that bases on information that are flowing from the monitoring 

subsystem. That is why in the INSIGMA project there has been also defined 

run-time ontology used for automatic identification of threats and dangers related 

to the traffic and, in case of emergency, for automatic generation of the notification 

to public safety services (like police, ambulance services, fire brigade) – so called 

INSIGMA Event Ontology (IEO). 

The remainder of this paper is as follows: in section 2 we describe motivation 

for our work, in section 3 – ENS that is the implementation of the run-time 

ontology application engine, in section 4 – the INSIGMA event ontology itself, in 

section 5 presents the RM that infers knowledge from the information collected. 

Section 6 presents results of testing the reasoning module. In section 7 we identified 

further work in the area of run-time ontologies that we are planning to perform 

in the INSIGMA project. The article is finalised by the summary and conclusions. 

II. Motivation 

INSIGMA project will be finished with the development of the prototype 

system. Currently the system is being developed component by component. One 

of the most important services that INSIGMA will provide is ENS. It enables creation, 

delivery and processing of short formalised messages about events of certain type. 

Information about events will be stored in Events Repository (ER) and made available 

to the other functional modules of the INSIGMA system [3]. 

ENS consists of two elements – reporting module located at the client device 

and notification module (including the reasoning module) located at the server 

side. The reporting module was proposed as a complementary to the fixed road 

traffic monitoring infrastructure composed of intelligent video cameras and sen-


241 

sors. It allows reporting of accidents and other events directly from users located 

outside the monitoring area. 

The idea of ENS was to apply the IEO for automatic classification of events 

and threats. On the basis of the A-Box ontology model and description of the event 

delivered by the reporting module, the server module is able to automatically 

classify the event to a certain type and generate notification for necessary public 

safety services. ENS is also useful as a source of dynamic data that, further on, 

can be presented on the road map as potential traffic difficulties or obstacles (e.g. 

information about the accidents) and used to compute routes taking into account 

threats and dangers and alerting of INSIGMA users. 

Application of the IEO in the ENS is well suited to the system exploitation 

phase when ontology is used to provide reasoning and automation of the processes. 

It is very important to get rid of “the man in the loop” and support decision process 

in terms of defining necessary actions in case of an accident or other dangerous 

situation. On the basis of the event description the reasoning module defines threats 

related to the observed situation and necessary actions to be taken by emergence 

services (e.g. calling the ambulance, calling the fire brigade, etc.). 

III. Event Notification Service 

The ENS was implemented as a set of functional software modules in the C 

ommunications&Information Infrastructure Laboratory of Military Communication 

Institute. The ENS allows creation, relaying and processing of short messages 

containing formatted information about events spotted by a user. The results 

of processing the messages is stored in Events Repository (ER) for further use [3]. 

The ENS infrastructure is composed of the notification module and reporting 

module (see Fig. 1). Notification module is used to collect and process messages from 

users, extract appropriate information and pass it to the Reasoning Module (RM). 

The output from RM is then fed into Message Dispatcher (MD) which notifies users 

specified in the subscription list. The client modules provide graphical user interface 

with formatted fields to fill in information about an event. The client module also 

allows creating of structured messages and it handles authentication of the user. 

The high level view of ENS model is presented in the Figure 1. The implementation 

of ENS is based on the Session Initiation Protocol enhancements for Instant 

Messaging – SIMPLE [4]. The SIMPLE messages are used as an application level 

transport protocol for relaying user generated information about observed and 

reported events. The information is structured according to high-level ontology 

dedicated for INSIGMA system [5]. The main reason behind the use of SIMPLE were 

requirements for identification, registration and authentication of users. The SIP 

Uniform Resource Identifier are used as an identification whereas mechanisms 

for registration and authentication are defined in the SIP RFC [6]. Localisation 

of a user is an additional benefit from using SIP architecture.


Figure 1. Model of the notification service components. Abbreviations: 

CM – Communications Module, SAS – SIP Application Server, ER – Events Repository 

The detailed structure of message was defined in [3] and consists of: 

• type of event (based on high level ontology), 

• time of event (based on real-time clock in the user terminal or manually 

entered by a user), 

• geo-localisation of event (acquired from embedded GPS receiver or set 

manually by a user on the touchable background map), 

• optional information about the event, such as a number of injured persons, 

• optional information about observed results of event, 

• the user or equipment identifier. 

The message with event information is encoded using eXtensible Markup 

Language (XML). The XML data is then put into the SIP MESSAGE protocol data 

unit as a payload. The encoding of information has a following structure: 

 

 

 

 

 

. . . 

 

 

 

 

 

 

 

 

 

 

The notification module (server part) consists of the SIP proxy server used 

to receive messages from the client, Communications Module (CM) that invokes


243 

the RM responsible for reasoning about the event and MD that forwards the notifications 

to subscribed public safety services. 

The implementation of SIP server for ENS is based on the SIP Express Router 

software (SER) [7] and its capability to interface with external software modules 

through the inter-process communication mechanisms. The SER was used because 

of its flexibility due to its high modularization and programmability of core functions. 

The developed CM provides the interface between SER and RM. It basically 

works as a translator of SIMPLE messages to the remote procedure calls based 

on Web Service technology. The translator was needed because of requirements 

of RM software, which provides Web Service interface only. Additionally the CM 

processes data about events and feeds them to the ER. The CM was implemented 

as a standalone program linked with “libpq” library available in the PostgreSQL 

package [8]. ER uses PostgreSQL 8.4.1 relational database system. The system environment 

for notification module is provided by Slackware Linux 12.0 operating 

system. The more detailed description of ENS service can be found in [3]. 

Event reports are prepared on a mobile terminal running dedicated client 

application. The client software provides graphical user interface (see Fig. 2) which 

helps to describe the event by assigning observed circumstances to the predefined 

types (e.g. event results like leakage of dangerous substance, person jammed 

in the vehicle, etc.). 

Figure 2. Graphical user interface view 

ENS client was created as an application dedicated for the Android platform. User 

with the graphical interface indicates: event location, its type and time of occurrence.


The event location is determined on the basis of data received from the GPS module 

or by indicating the exact place of the event on an embedded map. Selected 

events are grouped into three categories: traffic incidents, traffic difficulties and 

weather difficulties. For events of the first category there is also an opportunity to 

submit information about injured people and event results. 

The application is written in Java, based on the following libraries: Android 

SDK, Jain-SIP – SIP protocol implementation for Android [9], Google APIs Addon 

[10]– APIs providing the possibility of identify the events location on the builtin 

Google map. 

The DM receives messages about events from the CM and passes them to 

suitable subscribed customers. These are public safety services (i.e. the police, 

fire brigade, ambulance, etc.) that are called in emergency situations to minimize 

the risk of the danger that has been reported. 

For the purpose of subscription management the endpoints of the customers 

will be stored in a database. They are divided into notification groups which 

consist of customers interested in particular event types. For example, information 

about the traffic accident with injured persons will be passed to the police, disposer 

of rescue ambulance service or emergency call center. When the reported event 

is a factory fire and the terrain contamination, notification will be passed to the fire 

brigade, police, disposer of rescue ambulance and sanitary and epidemiological 

station. The message coming from the CM contains the event description as well 

as the name of notification group. This allows the dispatcher to send notification 

to group members. The notification message also includes the geographical coordinates 

of the event as well as essential information about it. 

IV. INSIGMA event ontology 

Ontologies at the run-time are used in the situations where the domain model 

cannot be fully elaborated during the system development (some domain aspects 

are unknown or uncertain) or a kind of reasoning is required. In case of ENS 

there is a need to reason about threats and dangers related to the traffic detected 

in the INSIGMA monitoring subsystem on the basis of the event description. In case 

of ENS IEO is used in the RM. 

IEO is typical example of run-time ontology model describes specific domain 

of knowledge: road events (like car collision, knocking down a pedestrian, 

damaged road surface, leakage of dangerous substance, etc.), weather events (like 

rain, snow, below freezing temperature) and threats related to occurred incident on 

traffic (like wet surface danger in case of rain precipitation). On the basis of the event 

description (provided by the reporting module) the reasoning mechanism supported 

by the event ontology and a set of rules enables to classify the event, define required 

action of the system and then generate notification to public safety services.


245 

IEO has the form of hierarchical descriptions of the domain of knowledge about 

traffic monitored by INSIGMA subsystem. The main class of the ontology model 

is InsigmaEvent. Together with its subclasses it describes road and weather 

events (see Fig. 3). Each class in the ontology has its own description expressed by 

using relations, attributes and restrictions which allows to create complex definitions 

of particular domain of knowledge 

Developed for the purpose of INSIGMA the event domain model includes 

formal model in Ontology Web Language (OWL) and rules created in Semantic 

Web Rule Language (SWRL). 

The formal ontology model consists of: 

• taxonomy of classes which describes concepts (T-Box) (see Fig. 3), 

• relations describe relationships between classes and instances (see Fig. 4), 

• individuals which are instances, specific objects of classes (A-Box), 

• attributes describe properties or parameters that classes or its instances 

can have, 

• restrictions – formally stated descriptions of what must be true in order 

for some assertion to be accepted as input, 

• axioms – assertions (including rules) in a logical form that together comprise 

the overall theory that the ontology describes in its domain of applications. 

Figure 3. Taxonomy of INSIGMA Event Ontology 

Rules are statements in the form of if-then (antecedent-consequent) sentences 

that describe the logical inferences that can be drawn from an assertion in a particular 

form.


Figure 4 Properties of InsigmaEvent class 

IEO, based on T-Box and A-Box statements, classifies event source to one 

of the following types of event: 

• Road Accident, 

• Traffic Collision, 

• Traffic Difficulties, 

• Weather Difficulties. 

Classifying and inferring knowledge is provided by the RM described 

in the next chapter. 

V. Reasoning Module 

A. Architecture 

The RM is one of the parts of ENS. It holds whole “logic” and decides about 

the type of event and necessary actions to be triggered. The knowledge inferred on 

the basis of the T-Box and A-Box ontology statements is used by the ENS dispatching 

module to send appropriate notifications. 

RM was implemented in Java as a Web Service. This implementation uses 

the following tools and libraries: 

• Protege-owl-3.4.6 – ontology development and modeling tool, 

• Pellet 2.2.2 –OWL reasoner provides reasoning services for OWL ontologies 

[11], 

• Jess71p2 – rule engine for the Java platform [12], 

• Glassfish 2.x – application server for the Java EE platform. 

Ontology development was done using Protégé 3.6.4 with OWL 1.0. We decided 

to use the older version of Protégé due to the fact that the newest version (4.2) did


247 

not support some of the libraries that were important in the process of ontology 

application like e.g. Protégé OWL API. This library has an important plugin which 

enables to generate java code form OWL classes which is useful while exploiting 

ontologies at run-time. 

Figure 5. Reasoning module interface to the Communication Module of ENS 

In general, existing implementation of the reasoning engine performs a set 

of operations on the ontology, e.g.: 

• filling in the domain model with event descriptions, 

• extending an ontology with SWRL rules, 

• reasoning and classifying knowledge, 

• querying an ontology about knowledge contained into the domain model 

by using the queries described in Semantic Query-Enhanced Web Rule 

Language (SQWRL). 

The RM after being invoked creates an object of the OWLModel class on 

the basis of event.owl ontology ; creates an object of the MyFactory class to 

fill in the ontology with instances; creates an instance of Protégé Pellet Reasoner; 

checks consistency of the created OWL model; classifies ontology; loads SWRL rules 

and invokes Jess rule engine; creates an SQWRL queries and returns the response. 

InsigmaEventOntology service implements Web Method called send- 

EventDescription used to invoke reasoning engine. Event description is used 

by the RM to infer knowledge. These are the following information (A-Box statements): 

kind of event, injured person in the event and result of the event (see 

example of simple SOAP request in Fig. 6). 

For the reasoning purposes we decided to use Pellet reasoning engine. The reasoner 

provides classification that compute complete class hierarchy, consistency 

checking (checking possibility for a class to have any instances) and finding the most 

specific classes that an individual belongs to.


soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/ 

envelope/” xmlns:ns=”http://my.org/ns/”> 

 

 

 

CarCollision 

YES 

roadblock 

 

 

 

Figure 6. Sample InsigmaEventOntology request sent by CM 

B. Rules 

In order to extend a domain knowledge about additional semantic relations 

between OWL classes we defined several SWRL rules. SWRL [13] language is used to 

enhance expression of OWL language. It is based on a combination of the OWL DL 

and OWL Lite sublanguages of the OWL Web Ontology Language with the Unary/ 

Binary Datalog RuleML sublanguages of the Rule Markup Language. SWRL enables 

extending the set of OWL axioms to include rules. 

SWRL rules are of the form of an implication between an antecedent (body) and 

consequent (head). The intended meaning can be read as: whenever the conditions 

specified in the antecedent hold, then the conditions specified in the consequent 

must also hold. Both the antecedent and consequent consist of zero or more atoms. 

An empty antecedent is treated as trivially true (i.e. satisfied by every interpretation), 

so the consequent must also be satisfied by every interpretation; an empty 

consequent is treated as trivially false (i.e. not satisfied by any interpretation), 

so the antecedent must also not be satisfied by any interpretation. 

Atoms in these rules can be of the form of simple assertions: C(x), P(x, y), 

or functions: sameAs(x, y) or differentFrom(x, y), where C is an OWL description, P is 

an OWL property, and x, y are either variables, OWL individuals or OWL data values. 

SWRL rules can be extended by using some built-in functions which are 

the limitations expressing in SWRLB (Semantic Web Rule Language Built-in) 

language. These limitations may be put into values occurrence in rules and express 

relationships between them, for example x>y. 

When defining the IEO model we considered different approaches. They all 

resulted in different possibilities in defining and automatically processing rules. 

The best choice for us was to define three classes as enumerated ones with strictly 

defined set of individuals: Result describes results of event, Threat which define 

dangers and Actions describes set of public safety services organization. These 

classes are used by SWRL rules that enhance semantic relationships in IEO. Some 

examples of SWRL rules are depicted in Fig. 7.


249 

RoadEvent(x) ^ hasResult(x, leakageOfDangerousSubstance) -> 

hasAction(x, CallingTheFireBrigade) 

RoadEvent(x) ∧ hasInjured(x, y) ∧ swrlb:containsIgnoreCase(y, 

\”YES\”) → RoadAccident(x) 

RoadEvent(x) ^ hasResult(x, fire) -> hasAction(x, CallingTheFire- 

Brigade) 

Figure 7. Examples of IEO SWRL rules 

In order to execute SWRL rules we used Jess engine. It is a Java-based rule 

engine that provides an opportunity for constructing a software with some peace 

of artificial intelligence contained in facts and rules. This tools is free to use for 

two years for research purposes. Jess rule engine supports execution of SWRL rules 

and is used in many expert systems which require some reasoning mechanism. 

InsigmaEvent(x) ^ has_action(x, y)→ sqwrl:select(y) 

Figure 8. Example of SQWRL query 

The knowledge inferred on the basis of ontology model and rules exists 

in working memory. It is not set in the OWL model. In order to retrieve this 

knowledge we can use Semantic Query-enhanced Web Rule Language (SQWRL) 

which is built on the basis of SWRL [14]. SQWRL takes a standard SWRL rule 

antecedent and effectively treats it as a pattern specification for a query. Figure 8 

depicts an SQWRL query for public safety services which should be notified about 

existing event detected in INSIGMA system. 

 

 

 

 

CallingTheAmbulance 

CallingTheFireBrigade 

CallingThePolice 

RoadAccident 

TrafficDifficulties 

CarCollision 

Fire 

PoorVisibilityDanger 

 

 

 

 

Figure 9. Example of the reasoning module SOAP response


C. Reasoning Module response 

The response from the RM provides the following information about the reported 

event (see Fig. 9): 

• classes that an individual belongs to ( and ), 

• threats which are results of reported event (), 

• public safety services, which should be informed about the reported accident 

(. 

VI. Results of testing the Reasoning Module 

It is well-known that reasoning on an ontology is time consuming. Long execution 

time for programs based on ontologies result from the time necessary for 

classification of the concepts in the ontology, checking the consistency of ontology, 

inferring knowledge and executing SWRL rules. 

In order to check efficiency of the RM and possibility to apply it for a number 

of users in the INSIGMA project there have been carried out performance tests 

in SOAP UI. We analyzed how a number of SOAP requests affect the reasoning 

module response time. The results of test are depicted in the table below. It is visible 

that the invocation time depends on a number of subsequent requests. 

Table I 

Number of requests Min time [s] Max time [s] Avg time [s] 

1 7,4 10,4 8,3 

2 9,1 11,2 10,6 

5 17,2 37,6 24,7 

10 20,7 52,8 37,1 

20 22 69,1 39,5 

hardware: Intel(R)Core(TM)i7 CPU 2.67 GHz; 8 GB RAM; Windows 7 64-bit; 

Java version 1.7.1_01 

Average time for one request is above 8 s, but when we invoked service ten 

times at the same time, the response time increased to 39,5 s. Results of the analysis 

indicate that if we want to use run-time ontology in a large system like INSIGMA 

with many end-users, we have to use correspondingly high computational power 

systems or develop reasoning modules on the basis of more efficient reasoning 

frameworks. 

VII. Future work 

We are planning to apply the proof of concept of ENS as test deployment 

in the city of Legionowo. The remarks from users of the report and server modules


251 

will be crucial for further development of ENS, especially in terms of ENS reporting 

module GUI and rules supporting RM. Moreover the service will be integrated with 

the rest of INSIGMA system, as one of the sensors providing information about 

accidents and emergency situations on the roads. 

In case of research area we are planning to make parallel implementation 

of the RM using other ontology processing tools, like e.g. CLIPS, which is a tool 

for building expert systems. We expect better performance results than the one we 

collected in our tests. After that we would be able to compare performance of these 

two implementations with multiple clients invocations. 

ENS has an authorization function incorporated with the SIP protocol, however 

we are planning to develop a mechanism supporting confirmation of reported 

events by authorized users. 

VIII. Summary 

The INSIGMA run-time ontology and the RM in ENS are used to infer knowledge 

about threats related to traffic and accidents on the roads. This is an introductory 

level to expert application on the basis of run-time ontology. It can be a support for 

emergency centers’ operators and automate the process of calling appropriate public 

safety services. When enhanced, it can also help to select appropriate equipment 

of the vehicles. However application of services based on semantic engines must 

be always tested against performance in target environment. 

References 

[1] G. Antoniou, F. van Harmelen, A Semantic Web Primer, Massachusetts Institute 

of Technology, 2003. 

[2] L. Yu, Introduction to the Semantic Web and Semantic Web Services, Taylor & Francis 

Group, LLC, 2007. 

[3] D. Duda, J. Głowacka, P. Pyda, A. Stańczak, The concept and model of Event 

Notification Service for INSIGMA system, KSTiT, Łódź 2011 (in Polish). 

[4] B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle, Session 

Initiation Protocol (SIP) Extension for Instant Messaging, IETF Request for Comments 

3428, December 2002. 

[5] J. Śliwa, W. Chmiel, K. Gleba, T. Podlasek, P. Caban, P. Szwed, Requirements 

for ontology in INSIGMA system, INSIGMA Consortium Report, D2.1, December 

2010 (in Polish). 

[6] J. Rosenberg et al., SIP: Session Initiation Protocol, IETF Request for Comments 

3261, 2002. 

[7] SIP Express Router project page, http://www.iptel.org/ser


[8] libpq–PostgreSQL C Library, http://www.postgresql.org/docs/8.4/static/libpq.html, 

2012. 

[9] JAVA API for SIP Signaling http://jsip.java.net/ 

[10] Google Projects for Android, http://code.google.com/intl/pl/android/ 

[11] E. Friedman-Hill, Jess in Action, Manning Publications Co., 2003. 

[12] http://clarkparsia.com/pellet/ 

[13] I. Horrocks, P.F. Patel-Schneider, H. Boley, Said Tabet, B. Grosof, M. Dean, 

SWRL: A Semantic Web Rule Language Combining OWL and RuleML. 

[14] M. O’Connor, A. Das, SQWRL: a Query Language for OWL.

A Robust and Scalable Peer-to-Peer 

Publish/Subscribe Mechanism 

Tobias Ginzler 

Communication Systems Fraunhofer FKIE Wachtberg, Germany, 

tobias.ginzler@fkie.fraunhofer.de 

Abstract: In this work a publish/subscribe peer-to-peer mechanism is presented. The purpose 

of KadScribe is to enable a subscription-based message dissemination mechanism for a large number 

of participants. The mechanism is intended as a building block for other protocols and applications. 

Possible applications include SOA messaging, weather information or an instant messaging presence 

service. The focus is on best-effort, low data rate services. The special challenges of disadvantaged 

networks such as volatile user behavior, low transmission capacity and faulty network connections are 

respected. Mechanisms to deal with these challenges in the publish/subscribe system are presented 

and evaluated in a simulated network environment. 

Keywords: peer-to-peer, publish/subscribe, computer networks 


Peer-to-peer overlay networks first appeared in the late 1990ies and rapidly 

gained popularity in the following years. The typical usage scenario was sharing 

and downloading of music files in the mp3 file format. File sharing over peer- topeer 

– or P2P – networks soon came to notorious fame, because it was mainly used 

to exchange copyright protected content. Ongoing legal disputes led to the end 

of the most popular file sharing network of that time, Napster, in 2001. The new 

feature of Napster was to enable users worldwide to share content and publish information 

without the effort of setting up hardware or writing code. The philosophy 

of P2P networks was and still is today, that every participant may be consumer of information 

as well as a publisher of information. Tim Berners-Lee had the concept 

of sharing in mind, “That was what it was designed to be as a collaborative space 

where people can interact.” [3]. The need for interaction and collaboration was unbroken 

by the end of Napster. Soon the gap left by Napster was filled by numerous 

P2P networks, built to overcome the fragile design of the first generation of peerto-peer 

networks. A nearly uncountable variety of protocols and P2P applications 

exist today. P2P technology is used to distribute software updates or to find persons 

for remote software support. Instant messaging relies on P2P overlays [1] as well


as IPTV solutions [15]. The reasons to use P2P instead of a centralized architecture 

are always the same: The first and most important is load balancing. The second 

reason is resilience against failures. 

Many emerging applications such as social networks are based on an eventdriven 

publish/subscribe model. In contrast to the traditional client/server model, 

publish/subscribe is a one-to-many communication scheme and complements 

the traditional one-to-one web communication. Publish/subscribe services and 

applications are popular and work smoothly as they relieve the user from acquiring 

information himself. The right information comes automatically to the user. 

This work aims to contribute in bringing the two promising innovations 

in network technology together: Peer-to-peer networks and publish/subscribe. 

Not only has the way of information exchange changed in the last decade 

but also the way how people communicate. Nowadays ubiquitous computing 

becomes reality. Mobile computers have the size of a mobile phone while still 

being able to use the full potential of online services. These new ways of information 

exchange face new challenges. The cellular networks or wireless local area 

networks do not offer the same quality of service for data transmission as wired 

communication. User mobility, wireless transmission and battery lifetime pose 

new challenges in terms of connection disruptions and device failures. From 

the application’s point of view users disconnect and connect again. This process 

of coming and going is called churn. Protocols developed for the Internet may 

perform badly when faced with churn. 

Peer-to-peer networks were originally designed to interconnect users in wired 

networks. Surprisingly, some P2P systems cope quite well with the new challenges 

because they already anticipate volatile user behavior and low data rate links. 

The new challenges in mobile wireless networks are the main constraints to be 

respected when considering publish/subscribe P2P systems. 

II. Publish/subscribe in disadvantaged networks 

The Publish/subscribe communication scheme has much in common with 

multicast. While multicasting describes the process of information delivery to 

the receivers, often the membership or group management is also considered a part 

of it. The multicast management provides a method to start and stop the reception 

of multicast messages. The receivers of multicast information form a multicast group. 

The members of a multicast group are called the subscribers. Users can choose what 

information they are interested in by subscribing to topics. This reduces the transmission 

of undesired messages. 

A multicast system with membership management is called a publish/subscribe 

system in the following. Groups and topics form the very basic concepts in a publish/subscribe 

system. Advanced concepts include group authorization, source 

specific multicast, multi-stream multicast [4] as well as filtering and aggregation.


255 

Multicast can be realized at different layers according to the ISO/OSI model. 

Multicast functionality may be realized at the physical layer by radio broadcasts. 

This is a straightforward and cheap method to offer one-to-many communication. 

It is widely used in voice communication. The data radio systems communication 

standards are vendor-specific. Multicast implementations on Ethernet are widely 

available and used in private networks. Outside of closed circuit networks Ethernet 

cannot be used as a common technology across autonomous system boundaries. 

The IP’s multicast extension is used for example as service discovery in local networks[6]. 

Outside of local networks it has not gained acceptance except in niches 

like research networks or company networks. Challenges regarding how to do 

billing in IP multicast prevents commercial success while scalability issues are still 

unanswered. A relatively new approach is to offer multicast at the application layer. 

The multicast functionality is not restricted to a certain network infrastructure and 

a large number of participants is possible. Also the responsibility of nodes to duplicate 

and distribute messages may change dynamically according to the network 

conditions. The disadvantage is that application layer multicast is more resource 

consuming than realizations at lower layers. 

The higher in the ISO/OSI model multicast is realized 

• the easier it is to cover a large number of participants, 

• the more network resources are consumed, 

• the more features are offered. 

In a disadvantaged network, publish/subscribe at lower layers are most suitable 

because of their efficiency. The proposed mechanism is understood as a besteffort 

service with high latency and minimal impact on existing network utilization 

for a large number of participants. A realization at the application layer then fits 

best. It now has to be proved that such a solution is able to perform in disadvantaged 

networks. 

III. P2P publish/subscribe with KadScribe 

KadScribe [8] is a novel publish/subscribe system based on the Kademlia [14] 

and the Scribe [5] protocol. The functionality of KadScribe will be described in this 

section. Scribe is based on Pastry [18], a structured peer-to-peer protocol which 

has been identified to be susceptible to churn [12]. 

Pastry uses recursive routing which makes it slow in unreliable networks [17]. 

Also it seems Pastry’s development has been transferred to proprietary custody [10] 

or ceased [7]. 

For these reasons it is imperative to look for an alternative routing beneath 

the publish/subscribe layer. 

The novelty is that KadScribe uses Kademlia’s routing algorithm instead 

of Pastry’s because of its robustness, efficiency and simplicity. Subscription 

and publishing are done in similar way to Scribe. By replacing the routing


mechanism, a more robust and more reliable publish/subscribe functionality 

is possible. In contrast to Pastry there are millions of active Kademlia nodes and 

three major implementations which are actively developed and researched [11]. 

A performance analysis of KadScribe is presented in section IV. A description 

of KadScribe follows. 

Kademlia defines a distance metric and a mechanism to route to a position – 

or equivalently – a key in the P2P network. The identifier is a key in the Kademlia 

key space. The routing table of a Kademlia node is a binary tree (Fig. 1). Each 

leaf contains a list of nodes, the so called buckets. A bucket holds a fixed number 

k of references to reach other nodes. As the network may contain up to n nodes, 

the routing table size has to be limited. In Kademlia the memory requirement 

for the routing table is O(k . b), with b as the number of bits of an identifier. 

A node carries a tag which defines which identifiers are contained in its subtree. 

In the figure, b and k are assumed to be 4, the standard key length of Kademlia 

is 160. A tag of 1xxx means that the most significant bit is 1 for the whole subtree 

and the other bits are unknown. The right subtree of the root carries this tag. 

The local node identifier is assumed to be 0000 in the depicted tree. If the local 

identifier is not 0000 the local node may do an XOR operation with its own 

identifier on all identifiers in the routing table. The table then looks exactly 

as in the example. The transformation can to be undone by applying the XOR 

operation again as the XOR operation is involutary. In comparison to the original 

description of Kademlia where the tree is built according to the local identifier, 

this transformation may simplify the implementation. 

Figure 1. The Kademlia routing table 

Routing to destination keys is done in Kademlia by iteratively querying nodes 

which are increasingly closer to the final destination. To do so, responses from 

queried nodes contain the k closest nodes to the destination they are aware of.


257 

The queried node looks up the bucket which shares the longest matching prefix with 

the destination key. If there are less than k entries in the bucket, buckets with shorter 

matching prefix length are searched. The k entries are returned to the querying 

node. The newly learned nodes are then queried until no closer nodes are found. 

The distance to the final destination is halved in each routing step if the tables 

are reasonably filled. Routing to a node can be seen as increasing the matching prefix 

length to the destination hop at least by one bit in each hop. The number of routing 

hops in Kademlia is within O(log(n)). In existing implementations the number 

of hops seldom exceeds 5. Routing to destination keys is used for publishing and 

in a slightly modified form also for subscribing. 

When a user of KadScribe wants to subscribe to a topic, it first generates 

an identifier of the topic. The node which is closest to the topic location according 

to Kademlia’s routing metric is called Rendezvous Point (RP). The subscriber, 

the topic location, the RP and the P2P connectivity are shown in figure 2(a). 

The edges depicted in the diagram are connections at the transport layer, e.g. UDP 

connectivity. The underlying technologies like MANET hops or wireless connection 

are abstracted. One hop in the P2P network may include multiple hops on lower 

layers. As the P2P network is on top of other network technologies it is also called 

an overlay network. The same mechanisms to derive the identifier as in a Distributed 

Hash Table may be used, e.g. hashing a textual topic description with a hash 

function. The method of generating a topic description is shared by all nodes. By 

doing so, a range query or a search which searches for similar topics is not possible. 

Other schemes ([16], [9], [19]) to determine topic identifiers or enable range 

queries or more detailed search requests exist. After the key of the topic has been 

calculated, a node is able to subscribe to a topic. The Kademlia routing table is 

searched and the known nodes closest to the RP are returned. No messages have 

been sent over the network so far. The subscriber then sends a subscribe message 

to the nearest node of the topic. The contacted node becomes a forwarder and adds 

the requesting node to a list. The forwarder sends a subscribe ack as an acknowledgment 

back to the subscriber. The forwarder then uses the same procedure to 

subscribe to the topic if it is not already subscribed. If a node is not able to send 

a subscribe to a node which is closer to the topic than itself the algorithm terminates 

and the node becomes RP for this topic. Any successive subscription from 

a different node terminates at the first forwarder (Fig. 2(c)). The constructed tree 

is a rooted tree with directed edges. The subscribers form the leaves of the tree. 

For each topic a separate tree is built. For simplification purposes, only a single 

topic is considered. When updated information is available for the topic, the publisher 

first finds the RP by means of the Kademlia routing. The topic identifier 

is used as the destination key. The root and the forwarders replicate the message 

and send out copies to all their successors in the tree until all subscribers have 

received the topic update.


(a) P2P connectivity and RP 

subscriber 

forwarder 

(b) Subscription with resulting multicast tree 

(c) Another subscription 

(d) A publish 

Figure 2. Subscribe and publish in KadScribe 

The messages used in KadScribe are called subscribe, subscribe ack, 

unsubscribe, publish, publish ack and multicast. KadScribe in contrast to 

Scribe has no create message to create a topic. The functionality of this message 

is integrated in the subscribe message as a topic is created as soon as the first node 

subscribes to it. In contrast to Scribe, publish and multicast are realized in two 

separate messages to be able to acknowledge the publishing. This contributes to 

the resilience of the protocol. Multicast messages are not acknowledged not to 

overwhelm the sender with acknowledgements.


259 

Success ratio 

1 

0.9 

0.8 

0.7 

0.6 

0.5 

0.4 

0.3 

0.2 

0.1 

0 

No errors PER churn PER, churn 

(a) Success ratio 

14 

Byte sent node -1 s -1 

12 

10 

8 

6 

4 

2 

0 

No error PER churn PER, churn 

(b) Traffic per node 

Figure 3. KadScribe in the simulated environment 

IV. Evaluation 

The OMNeT++ simulation framework [21] with the OverSim framework [2] 

was used to simulate the network and to analyze the protocol. The implementation 

of KadScribe was done within the simulator as a separate module. The network 

consists of 1024 peer-to-peer nodes and all peers are directly interconnected. 

The simulation features the IP and UDP protocol, the lower layers are abstracted 

by an error and churn model. The reasons to do so is the complexity of a wireless 

simulation and the loss of generality of the results. The use of a churn and error model 

also simplifies the comparison of the results with other publications. The churn 

process was modeled as Weibull-distributed as described in [20] with a reduced 

mean lifetime of 60 minutes. The churn model is supposed to cover all the cases 

where user equipment drops the connection against the will of the user, e.g. because 

of mobility or low battery. The connections between each peer have a constant


bit error rate of 2 . 10 −5 to reflect unreliable connections and media overload. 

If a message contains a bit error it invalidates the UDP checksum of that packet. 

The packet is then discarded by the network stack of the receiver. 

Table I. Kademlia parameters within KadScribe 

Kademlia 

n tell 8 

k 8 

α 3 

t stab 10 000 

weight 0, 0.5 

A considerably higher success ratio can be achieved by increasing the redundancy 

of the multicast tree by allowing multiple predecessors. The multicast 

tree then becomes a directed acyclic graph without a designated root (Fig. 4). It is 

then possible for a publish message to reach a subscriber by an alternate path even 

if the direct path to the subscriber is broken due to churn (Fig. 5). This behavior 

is much more robust than the previously shown tree dissemination scheme 

in Fig. 2(d). The success ratio can be increased from 0.7, to 0.9 subscribers do not 

get the publish. 

Figure 4. Subscription and multicast dissemination structure with p max = 2 

This simulation feature can be switched on and off and is marked as PER 

(Packet error rate feature) in the figures. The publish/subscribe success ratio 

is defined as the ratio of successful receptions per publish. Initially half of the nodes 

subscribe to a topic. Every new node which arrived through churn immediately 

subscribes with a probability of 50%. Every node in the simulation produces 

publish messages about the topic by an equally distributed probability function 

with a mean of 10 000 s (≈2:40 h). The most important parameters are shown


261 

in Table I and II. The Kademlia parameters are the churn-optimized parameters 

from [13] to facilitate a limited degree of comparability. The parentTimeout and 

childTimeout parameters determine when a predecessor or successor is considered 

gone after no messages have been received for the given timeout. Message 

receptions fail due to bit errors or churn. 

In Fig. 3(a) the publish/success ratio is shown. The leftmost labeled with ”No error” 

shows the result for a perfect network without churn and network transmission 

errors, consequently resulting in a success ratio of 1. All publish/subscribes were 

successful. When bit errors are simulated (bar labeled ”PER”) or churn is added 

to the simulation (bar labeled ”churn”) or both (”PER, churn”), the success rate 

drops due to outdated routing tables and packet loss. The unmodified protocol 

suffers a significant degradation of service when encountered with harsh conditions 

as shown in this figure. 

When faced with the churn the success ratio was 0.75 with additional bit errors, 

the ratio of successful receptions per publish dropped to 0.6 (rightmost bar 

in Fig. 3(a)). While it can be considered sufficient for some applications, a higher 

success rate is desirable. If a packet loss occurs or a node in the multicast tree 

leaves, the multicast messages get lost. Depending on the location of the loss 

in the tree, more or less (with p max = 2) and up to 0.92 when the number of maximum 

predecessors are increased to 3 (Fig. 6). A further increase of the p max 

parameter increases the success ratio only slightly and results in much higher 

traffic load. 

Figure 5. Publish circumvents a broken node, p max = 2 

Figure 6. Success ratio with different values of p max and c max with churn


In a manner similar to how the number of parent nodes may be controlled 

through the p max parameter, the number of children may be controlled by a parameter 

c max . This allows for more control over the structure of the tree and has two 

advantages. 

• A node is less prone to be overloaded by multicast forwards. The more outgoing 

edges a forwarder has the more messages are to be sent. In environments 

without native multicast support every inbound message causes the same 

number of transmissions as there are children of this forwarder. 

• Subscription storms are avoided. As a consequence of a parent node failure, all 

former child nodes try to resubscribe to other nodes in a short time frame, resulting 

in a subscription burst. This is undesirable in terms of network utilization. 

The c max value was set to unlimited, 25 and 10. In Fig. 7 the effects on 

the path length are shown. The effects on the success ratio in Fig. 6 are a direct 

consequence of the increased path length. The impact of a c max = 25 can be seen 

as a compromise between the disadvantage of reduced resilience against churn 

and the advantage of improved balance of the dissemination structure. A value 

of c max = 10 shows a more grave impact on the performance of the system. When 

c max is too low, it becomes more likely that nodes are unable to subscribe because 

all parent candidates have already reached their maximum child count. The c max 

value should be chosen according to the expected churn, the network transfer 

rates and the number of subscribers. 

Table II. KadScribe parameters 

KadScribe 

p max 1, 2, 3 

c max ∞, 25, 10 

parentTimeout 

45 s 

childTimeout 

45 s 

4 

3.5 

3 

path length 

2.5 

2 

1.5 

1 

0.5 

0 

inf 25 10 

c max 

Figure 7. Effect of c max on the path length


263 

V. Summary and conclusion 

The presented peer-to-peer publish/subscribe mechanism is an approach to 

combine the advantages of application based multicast – scalability and usability – 

with the challenging nature of disadvantaged networks. The result is a scalable and 

robust publish/subscribe system capable of working in disadvantaged networks. 

For the future it is envisioned to integrate the publish/subscribe mechanism into 

a system which provides access control, group management and a unified messaging 

interface. Such a system could be a service-oriented architecture framework. Also 

the publish/subscribe mechanism of KadScribe will be improved. The research 

on KadScribe will focus on a further reduction of the required transmission 

bandwidth and increased robustness. Dynamically determined timeouts could 

be used in the future to adapt to changing network conditions. Opportunistic 

listening and multicasting are techniques which may be useful to further reduce 

the required transmission bandwidth and it can speed up bootstrapping. The collection 

of packets and sending them in a burst is a promising approach to react 

to the constraints of data radios. 

REFERENCES 

[1] S.A. Baset and H.G. Schulzrinne, An analysis of the skype peer-to-peer internet 

telephony protocol. INFOCOM 2006. 25th IEEE International Conference on Computer 

Communications. Proceedings, 25:1-11, 2006. 

[2] I. Baumgart, B. Heep, and S. Krause, OverSim: A Flexible Overlay Network 

Simulation Framework. In Proceedings of 10th IEEE Global Internet Symposium (GI ’07) 

in conjunction with IEEE INFOCOM 2007, Anchorage, AK, USA, pp. 79-84, May 2007. 

[3] T. Berners-Lee, Originator of the web and director of the world wide web consortium 

talks about where we’ve come, and about the challenges and opportunities ahead. IBM 

developerWorks Interviews, July 2006. 

[4] M. Castro, P. Druschel, A.-M. Kermarrec, A. Nandi, A. Rowstron, and A. Singh, 

Splitstream: High-bandwidth content distribution in a cooperative environment. 

In IPTPS’03, February 2003. 

[5] M. Castro, P. Druschel, A.-M. Kermarrec, A. Nandi, and A. Rowstron, Scribe: 

A large-scale and decentralized application-level multicast infrastructure. IEEE Journal 

on Selected Areas in Communication (JSAC), 20(8):1489-1499, October 2002. 

[6] S. Cheshire and M. Krochmal, Multicast dns. RFC draft-cheshire-dnsextmulticastdns-15, 

IETF, Dec 2011. 

[7] P. Druschel, A. Haeberlen, and J. Hoye et al., Freepastry. Technical report, Rice 

University, 2009. accessed on 2011-02-13. 

[8] T. Ginzler, A robust and scalable publish/subscribe mechanism for peer-to-peer networks. 

PhD thesis, Military University of Technology, Warsaw, Poland, 2011.


[9] M. Harren, J.M. Hellerstein, R. Huebsch, Boon Thau Loo, S. Shenker, and 

I. Stoica, Complex queries in dht-based peer-to-peer networks. In Revised Papers 

from the First International Workshop on Peer-to-Peer Systems, IPTPS ’01, pp. 242-259, 

London, UK, 2002. Springer-Verlag. 

[10] A. Herbert, What happened to pastry. SIGOPS Oper. Syst. Rev., 41:10-16, April 2007. 

[11] R. Jimenez, F. Osmani, and B. Knutsson, Sub-second lookups on a large-scale 

kademlia-based overlay. In Peer-to-Peer Computing (P2P), 2011 IEEE International 

Conference on, pp. 82-91, September 2011. 

[12] D. Kato and T. Kamiya, Evaluating DHT implementations in complex environments 

by network emulator. In International Workshop on Peer-to-Peer Systems (IPTPS ’07), 

February 2007. 

[13] J. Li, J. Stribling, R. Morris, M. Frans Kaashoek, and T.M. Gil, A performance 

vs. cost framework for evaluating DHT design tradeoffs under churn. In INFOCOM, 

pp. 225-236. IEEE, 2005. 

[14] Maymounkov and Mazieres, Kademlia: A peer-to-peer information system based 

on the XOR metric. In International Workshop on Peer-to-Peer Systems (IPTPS), LNCS, 

vol. 1, 2002. 

[15] PPLive. PPTV. http://www.pptv.com. accessed on 2011-03-11. 

[16] S. Ratnasamy, J.M. Hellerstein, and S. Shenker, Range queries over DHTs. 

Technical report, Intel Corporation, 2003. 

[17] S. Rhea, B.-G. Chun, J. Kubiatowicz, and S. Shenker, Fixing the embarrassing 

slowness of opendht on planetlab. In WORLDS ’05: Proceedings of the 2nd conference 

on Real, Large Distributed Systems, pp. 25-30, Berkeley, CA, USA, 2005. USENIX 

Association. 

[18] A. Rowstron, P. Druschel, Pastry: Scalable, distributed object location and routing for 

large-scale peer-to-peer systems. In IFIP/ACM International Conference on Distributed 

Systems Platforms (Middleware), pp. 329-350, November 2001. 

[19] C. Schmidt, M. Parashar, Enabling flexible queries with guarantees in p2p systems. 

IEEE Internet Computing, 8:19-26, 2004. 

[20] D. Stutzbach, R. Rejaie, Understanding churn in peer-to-peer networks. In Jussara 

M. Almeida, Virg´ılio A.F. Almeida, and Paul Barford, editors, Internet Measurement 

Conference, pages 189-202. ACM, 2006. 

[21] A. Varga, OMNeT++ discrete event simulation system. http://www.omnetpp.org, 

April 2009.

Automatic Exploitation of Multilingual Information 

for Military Intelligence Purposes 

Sandra Noubours, Matthias Hecking 

Fraunhofer Institute for Communication, Information Processing and Ergonomics FKIE, 

D-53343Wachtberg, Germany, {sandra.noubours, matthias.hecking}@fkie.fraunhofer.de 

Abstract: Intelligence plays an important role in supporting military operations. In the course 

of military intelligence a vast amount of textual data in different languages needs to be analyzed. 

In addition to information provided by traditional military intelligence, nowadays the internet offers 

important resources of potential militarily relevant information. However, we are not able to manually 

handle this vast amount of data. The science of natural language processing (NLP) provides technology 

to efficiently handle this task, in particular by means of machine translation and text mining. 

In our research project ISAF-MT we created a statistical machine translation (SMT) system for Dari 

to German. In this paper we describe how NLP technologies and in particular SMT can be applied 

to different intelligence processes. We therefore argue that multilingual NLP technology can strongly 

support military operations. 

Keywords: Statistical machine translation, natural language processing, open source intelligence, 

military intelligence 


Military operations strongly depend on up-to-date information. This is necessary 

to be able to act in the most effective and coordinated way possible at any given 

time. Therefore relevant information must be provided by military intelligence cells 

operating according to a specific process. This process includes collection, processing 

and analysis of information. Information which is important for military purposes 

can come in a variety of forms, e.g., signals, geospatial data, audio and video files 

or textual data. In this paper we will focus on the processing of text. 

In addition to intelligence provided by humans (HUMINT), nowadays open 

source intelligence (OSINT), particularly in terms of exploiting the internet, has become 

an essential source of potentially relevant information [1]. Live information 

from global news sites and user-generated content can now provide us with important 

knowledge. Terrorist organizations present in the web make the internet 

even more interesting from a military point of view. Consequently, we have access 

to a vast amount of data, which imposes great challenges to information processing


and analysis. In the course of the intelligence process, collected raw data must be 

processed to extract and analyze relevant information [2], [3]. In order to do this, 

in current operations, military analysts must read the source data and process its 

content. Only then can the results of the evaluation be incorporated into the command 

and control process. 

Due to capacity issues, information overload represents a serious intelligence 

problem, which not only applies to OSINT but often is also true for every kind 

of data, e.g., HUMINT data. This means that we have access to various sources 

of potentially relevant data but may miss critical information as we are not able to 

process it. Processing capacities become further limited if we deal with texts 

in foreign languages that need to be translated. In particular, with respect to less 

common languages not enough or no human translators might be available. For 

example, in the case of the Afghanistan mission, Dari is one such language that 

causes our forces different kinds of translation problems. In any case, it is clear that 

intelligence tools for efficient processing of data are required. 

The science of natural language processing (NLP) provides technology to assist 

military intelligence. There are different NLP applications to support the intelligence 

process on different levels, i.e., finding relevant documents, document classification, 

extraction of document content or specific information and even sentiment 

analysis. To meet the challenge of multilingual document processing, machine 

translation (MT) can be used. In our research project ISAF-MT [4] we have created 

a machine translation system for Dari to German. We proved that the approach 

of statistical machine translation (SMT) makes it possible to rapidly construct new 

translation systems. We argue that the generated output of such a system, a rough 

translation, even if usually not of high quality, can be used to assist military intelligence 

at different levels. Therefore, SMT can be applied for intelligence purposes 

to efficiently process large amounts of data. 

II. The significance of web information 

The modern connected world has significant impact on open source intelligence. 

Nowadays, global news sites as well as social media provide us with live information 

of different kinds, i.e., about events, public opinion, etc. As web technologies 

develop rapidly they become integrated into our lives. Therefore, the information 

content of the web will become increasingly relevant, also for military applications. 

An example for this is the role that social media played in the revolutions 

of the Arab world starting on December 18, 2010 in Tunisia. Here, social networks 

played as a critical function in sharing information and organizing protests [5]. 

Statistics mirror the importance of the internet in our world (visualized by 

Figure 1): with a world population of 7 billion, more than 2 billion people use 

the internet. Due to the recent development of mobile devices, i.e., smart phones 

and tablets, the use of the internet is no longer restricted to access locations. Over


267 

80% of the world’s population now has a mobile phone and the share of smartphones 

is increasing. Here internet usage shows a rapid development trend. During 

the last 5 years the total number of internet users has increased from 18% in 2006 

to 35% in 2011. This trend is not only present in the developed countries but also 

applies to the developing world [6]. Likewise, the rise of social networks can be 

seen in numbers: For example, Facebook, which launched in 2004, today has 845 

million monthly active users [7]. Twitter, that started two years later, has 140 million 

users now and sees 340 million tweets per day [8]. This immense use of internet 

technologies results in an increasingly vast quantity of textual online data. 

Figure 1. Share of Internet users in the total population 

Along with the rise of modern web technologies, the use of the internet for 

criminal purposes has grown. Focusing on military issues, the internet holds many 

possibilities for terrorist purposes, e.g., ease of access, lack of regulation, vast potential 

audiences, fast flow of information, etc. It is utilized by terrorists in different 

ways, i.e., psychological warfare, publicity and propaganda, fundraising, recruiting 

and mobilization, networking, information sharing and planning and coordination 

[9]. In an 8-year-long monitoring of terrorist presence on the Internet from 

1998 to 2007 a study by [10] found more than 5,000 terrorist web sites. All active 

terrorist groups had established at least one form of presence on the internet, i.e., 

web sites, online forums, and chat rooms serving terrorists and their supporters. 

Recent results showed that today about 90% of organized terrorism on the Internet


is being carried out through the social media [11]. The large involvement of terrorist 

activities in the internet indicates the urgency to monitor internet data for 

security and defense issues. 

As the use of web technologies is growing its information content is growing, 

too. Therefore, the probability that information relevant for military purpose 

is present in the internet is increasing, too. Hence, it is essential to be able to extract 

information not only from traditional intelligence sources but also from the internet. 

Due to the vast quantity of possibly important documents, intelligence tools 

are needed [1]. These tools must help analysts to efficiently and rapidly receive 

relevant documents from the internet and collected data sources, translate them 

if necessary, extract critical information and analyze them. 

III. Natural language processing for intelligence purposes 

Natural language processing (NLP) is an active research field that combines 

computer science with linguistics. Through the application of different techniques 

from computer science, natural language text or speech is processed. As this paper 

focuses on the processing of text, in the rest of this paper only “text” will be used, 

although in all cases, NLP research exists that also looks into the corresponding 

processing of speech. 

In general, NLP approaches are either based on rules or on machine learning. 

Rule-based approaches apply a set of hand-written rules that indicate how to 

process the input text. Machine learning is a technique from the field of artificial 

intelligence (AI). NLP approaches that are based on machine learning usually apply 

statistical models to analyze the input. Such models are automatically learned (or 

trained) based on example data (training data). After training, the system is able to 

analyze new input. This means, the system derives the most probable analysis based 

upon the trained statistical model. For example, in the course of statistical machine 

translation (SMT), translations are generated according to the translation model. This 

model is trained on a parallel corpus, a collection of texts that represent translations 

of each other in both languages of interest. During training the system learns how 

to translate source language text into target language text based on the probability 

distribution of the training data. The trained SMT system is then able to find the most 

probable translation in the target language given the source language input text. 

Both rule-based and statistical NLP techniques have different advantages and 

disadvantages. Rule-based NLP technology is usually more accurate than statistical 

approaches, as it processes everything based on rules. Statistical systems always 

output the most probable result which is not necessarily the correct result. Statistical 

approaches, however, also have different advantages especially with respect to military 

applications: in general, statistical systems have a higher coverage, they tend to 

be more robust, and they can be produced rapidly and more cost efficiently. Language 

is highly irregular and dynamic. This leads to the fact that it is almost impossible to


269 

formulate rules for every specification or exception. And rule-based systems can only 

process the input if corresponding rules exist. Furthermore, the formulation of rules 

for linguistic phenomena usually results in a large amount of rules that might then 

interfere with each other in a highly complex way that is difficult to predict. A statistical 

system learns linguistic regularities as well as irregularities when being trained on 

representative data. This results in statistical NLP generally having a higher coverage. 

Hence, such NLP systems can usually process more different input. Therefore, they are 

also usually more robust. In general, statistical NLP systems always process the input 

and give you some result, namely, the most probable output based on the model. This 

might also be advantageous if the input is erroneous. Statistical NLP tools usually 

can be produced much faster (and often more cost efficiently) as no hand-written 

rules are needed but models are applied that are learned automatically. Whether 

NLP tools for military purposes perform best when being based on rules, statistical 

or hybrid depends on the specific application context. 

An approach for applying NLP to intelligence processing 

The intelligence process usually includes the following tasks: planning and 

direction, collection, processing and exploitation, analysis and production, and 

dissemination and integration. The intelligence cycle is visualized in Figure 2. During 

planning and direction the mission-specific intelligence needs are identified. 

According to these needs, relevant data are then collected from different sources. 

The raw data collected must be processed and exploited so that they can be used 

by the analyst, i.e., relevant information must be extracted and converted into 

a usable form. Analysis and production involves integrating, evaluating, analyzing, 

and interpreting information into a finished report. The results can then be 

incorporated into the command and control process. The intelligence steps relevant 

in the context of this paper are those that involve text processing, i.e., collection, 

processing and exploitation, and analysis and production. 

Figure 2. NLP Technology for Intelligence


There are various NLP technologies that can support intelligence with the processing 

of text. A selection of those is presented below: 

• Information retrieval (IR): Information retrieval is the technology underlying 

modern search engines, i.e., it is concerned with efficiently and effectively 

searching for documents. By the application of professional search methods 

we are able to find specific texts from document collections like databases 

or the World Wide Web. 

• Document classification: Document classification (or text categorization) 

is an NLP method to assign documents to one or more classes or categories. 

This may also mean the classification of documents relevance. As document 

classification is usually used to enhance information retrieval, it is 

sometimes regarded as a sub-field of IR. 

• Information extraction (IE): Information extraction describes the extraction 

of specifically defined information from text. For this, different text 

processing is performed. Critical information is identified and extracted 

and may also be structured and combined. 

• Text mining: Text mining refers to the process of deriving text content. The aim 

is to discover previously unknown information that is relevant for a particular 

purpose. In the course of text mining different NLP technology may be applied 

such as, for example, the related task of IE to extract specific items. 

• Opinion mining: Opinion mining, which is also called sentiment analysis, 

involves the analysis of subjective information from text. It is used to try to 

determine the attitude of a writer with respect to some topic or the overall 

contextual polarity of a document. 

• Machine translation (MT): The automatic translation of text is done by 

machine translation. There are different approaches to generate a target 

language translation from a source language text. Which approach is best 

depends on the application and various circumstances. Most modern research 

is performed in the area of statistical machine translation (SMT). 

In section 4, SMT is described in more detail. 

The technologies presented can be applied to assist the human intelligence 

analyst. Through automatic document processing, the intelligence process can be 

improved in terms of efficiency as well as effectiveness. The computational processing 

of text is much faster than human processing. This means that time-critical information 

will reach the mission’s command and control in a much shorter time. Many 

intelligence tasks cannot possibly be performed by humans (such as the manual 

search for information in the web). Only by the use of technology are we able to 

fully exploit the information that we have access to nowadays. In the following, we 

illuminate one possible approach of supporting the intelligence process by the application 

of NLP technology (Figure 2). 

a) Collection: Intelligence involves the collection of data that are relevant for 

the mission. There are different sources of relevant textual data. For example,


271 

data can be provided by HUMINT, or found on the internet (i.e., OSINT). 

Nowadays, media monitoring systems and real time search tools provide 

technology to rapidly access data on the internet. From available data sources, 

i.e., intelligence document collections or the internet, the specific texts that 

may include important information must be extracted. Information retrieval 

provides efficient and effective search technology to find the specific documents 

that meet the missions identified needs. These documents may be further 

filtered according to their relevance. Here, document classification can be 

used to determine the documents’ relevance with respect to the mission. 

b) Processing and exploitation, and analysis: The documents collected must be processed 

to identify and extract information that are important for the mission. 

This is an extremely time-consuming and labor-intensive task. For example, 

the human analyst has to manually read every document, identify and extract 

important information and analyse it with respect to the mission. Information 

extraction, text mining and opinion mining are examples of NLP technology 

that can assist the intelligence analyst with these tasks. Information extraction 

and text mining are related NLP approaches for content analysis. They include 

tools for tagging, identification and extraction of specific or mission relevant 

information. For example, systems that perform information extraction for 

military purposes are described in [12] and [13] as well in [14]. There are also 

techniques for the combination of information and for automatic reasoning. 

See [15] for an example of such a system. Furthermore, tools for opinion 

mining can provide the analyst with information about writers’ attitudes or 

sentiments. 

NLP can provide the analyst with tools for all intelligence steps that involve 

the processing of text. The analyst does not need to read through the documents 

manually but can utilize the NLP processing results. To what extent the processing 

can be performed automatically by the application of NLP technology depends 

on the nature and complexity of the data that needs to be processed, as well as on 

the nature and complexity of the NLP task. In any case NLP tools can improve intelligence 

processing in terms of speed, of efficiency, and of effectiveness. Moreover 

new opportunities will arise as NLP is an active, quickly developing research field. 

IV. Statistical machine translation for intelligence purposes 

To fully exploit the power of a vast global intelligence source such as the internet 

and, in order to access international information in general, documents in different 

languages need to be processed. As texts in different languages are relevant not only 

in the context of foreign military operations but also for internal security issues, 

the translation of text is of fundamental importance for intelligence purposes. In this 

context, machine translation (MT) is highly useful. Machine translation denotes 

the fully automatic translation of text (or speech).


There are different machine translation approaches, from simple word-toword 

translation, to rule-based approaches to statistical machine translation, and 

hybrid approaches. Word-to-word translations operate on the basis of dictionaries. 

Rule-based approaches apply a set of handwritten linguistic rules that describe how 

to translate one specific source language into one specific target language. In contrast, 

SMT is based on machine learning. Most modern MT research is performed 

in statistical machine translation. 

The objective of SMT is to find the most probable translation for a given 

sentence. SMT uses machine learning techniques which means that the system 

learns how to translate source language texts into target language texts, based on 

training data and by the application of learning algorithms. The focus thereby is not 

on generating a perfect word-to-word translation but on transferring the meaning 

of the source language text into the target language. 

Figure 3. Excerpt of the Dari-German Corpus 

To build an SMT system, it has to be trained by the application of machine 

learning techniques. The training data are parallel corpora, i.e., large collections 

of texts in the source as well as in the target language that represent translations 

of each other (see Figure 3 for an example). During the training stage, the system 

statistically analyses the training corpus in order to learn a so-called translation 

model. For this, different learning algorithms may be applied. The model assigns diverse 

probabilities to co-occurrences of textual segments (e.g., phrases) in the source 

language and in the target language. The model then contains phrases in the source 

language together with possible translations in the target languages and different 

probabilities for each specific phrase pair. Figure 4 shows an excerpt of a translation 

model that has been generated by our ISAF-MT SMT system. The purpose 

of the translation model is to generate a reasonable translation. In addition to 

the translation model, a language model is trained using a monolingual text corpus 

in the target language. The language model contains n-gram probabilities for word 

sequences of the target language. Based on the language model the system is designed 

to derive good target language expressions in terms of naturalness. After 

training on the training corpus, the SMT system is able to translate new input text. 

It will generate the translation of highest probability based on the trained models.


273 

Figure 4. Excerpt of a Translation Model generated by the ISAF-MT SMT System 

Different factors can influence the performance of an SMT system, e.g., the size 

and quality of the training corpus (as described below), the integration of linguistic 

knowledge or the different machine learning implementations. Training data are 

highly essential for SMT performance. There are certain requirements that, the more 

satisfied, can lead to better translation quality: 

• Size of the training data: In general, the larger a training corpus is the more 

expressions in terms of vocabulary and word combinations it will cover. 

Therefore, corpus size is significant for the training of the system and system 

performance will improve when more training data are provided. 

• Translation quality of the training data: The translation quality of the training 

corpus directly corresponds to the correctness of the translation model. This 

means the more correct translations the training corpus contains the better 

the system will be able to learn how to produce correct translations. 

• Domain adaption of the training data: Language is highly ambiguous, i.e., 

a word, phrase or sentence can have different meanings and therefore 

may also have different translations. The meaning of a text segment may 

depend on its contextual domain. If a system has been trained for a specific 

domain it will choose translations appropriate for that domain. The more 

domain-specific a training corpus is, the better the translation performance 

for texts from this domain will be. 

Linguistic expertise can be applied to adapt SMT technology to the specific 

language pair of interest, thus improving translation quality. Also, different SMT 

approaches and machine learning algorithms can be applied to modify a system 

in terms of translation quality as well as efficiency. As SMT is an active research 

field, better and faster approaches are constantly being implemented. 

The advantages that SMT holds over other machine translation approaches 

are, for example, the same that statistical NLP technology in general holds over 

rule-based approaches, i.e.:


i) Higher coverage and robustness: Generally, SMT systems have a higher coverage 

than rule based system. As language is highly irregular and dynamic 

it is nearly impossible to formulate a rule for every specification or excetion. 

Therefore there will be textual segments that cannot be translated by rulebased 

machine translation because no explicit rule has been defined for that 

case. If the training corpus is representative and of sufficient size even irregular 

or new segment can been seen in the data. The SMT system can then learn 

the linguistic phenomena during training and the input can be statistically 

translated. Higher coverage also leads to more robustness with respect to 

linguistically new or irregular input. 

ii) 

Rapid and efficient production of SMT systems: SMT systems can be produced 

rapidly and efficiently because no manually implemented rules are needed. 

Instead, the system automatically learns how to generate translations. Many 

tools are ready available to built an SMT system many tools are ready available. 

Linguistic expertise may be applied to improve translation quality by 

adapting system components to the specific language pair. A parallel corpus 

needs to be provided for training. Parallel corpora may be either generated 

manually by translators, or, if language resources are available, can be extracted 

semi- or fully-automatically. Due to the large amount of multilingual data on 

the internet it is usually utilized as a resource to extract parallel corpora. For 

automatic corpus extraction web crawlers and automatic aligners can be applied. 

If not enough data for the language pair in question are available there 

are also approaches to use pivot languages. For example, English, may be 

used as pivot language if there are enough online documents for the source 

language and English as well as the target language and English. Apart from 

that, crowdsourcing has been used to generate corpora. A very interesting 

example of creating a translation system very fast is the Haitian Creole to/from 

English system [16], [17]. After the disaster in Haiti, researchers from Microsoft 

Research built a first version of this SMT translation system for texts within four 

and a half days. The idea was to have a system for translating emergency relief 

documents, medical documents, SMS text messages, and common phrases 

and expressions. The incident showed that SMT systems can be developed 

by putting together data from a variety of sources and by engaging native 

speakers and a broader community (crowdsourcing) to assist in the effort. 

The authors conclude that MT might be a crucial component in crisis situations 

and can be developed rapidly. 

In general, machine translation represents an essential step for efficient analysis 

of foreign language documents. It can therefore be applied for a variety of task. That 

MT is valuable for military purposes can be seen from the fact that currently major 

funding for MT research comes from the US Defense Department [18].


275 

ISAF-MT 

In our research project Machine Translation for ISAF Forces (ISAF-MT) [4] 

we have built a Dari-German translation system. As the project takes place in a German 

– U.S. cooperation, research in SMT for Dari and English is also being 

conducted. The objective of our project is the application of statistical machine 

translation technology for the construction of a Dari-German translation system 

in a military context. 

The software framework we used for the ISAF-MT project is Moses [19]. 

Moses is the most widely used toolbox for constructing SMT systems. It is an opensource 

project and has a very large user and developer community. This ensures 

that the latest concepts and techniques are available for developers of SMT systems. 

In the course of our project we built a parallel German-Dari corpus because no 

corpus for this language pair was available. We have built a text corpus that consists 

mainly of news texts focusing on OSINT terrorism topics. To find a compromise 

between size of training data and quality of translation, we applied a multilevel 

approach for corpus creation. On the one hand, we efficiently extracted parallel 

texts from the internet to meet the requirement of corpus size. On the other 

hand, high quality translations were generated by native speakers and professional 

translators. Our current corpus contains about 27 000 lines. 13 000 lines are web 

extracted news text and about 4500 lines are high quality translations. About 9500 

corpus lines consist of diverse text material, such as open source subtitles, public 

translation examples, the Dari constitution and texts of common information. 

We further improved the system by integrating a Dari-German dictionary of about 

80 000 entries that also contains some military terms. 

In the course of our project we ran different experiments for the improvement 

of system performance. In the following, we will describe some of the objects 

of the experiments that significantly influenced SMT performance. 

• Quality of the training corpus: We ran experiments with different subsets 

of the corpus, focusing on different translation quality or type of text. We also 

looked into various ways of integrating dictionaries into our training data 

in the most beneficial way. 

• Corpus preparation: System performance improved by the normalization 

of the training corpus, e.g., in terms of different Unicode normalizations 

and normalization that were done specifically for the language Dari. 

• Software experiments: To build our SMT system we tried different available 

software, e.g., for training of translation model or language model. 

• Training configuration: The Moses framework provides different possible 

approaches and configurations for SMT. We looked into various settings 

(e.g. maximum length of trained phrases) as well as into the integration 

of linguistic knowledge (e.g., lemmas) into the translation model.


Our project proved the usefulness of SMT for military purposes in terms 

of fast system production and applicability of translation results. We showed that, 

after building up the SMT infrastructure (computer cluster, procedures for building 

corpora, etc.), a translation system for rough translation can be produced 

rapidly [4]. We also argue that the system outputs translations that can support 

military operations. This means that the translations generated by our SMT system 

are of a quality that is good enough to capture the meaning of the input text, i.e. are 

rough translations. This already applies to a system trained on only a few thousand 

lines, for example, on the 4000 lines of high quality translations of our training 

corpus. System performance improved with size of corpus data. Apart from that, 

the integration of dictionaries significantly improved translation quality especially 

when the system was trained on small data. 

In our project we showed that SMT systems that can support military intelligence 

can be produced rapidly. In order to build a translation system, training 

data can be obtained from the internet. In case of insufficient amount of data 

resources, as it is often the case for rarely spoken languages, the training corpus 

can be produced by human translators. Additionally, available linguistic resources 

can be usefully integrated, and, on the basis of linguistic expertise, system components 

can be modified to adapt to the specific language pair. Such a system could 

already support military intelligence. After more corpus development, as translation 

quality increases with corpus size, the system could be applied for tasks of higher 

complexity or difficulty. For a more detailed description on the fast production 

of SMT systems in the context of military missions, see [4]. 

The ISAF-MT SMT system outputs translations of different quality, i.e., 

translation quality can vary from very bad to very good translations. In Figure 5 

you can see an example translation of a newspaper article generated by a current 

version of our ISAF-MT system. Bad translations can be caused by words or 

phrases that have not been translated from Dari to German. Furthermore, words or 

phrases can occur that have been translated into wrong German words or phrases. 

Translations that are useful for military purposes can be sentences that are not 

good in terms of naturalness or correctness of the target language but that bring 

across the semantic content of the source sentences. There are also translations that 

capture the right semantic content of the Dari sentences and that are correct and 

natural German sentences. Overall, we argue that a translated document consisting 

of translations of different quality (like in Figure 5) can bring across the meaning 

of the source document. Thus, even a translation system that has been trained on 

only a small number of sentences, like our system, can be useful in the context 

of military intelligence. 

Though machine translation is an active research area, to our knowledge, there 

are not many systems for translating Dari to/from German. We have compared our 

SMT system to Google Translate [20]. We ran Google’s Persian to German translation 

on a random test set that has been extracted from our Dari-German Corpus.


277 

We got a BLEU-Score [21] of 8.06 for Google’s output and a BLEU-Score of 9.69 

for the ISAF-MT translation. To our knowledge, there is no rule-based translation 

system for Dari and German publicly available. For further reports on evaluation 

results regarding the ISAF-MT (e.g., BLUE-Scores) system see [4]. 

Figure 5. Excerpt of Translation Ouput generated by the ISAF-MT SMT System 

An approach for applying SMT to intelligence processing 

Translations produced by SMT can be of different quality, depending on 

the complexity of the input text, on the SMT system, the available training data, 

the language pair, etc. In any case, to bring across the meaning, translation does 

not have to be perfect. We therefore argue that the output of SMT systems, even 

though of varying quality, can support the intelligence process in different ways. 

This concept is presented in Figure 2, and will be discussed in the following. 

a) First impression / idea of text content for the human analyst: On the basis 

of a translation produced by SMT, even if not of perfect quality, the human analyst 

can infer the document’s content. Such a broad translation can serve 

the human analyst in a first screening of the documents to decide whether 

the document is of any relevance and should be passed on for proper (human) 

translation or a different further analysis. Apart from that, under the dogma 

“any translation is better than no translation” this rough translation can help 

the analyst with the different intelligence tasks, where texts in different languages 

need to be processed. This would apply if no translator is available, or, 

for efficiency reasons. 

b) Automatic collection: A rough translation can also serve as input for automatic 

information retrieval and for automatic classification. To automatically search 

for relevant documents in different languages, it is usually sufficient if the broad 

content of the documents is provided. The same applies to automatic classification 

of the relevance of documents according to the mission’s needs.


c) Automatic processing and exploitation, and analysis: Translation output of higher 

quality can serve as input for automatic document processing and content 

analysis. If it is important to efficiently or to fully automatically process documents, 

e.g. where a vast amount of data needs to be analyzed, automatic translation 

might be the only way to exploit the whole data. In this case, the documents 

collected can be translated by an SMT system and the translations serve 

as the input for further NLP processing such as information extraction, text 

mining or opinion mining. The quality of the final NLP output then highly 

depends on the translation quality. 

Our approach claims that machine translation is highly useful for the optimal 

analysis of large amounts of foreign material. It can be applied to assist the human 

analyst and can generate translations that can serve as input for further automatic 

NLP processing. As regards the latter, the quality of the generated translations 

will determine what kind of further automatic analysis can be deployed. Therefore, 

the extent to that text in different languages can be processed automatically by 

NLP applications depends on the quality of the generated translations as well as on 

the nature and difficulty of the further NLP tasks. And, if a vast amount of textual 

data in different languages needs to be processed, i.e., on the internet or from 

other document collections, the application of MT tools might be the only way to 

process the data. 

V. Conclustions 

This paper discussed that NLP technology can strongly support military intelligence 

with the processing of information. Textual data that needs to be analyzed 

for intelligence purpose includes not only documents collected by human intelligence 

but also open source documents. Especially, the internet today carries a lot 

of information that may be relevant in the context of military operations. Overall, 

the amount of documents that needs to be processed for intelligence purposes 

is extremely large. The manual analysis of textual data is very labor-intensive and 

time-consuming and in some cases not even practicable. This problem is even worse 

if documents in different languages have to be processed as there may be only few or 

no translators available. This work argued that NLP intelligence tools can be applied 

for the efficient and effective content analysis of documents in different languages. 

We described how NLP technology can be applied to support the intelligence 

process on tasks that involve the processing of text. For the collection of relevant 

documents from intelligence document collections or open source databases, such 

as the internet, NLP tools for automatic information retrieval and document classification 

can be utilized. Texts can be processed and information can be identified, 

extracted and analyzed by NLP technologies such as information extraction, text 

mining and opinion mining. For the processing of documents in foreign languages


279 

machine translation can be applied. In particular, the approach of statistical machine 

translation holds various advantages in the context of military applications. 

In our research project ISAF-MT we have created a statistical machine translation 

system for Dari and German. By our work we proved i) that SMT systems can be 

built rapidly and ii) that the generated translations can be of sufficient quality to 

bring across the meaning of the source text. We therefore argued that translations 

generated by such an SMT system can assist intelligence processing in different ways: 

a) to give the human analyst a broad idea of the documents’ content, b) as input for 

automatic document collection, and c) (if of sufficient quality) as input for automatic 

processing, exploitation and analysis of information from texts. 

NLP technology may be applied to assist the human intelligence analyst at different 

levels. In general, NLP processing does not reach 100% accuracy. Therefore, 

the extent to that processing can be performed automatically depends on different 

factors, e.g., the nature and complexity of the input data as well as on the nature and 

difficulty of the NLP processing task. As NLP is an active and quickly developing 

research field, technologies will improve. We argued that NLP tools can support 

military intelligence today, and due to the increasing importance of the internet and 

the development of NLP technology, will become even more essential in the future. 

Consequently, NLP technology for multilingual content analysis is needed to fully 

exploit the information that is provided to us by different intelligence sources. 

References 

[1] C. Best, “Challenges in Open Source Intelligence,” in Proceedings of the European 

Intelligence and Security Informatics Conference (EISIC), pp. 58-62, Athens, Greece, 

September 2011. 

[2] Joint Publication, “2-0: Joint Intelligence,” 2007. [Online]. Available: http://www.dtic. 

mil/doctrine/new_pubs/jp2_0.pdf 

[3] Joint Publication, “2-01: Joint and national intelligence support to military operations,” 

2012. [Online]. Available: http://www.dtic.mil/doctrine/new_pubs/jp2_01.pdf 

[4] M. Hecking, and S. Noubours, “Fast Realization of Automatic Translation Systems 

for New Mission-Relevant Languages,” in Proceedings of the 17th International 

Command and Control Research and Technolgy Symposium (ICCRTS), Fairfax, VA, 

USA, June 2012. 

[5] T.M. Chen, “How networks changed the world,” Network, IEEE, vol. 25, no. 6, pp. 2-3, 

November 2011. 

[6] International Telecommunication Union, “The World in 2011: ICT Facts and 

Figures,” 2011. [Online]. Available: http://www.itu.int/ITU-D/ict/facts/2011/material/ 

ICTFactsFigures2011.pdf 

[7] Facebook, “Facebook’s latest news, announcements and media resources: Fact Sheet – 

Facebook,” Internet: http://newsroom.fb.com/content/default.aspxNewsAreaId=22, 

December 2012 [Mar. 30, 2012].


[8] Twitter, “Twitter Blog: Twitter Turns Six,” Internet: http://blog.twitter.com/2012/03/ 

twitter-turns-six.html, March 2012 [Mar. 30, 2012]. 

[9] G. Weimann, and United States Institute of Peace, “www.terror.net: How 

Modern Terrorism Uses the Internet,” 2004. [Online]. Available: http://www.usip. 

org/publications/wwwterrornet-how-modern-terrorism-uses-internet. 

[10] G. Weimann, “The Psychology of Mass-Mediated Terrorism,” American Behavioral 

Scientist, vol. 52, no. 1, pp. 69-86, September 2008. 

[11] R. Feldman, “‘Friend’ request from Al-Qaeda,” University of Haifa: Communications 

and Media Relations, March 29, 2004. [Online]. Available: http://newmedia-eng.haifa. 

ac.il/p=5680. [Apr. 2, 2012]. 

[12] M. Hecking, and C. Schwerdt, “Multilingual Information Extraction for Intelligence 

Purposes,” in Proceedings of the 13th International Command and Control Research 

and Technolgy Symposium (ICCRTS), Bellevue, WA, USA., June 2008. 

[13] S. Noubours, and M. Hecking, “Semantic Analysis of Military Relevant Texts for 

Intelligence Purposes,,” in Proceedings of the 16th International Command and 

Control Research and Technology Symposium (ICCRTS), Québec City, Québec, 

Canada, June2011. 

[14] B. Haarmann, L. Sikorski, and U. Schade, “Text Analysis beyond Keyword Spotting,” 

in Proceedings of the Military Communications & Information Systems Conference 

(MCC), Amsterdam, The Netherlands, October 2011. 

[15] M. Hecking, A. Wotzlaw, and R. Coote, “Multilingual Content Extraction Extended 

with Background Knowledge for Military Intelligence,” in Proceedings of the 16th 

International Command and Control Research and Technology Symposium (ICCRTS), 

Québec City, Québec, Canada, June 2011. 

[16] W.D. Lewis, “Haitian Creole: How to Build and Ship an MT Engine from Scratch 

in 4 days, 17 hours, & 30 minutes,” in Proceedings of the 14th Annual Conference 

of the European Association for Machine Translation (EAMT), St Raphael, France, 

May 2010. 

[17] W.D. Lewis, R. Munro, and S. Vogel, “Crisis MT: Developing a Cookbook for MT 

in Crisis Situations,” in Proceedings of the Sixth Workshop on Statistical Machine 

Translation (WMT-11), located at EMNLP, Edinburgh, United Kingdom, July 2011. 

[18] P. Koehn, Statistical Machine Translation. Cambridge, UK: University Press, 2010. 

[19] P. Koehn, H. Hoang, A. Birch, C. Callison-Burch, M. Federico, N. Bertoldi, 

B. Cowan, W. Shen, C. Moran, R. Zens, C. Dyer, O. Bojar, A. Constantin, 

and E. Herbst, “Moses: Open Source Toolkit for Statistical Machine Translation,” 

in Proceedings of the Annual Meeting of the Association for Computational Linguistics 

(ACL), Prague, Czech Republic, June 2007. 

[20] Google Translate, http://translate.google.com/ 

[21] K. Papineni, S. Roukos, T. Ward, and W.-J. Zhu, “BLEU: a method for automatic 

evaluation of machine translation,” in Proceedings of the 40th Annual Meeting on 

Association for Computational Linguistics (ACL 2002). Association for Computational 

Linguistics, Stroudsburg, PA, USA, July 2002.

Information Fusion Under Network Constraints 

Felix Govaers, Alexander Charlish, Wolfgang Koch 

Department of Sensor Data and Information Fusion, 

Fraunhofer FKIE, Wachtberg, Germany, 

{felix.govaers, alexander.charlish, wolfgang.koch}@fkie.fraunhofer.de 

Abstract: In this paper, various techniques for information fusion in distributed sensor applications are 

presented. In the considered scenarios a number of challenges exist due to limitations on the communication 

between sensor nodes. Firstly, the challenge of delayed data processing is addressed in order 

to present solutions for optimal state estimation when out of sequence data is received at the fusion 

center. Secondly, solutions for Measurement Fusion and Track-to-Track Fusion in distributed sensor 

applications with the challenge of constrained communication are summarised. In a simulative evaluation 

the behaviour of several approaches under conditions of a reduced probability of successful 

communication is investigated. It is found that decorrelated distributed tracking performs better 

than a central Kalman filter when communication is constrained. 

Keywords: Track-to-Track Fusion, Distributed Kalman Filter, Communication Constraints 


The increasing trend in ubiquitous communication technologies coupled 

with decreasing costs for electronic components and hardware is leading to sensor 

systems producing large quantities of data. As a branch of applied computer 

sciences sensor data fusion addresses the ability to process this vast quantity 

of information, generated by potentially multiple heterogeneous sources, in an effective 

and timely manner. Both methods and results of sensor data fusion are 

focused towards obtaining cognition, whereby information is intelligently processed 

to obtain situation awareness, which can provide the basis for informed 

decisions and actions. 

The objective of sensor data fusion is best described by a situational awareness 

emerging from combining partial information. Efficient algorithms support 

the user in order to enable decision making in critical situations. Through these 

high-performance algorithms, sensor data fusion is able to utilize both data correlations 

in time as well as complementary information gained by different sensors. 

To this end, both the measurement noise and the process evolution are described 

as a stochastic model. Combining these models one is able to fuse sensor data accumulated 

over time and to derive estimates. By means of computer implementations


and highly sensitive sensors, it is possible to estimate the state of one or multiple 

objects with a high accuracy even if they are spatially remote. Furthermore, the fusion 

process may integrate context information or expert knowledge in order to 

improve the results. 

There are various challenges which must be tackled for effective sensor data 

fusion. Fluctuations in the signal within the circuit board of a sensor leads to 

noisy, imprecise data. Interference from the environment or poor sensor calibrations 

directly imply a systematic bias. Furthermore, challenges can result from 

a mathematically under-determined relationship between observation and state 

space. This inevitably results in “ghost measurements”, which contradict the real 

solution. In many applications, the objects of interest cannot be separated from 

the environment. Consequently, algorithms for sensor data fusion often have to 

cope with clutter generated by additional objects, which are not of interest. 

Practical needs from both civilian and military applications as well as the rapid 

development of information and communications technology are driving factors 

behind multiple sensor applications. In such scenarios, one faces additional 

challenges if the sensors are located at spatially distributed positions and the data 

communication possibly involves heterogenous network links. For example, coordinate 

systems for local data processing can be displaced with respect to a central 

fusion center. Moreover, it is common that local clocks in distributed systems are 

unsynchronized, which must be considered by the information fusion scheme. 

Furthermore, local data caching as well as varying communication delays give 

rise to outdated measurements, which requires sophisticated treatment because 

reprocessing schemes are usually not feasible due to time limitations. 

Generally, tracking refers to estimating a state of an object in terms of selected 

parameters, like its position and velocity. The resulting tracks consist of both 

the estimate and an associated measure of uncertainty. In this paper, we describe 

challenges of tracking in communication-constrained distributed sensor applications, 

i.e. a statistical parameter estimation conditioned on sensor data obtained 

by multiple sensors, which are connected to one or more fusion centers. Such 

a scheme is depicted in Figure 1. 

This scheme is hindered in real implementations as the communication 

channels have time varying properties. Therefore, it is of crucial importance to 

find proper fusion algorithms, which take into account the imperfect nature 

of the communication links. Imperfect communication implies that information 

packages can get lost, change their order of arrival, or link breakdowns may appear. 

This specific topic has received little attention for many years in literature. In order 

to cover a great variety of network scenarios, we will present solutions at different 

levels of data preprocessing in this paper.


283 

Figure 1. An example of a distributed sensor application. A heterogenous communication network 

including reliable high bandwidth links for stationary sensors on the ground, time slot based satellite 

communication for far distance transmissions, maritime network techniques using VHF/UHF 

frequencies, and underwater links with very unpredictable properties illustrate the variety of challenges 

in such a scenario 

II. Formulation of the problem 

Let us assume, state vector describes the parameters of interest of an object 

observed by one or multiple sensors at time . In the classical tracking scenario, 

this state usually includes the position, velocity, and acceleration, but other properties 

such as classification might also be included. The observation process is modeled 

as a function of the state. For the sake of simplicity, the measuring function 

is assumed to be linear and might therefore be written as a matrix . Moreover, 

the measuring process includes some noise 1 , which is modeled as an additive 

Gaussian white noise with a covariance Matrix Therefore, the measurement 

of the object at time can be expressed as 

z Hx , 

(1) 

l l l l 

where vl 

Rl 

In order to fuse the following measurement at time to the estimate of time 

 

P , 

kk | 

Pkk | 1 Wkk | 1 SW 

k kk | 1 the evolution of the state is modeled as a Markov 

chain as follows. Similar to the sensor model, a linear transition function Fl 

1| l 

is introduced and a Gaussian distributed process noise is added. We have 

xl 1 Fl 1| l 

xl wl, 

(2) 

where wl ~ Ql 1| l. 

The optimal, iterative solution to the problem of estimating the expected 

state x 

kk 

and its estimation error covariance P 

kk 

considering all sensor data up to 

1 

Noise of the measurement process is usually caused by thermal fluctuations or by unintended interplay 

with the surrounding environment.


time with respect to the minimum mean squared error (MMSE) yields the Kalman 

filter [1] The Kalman filter consists of the two steps prediction: 

x F x 

(3) 

, 

kk | 1 kk | 1 k1| k1 and filtering: 

P F P F Q 

 

kk | 1 kk | 1 k1| k1 kk | 1 kk | 1 

(4) 

x x W 

(5) 

kk | kk | 1 kk | 1 k, 

(6) 

, 

k 

zk Hx 

k kk | 1 

W P H S 

 

kk | 1 

kk | 1 k k 

, 

(7) 

S HP H R 

(8) 

k 

k kk | 1 k 

 

k, 

P P W SW 

 

. 

kk | 

 

kk | 1 

kk | 1 k kk | 1 (9) 

However, in network constrained scenarios Kalman filter assumptions are 

often not satisfied. In particular, imperfect communication leads to: 

a) measurements, which arrive in a timely disordered way, 

b) insufficient bandwidth such that not all measurements can be transmitted, 


c) synchronization and sensor registration errors. 

As a consequence, there is a need for sophisticated algorithms which are 

suited to multi-sensor scenarios and robust against significant communication 

constraints. In this paper, we present two state-of-the-art Kalman filters for tracking 

object parameters in such scenarios. 

III. Kalman filter processing for delayed measurements 

In most target tracking algorithms, the characteristics of conditional probability 

k 

densities p( xl 

| Z ) of target states are calculated, which describe the available 

knowledge of the target properties at a certain instant of time given a time 

series of imperfect sensor data accumulated up to time In certain applications, 

however, the kinematic target states xk 

, , xn, 

n k, 

accumulated over a certain time 

window from a past instant of time up to the present time is of interest. 

The statistical properties of the accumulated state vectors are completely described 

by the joint probability density function conditioned on the measurement data, 

k 

p( xk, , xn 

| Z ). These densities are called Accumulated State Densities (ASDs). 

By marginalizing them, the standard filtering and retrodiction densities directly 

result; in other words, ASDs provide a unified description of filtering and retrodic-


285 

tion. In addition, ASDs fully describe the correlations between the state estimates 

at different instants of time. 

All information on the target states accumulated over a time window 

tk, tk , , tn 

of length kn 

1, 

xkn ( xk, , xn) 

(10) 

that can be extracted from the time series of accumulated sensor data up to 

k 

and including time is contained in a joint density function p( x 

kn| Z ), which 

is called a ASD. 

Iterative ASD 

ASD posterior 

z z z z z z z z z 

0 

time t 

Figure 2. Schematic illustration of an iterative ASD filter and the ASD posterior. The iterative filtering 

scheme includes the calculation of a prior ASD density using a fixed window size. It is based 

on an ASD posterior, which yields the joint density conditioned on the entire set of measurements 

Given the full posterior ASD [2], one can calculate the exact cross-covariance 

to timely delayed measurements. To this end, let us consider a measurement 

produced at time with t n 

m t k 

i.e. possibly before the `present’ time 

where the time series is available and has been exploited. We would like to 

understand the impact this new, but late sensor information has on the present 

and the past target states xl , l n, , k, 

i.e. on the accumulated state x 

kn 

Let 

be a measurement of the observed object state at time characterized by 

a Gaussian likelihood function, which is defined by a measurement matrix and 

a corresponding measurement error covariance matrix We further renumber 

the target states xk, , xn 

such that xk, , xm, , xn : xkmn 

: : 

are consistent with 

their time stamps ( tl) lk, , m, , 

n. 

By an application of continuous time retrodiction (see [3], e.g., for a detailed 

discussion), it is well possible to extend the posterior density of the state x 

kn 

to 

a prior density of the extended state x 

kmn : : 

[4]. One obtains a single Gaussian density 

with a joint expectation vector including the estimates for all single states: 

k 

px ( | Z) N ( x ; x , P ), 

(11) 

kmn : : kmn : : kmnk : : | kmnk : : | 

where the expectation vector accumulates the target estimates for each state within 

the time window: 

x ( x , , x , , x ). 

(12) 

k: mnk : | kk | mk | nk |


The single state covariances are the block-diagonal entries of P 

k: mnk : | 


the off-diagonal entries correspond to the respective cross-correlations in time [2]. 

If one introduces a projection matrix defined by mxkmn : : 

xm, 

which 

extracts the target state from the accumulated state vector x 

kmn : :. The likelihood 

function of the out-of-sequence measurement with respect to the accumulated 

target state is thus given by: 

pz ( 

m 

| xkmn : :) 

N ( zm; Hm mxkmn : :, Rm) 

. 

(13) 

Standard reasoning for the Kalman filter directly yields for the accumulated 

state density: 

pz ( | x ) px ( | Z) 

px ( | z, Z) 

(14) 

( | ) ( | ) 

k 

k m kmn : : kmn : : 

kmn : : m k 

dxkmn : : 

pzm xkmn : : 

pxkmn 

: : 

Z 

N ( x ; x , P ) 

(15) 

kmn : : kmnk : : | , m kmnk : : | , m 

with parameters obtained by a version of the Kalman update equations: 

x x W ( z H x ) 

(16) 

kmnk : : | , m kmnk : : | kmn : : m m m kmnk : : | 

 

Pkmnk : : | , m 

Pkmnk : : | 

Wkmn : : 

Skmn : : 

Wkmn 

: :, 

(17) 

where the corresponding Kalman gain and innovation matrices are given by: 

S H P H R 

 

kmn : : m m kmnk : : | m m m 

(18) 

Wkmn : : 

Pkmnk : : | 

mH mS 

kmn : :. 

(19) 

Note that the matrix S 

kmn : :, which has to be inverted when calculating the Kalman 

gain matrix, has the same dimension as the measurement vector i.e. 

is low-dimensional matrix, just as in standard Kalman filtering. Moreover, it is 

easy to see that it is equivalent to the standard innovation covariance, as we have 

mPk : mnk : | 

mPmk 

|. 

(20) 

Nevertheless, the processing of an out-of-sequence measurement has impact 

on all state estimates and the related error covariance matrices in the time window 

considered. Accumulated state densities are therefore well suited to quantitatively 

discuss the question to what extent a delayed measurement is still useful or not, 

a phenomenon that is sometimes called “information aging”. 

IV. Fusion schemes for distributed tracking 

This section presents a modified Kalman filter processing scheme for distributed 

tracking applications such that the locally produced tracks can easily be 

fused. The basic idea of this scheme is to remove parts of the track maintenance


287 

in the fusion center. In particular, it is possible to modify all local tracks such that 

they become decorrelated. The cross-correlations occur because of a common evolution 

covariance in every prediction step [5]. This is due to the fact that all sensors 

sites observe the same target. In [6] it is shown that a central Kalman filter can be 

calculated in a distributed manner by decorrelating the local tracks. This is achieved 

by calculating the global estimation error covariance of the system. The proposed 

distributed Kalman-type processing scheme makes essentially use of the fact that 

the sensor measurements do not enter into the update equation for the estimation 

error covariance matrices. In particular, the covariance matrices of all sensors 

can be calculated at each individual sensor site without any further communication 

(provided the relevant parameters of all sensors are known at each sensor site). 

For the sake of notational simplicity, let all S sensors be equally aligned and 

synchronized with the same data update rate. However, these assumptions are not 

essential and can well be relaxed. Furthermore, we assume the measurement error 

covariance matrices { R 

s } 

S 

k s 

of all individual sensors to be known to each local sensor 

processor. As mentioned above, the proposed distributed processing scheme aims at 

establishing decorrelated local tracks, such that fusing them yields exactly the result 

of central Kalman filter processing. Let us assume, a set of decorrelated local tracks 

at time are given which have processed all sensor data up to time Then, as all 

densities involved are Gaussians, we can write the fused track as the following product: 

S 

k s s 

l lk | 

N ( 

l; xlk | 

, 

lk | 

s1 

px ( | Z) c x P) 

,. 

(21) 

In the sequel, as well as in most applications, it is unnecessary to calculate 

the normalization constant c 

lk 

explicitly. By virtue of the factorization lemma for 

Gaussians, this product representation can be transformed into a single Gaussian: 

S 

k s s 

l lk | 

N 

l; lk | 

, 

lk | 

s1 

px ( | Z) c ( x x P) 

(22) 

N ( x ; x , P ), 

(23) 

l lk | lk | 

with an expectation vector x 

lk 

and a covariance matrix P 

lk 

obtained by fusing x 

lk 

and P s , s1, , S, 

according to following equations: 

lk 

S 

1 s 1 

lk | 

Plk 

| 

s1 

P 

(24) 

S 

s 

s 

lk | lk | lk | lk | 

s1 

x P ( P x ). 

(25) 

Convex combinations of this type are fundamental in almost all data fusion 

applications (see e.g. [7]). As previously stated, under conditions where Kalman

modeled by a linear Gaussian central Kalman Markovian Kalman filtering transition filter. is applicable, density i.e. in case of wellseparated 

targets, assuming perfect detection, k|x k−1) = N xscheme and in absence k; F directly calculated: 

k|k−1 x k−1, Dto an arbitrary 

local posterior density is introduced in the following way. By 

p(x apply the proposed 

 

exploiting k|k−1 For the number sake 

x 

processing given that l|k = P 

Kalman l|k 

p(x apply the proposed scheme directly to an arbitrary number 

x l|k = P l|k P s −1 

l|k x s k|x k−1) = N in [2], the result is equivalent to a central 

l|k fil 

In 2008 and 2009, first T2TF the product formula for Gaussians, we replace all 

of of simplicity, sensors. schemeInfor we 2010, arbitrary 

here the assume generalized conditions solution where was . measurement 

x k; F 

derived standard 

(3) 

k|k−1 x k−1, D k|k−1 . For the sake processing given that Kalman filter assumptions hold s=1 

of false measurements. For notational simplicity let us assume 

all sensor covariances are known. 

instants of time, which is equivalent local covariances by a one: 

Kalman presented to a 

filtering in Kalman [2]. filter 

is applicable, i.e. in the 

P 

case −1 

l|k 

S synchronized sensors produce measurements the same 

= S and 

of sensors. In 2010, the generalized solution was derived and 

s=1 

of simplicity, we here assume conditions where standard all sensor covariances are known. To this end, a globalized 

of wellseparated 

Notational center, posterior combinations 

P s −1 

l|k local Convex posterior combinations density is of (2) 

introduce this type 

Kalman presentedfiltering in [2]. is applicable, processing i.e. inallthe measurements case of wellseparated 

Notational targets, Preliminaries: 

assuming perfect Let 

in a fusion local Convex 

was density 

targets, Preliminaries: 

presented is ofintroduced this type are 

assuming 

instants of time t l, l =1,...,k denoted by Z l = {z s perfect Letin detection, all the fundamental 

time-varying following in 

s=1 way. almost 

and in absence S 

target By 

exploiting all data fusion 

l }S s=1. 

p(x k|Z k ) ∝ N x k; x s k|k 

The proposed methodology can be directly extended to asynchronous 

Military sensors. Communications The accumulation of and the sensor Information data Z l up Technology... same 

all P 

, the product applications formula (seefor 

e 

by Koch detection, all time-varying 

in [14] and and in[15]. absence target 

However, exploiting all 

of properties data 

was 

fusion the 

false measurements. of notinterest product possible 

applications 

For at formula to 

(see 

anotational given for e.g. 

time Gaussians, [16, Chapter 

simplicity t l be collected we replace 12]). 

let us assume by all 

S a 

local Note covariances Ps that k|k this type by aofglobalized T2TF (4) requ 

of properties false measurements. of interest For at anotational given time o 

apply the simplicity t 

proposed l be collected letscheme us assume by a 

directly local 

Sstate to 

Note covariances 

synchronized vector an 

that 

arbitrary 

this type 

x l, sensors whose by number aofglobalized T2TF requires 

produce posterior one: a decentralized 

measurements density conditioned x l|k = Pdecorre- 

lation, 

at the s=1 l|k on 

288 

lation, s −1 

l|k x s l|k 

because . 

all sensors (3) 

observe 

Sstate synchronized vector x l, sensors whose produce posterior 

of sensors. measurements density conditioned 

In 2010, the the on 

generalized same all 

instants data solution 

because 

upoftotime the t 

to and including the time t k, typically the present l, current l =1,...,k time t k denoted is givenbyby Z 

time, is 

l 

the = {z Gaussian s 

= N x 1 S 

k; ˜x s 

a time series recursively defined by Z k = {Z k, Z k−1 k|k 

}. The 

S 

, 1 S 

l }S s=1. 

The N was derived 

all sensors 


observe the same target. Therefore, s=1 

the local tracks 

p(x k|Z 

S ˜P k x s l|k are not opti 

instants data up to the current time t 

presented k is given by the Gaussian 

[2]. 

) ∝ k|k , N(5) 

x k; x 

N of time t l, l =1,...,k denoted by Z the local tracks x s l = {z s S 

proposed x l; x l|k , Pmethodology l|k with l|k are not 

 

optimal in a local 

 

sense, if (1) 

l 

x expectation can Convex be directly vector combinations xl|k extended and covariance of to this asynchronous 

matrix all time-varying Psensors. l|k . The The mechanical target s=1 accumulation alldynamics dataoffusion the of sensor applications the data system Z (see 

type are holds. fundamental However, inif almost 

l; x l|k , P l|k with expectation vector xl|k and covariance 

}S s=1. 

p(x 

holds. However, k|Z k ) ∝ N x 

if all of them k; x 

are s k|k all of them 

The proposed methodology can beNotational directly extended Preliminaries: to asynchronous 

matrix Psensors. l|k . The The mechanical accumulation dynamics 

, fused Ps k|k 

(4) 

according to (2) 

Let s=1 

s=1 

time series produced by the measurements of an individual 

l up are e.g. and [16, (3), Chaptera globally 12]). optimal estim 

properties of the of 

of interest sensor the data system aZ l given up are and (3), a globally optimal estimate is obtained. As shown 

to 

time modeled and 

t l including 

bebycollected a linear S 

filtering is appropriate sensor s ∈ {1,...,S} for tracking, only denoted the by covariance Zs k the time Gaussian t 

. The statistical matrices P 

lk 

can = be Ncalculated 

x k; ˜x s 

properties of an individual sensor measurement z 

locally for all sensors without exchanging sensor s k|k , ˜P 

 

k, typically Markovian the transition present time, density is 

k|k , = N (6) x 1 S 

ap(x k; 

time k|xseries k−1) = recursively N by a Note that this type 

 

of T2TF requires in a[2], decentralized the resultdecorre- 

lation, xby k−1, Zbecause l is described 

k D= k|k−1 {Zall k, . sensors Z For k−1 the }. observe The sake the processing same target. givenTherefore, 

k|x k−1) = N time t k, typically the present time, is in [2], the result 

is equivalent 

tomodeled and including by a linear the Gaussian Markovian transition density 

state vector x l, whose posterior density conditioned xon k; all 

p(x Fdefined k|k−1 = N 

equivalent 

x 1 S 

to a central measurement 

x k; F k|k−1 x that Kalman S fi 

s=1 

s= 

data k−1, D 

up to k|k−1 . For the sake 

k; ˜x s 

a time series recursively defined the current time t k time 

is of given simplicity, 

by a probability density function p(z data, provided the measurement 

s series 

by 

produced 

theweGaussian 

here by the assume measurements conditionsofwhere an individual standard all sensor covariances are 

l |xl), also called sensor 

S 

sensor s ∈ {1,...,S} only is denoted where the by Zglobalized local parameters ˜x 

error covariance likelihood matrices function, of which each needsindividual to be known up tosensor a constantare known, k or if they can be 

s known 

N by Z k = {Z k, Z k−1 k|k 

}. The processing given that Kalman S filter assumptions , 1 S ˜P k|k , (5) 

the local tracks x s hold and 

s=1 

l|k are not optimal in a local sense, if (1) 

time of simplicity, series produced we here by the assume measurements conditions 

x l; x l|k , P ofwhere an l|k with individual standard all sensor covariances are known. To this end, a globalized 

expectation Kalman vector xl|k filtering and covariance is applicable, 

S holds. i.e. However, in the k|k and covariance 

s . The case if all statistical of of wellseparated 

of 

them are local fused posterior according density = 

to is (2) 

Nintroduc 

sensor Kalman s ∈ filtering {1,...,S} is applicable, only is x k; ˜x 

matrix denoted i.e. 

P by in 

l|k . Zthe case of wellseparatedof 

targets, an individual assuming sensor perfect 

local posterior density is introduced in the following way. By 

The s k . The mechanical statisticaldynamics factor only: p(z 

reconstructed each node s 

l |xl) ∝ of s l (xl; properties 

the zs l ). of targets, the 

an individual 

system assuming = areN 

x 

sensor perfect and k; ˜P measurement k|k 

(3), ˜x s detection, area given globally zand by: s l isoptimal in described absence estimate exploiting is obtained. the product As shown 

s=1formula fo 

properties modeled measurement detection, 

by a linear zand s k|k 

in absence 

Gaussian Markovian 

by of afalse probability measurements. transition 

density 

density For function notational p(z 

Structure: This paper is organized sensor as follows. network. The next If the locally s l |xl), simplicity also called let us 

produced ˜x tracks 

s k|k = sensor assume 

likelihood function, which needs to be known up to a constant ˜P 

local covariances by a globalized 

p(x k|x k−1) = N exploiting the product formula for Gaussians, , ˜P 

 

k|k , (6) 

we replace all 

l is described 

s=1 

in [2], the result is equivalent to a central measurement 

by of afalse probability measurements. density For function notational p(z s simplicity let us assume local covariances by a globalized one: 

l |xl), also called x k; Fsensor 

k|k P s where −1 

k|k xs the globalized local 

k|k (7) param 

k|k−1 x k−1, where S synchronized D k|k−1 the globalized . For sensors the sake local produce parameters processing measurements ˜x 

S synchronized sensors produce measurements at the same 

given s k|k and that covariance the Kalman same filter assumptions hold and 

likelihood function, which needs ofsection to simplicity, be known states the we upproblem to here a constant assume addressed conditions this paper. In particular, 

 

x 

lk 

are sent at 

we 

some 

introduce 

arbitrary 

the productinstant representation 

of 

for 

time 

the fused 

to 

posterior 

a fusion node, they can be S 

 

factor instants only: ofwhere p(z time s fused −1 

l |xl) t l, standard l =1,...,k s l (xl; zs l ). denoted by Z l = {z s ˜P k|k are given by: 

S 

instants of time t 

all sensor covariances arel }S known. s=1. To this end, a 

p(x k|Z k globalized 

l, l =1,...,k denoted by Z ) ∝ 

TheStructure: proposed methodology This kpaper iscan organized be directly as follows. extended ˜P 

according to (25), densityyielding which was the the key element density in [2] px for( exact 

k 

| Zsolution 

) N ( xl; xlk | 

, Plk 

| 

) 

k|k The = to Sasyn- 

chronous detection, sensors. and in˜x The s k|k absence accumulation of sensor data Z l up 

 

next P 

. According s −1 

k|k . ˜x (8) 

section states the problem addressed in this paper. In particular, s=1 to 

s k|k = s=1 ˜P 

N x 

Kalman filtering is l = {z s S 

 

factor only: p(z s l applicable, }S s=1. 

l i.e. in the case of wellseparated 

organizedtargets, as follows. assuming The next perfect s −1 

k|k 

k; 

The proposed methodology |xl) ∝ s l (xl; can zs l ). 

˜P k|k are given by: 

p(x k|Z k ) ∝ N local x k; xposterior s k|k 

be directly extended to asynchronous 

sensors. The accumulation of the sensor data Z 

, Ps k|kdensity is introduced (4) in the following way. By 

Structure: This paper is k|k P 

exploiting the product formula for Gaussians, we replace all 

of T2TF. Based on the results of the cited preliminary paper, 

 

of false measurements. For notational l up 

= s=1 ˜P k|k P s −1 

k|k 

S 

the approach of a globalized [6], it is likelihood not required 

we to simplicity 

introduce and including let us 

function is derived to update 

the product the assume time 

in sectionthe representation t 

III. Its global k, typically 

Note that track 

forthe the 

thepresent globalized 

fused 

at each 

posterior time, is 

covariance scan time ˜P = N x 1 

to and including the time t 

local covariances by a globalized one: 

k|k does not ˜P depend on k; 

S k, typically the present time, is 

synchronized sensors produce measurements 

density a time which series was recursively the= same N x 1 S 

xs k|k 

(7) 

section states the problem addressed in this paper. In particular, 

S 

−1 

we introduce the product representation for the fused posterior 

the key defined k; ˜x 

elementby impact on practical implementations is discussed in section 

in 

local 

[2] Z k s for = {Z 

sensor 

an k, exact Z k−1 

index 

solution }. The 

k|k = S SP 

a time series recursively defined by Z s 

instants of time t s anymore. This two-stage prediction s=1 

in order to obtain an k = {Z k, Z 

optimal k−1 k|k 

}. The 

S 

, 1 S ˜P k|k , (5) 

˜P 

density which was the key element [2] for an l, exact l =1,...,k solution 

k|k = S P s −1 

denoted 

result. of time 

Furthermore, T2TF. series by Z 

Based produced l = {z 

on s l }S s=1 k|k . S (8) 

 

time series produced by the measurements of an individual 

s=1. by 

it results is 

thenot s=1 measurements of necessary to send the fusion 

result x 

IV. We close the with a conclusion given in section V. (globalization 

the cited preliminary of an individual 

and application 

paper, 

of the evolution model) 

S 

of T2TF. Based on the resultsThe of the proposed cited preliminary methodologypaper, 

can be was 

asensor directly 

globalized s extended ∈ {1,...,S} to asynchronous 

sensors. The accumulation tracking 

likelihood only 

S 

p(x k|Z k ) ∝ N x k; x s 

function is denoted 

kk 

and P 

kk 

to any node. Therefore, 

necessary 

is derived by Z 

this 

to 

ins distributed k k|k 

. 

reveal 

section The statistical 

, Ps k|k 

(4) 

sensor s ∈ {1,...,S} only is denoted by Z 

a general 

III. Its Note that the globalized = covariance N x 

s k . The statistical 

= N 

x k; 

scheme for decorrelated tracks: 

II. FORMULATION OF impact properties of the sensor 

THE PROBLEM on of practical an data individual Z 

implementations l up k; ˜x s sensor measurement 

We obtain discussed z s s=1 

l updates 

indescribed 

 

 

properties of an individual sensor measurement z s k|k , ˜P 

 

a globalized likelihood function is derived in section III. Its Note that the globalized covariance ˜P k|k does k|k not , depend on (6) 

of 

section the local sensor indexs=1 

s anymore. 

impact on practical implementations to and including is discussed l is 

the indescribed 

time section t local track estimates using the global 

scheme is well suited for applications 

k, typically the local 

IV. by We a probability the sensor presentindex s=1 

where 

close the 

reduced 

paper density time, sisanymore. This 

with function aor conclusion p(z 

covariance arbitrary s two-stage prediction 

l |xl), given also 

instead 

in = called 

communication 

of 

section N sensor x k; 

the local 

V. 

1 S 

(globalization and application of 

one. 

where ˜x s In other 

the 

words, 

globalized 

we engage 

local param 

time In series this paper, recursively we address definedthe bylikelihood problem Z k = {Zof function, k, optimal Z k−1 k|k 

}. which T2TF Theneeds to be known up to a constant S 

, 1 S ˜P k|k , (5) 

IV. by We a probability close the paper densitywith function a conclusion p(z s l |xl), given alsoincalled section sensor V. (globalization where the globalized and application local parameters of the evolution ˜x s k|k andmodel) covariance was 

likelihood function, which needs to be known up to a constant 

s=1 necessary to reveal a general schem 

time a modified likelihood function in order to keep the tracks 

rates are to be taken at arbitrary series produced 

into instants by 

account. of the time. measurements 

The Asfactor discussed schematic 

only: of 

II. in p(z an 

FORMULATION [2], s individual 

l |xl) idea this ∝ s can l to (xl; the zs OF l THE 

decorrelated. ). 

˜P k|k are given by: 

factor only: p(z s distributed PROBLEM S 

In this paper, 

Kalman We 

we derive 

filter obtain updates of local track 

sensor a closed formula for 

be achieved, s ∈ {1,...,S} if all measurement only is denoted errorby Structure: covariances Zs k . TheThis statistical are paper knownis organized as follows. = The N next 

x k; ˜x covariance s instead˜x of the local one. 

is illustrated in atFigure the sensor 3. 

s k|k In this paper, we address the thisproblem likelihood of function. optimal T2TF 

= ˜P k|k P s − 

k|k 

properties of an individual sites. To sensor this end, measurement section we states achieved z s k|k , ˜P 

 

l |xl) ∝ s l (xl; zs l ). 

necessary ˜P k|k are to given reveal by: a general scheme for decorrelated tracks: 

II. FORMULATION OF THE PROBLEM 

We obtain updates of local k|k , (6) 

Structure: This paper is organized as follows. The next 

lthe is problem described 

˜x s k|k 

a product 

= addressed ˜P 

track estimates using the global 

covariance instead of the local k|k Pone. s −1 

k|k In 

in xs k|k other words, we engage (7) 

this paper. Ins=1 

section 

In this 

states 

paper, 

the 

we 

problem 

address 

addressed 

the problem 

in this paper. 

of optimal 

In particular, 

T2TF 

particular, a modified likelihood function in 

by at arbitrary instants of time. As discussed in [2], this can 

S 

representation a probability of density the functiondensity p(z a 

we s modified 

introduce of the state the product x l,l ≤ k: representation III. forGLOBALIZED the fused posterior 

 

l |xl), alsolikelihood called sensor function 

we introduce the product representation for the fused posterior 

where S in order −1 to keep the tracks 

at arbitrary instants of time. As discussed in [2], this can 

the globalized localLIKELIHOOD parameters decorrelated. ˜x FUNCTION In this FORpaper, we de 

likelihood function, which needs tobe decorrelated. 

density beachieved, known which upifIn to was 

all athis measurement constant the key element 

error 

in 

covariances 

[2] for 

are known 

s k|k and covariance 

˜P paper, ˜P 

S DISTRIBUTED an exact solution 

k|k = S P 

density which was the key element in [2] for KALMAN this PROCESSING 

likelihood function. 

atthe sensor sites. To this end, we achieved a product 

s=1 

factor only: p(z s an 

l 

p(x |xl) exact 

l|Z k of T2TF. 

)=c ∝ solution 

k|k = S we derive P s l (xl; zs l ). 

˜P s −1 a closed 

k|k are k|k . formula for 

be achieved, if all measurement error covariances are known 

(8) 

this likelihood function. 

given by: 

at 

of 

the 

T2TF. 

sensor 

Based 

sites. 

on the 

To 

results 

this end, 

of the 

we 

cited 

achieved 

preliminary 

a product 

l|k 

paper, Nrepresentation x l; x s Based 

l|k , on the resultss=1 

of the cited preliminary paper, 

Structure: This paper is organized Ps l|k of the posterior (1) 

representation density Firstof ofthe all, state we xintroduce l,l ≤ k: a new notation. III. GLOBALIZED The globalized 

a globalized as follows. likelihood The next function is derived in ˜x section s III. Its Note that the globalized LIKELIHO 

k|k covarianc 

a globalized likelihood 

of the posterior 

function 

density 

is derived 

of the 

in 

state 

section 

x l,l ≤ 

III. 

k: 

s=1 Its Note III. that GLOBALIZED the globalized LIKELIHOOD covariance 

section states the problem addressed local posterior ˜P for the = state ˜P k|k P s −1 

k|k x k at xs k|k FUNCTION does notFOR 

depend on k|k (7) 

sensor s will be denoted by 

impact in this paper. on practical In particular, implementations 

Sensor 

S DISTRIBUTED KALMA 

 

discussed in section S 

the local −1 sensor index s anymore 

impact on practical implementations S is discussed in section the local sensor DISTRIBUTED index s KALMAN anymore. This PROCESSING 

 

two-stage prediction 

we introduce 

 

the product 

 

representation IV. We for close the p(x fused l|Z the k paper posterior )=c l|k with Nconclusion x l; x s given l|k , 

Ps in section l|k (1) V. (globalization First of all, we andintroduce application a new of 

IV. We close p(x l|Z the k paper )=c with a conclusion given in section V. (globalization and application of the evolution ˜P 

density which was the key element in [2] for an exact solution 

k|k model) = S wasP s −1 

l|k N x l; x s l|k , Ps l|k (1) First of all, we introduce a new notation. The globalized 

s=1 

local necessary k|k . (8) 

necessary to reveal a general scheme for decorrelated tracks: posterior to reveal for thea state general x k 

sche 

s=1 

local posterior for the state x s=1 

at s 

II. 

of T2TF. Based on the results of the cited preliminary II. FORMULATION paper, k at sensor s will be denoted by 

FORMULATION OF THE PROBLEM 

OF THE PROBLEM 

We obtain updates of local track We obtain updates of local track 

a globalized likelihood function is derived in section III. Its Note that Sensor estimates using the global 

Sensor 

the globalized covariance covariance instead of the local one 

In this paper, we address the problem of optimal T2TF 

˜P k|k does not depend on 

covariance instead of the local one. In other words, we engage 

In this paper, we addressimpact the problem on practical of optimal implementations T2TF is discussed in section the local sensor index s anymore. aThis modified two-stage likelihood prediction function i 

at arbitrary instants of time. at a arbitrary modified instants likelihood of function time. Asindiscussed order toin keep [2], the thistracks 

can 

IV. As Wediscussed close thein paper [2], with this acan 

conclusion given in section V. (globalization and application of the decorrelated. evolution In model) this paper, was we d 

be achieved, if all measurement error covariances are known be decorrelated. achieved, ifInallthis measurement paper, we 

necessary 

error derive covariances a closed formula 

to reveal a 

are 

general 

known for 

scheme thisfor likelihood decorrelated function. tracks: 

at the sensor sites. To this end, we II. achieved at this thelikelihood sensor sites. function. To this end, we achieved a product 

FORMULATION a product OF THE PROBLEM 

We obtain updates of local track estimates using the global 

representation of the posterior density of the state x representation Fusion of the posterior 

covariance 

density of 

instead 

the state 

of the 

x l,l 

local 

≤ k: 

one. In other III. words, GLOBALIZED we engageLIKELIH 

In this paper, we address l,l ≤ k: 

the problem 

III. GLOBALIZED LIKELIHOOD FUNCTION FOR 

of optimal T2TF 

Center 

S a modified DISTRIBUTED KALMA 

at S DISTRIBUTED KALMAN 

arbitrary instants of time. As discussed in [2], 

PROCESSING likelihood function in order to keep the tracks 

 

 

p(x l|Z k this can 

p(x )=c l|k decorrelated. N x l; x s l|k In , Ps this l|k paper, we (1) derive 

be achieved, if all measurement error covariances are known 

First a closed of all, formula we introduce for 

l|Z k )=c a ne 

l|k N x l; x s l|k , Ps l|k (1) First of all, we introduce a new notation. The globalized 

s=1 this likelihood function. 

s=1 at the sensor sites. To this end, local we achieved posterior for a product the state x local posterior for the state x k at 

k at sensor s will be denoted by 

representation Sensor of the posterior density of the state x l,l ≤ k: III. Sensor GLOBALIZED LIKELIHOOD FUNCTION FOR 

S DISTRIBUTED KALMAN PROCESSING 

 

 

p(x l|Z k )=c l|k N x l; x s l|k , Ps l|k (1) First of all, we introduce a new notation. The globalized 

s=1 

local posterior for the state x k at sensor s will be denoted by 

Sensor 

Figure 3. Schematic illustration of a distributed Kalman filter. The sensor nodes process the data 

to local auxiliary tracking parameters. When communication is successful, these can be fused 

at the fusion center in order to obtain the estimated track. When applying exact Track-to-Track fusion, 

the result is equivalent to a central Kalman filter receiving all sensor data 

In the following the most common and state-of-the-art schemes for target tracking 

using multiple sensors are listed. The performance of all of them will be compared 

in the next section. These variable approaches can roughly be divided in the categories 

Measurement-to-Track Fusion (M2TF) and Track-to-Track Fusion (T2TF). 

• Central Kalman Filter (CKF): A Kalman filter at the fusion center is processing 

the measurements of all sensors. This scheme results in an optimal 

solution with respect to the mean squared error metric. 

• Single Kalman Filter (SKF): Each sensor node in the scenario performs M2TF 

using its local data. The tracking algorithm is a Kalman filter processing 

the linearised measurements. At each time step, the node sends its current 

estimate and estimation error covariance to the fusion center, which in turn


289 

selects the track having the smallest trace of the covariance. This scheme 

is included in the evaluation as a benchmark of the worst performance 

achieved when no fusion is performed. 

• Naive Fusion: In this scheme, each sensor node performs its own local 

Kalman filter resulting in local optimal tracks, which are sent to the fusion 

center. In the fusion center the tracks are fused to a global estimate as if they 

were decorrelated. Given a set of local tracks {( x s | 

, s | 

)} 

S 

kk 

Pkk s 1 

the fused parameters 

are obtained via the decorrelated fusion equations (24) and (25). 

As the local optimal tracks are correlated to each other if process noise 

is assumed, this fusion scheme ignores these cross-correlations. 

• Distributed Kalman Filter (DKF): Our approach to T2TF is the decorrelated 

DKF, which was proven to be exact under perfect data association 

conditions previously. It is based on a product representation for the global 

posterior density: 

S 

k 

s s 

k1 Z N( xk 1; xk 1| k1 , Pk 1| k1 

s1 

px ( | 

) ). 

(26) 

The decorrelated DKF described in [6] uses a covariance globalisation step. 

For known posterior covariance matrices P s 

1| 1 

, the globalised prediction 

k k s 1, , S 

parameters are given by 

 

1 

 

 

 

s1 

 

Pkk | 1 SF 

kk | 1 

P 

k1| k1 Fkk | 1 Q 

 

kk | 1 , 

(27) 

 

s 

 

 

x SF P P x 

(28) 

s s1 s1 

s 

. 

k| k1 

k| k1 k1| k1 k1| k1 k1| k1 s 

In the scenario considered in this paper the posterior covariances of the remote 

sensors are known at each node. However, when the sensor measurement characteristic 

is geometry dependent, as with radar, the posterior covariances of the remote 

sensor nodes are not known as they are dependent on the target-sensor geometry, 

and there are no data transmissions between the sensors. In this case, it is possible to 

replace the exact remote covariances by approximations based on the local estimate 

and a radar model applied to known parameters of other sensors. 

• Distributed Kalman Filter with Feedback (DKF-FB): For the DKF with FB, 

we assume that the fusion center transmits the fused track to all sensors at 

each time step. With the global covariance Pk 

1| k 1 

for time available, 

the globalised prediction is given by the following lines. 

 

P S P F Q 

 

kk | 1 Fkk | 1 k1| k1 kk | 1 

kk | 1 , 

x SF P P x 

s s 

s 

. 

k| k1 

k| k1 k1| k1 k1| k1 k1| k1


• Distributed Kalman Filter using Relaxed Evolution (DKF-RE): The relaxed 

evolution model describes the transition kernel with an increased process 

noise covariance by a factor of S. The prediction is therefore given by 

s 

s 

kk | 1 

, 

kk | 1 k1| k1 kk | 1 S 

kk | 1 P F P F Q 

(29) 

s 

s 

x . 

kk | 1 Fkk | 1xk1| k1 (30) 

This approach spares out the decorrelation by remote covariance matrices. 

Instead, an approximation which relies only on local parameters and the constant 

number of sensors is used. 

x 10 4 

Target state estimates 

3 

2 

1 

Y 

0 

−1 

−2 

−3 

−3 −2 −1 0 1 2 3 

X 

x 10 4 

Figure 4. Example trajectory of the simulated target in the field of view of 20 sensors 

V. Evaluation 

In this section the previous fusion schemes are assessed through simulation. 

In a single simulation run each algorithm uses the same measurement data. 

The trajectory is sampled accordingly to the Discrete White Noise Acceleration Model 

(DWNAM) [1] and all filters use perfectly matched models for the dynamics and 

the sensors, respectively. A Gaussian distributed zero-mean measurement noise 

is simulated for each sensor measuring the position of a single target with a variance 

of 500 m 2 in x- and y-direction. Figure 4 shows an example trajectory of the target. 

Packet losses by network effects such as congestion and buffer overflows or 

unreliable Layer-2-Links are simulated by randomly discarding data, which is sent 

over the connecting network. Figure 5 (a) – (d) shows the Root Mean Squared Er-


291 

ror (RMSE) of the aforementioned multi sensor fusion schemes at different levels 

of communication losses. The probability of a successful transmission was set to 

(a) 100% (full communication) and (b) 60%, (c) 30% or (d) 10% respectively. 

It can be seen with full communication, which is shown in Figure 5 (a), 

the CKF, DKF-GP and DKF-RE have identical performance. This is in agreement 

with the established assertion in the literature that optimal track to track fusion, 

in terms of the MSE metric, can be achieved under full communication. 

It can also be seen that there is a significant improvement in performance by 

adopting a fusion scheme in comparison to just a single Kalman filter. However, 

the performance of the Naive fusion scheme is worse than the optimal achieved by 

CKF, DKF-GP and DKF-RE, as Naive fusion maintains an inconsistent covariance 

due to ignoring the cross correlations. 

CKF 

Single KF 

DKF_Gp 

DKF_Relaxed_Evolution 

Naive_Fusion 

CKF 

Single KF 

DKF_Gp 


Naive_Fusion 

RMSE 

RMSE 

10 1 0 20 40 60 80 100 120 140 160 180 200 

Time (s) 

10 1 0 20 40 60 80 100 120 140 160 180 200 

Time (s) 

(a) 100% (full communication) (b) 60% 

CKF 

Single KF 

DKF_Gp 


Naive_Fusion 

RMSE 

RMSE 

CKF 

Single KF 

DKF_Gp 


Naive_Fusion 

10 1 0 20 40 60 80 100 120 140 160 180 200 

Time (s) 

0 20 40 60 80 100 120 140 160 180 200 

10 1 Time (s) 

(c) 30% (d) 10% 

Figure 5. Log-scaled plots of the Root Mean Squared Error for 200 Monte Carlo simulations. 

The probability of a successful transmission was set to (a) 100% (full communication), (b) 60%, 

(c) 30% or (d) 10% respectively 

Figure 5 (b) shows the RMSE when the communication capability is reduced 

and only 60% of the transmissions are successful. As the complete information 

can no longer be transmitted to the fusion center, the RMSE of the fused esti-


mate deteriorates for the fusion schemes. In this case the DKF-GP and DKF-RE 

perform the best as they are designed to operate at arbitrary communications rates. 

The CKF however, which is optimal under full communication, performs worse 

due to the fact that the fusion equations (24) and (25) for a central T2TF assumes 

that all sensors had a successful transmission of parameters at this time step. This 

can further be seen as the probability of successful transmission is reduced to 30%, 

which is shown in Figure 5 (c). When the communication is most severely constrained, 

to 10% in Figure 5 (d), it can be seen that although DKF-GP and DKF-RE 

still perform the best, there is no longer a significant improvement over just using 

a single Kalman filter. This confirms what may be intuitive, that information fusion 

cannot be achieved when communication is severely constrained. 

It can be seen in Figures 5 (a) – (d) that DKF-GP and DKF-RE have equivalent 

performance, and so the DKF-RE is suitable as an approximation to DKF-GP, but 

with lower computation. However, this equivalence in performance will not hold 

when the sensor exhibits geometry dependent measurement characteristics which 

is not considered in these simulations. 


In this paper, an overview of state-of-the-art algorithms for object tracking 

in communication constrained scenarios is given. For the challenge of delayed 

measurements, which arises because of unsynchronized sensors or varying communication 

delays, the Accumulated State Density (ASD) filter gives the optimal 

solution with respect to the mean squared error. If communication links offer 

only small bandwidths, local tracking should be performed. If multiple sensors 

send their preprocessed tracks to a fusion node, the problem of track-to-track 

fusion (T2TF) arises due to cross-correlations between the local tracks. Through 

simulation it has been shown that when communication is constrained, distributed, 

decorrelated tracking outperforms a central Kalman filter, which is optimal under 

full communication. 

References 

[1] Y. Bar-Shalom, X. Li, and T. Kirubarajan, Estimation with Applications to Tracking 

and Navigation. Wiley-Interscience, 2001. 

[2] W. Koch, F. Govaers, “On Accumulated State Densities with Applications to Out-of- 

-Sequence Measurement Processing,” IEEE Transactions on Aerospace and Electronic 

Systems, vol. 47, no. 4, pp. 2766-2778, October 2011. 

[3] W. Koch, J. Koller, and M. Ulmke, “Ground target tracking and road map extraction,” 

ISPRS Journal of Photogrammetry and Remote Sensing, vol. 61, no. 3-4, pp. 197-208, 

2006, theme Issue: Airborne and Spaceborne Traffic Monitoring. [Online]. Available:


293 

http://www.sciencedirect.com/science/article/B6VF4-4MBCBFF-1/2/0da6734be33f 

666f433986401ecfb7c2 

[4] F. Govaers, W. Koch, “Out-of-Sequence Processing of Cluttered Sensor Data using 

Multiple Evolution Models,” in Proceedings of the 13th International Confernece on 

Information Fusion, 2010. 

[5] Y. Bar-Shalom, “On the track-to-track correlation problem,” IEEE Transactions on 

Automatic Control, vol. 26, no. 2, pp. 571-572, Apr. 1981. 

[6] F. Govaers, W. Koch, “Distributed Kalman Filter Fusion at Arbitrary Instants of Time,” 

in Proceedings of the 13th International Confernece on Information Fusion, 2010. 

[7] D. Hall, J. Llinas, Eds., Handbook of Multisensor Data Fusion. CRC Press, 2001.

Examination of Combination Rules for the Purpose 

of Information Fusion in C2 Systems 

Ksawery Krenc 

C4I R&D Department, OBR CTM S.A., Gdynia, Poland, 

ksawery.krenc@ctm.gdynia.pl 

Abstract: This paper presents an analysis of known rules of combination as well as a new method 

of combining uncertain evidence. 

The author concentrates on examination of the rules with accordance to target threat models. The examination 

have been taken with usage of the predefined measuring scenarios applied to information sources. 

Keywords: attribute fusion, Theory of Evidence, DSmT, rules of combination, threat models, Command 

& Control systems 


Contemporary Command & Control systems should be prepared for integration 

of information gathered from diverse sources. It is obvious that together with 

technological progress new generation sensors need to be plugged-in in order to 

keep the defence and security up-to-date on the required level. On the other hand, 

the existing verified and certified sources do not become useless, and still provide 

valuable information. This variety of information sources, diversified ontologically, 

causes that specific processing (including lexical translations) needs to be performed 

in order to keep particular subsystems compatible. This in turn often generates 

errors, and in the consequence raises uncertainty of the elaborated final decisions. 

During last three decades many solutions for dealing with the above mentioned 

uncertainty have been proposed. Omnipresence of the uncertainty, even while determining 

technical parameters of the sources, had made many researchers found 

Theory of Evidence (Dempster-Shafer Theory) very attractive. Dezert-Smarandache 

Theory (DSmT) performs an extension of the original Theory of Evidence by 

Shafer, and proposes several modification of attributes model construction and 

hypotheses conflict distribution. As the result of these modification there are many 

fusion formulas in Theory of Evidence, called combination rules. 

This work was supported by the National Centre for Research and Development for the years 2009-2011 under 

Commissioned Research Project MNiSW-OR00007509.


Diversity of the existing combination rules bears testimony to the fact that 

there is no universal combination rule, adequate in every fusion case, and in every 

condition. 

Combination rules perform tools for integration of so called basic belief assignments 

(bbas) i.e. substitutes of probability distributions in Evidence Theory, 

which are obtained based on qualitative parameters of the sources (constant and 

variable), observation distances and many other factors that influence on the process 

of observation. 

In the preliminary stage of the research, not presented in this paper, the author 

had selected certain rules of combination based on their mathematical properties 

and relevance for C2 systems applications. This had been performed in order to 

distinguish rules which have potential to be applied in C2 systems. 

However, the actual choice of the particular rule should not be made without 

regarding target attribute models and structures of bbas. The closer to reality 

the model is the more precise fusion result may be expected. On the other hand: 

the more extensive bba is the more precise fusion result. 

The problem of target threat assessment in C2 systems seems to be especially 

suitable to be solved within the DSmT framework for the matter the attribute of target 

threat according to standards like [7] and [10] consists of values that are in large 

degree mutually dependent (e.g. FRIEND and ASSUMED FRIEND). Additionally, 

hierarchy of these values is quite easy to be revealed, distinguishing primary 

hypotheses: {FRIEND, HOSTILE, and UNKNOWN} and secondary hypotheses 

{ASSUMED FRIEND, SUSPECT, JOKER, and FAKER}. 

Nevertheless, not all (but selected) target threat values known in military 

literature are taken into account in order to avoid the blackout the idea of the paper 

which is the examination of combination rules with accordance to particular 

threat model. 

II. Threat models 

In order to compare combination rules it is necessary to define the model 

of the considered attribute. In the next stages of the research works the following 

models of the target threat attribute are going to be taken into account: 

DSmT free model, where the subsequent secondary hypotheses (ASSUMED 

FRIEND, SUSPECT, FAKER, and JOKER) perform subsets of the main classes 

(primary hypotheses: FRIEND, HOSTILE, UKNOWN). 

DSmT hybrid model, where the classes FRIEND and HOSTILE are assumed 

to be disjoint. The rest of the hypotheses is defined in the same manner 

as in the free model.


297 

Figure 1. Venn’s diagram for the threat attribute – the free model 

Figure 2. Venn’s diagram for the threat attribute – the hybrid model 

III. Numerical experiments 

The classic rule of combination works with the free model Figure 1. If not all 

of the hypotheses conjunctions exist in the reality the authors of DSmT suggest to 

use the hybrid rule of combination or any of proportional conflict redistribution 

PCR rules. 

During the research works another evolving mechanism for resolving evidence 

conflicts has also been verified. The mechanism, called decomposition 

of the conflicting hypothesis, is based on separation of the total mass referring to 

conflict for two components: strictly conflicting and supporting primary hypotheses. 

The fundamental difference between this mechanism and PCR resides in fact 

that PCR rules operate on bba level, where the conflicting mass is transferred with 

respect to normalization. On the contrary, the decomposition mechanism operates 

on the belief function level. That means the particular masses are not subject 

to normalization and they support the respective primary hypotheses according 

to the belief function calculation procedure.


Due to the fact that the mechanisms of proportional conflict redistribution 

and decomposition of conflicting hypothesis do not operate on the same level 

of information processing the research works have been based on comparison 

of the respective belief function changeability for these two methods. 

Particularly, PCR5 and DSmC with two-element decomposition were subject 

to the comparison. The result of the ‘pure’ DSmC has also been presented 

as the reference. 

In the examination, two sensor fusion scenario was under consideration. 

It was assumed the first sensor provides a constant bba, defined as follows: 

m 1 (F) = 0.275 m 1 (H) = 0.275 m 1 (U) = 0.05 

m 1 (J) = 0.1 m 1 (K) = 0.1 m 1 (AF) = 0.1 

m 1 (S) = 0.1 

The second sensor was assumed to provide the following constant bba: 

m 2 (U) = 0.03 m 2 (J) = 0.1 m 2 (K) = 0.1 

m 2 (AF) = 0.1 m 2 (S) = 0.1 

Additionally, the mass corresponding to FRIEND hypothesis was gradually 

increased within with a step of 0.02 and simultaneous reduction 

of HOSTILE hypothesis, which may be defined as follows: 

m 2 (F) = 0.01 : 0.41 m 2 (H) = 0.56 : 0.16 

Application of the free DSmT model (see Figure 1) with the classic rule of combination 

DSmC leads to the following belief function changeability 

Figure 3. presents changeability of belief functions for two the most dominant 

hypotheses: FRIEND and HOSTILE. Due to the fact that the bba obtained from 

the first sensor does not show any predominance of one of the mentioned hypotheses 

over the other, the result of the combination strongly depends on the preset 

masses of FRIEND and HOSTILE for the second sensor. Based on Figure 3. it is 

clearly seen that for the mass of m 2 (F) residing within HOSTILE 

hypothesis should be accepted. Exceeding the value of 0.275 causes a decision 

change from HOSITLE to FRIEND, which according to the definition of bba for 

the first sensor is intuitive. 

Figure 4. presents changeability of belief functions for the hybrid model with 

PCR5 applied. Similarly, as in case of application of the classic rule the decision 

change is observable for m 2 (F) @ 0.275. It is important to notice that maximal 

values of the respective belief functions paradoxically have lower values than for 

the classic rule. Given the fact that in PCR rules transfer the conflicting mass to 

the corresponding primary hypotheses it is intuitive to expect relatively higher 

values of the belief functions. However, the opposite happens as the belief function 

calculation performs the decisive factor. In case of PCR5 the primary hypotheses 

are supplied by relatively lower masses of the secondary hypotheses even though


299 

in normalized bbas the primary hypotheses of FRIEND and HOSTILE take higher 

values than for the classic rule. 

Figure 3. Changeability of belief functions for DSmC 

Figure 4. Changeability of belief functions for PCR5 

Figure 5. presents the changeability of belief functions for the hybrid model 

(see Figure 2) with application of the classic DSmC rule and two-element conflicting 

hypothesis decomposition mechanism. In the considered case the conflicting 

hypothesis is FH, which causes the necessity of two secondary hypotheses: 

FAKER and JOKER.


Figure 5. Changeability of belief functions for DSmC with two-element FAKER decomposition 

The two-element decomposition of FAKER hypothesis is defined as follows: 

K = K CONF + K SPEC (1) 

where: 

K CONF – ‘conflicting’ FAKER i.e. FH, 

K SPEC – ‘specific’ FAKER i.e. {KK, FK, KH} 

Analogically, the two-element JOKER decomposition may be performed 

in the same manner: 

J = J CONF + J SPEC (2) 

where: 

J CONF – ‘conflicting’ JOKER i.e. {FS, AFH } 

J SPEC – ‘specific’ JOKER i.e. {JJ, FJ, JH, JU, KJ, JS, JAF } 

Thus the corresponding belief functions may be calculated as follows: 

Bel(F) = m 12 (F) + m 12 (AF) + m 12 (K) + m 12 (J) (3) 

Bel(H) = m 12 (H) + m 12 (S) + m 12 (K CONF ) + m 12 (J CONF ) (4) 

where: 

m 12 (.) – the resulting mass as a combination of evidence from the first sensor and 

second sensor. 

From Figure 5. it can be seen that the decision change from FAKER to FRIEND 

takes place at m 2 (F) @ 0.06. A relatively fast increase of FRIEND hypothesis is observable 

comparing to slow decrease of HOSTILE hypothesis, which in the considered 

case is never accepted. This disproportion is due to the fact that FRIEND 

hypothesis is supplied by conflicting masses and specific masses, corresponding 

to decomposed training classes while HOSTILE hypothesis is supplied only by 

the conflicting masses.


301 

Figure 6. presents the changeability of belief functions for the hybrid model 

(see Figure 2) with application of the classic DSmC rule and three-element conflicting 

hypothesis decomposition mechanism. Similarly as in the previous experiment 

two secondary hypotheses: FAKER and JOKER are subject to decomposition. 

Figure 6. Changeability of belief functions for DSmC with three-element FAKER decomposition 

The tree-element decomposition of FAKER hypothesis is defined as follows: 

K = K CONF + K KK + K KF + K KH (5) 

where: 

K CONF – ‘conflicting’ FAKER i.e. FH, 

K KK – ‘pure’ FAKER i.e. KK 

K KF – ‘friendly’ FAKER i.e. FK 

K KH – ‘hostile’ FAKER i.e. KH 

Analogically, the three-element JOKER decomposition may be performed 

in the same manner: 

J = J CONF + J JJ + J JF + J JH (6) 

where: 

J CONF – ‘conflicting’ JOKER i.e. {FS, AFH } 

J JJ – ‘pure’ JOKER i.e. JJ 

J JF – ‘friendly’ JOKER {FJ, AFJ, KJ, UJ} 

J JH – ‘hostile’ JOKER {JH, JS, KS} 

Thus the corresponding belief function may be calculated as follows: 

Bel(F) = m 12 (F) + m 12 (AF) + m 12 (K CONF ) + m 12 (K KK ) + m 12 (K KF ) 

+ m 12 (J CONF ) + m 12 (J JJ ) + m 12 (J JF ) (7)


Bel(H) = m 12 (H) + m 12 (S) + m 12 (K CONF ) + m 12 (K KH ) 

+ m 12 (J CONF ) + m 12 (J KH ) (8) 

where: 

m 12 (.) – the resulting mass as a combination of evidence from the first sensor and 

second sensor. 

From Figure 6. it can be seen that the decision change from HOSTILE to 

FRIEND takes place at m 2 (F) @ 0.21 which is insignificantly lower than in case 

of applying PCR5 and the classic rule of combination without the decomposition 

mechanism. The observed increase of mass corresponding to FRIEND hypothesis 

is equal to decrease of HOSTILE hypothesis. 

IV. Summary of the research works 

The results presented herein indicate significant differences in changeability 

of the belief functions corresponding to particular rules of combination. Taking 

the changeability of belief functions for DSmC as the baseline it is important to 

notice that for the next of the examined rules: PCR5 and DSmC + decomposition 

lower maximum values of the belief functions were observed. In particular, for 

DSmC + decomposition (equally for two-element and three-element decomposition) 

maximal belief function values were below 0.8. 

The mechanism of two-element decomposition of the conflicting hypothesis 

does not seem to very useful in practical applications due to significant values 

of so called decision deviation i.e. a measure of the symmetry of the decision for 

all possible fusion scenarios (see [9]). It was presented mainly as the reference for 

three-element decomposition mechanism. 

Application of DSmC with three-element conflicting hypothesis decomposition 

mechanism provides similar results as PCR5. However, the intersection 

of straight lines of maximal belief functions, and thus the decision change, occurs 

with slightly lower value than for the examined conflict redistribution rule. It is 

worth of consideration which of these results better fits reality. With given bba 

for the first sensor the masses of the contradictory hypotheses of FRIEND and 

HOSTILE are equal to 0.275. The decision change at 0.275 seems to be intuitive. 

It is important that the rest of the hypotheses included in bba i.e. SUSPECT, AS- 

SUMED FRIEND, JOKER, and FAKER supplies the primary hypotheses in diverse 

degree. Even though they are equally distributed FRIEND hypothesis is supported 

by larger number of secondary hypotheses i.e. ASSUMED FRIEND, JOKER, and 

FAKER than HOSTILE hypothesis (supplied only by SUSPECT). Thus application 

of DSmC with three-element conflicting hypothesis decomposition mechanism 

may be more adequate in the considered fusion case.


303 

V. Conclusions 

In this paper an analysis of known rules of combination as well as a new 

method of combining uncertain evidence has been presented. The examination 

have been taken with usage of the predefined measuring scenarios applied to information 

sources. 

After preliminary comparative analysis and numerical experiments there have 

been selected rules which may be useful in C2 systems. However the results are not 

satisfactory for unambiguous appointment of the optimal rule for the considered 

fusion case. In the author’s opinion the final decision should be taken after scrutiny 

with usage of simulators, which enable to establish the necessary statistics, and also 

to compare the elaborated fusion results with the ground truth. 

References 

[1] G. Shafer, A mathematical theory of evidence, Princeton U.P., Princeton, NJ, 1976. 

[2] F. Smarandache, J. Dezert, Advances and Applications of DSmT for Information 

Fusion, vol. 1, American Research Press Rehoboth, 2004. 





[5] T. Inagaki, Independence between safety-control policy and multiple-sensor schemes 

via Dempster-Shafer theory, IEEE Trans. On reliability, vol. 40, no. 2 pp. 182-188, 1991. 

[6] K. Sentz, S. Ferson, Combination of Evidence in Dempster-Shafer Theory, SAND 

2002-0835. 

[7] NATO Standardization Agency, Tactical Data Exchange – Link 16, STANAG no. 5516, 

Ed. 3. 

[8] K. Krenc, A. Kawalec, An evaluation of the attribute information for the purpose 

of DSmT fusion in C&C systems, Fusion2008, Cologne, ISBN 978-3-00-024883-2, 2008. 

[9] K. Krenc, A. Kawalec, T. Pietkiewicz, Does Basic Belief Assignments definition affect 

Information Fusion quality, Military Communications and Information Technology: 

A Comprehensive Approach Enabler, Warszawa 2011, ISBN 978-83-62954-20-9. 

[10] The Joint C3 Information Exchange Data Model, Edition 3.1b, 2007.

Commanding Multi-Robot Systems 

with Robot Operating System 

Using Battle Management Language 

Thomas Remmersmann 1 , Alexander Tiderko 1 , 

Marco Langerwisch 2 , Stefan Thamke 3 , Markus Ax 3 

1 Fraunhofer Institute for Communication, Information, Processing and Ergonomics FKIE, 

D-53343 Wachtberg, Germany, {thomas.remmersmann, alexander.tiderko}@fkie.fraunhofer.de 

2 Leibniz Universität Hannover, Real Time Systems Group (RTS), 

D-30167 Hannover, Germany, langerwisch@rts.uni-hannover.de 

3 University of Siegen, Institute of Real-Time Learning Systems (EZLS), 

D-57068 Siegen, Germany, {stefan.thamke, markus.ax}@uni-siegen.de 

Abstract: Multi-Robot Systems have become an important research topic. One of the main questions, 

when looking at usability of a MRS, is how it can be controlled. In this paper we describe an approach 

were the commanding is done by using an artificial language very similar to English, the Battle 

Management Language (BML). The orders can thus be created intuitively and on a high abstraction 

level. We developed a GUI to allow fast and efficient creating of orders for the robots system. On 

the robots we used the Robot Operating System (ROS). The interpretation and execution of the orders 

are controlled by ROS nodes. We created control nodes for every robot which handle the execution 

of a task for a single robot. We also created intelligent nodes for groups of robots. These nodes handle 

commands directed to a group of robots and split that BML order into BML orders for each robot. 

These orders are sent to the control nodes and executed by the robots. ROS provides numerous 

of libraries and tools which helps to create new robot applications. We mainly used the publish 

subscriber based communication capabilities. In this paper we concentrated on the architecture and 

how the translation of BML orders into basic ROS command is done and how feedback messages 

were sent back to the C2 System. This presented work is the result of cooperation between the Real 

Time Systems Group (RTS), Leibniz Universität Hannover, the Institute of Real-Time Learning 

Systems (EZLS), University of Siegen and the Fraunhofer Institute for Communication, Information 

Processing and Ergonomics. 

Keywords: natural language, BML, multi-robot systems, C2 systems, ROS 


There are many reasons to use a multi-robot system instead of a single robot. 

Multiple robots can do some jobs more cheaply, faster or more reliably, e.g., a group 

of different robots can reconnoiter an area towards different aspects. UAVs might


produce aerial photo and UGV can produce a 3D grid using laser scanners. Another 

example is a group of drones that must be coordinated to scan the corridor 

ahead of a convoy. This task can’t be done by a single robot and the group should 

be automatically fly in formation in a predefined distance from the first truck. 

In this paper we show an approach how a single user can control an MRS 

in similar situations using BML. The goal of our project was to demonstrate that 

the robots of MRS can be coordinated quickly and efficiently by using BML as a command 

and report language and using ROS as a communication standard between 

different robot systems. We defined a set of commands that should be supported 

by the MRS and how they should be implemented to test our approach. 

We use a simple hierarchical approach with intelligent node representing groups 

of robots and the control nodes for each robot. This means that one intelligent node 

receives the command from the user and this node is capable of breaking the command 

up into subcommands for all subordinate robots. This allows less coupling 

between the robots. Each node must only know how to interpret a command and 

what commands are supported by it subordinate units. Having the intelligent nodes 

on the robots makes it possible for the robots to be reactive to new situations even 

if the connection to the C2-Central is not available. 

The paper is structured as the following. In Section 2 some background information 

is given about supervisory control, BML and ROS. Section 3 describes 

the systems that are used in the project. This includes the graphical user interface 

and the robot systems of the Leibniz Universität Hannover and University of Siegen. 

Section 4 describes the challenges and benefits using ROS on the robots. The implementation 

of commands is described in section 5. A conclusion and an outlook 

are given in section 6. 


A. Supervisory control of Multi-Robot Systems 

The goal of our work is to provide supervisory control of Multi-Robot 

Systems without excessive human workload. Related work on controlling UAV 

Multi-Robot System was done by Cummings and Mitchell [1] and Nehme et 

al. [2]. The workload of controlling a UAV Multi-Robot System was analyzed by 

Dixon et al. [3]. 

Quite similar to the supervisory control of Multi-Robot Systems is the supervisory 

control of multi-agent systems (MAS) [4]. For that area different approaches 

are known. The first one is “control-by-behavior.” In this approach, different 

behaviors for each agent are defined and the operator selects one of them. 

However, this approach does not scale with larger groups of agents, more behaviors 

or more complex behaviors as mentioned by Wilson et al. [5]. Another approach 

is the “control-by-policy” approach. Here, the operator can define constraints or


307 

advices in a limited natural language and the agent plans corresponding actions. 

This is e.g., used by Myers [6]. 

B. BML 

To express commands that are pushed from the user (C2 System) to the intelligent 

node on the lead robot and from there to the other robots we use Battle 

Management Language (BML) [7], because it is human readable, unambiguous, 

already used in military context, and in standardisation process of SISO. BML 

can be used to express orders, reports and requests between command and control 

systems (C2 systems), simulation systems and real units. In addition, BML also may 

be used to interact with robotic forces. Thus, it allows C2 systems and their users 

to interact with robot systems in the same way as with real units or units simulated 

in simulation systems. It is also possible to control robots with this language because 

it unambiguous and follows a formal grammar. We described in [8-9] how 

to control robots running our own middleware RoSe [10] by using BML. 

BML must be unambiguous to allow automatic processing. This unambiguousness 

is not self-evident for a language. For example, in natural English, the lexical 

term bark can refer to the sound a dog produces or to the skin of a tree. The interpretation 

of such ambiguous terms depends on the situational context and on 

the world knowledge of the listener. 

In order to be unambiguous, BML has been designed as a formal language. 

A formal language is the set of all sentences generated by a formal grammar. A formal 

grammar consists of a lexicon (the words of the language) and a set of rules 

(how to combine the words). In the case of BML, this grammar is the Command 

and Control Lexical Grammar (C2LG) [11]. To be more precise, the lexicon contains 

the attributes and values provided by the Joint Consultation Command and 

Control Information Exchange Data Model (JC3IEDM) (see http://www.mip-site. 

org or [12]). This set of rules has been developed based upon the doctrines of commanding 

and reporting, e.g., STANAG 2014, and incorporates the idea of the 5Ws 

(Who, What, Where, When, Why) for individual BML expressions. 

C. ROS 

We are running Robot Operating System (ROS) on the robots because it contains 

many useful capabilities and is the most widely used operating system for robots. 

ROS is developed and maintained by Willow Garage. It provides a centralized 

architecture with publish / subscribe semantics. A central instance, the ROSCore, 

provides lookup information about topics, services and nodes. Each node reports 

its register information and can receive information about other nodes. A node 

that subscribes to a topic requests connection information through ROSCore and 

connects directly to publisher node. In order to accomplish this, an agreed-upon


connection protocol will be used. Although TCP is the most common protocol 

used in an ROS, a UDP can also be used. The data exchange between nodes will 

create a peer-to-peer network. 

III. Systems in use 

A. C2LG GUI 

We use a graphical user interface, the C2LG GUI, to enter the orders for our 

robot system. C2LG GUI is used in other projects to test interoperability with 

simulation systems, e.g., with French and German systems [13]. The GUI supports 

the user generating the orders. It allows selecting objects from a list or to pick 

them from the integrated map. Geographical features like areas can be created on 

the map as well. These features then can be referenced. The GUI also visualizes 

the robots’ reports. In particular, the robots themselves are shown the map due to 

their periodic position reports. 

Figure 1. The GUI we used to create BML orders. First the action “move” was selected. 

Then the taskee “robot_group_1” was selcted and route “routeA” was created on the map 

and given as a paremter to the order 1 

The initialization of the GUI was done using the Military Scenario Description 

Language (MSDL) [14]. We created an MSDL File which includes the units, 

the associated symbols, the order of battle, and also some geographical objects e.g., 

where the base is. 

1 

Map data (c) ῾OpenStreetMap’ (and) contributors (http://www.openstreetmap.org/), CC-BY-SA 

(http://creativecommons.org/licenses/by-sa/2.0/)


309 

B. UGV RTS-HANNA 

Our multi-robot system consisted of a ground vehicle and two UAVs. This 

section provides information about the ground vehicle. The following section will 

cover the UAVs. 

The unmanned ground vehicle is called RTS-HANNA (see Fig. 2). It is based 

on an off-the-shelf Kawasaki Mule 3010 Diesel chassis which has been retrofitted 

with a drive-by-wire interface (by PARAVAN GmbH). That interface enables 

manual as well as full computer control of the vehicle. Due to the manual control, 

HANNA is fully street-licensed. Its maximum velocity is 40 km/h, and its maximum 

payload is 600 kg. 

HANNA can be equipped with a multitude of sensors. For environmental 

perception, two continuously rotating 3D laser rangefinders RTS-ScanDriveDuo 

with an update rate of 0.8 Hz each for close range, one Velodyne HDL-64E with 

an update rate of 15 Hz for long range, one Ibeo Lux for fast obstacle detection 

within the main driving direction, and a Microsoft Kinect are mounted. For 

the navigation, odometry, a gyroscope, and two GPS receivers are available. HANNA 

communicates either by WiFi, or a serial link in the unlicensed industrial, scientific 

and medical (ISM) radio band, or by GSM/UMTS. 

HANNA has five embedded PCs at her disposal, used for processing the sensor 

data, for navigation and to control her, in our case by BML orders, cf. [15] for more 

details. Software for those PCs is developed using the robotic framework RACK 

(Robotics Application Construction Kit). To make the PCs capable for executing 

ROS components, we, in general, cross-compiled ROS and made the ROS libraries 

and API available to our middleware RACK. In particular, a kind of gateway 

module has been implemented. That module is part of the RACK communication 

system, but is also able to publish and subscribe to ROS topics. It receives the BML 

tasks and organizes their execution by publishing corresponding tasks for the UAVs 

as ROS topics. It also publishes sensor data for the BML-GUI. In short, HANNA 

is running the ROSCore and the BMLConnector in the ROS context, the gateway 

module to connect both worlds, and the rest of the software components in RACK. 

HANNA navigates on a known road network available in OpenStreetMap 

(OSM) format. To navigate to a certain point of destination, a simple A* search 

for a shortest path in the OSM geodata is initiated, cf. [16] for details. To follow 

the planned path, a hybrid feedback controller, introduced in [17], is applied. This 

service uses reactive obstacle avoidance and local path re-planning.


Figure 2. The unmaned ground vehicle HANNA from the RTS, Leibniz Universität Hannover 

C. UAV PSYCHE 1000 

The multi-robot system’s two UAVs are Psyche 1000 (see Fig. 3) modified drones 

MD4-1000 which originally were built by Microdrones. The UAVs are electronically 

driven helicopters with four rotors, so called quadrocopters that provide a maximum 

flying weight of 6 kg. Running four rotors means that such a UAV is controlled only 

by changes in rotational speed of each rotor. Every one of this rotors is driven by its 

own brushless engine, so that the UAVs are almost maintenance free. In comparison 

to a conventional helicopter design with a lot of moving parts like a swash plate, 

the possibility for technical failures is reduced significantly. 

Figure 3. The unmaned airial vehicle PSYCHE 1000 from EZLS, University of Siegen


311 

The UAVs have high precision position stabilization as well as a location estimation 

system. As in most localization systems a GPS receiver provides information 

about the absolute position which is fused with measurements from accelerometers, 

gyroscopes, a magnetometer, and a barometer. For communication, a special chip 

running a specialized embedded Linux distribution is added. It supports both 

the communication channel with the base station and with the other robots, as well 

as autonomous flight control. Our control module utilizes the position and attitude 

estimations from the UAV, as provided by the manufacturer, and generates signals 

that are fed back into the proprietary control software of the drone. The interface 

we use is identical to the original radio control connection. This allows us to make 

use of all position stabilization functionalities provided by the manufacturer, as we 

electronically simulate a human operator. By the flick of a switch a real operator 

can obtain control over the UAVs at any given time. 

Communication from and to the UAV is realized with two wireless connections. 

The original radio control device is connected over a bi-directional low-bandwidth, 

but high distance 2.4 GHz channel. It sends control commands to the UAV and receives 

information about the height, attitude and the state of the battery. The second 

channel is a 5 GHz Wireless LAN connection used to transmit data with high bit rates. 

Since the project is mainly focused on reconnaissance, each UAV is equipped 

each with a 14.7 MP zoom camera. However, as the UAVs have to alter their attitude 

to make changes in movement, a fixed mounting of the cameras would result 

in blurry images. To prevent this, the cameras are mounted within a moveable frame, 

which is deflected by two servos. The angle control input is taken from the attitude 

estimation made by Microdrones. Pictures are accessible in two versions. One 

is the live video preview used on the camera display as default. Respective pictures 

have a resolution of 320 x 240 pixels, an average file size of 9 kB, and are available at 

25 Hz. The second is the single picture mode by which high resolution pictures 

can be taken. High resolution pictures have a resolution of up to 4416 x 3312 pixels 

and an average file size of 4 MB. 

IV. Challenges using ROS 

The requirements of robot control software for MRS are a) the control 

of the MRS as one unit, and b) the separate control of specific robots. This demands 

self-sufficient control software on each robot but also communication between 

the robots. To be able to use the communication interface of ROS it must be 

compiled for the specific processor structure and operating systems of the robots. 

We used one ROSCore for all robots, which allows communication over 

ROS topics. For each robot there is a ROS node which listens to specific topics 

and controls the robots according to the given commands. Those commands are 

defined in BML. The robots communicate not only with the C2 system over BML 

but also with each other. This means an intelligent node, handling the commands


which are given to a robot group, splits that commands up into BML commands 

for specific robots. Internally we used a newly defined ROS-BML message type, 

which includes the same information as BML command given by the C2 System. 

Using the internal format allows direct access to the values, while the XML-BML 

format given by the C2 System must be parsed to access the information. We used 

the ROS-BML format for communication between robots only to avoid additional 

converting. 

The exchange of data between the robots and the C2 System is done sending 

XML-BML over TCP/IP. We implemented an ROS node called BMLConnector 

for this reason. It handles the translation between XML-BML and ROS-BML 

and transfers the data between a simple TCP/IP connection to the C2 system and 

the ROS internal publish subscriber system. 

Some data that cannot be expressed in BML because either there is no construct 

for this kind of data, or it is data that cannot be expressed in human-readable 

sentences, e.g., pictures or video streams. Whenever this is the case, we encode 

the ROS message in based64 and include it in a small XML structure. We called 

this the sensor data return channel (SDRC). If the standard is adjusted in the future 

we can change the encoding of a message from base64 to BML. 

Some robot status information will always be transferred to the C2 system. 

This can be BML reports about several things like positions of units or the current 

status of a task. As not all data need to be reported to C2 system or to other robots, 

at least not all the time, the data transferred must be specified via a configuration. 

The configuration can be done by a script or via XML Remote Procedure Call 

(XML-RPC) at runtime. It is especially useful if new nodes are running on one 

of the robots or if a robot is added or removed from the group. Additionally it is 

possible to request pictures or videos from the robots using BML commands. 

V. Challenges in using BML 

The main problem of using BML is that the high level commands must be 

transformed into basic orders for the robots. This is done by so called intelligent 

nodes which break a BML command down into several smaller orders until only 

elemental orders remain which can be executed directly. The structure is visualized 

in Fig. 4. 

These intelligent nodes are connected to the BMLConnector and as a result, 

they are able to receive orders and to forward orders to other robots or to intelligent 

nodes on other robots. Because the input and output of the intelligent nodes 

is standardized by BML, orders can easily be exchanged. 

In case of a situation in which a BML command can not longer be executed 

in the default way for any reason, first the control nodes on the robots try to find 

a way to continue the task. For example, a UGV might move back and than move 

around an obstacle. Second, if a control node is not able to continue the task, it re-


313 

ports this problem back to the intelligent node which then can try to reschedule. 

If this also fails, it can report back to the C2 System. If the connection to the C2 

System is lost, it can react in a predefined way, e. g., all robots return to base. 

Figure 4. Structure of the command flow. A BML command for a robot group is send from the 

C2 System to the intelligent node on the UGV and is split up into BML commands for all robots 

In our test case the MRS consisting of a UGV (HANNA) and two UAVs 

(PSYCHE 1000). We implemented several BML commands, e.g., reconnaissance, 

patrol, distribute, guard, and observe. 

To command this MRS a reconnaissance mission the user enters the BML 

expression “reconnaissance C2 Robot_Group1 at Area_1 start at now” in the GUI. 

The user is supported by dropdown boxes which show him which values are allowed 

for a given part of the expression and he also can choose targets, routes and areas on 

a map. The intelligent node that receives that mission orders the UGV to move 

along the roads to report about any obstacles and also assigns a part of the area to 

each UAV to reconnoitre it. The control node of the UGV only receives waypoints 

on the roads which should be reached and does its way planning and collision 

avoidance on its own. The control nodes on the UAVs split their reconnoitre orders 

into move orders inside the area assigned to them. During execution the robots 

of course report their position but the UGV also reports a map. The map shows 

obstacles that were detected and which ways the robot can take. An example of this 

can be seen in Fig. 5. 

If the patrol command is given it is split up in a move order along the given 

patrol points for the UGV and the UAVs get a command to orbit the UGV. 

The distribute command is implemented by giving a move command to 

the center of the area. The area is split into 2 pieces and each of the UAV receives 

a move command to the center of one them.


Execution of the guard command is done very similar; the UGV is ordered 

again to move to the center of the area and each UAV receives an order to patrol 

in one half of the area. 

The observe command is performed by moving the UGV to the target position 

and let the UAVs orbit around that position. 

We also added two emergency buttons. The first is “Emergency Stop” which 

cancels all previously given commands and lets all robots stop. The second is “Return 

to Base” which gives each robot a “move to base” task. The base must have 

been defined previously in the C2LG GUI. 

We tested and demonstrated all that functionality on our test side in Wachtberg, 

next to the Fraunhofer FKIE. It showed that our approach works. Due to the standardization 

of BML and ROS the interaction between the components of the three 

different institutes was no problem. 

Figure 5. Map returned by the UGV during the reconnaisance mission. White represents free area, 

black represents obstacles and gray is undiscovered area. The blue lines are predefined roads 

VI. Conclusion and outlook 

We presented a system that allows commanding an MRS with BML. Giving 

the orders in restricted normal English is an intuitive way but requires complex 

intelligent nodes. The BML exchange format makes it possible to develop the intelligent 

nodes independent of each other because of the standardization. But BML 

does not always allow giving orders at a level of the detail which might be desirable. 

Adjusting BML to the special needs of a multi-robot system is one of the work 

items for the future. The intelligent nodes often have similar structures and we are 

planning to generate them from scripts or rules. This would allow faster integration 

of new commands or adjusting behavior to new robots. Reporting position and


315 

task status was no problem using BML. Pictures and videos cannot be encoded 

in BML, for this reason we used the SDRC. 

In future work it must be proven if this approach scales for lager MRS. Another 

interesting point is how the system must be adjusted to be able to add and remove 

new robots to the MRS at any time. 

REFERENCES 

[1] M.L. Cummings, and P.J. Mitchell, “Operator scheduling strategies in supervisory 

control of multiple UAVs,” Aerosp. Sci. Technol., vol. 11, no. 4, 2007, pp. 339-348. 

[2] C. Nehme, B. Mekdeci, J.W. Crandall, and M.L. Cummings, “The impact 

of heterogeneity on operator performance in futuristic unmanned vehicle systems,” 

Int. Command Control J., vol. 2, no. 2, 2008. 

[3] S.R. Dixon, C.D. Wickens, and D. Chang, “Mission control of multiple unmanned 

aerial vehicles: A workload analysis,“ Human Factors, vol. 47, no. 3, 2005, pp. 479-487. 

[4] G. Coppin, and F. Legras, “Autonomy Spectrum and Performance Perception Issues 

in Swarm Supervisory Control,” Proceedings of the IEEE vol. 100, no. 3, 2012. 

[5] M.S. Wilson, and M.J. Neal, “Diminishing return of engineering effort in telerobotic 

systems,” IEEE Trans. Syst. Man Cybern. A, Syst. Humans, vol. 31, Special Issue on 

Socially Intelligent Agents–The Human in the Loop, no. 5, 2001, pp. 459-465. 

[6] K.L. Myers, “Advisable planning systems in Advanced Planning Technology,” A. Tate, 

Ed. Menlo Park, CA: AAAI, 1996. 

[7] K. Heffner, A. Brook, N. de Reus, L. Khimeche, O.M. Mevassvik, M. Pullen, 

U. Schade, J. Simonsen, and R. Gomez-Veiga, “NATO MSG-048 C-BML Final Report 

Summary,” 2010 Fall Simulation Interoperability Workshop (Paper 10F-SIW-039), 

Orlando, FL., 2010. 

[8] T. Remmersmann, B. Brüggemann, U. Schade, and D. Schulz, „Roboterinteraktion 

mittels Battle Management Language,“ Technical Report FKIE-ITF/2010/01. Wachtberg: 

Fraunhofer FKIE, 2010. 

[9] T. Remmersmann, B. Brüggemann, and M. Frey, “Robots to the Ground.” in Concepts 

and Implementations for Innovative Military Communications and Information 

Technologies, Military University of Technology, ISBN 978-83-61486-70-1, 2010, 

pp. 61-68. 

[10] A. Tiderko, T. Bachran, F. Hoeller, and D. Schulz, “RoSe – A framework for 

multicast communication via unreliable networks in multi-robot systems,” Robotics 

and Autonomous Systems, vol. 56, 2008, pp. 1017-1026. 

[11] U. Schade, M.R. Hieb, M. Frey, and K. Rein, “Command and Control Lexical 

Grammar (C2LG) Specification”, Technical Report FKIE-ITF/2010/02. Wachtberg: 

Fraunhofer FKIE, 2010. 

[12] M. Gerz, and U. Schade, “Das Joint Consultation Command and Control 

Information Exchange Data Model”, in J. Grosche, and M. Wunder, (Eds.), Verteilte 

Führungsinformationssysteme. Heidelberg, Germany: Springer, 2009, pp. 219-234.


[13] T. Remmersmann, U. Schade, L. Khimeche, B. Gautreau, and R. El Abdouni 

Khayari, “Lessons Recognized: How to Combine BML and MSDL,” 2012 Spring 

Interoperability Workshop, Orlando, FL, 2012. 

[14] J. Surdu, R. Wittman, and J. Abbott, “Military Scenario Definition Language 

Study Group Final Report,” 2005 Fall Simulation Interoperability Workshop, Orlando, 

FL, 2005. 

[15] J. Kiszka, and B. Wagner, “RTnet – a flexible hard real-time networking framework,” 

10th IEEE Conference on Emerging Technologies and Factory Automation, vol. 1, 

2005, pp. 449-456. 

[16] M. Hentschel, and B. Wagner, “Autonomous robot navigation based on 

OpenStreetMap geodata,” 13th International IEEE Conference on Intelligent 

Transportation Systems, 2010, pp. 1645-1650. 

[17] M. Hentschel, O. Wulf, B. Wagner, A hybrid feedback controller for car-like robots 

– combining reactive obstacle avoidance and global replanning,” Integr. Comput. 

– Aided Eng., vol. 14, Amsterdam, The Netherlands, 2007, pp. 3-14.

Application of CID Server in Decision Support 

for Command and Control 

Krzysztof Muchewicz, Marek Piotrowski, 

Henryk Kruszyński, Robert Palka 

Research & Development Department, 

TELDAT Sp. J., 85-640 Bydgoszcz, Poland, 

{kmuchewicz, mpiotrowski, hkruszynski, rpalka}@teldat.com.pl 

Abstract: In brief, Combat Identification (CID) is the capability to differentiate entities in a combatant’s 

area. Effective CID is a crucial factor for minimizing casualties and improving performance of military 

forces. A lot of solutions have been already created and applied on various military scenarios. 

Two of them are NFFI and Link 16. Although they prove to be useful on ground and air respectively, 

it has been identified that one cannot use information from both systems on air to ground arena. 

From this scenario the idea of CID Server has grown. First implementations have been created. 

Also NATO recognized the need for standardization and has started development of corresponding 

STANAG document. 

This article organizes knowledge about CID Server and presents CID JASMINE, which is a realization 

of CID Server concept. 

The main idea of CID JASMINE is to provide effective solution that will satisfy all requirements for 

CID Server both in national and multinational environment. To make it possible, the topic of CID 

has been deeply analyzed. Also existing CID solutions and capabilities have been studied. After that, 

advanced programming techniques and patterns have been applied to achieve goal. 

The final CID JASMINE will be a leading product in its category. Its first beta version was tested 

during CWIX exercise and first official release is planned at the end of 2012. 

Keywords: Combat Identification; Friendly Force Information; CID Server; JASMINE System; 

CID JASMINE 


“In combat, the only thing worse than enemy fire is incoming friendly fire.” 

The above statement from Marine Corps Sgt. Aldo Wong best describes 

the importance of the subject of Combat Identification (CID). Developing solutions 

for identification of objects on battlefield is crucial to minimize casualties and 

improve performance of military forces. In brief, definition of CID is as follows: 

Combat Identification (CID) is the process of attaining an accurate characterization 

of entities in a combatant’s area of responsibility to the extent that high-confidence, 

real-time application of tactical options and weapon resources can occur.


CID capability consists of following elements: 

Combat Identification (CID) = Situation Awareness (SA) + Target Identification 

(TI) + Non-materiel alternatives. 

A lot of CID solutions have been already created and applied on various military 

arenas. This includes: non materiel solutions like doctrine, training and materiel 

solutions e.g. sensors and C2 Systems. Two of them that should be mentioned are 

NFFI and Link 16. They have been already deployed and well tested, among others 

in Afghanistan. Although they prove to be useful on ground and air arenas respectively, 

it has been identified that one cannot use information from both systems 

on air to ground scenario. From that the need of CID Server has grown. The CID 

Server is one of CID solutions that improve combat identification process by collecting 

CID data from different sources and providing it on demand to consumers. 

First implementation of CID Server has been created by USA (BAE Systems, 

[1]) and Germany (CIGAR from ESG, [2]). Also NATO recognized the need 

for standardization and has started development of STANAG document [3][4]. Since 

the idea of CID Server is still young, there is only slight knowledge about possible 

features and its applications. The minimum is to provide Friendly Force Information 

from ground units to fighter aircraft. However, possible applications could be 

much wider and include all scenarios when the decision of engagement is weighed. 

Also TELDAT, an innovative company from Poland, has started development 

of its own CID Server product – CID JASMINE. The main goal of this article is to 

present concept of CID JASMINE and to show its main features according to existing 

CID and CID Server solutions. 

The CID JASMINE product will be based on existing components of JASMINE 

System, both software and hardware. As a hardware component CID JASMINE 

will use Server Box V.3, which is an efficient and powerful military Server station. 

Dedicated CID JASMINE software will work on Microsoft Windows 2008 Server 

operating system. All software elements are based on the SOA architecture and 

build upon MessageBus. Position Location Information (PLI) will be received 

using NFFI IP1, IP2 (NATO Friendly Force Information, Interoperability Profile 

1 and 2) and Link 16. It will be provided using Link 16 and NFFI SIP 3 (Service 

Interoperability Profile 3). CID Server capabilities will be successively extended 

to all available CID solutions, like VMF (Variable Message Format) and BRM 

(Battlefield Replication Mechanism). CID JASMINE will also provide operational 

picture and expose it using NVG (NATO Vector Graphics) protocol and web client 

application. This will enable to use CID information created by Server directly 

from Web Browser user interface. Therefore CID JASMINE will not only be a set 

of functional services but it will also provide operational picture on tactical level. 

The architecture and implementation of CID JASMINE will be focused on quality 

parameters of product. 

The article is organized as follows. Section 2 presents general definition and 

information concerning Combat Identification. Section 3 gives short overview


319 

of selected CID solutions. Section 4 presents general CID Server concept. Section 5 

describes the main ideas, features, architecture of CID JASMINE. 

II. Combat identification 

In this section the main facts concerning Combat Identification (CID) are 

introduced. The general definition is given below: 

Combat Identification (CID) is the process of attaining an accurate characterization 

of entities in a combatant’s area of responsibility to the extent that high-confidence, 

real-time application of tactical options and weapon resources can occur. The objective 

of CID is to maximize combat/mission effectiveness while reducing total casualties 

(due to enemy action and fratricide) [5]. 

Another definition is as follows: 

Combat Identification (CID) is the capability to differentiate potential targets 

mobile and fixed, over large areas with corresponding long distances as friend, foe, or 

neutral in sufficient time, with high confidence, and at the requisite range to support 

engagement decisions and weapon release [6]. 

It can be seen from above definitions that CID is a very general term that 

touches various operational and functional topics. The main motivation to develop 

CID in military forces is to minimize friendly fire accidents and to help prevent 

unnecessary combat losses. However CID is required also for other reasons. It is 

needed among others to: 

• effectively field fighting forces, 

• support to rapidly and positively identify enemies, friends, and neutrals 

in the battlespace, 

• manage and control the battle area, 

• optimally employ weapons and forces, 

• minimize casualties. 

The importance of CID has grown in the modern times since there is much 

more attention about personnel loss than, for example, in the beginning of 20 th 

century. 

Below some aspects of CID are shown. First operational and functional 

capabilities are presented then description of system-of-systems concept is given 

in accordance to CID. 

A. Operational capabilities 

CID is applicable in the following areas: 

• Air to air, 

• Air to surface, 

• Surface to Surface, 

• Surface to air.


Surface area includes land and sea. The subsurface is known as ground and 

maritime. In each of the these CID need is essential for commanders. CID capability 

is required for all mission scenarios. However, in different ones it can be implemented 

differently. The next picture presents various actors on various mission areas. 

Figure 1. CID Application on mission areas, source [5] 

To deliver CID capability, it is required to provide solutions that implement it. 

The CID concept can be implemented with two main types of solutions: materiel 

and non-material. 

Non-materiel solutions contain: 

• doctrine; 

• tactics, techniques, and procedures (TTP); 

• training. 

Non-materiel solutions often need to be augmented by materiel solutions. 

Materiel solutions can be characterized as: 

• sensor systems – cooperative and non-cooperative (like radar signal modulation, 

high-range resolution radar, electronic support measures), 

• command, control, and communications (C3) systems, in particular these 

could be digital data links and radios, each of which contributes a portion 

to the CID solution. 

One can see that, in the given description, CID is viewed as capability rather 

than a single program or system. This is the approach of “system-of-systems”. CID


321 

is a result of a process that appropriately and accurately characterizes the entities 

present in a combatant’s area of responsibility. Effective CID can vary depending 

on the conditions of the battlespace. The following scenarios can be identified: 

• In some cases the required identification is used only to rapidly distinguish 

among friendly, neutral, and enemy forces with confidence high enough 

to support weapon employment decisions. 

• At other times, identification of target class (e.g., cruise missile, fighter, or 

bomber) or target recognition (e.g., target vs. decoy) is required to select 

the correct defensive or offensive tactical weapon response. 

• In other cases, a more precise characterization that identifies specific target 

parameters, such as platform type (e.g., MiG–29 vs. MiG–21) and intent (e.g., 

an active interceptor vs. a defector), is required to select optimal defensive 

weapons and to support weapon release decisions. 

In all cases, the goal for CID is to provide the level of identification that 

is necessary for Weapon Delivery Assets to make correct decisions. 

B. Functional capabilities 

The functional capabilities for CID include: 

• foe identification (including platform type, class, nationality, allegiance, and 

intent information), 

• friend identification, 

• neutral identification, 

• interoperability. 

From the above one should put special attention on interoperability, since 

it is crucial for CID System to operate in multinational environment. To achieve 

interoperability, CID solutions have to be build upon standards, in particular NATO 

standards. Different solutions can be applied to obtain described above functionalities, 

both materiel and non-materiel. 

C. CID system-of-systems 

From presented earlier classification, CID can be seen as a capability, not 

a single system or program. Therefore CID implementation can be described 

as “system-of-systems”. It can be seen as collection of task-oriented or dedicated 

systems that pool their resources and capabilities together to create a new more 

complex system which offers broader functionality. All of these systems are critical 

contributors to a system-of-systems approach in providing both situational awareness 

and identification to use lethal weapons in the battlespace. The functional 

capabilities of all CID systems must work synergistically to provide a robust, 

high-confidence.


III. Overview of selected CID solutions 

Below selected CID solutions are presented. All of them belong to the group 

of materiel, C3 solutions. First two solutions are well known and broadly used 

NATO standards. The third is a radio replication mechanism that is an element 

of JASMINE System. All this mechanisms will be adopted in CID JASMINE. 

A. Friendly Force Information – NFFI 

NFFI standard was created in 2005 and has been developed until today by 

NATO Consultation Command and Control Agency (NC3A). It has been created 

to improve and simplify Real-time Friendly Force Tracking in the multinational 

environment. It enables tracing and identifying friendly forces in near-real time. 

NFFI is divided into three parts: 

• Interface Protocol 1 (IP1 – TCP); 

• Interface Protocol 2 (IP2 – UDP); 

• Service Interoperability Profile 3 (SIP3 – WebServices). 

Information is exchanged via IP1 and IP2 using formal messages that contain basic 

track information like identifier, system parameters, position and report time. 

Development of SIP3 protocol was started in 2006. SIP3 is based on Web 

services. More information about NFFI can be found in [7][8]. 

B. Tactical Data Link – Link 16 

Link 16 is a military tactical data exchange network created and used by 

the United States and adopted by some of its Allies and by NATO. Its specification 

is part of the family of Tactical Data Links. It uses the transmission characteristics 

and protocols, conventions, and fixed-length or variable length message formats 

defined by MIL-STD 6016, STANAG 5516. Link 16 information is primarily coded 

in so called J-series messages. This messages are binary data words with well-defined 

meanings. In particular, Link 16 can be used to report and to pull CID information. 

More details about Link 16 can be found in [9][10]. 

C. National solutions – BRM 

BRM data exchange mechanism has been created to enable exchange of operational 

information on tactical command level, mainly in the low-bandwidth radio 

networks. It has been developed by TELDAT Company and is applied in JASMINE 

System. BRM is based on UDP protocol and it combines high performance with 

flexibility and great capacity to exchange operational information. It supports exchange 

of data according to MIP C2IEDM and JC3IEDM data models. 

BRM mechanism is used in C3IS JASMINE System on tactical and dismounted 

soldier level, therefore this system can be used to exchange and provide CID information. 

More information about BRM can be found in [11].


323 

IV. CID server concept 

In Section III we have presented various systems that provide and exchange CID 

information. NFFI and Link 16 have been adopted in NATO and are used also in Afghanistan. 

Although being very useful, they are limited to specific areas and scenarios. 

As a way to improve CID, especially in ground to air scenarios, CID Server concept 

has been created. CID Server collects information from different land CID sources: 

• CID Sensors, 

• BFT systems, 

• Situation Awareness systems (SA). 

CID Server provides this information on demand, for specific area. 

Figure 2. CID Server application, source [3] 

The primary goal of CID Server is to support non-engagement decisions, whenever 

a risk of exposing own forces exists. This is because FFT, cooperative CID and 

SA systems might only provide near real-time situation awareness information. 

CID Server will use various communication protocols for receiving and 

providing information. In modern military operations, interoperability will be 

one of the most important features of CID Server. Therefore it should support 

international standards. To satisfy this, the service should be agnostic on: 

• data source/system (friendly force tracking [FFT], combat identification 

[CID], situational awareness [SA] system), 

• receiving platform/system (aircraft, ship, artillery battery, fire support cell, etc.), 

• communication means (tactical data link, local area network [LAN], etc.).


Server should support existing data exchange standards, therefore NFFI and 

Link 16 shall be supported. Following protocols have been identified as applicable 

for CID Server: 

• Link 16, 

• NFFI IP1, IP2, 

• NFFI SIP3, 

• VMF, 

• Cooperative sensors, 

• National standards for exchanging PLI (Position Location Information) 

from SA systems. 

A. CID server NATO standardization 

The lack of a system of this type has been identified in NATO, and work on 

the standardization has been started. Draft version of STANAG was created: “NATO 

STANDARD FOR SERVICES TO FORWARD FRIENDLY FORCE INFORMA- 

TION TO WEAPON DELIVERY ASSETS” [3][4]. 

This STANAG provides guidance for implementation of existing interoperability 

and data exchange standards, interface profiles, and both business rules and forwarding 

rules for collecting PLI and forwarding it to users in the appropriate systems. 

Currently there are no fielded CID systems capable of providing friendly PLI to 

the service for forwarding to weapon delivery platforms. For the foreseeable future, only 

FFT and SA systems are capable of providing the necessary information. The service 

is primarily based on conveying friendly PLI to weapon delivery platforms through 

Link 16, the only NATO-wide, standardized tactical data link (STANAG 5516). 

The service is planned to be based on an open architecture to provide connectivity 

of all FFT, CID, and SA technologies and as much as possible: 

• use existing ground and air systems and infrastructure, 

• require no modification of existing systems, 

• be expandable/adaptable to emerging PLI Sources (e.g. MMW, RBCI), 

• be NATO and Coalition interoperable. 

The work on STANAG for CID Server will last at least until the end of 2012. 

B. CID server usage scenarios 

Below some of the usage scenarios for CID Server are listed: 

• Air-to-surface – in this scenario CID data from ground actors is pushed into 

CID Server and exposed to fighter aircrafts. Aircrafts use CID information 

to identify targets and to support engagement decision. 

• Ground-to-ground – in this scenario CID data from CID Server is consumed 

by Weapon Delivery Assets on battlefield. CID information supports 

decision about weapon usage.


325 

• Multinational – in this scenario CID Servers from different countries and 

systems can exchange information with each other and enable CID when 

forces from various countries cooperate on battlefield. 

The use cases described above are presented on the next picture. 

Figure 3. CID Server use cases 

C. CID server application in NATO operations 

Since the idea of CID Server has grown during Afghanistan mission, its usability 

in NATO operations is the main motivation for its development. Different 

nations have various CID capabilities, both cooperative and non-cooperative, 

that are specific and not based on NATO standards. This capabilities cannot be 

used in multinational environment. It would be very non-efficient to replace this 

national solutions and create new ones dedicated for NATO missions. Therefore 

creation of one solution – CID Server – that will mediate between different solutions 

from different vendors and countries, will simplify the goal of unification 

and cooperation of NATO forces. Such an application of CID Server might be 

a goal in a long term. 

In a short term CID Server will use already proven solutions like NFFI and 

Link 16. This will be still very valuable for improving CID capabilities of joint 

forces NATO operations. 

Another important capability is an ability to exchange information between 

different CID Servers. This can be made using already existing NATO standards 

and protocols (like NFFI) however STANAG document can simplify this task.


V. CID JASMINE concept and implementation 

CID JASMINE is an implementation of the concept of CID Server from 

TELDAT Company. CID JASMINE is a part of JASMINE System. 

According to NNEC concept elements of JASMINE system was designed 

to be able to work at all military levels, starting from the highest to the brigade 

level or even at the mobile battlefield unit. The system consists of hardware and 

software. The main advantage of the JASMINE system is its high flexibility and 

easy way of configuration, which shortens the time needed for achieving operational 

condition. JASMINE system equipment and its interoperability have 

been tested during the national and international exercises, where wide range 

of provided services were presented. More information about JASMINE System 

can be found in [12]. 

The CID JASMINE product is based on existing components of JASMINE 

System, both software and hardware. As a hardware component CID JASMINE 

uses Server Box V.3, which is efficient and powerful military Server station. 

Dedicated CID JASMINE software works on Microsoft Windows 2008 Server 

operating system. 

All software elements are based on the SOA architecture that is build upon 

MessageBus. The next picture presents functional features of CID JASMINE. 

Figure 4. Functional capabilities of CID JASMINE 

PLI information is received using: 

• NFFI IP1, IP2 – land tracks is send to CID JASMINE using UDP or TCP 

protocol; 

• Link 16 – messages containing information about paths of different types 

of objects can be provided to CID JASMINE. Some of the possible messages 

are J3.5, J3.2.


327 

The information is provided for consumers using: 

• Link 16 – there are dedicated Link 16 messages that enable to provide 

information on demand, according to given area; 

• NFFI SIP 3 – based on Web Services this protocol allows to pool for tracks 

information for specified area. 

CID Server capabilities will be successively extended to all available CID solutions, 

(like VMF and BRM). Link 16 communication will be implemented over 

JREAP C protocol. The timeline for CID Server is presented on the next diagram. 

Figure 5. CID JASMINE Timeline 

CID JASMINE provides also operational picture and exposes it using NVG 

protocol and Web Client application. This enables to use CID information created 

by Server directly from Web Browser user interface. Therefore CID JASMINE 

is not only a set of functional services but it also provides operational picture on 

tactical level. 

The architecture and implementation of CID JASMINE is focused on quality 

parameters of product, in particular: 

• Performance – Server process a lot of real time data. 

• Scalability – it is possible to scale CID JASMINE to multiple computer 

stations. This is achieved using MessageBus infrastructure and SOA architecture. 

• Reliability – Server Box V.3 is a military server that satisfies all quality and 

reliability parameters for military equipment. Also development of CID 

JASMINE software has been focused on reliability. 

CID JASMINE is developed in connection with STANAG for CID Server. 

The development of STANAG will be observed and all important conclusions will 

be implemented. 

The first official release is planned at the end of 2012.


A. CWIX 2012 

First tests of the product has taken place during CWIX 2012 exercise. Link 16 

Gateway, which is a part of CID JASMINE has been extensively tested with systems 

from various countries and vendors. Below there is a list of CWIX capabilities that 

where test partners for CID JASMINE: 

• 2012-DEU – CIGAR3; 

• 2012-FRA – COCCA; 

• 2012-FIN – JADEC2; 

• 2012-ITA – AF AC2IS BladeRunner; 

• 2012-DNK – C-Flex; 

• 2012-NATO – ACCS LOC1 ARS; 

• 2012-POL – PAFLINK16; 

• 2012-NATO – NC3A-IETV-NIRIS; 

• 2012-NATO – TEDS JCTD/CWP; 

• 2012-NATO – NLVC (FLAMES), including JTLS. 

All test where successful. Performed tests covered exchanging Link 16 messages 

over JREAP protocol and visualization of exchanged information. 

B. Unification of identifiers 

CID Server uses various protocols and each of them use its own identifiers 

for battlefield objects. CID JASMINE will solve this issue in the following way: 

• For all types of information received by CID JASMINE the original information 

will be preserved. 

• If it will be necessary to map information between different protocols and 

it will be impossible to translate identifiers, then new identifiers will be 

generated according to configuration. 

• Once created mappings for identifiers will be stored for future use, to guarantee 

that each piece of information will be mapped in one way. 

• System will provide user interface for configuring and manually manipulating 

all mappings. 

Presented above strategy will be used not only for identifiers mappings but 

for all parameters of battlefield objects that require mappings. 

C. Performance and reliability 

The quality of CID Server depends mainly on the two factors: 

• Quality of Data Services, i.e. the services that are responsible for storing 

and providing data. 

• Quality of internal communication infrastructure.


329 

This two elements will be supported in CID JASMINE in the following way: 

• Data Store will be based on relational database, however it will be supported 

with object oriented database and additional caching mechanism. On this 

area TELDAT engineers has broad experience gained during developing 

Data Services for tactical command systems (BMS JASMINE). 

• Communication and messaging infrastructure will be provided by Message 

Bus, the TELDAT middleware solution that provide robust, scalable and 

reliable infrastructure for interconnecting system services. 

Provided mechanisms will guarantee proper quality: 

• The performance of system will be based on scalability of data services and 

Message Bus. It will be possible to add new physical servers that will work 

as cluster for CID JASMINE during mission, without interrupting the server. 

• Reliability will be assured by reliable-messaging that is part of TELDAT 

Message Bus solution. 

VI. Summary 

As has been presented in the article, Combat Identification is a basic capability 

for modern forces. CID Server is one of the solutions that extend CID capabilities 

and in some scenarios it is essential. The importance of CID Server has been noticed 

by NATO nations and also by NATO itself. First solutions have been implemented 

and STANAG development has been started. 

CID JASMINE is an implementation of CID Server from TELDAT company. 

The main advantages of CID JASMINE will be: 

• Interoperability – it supports all required interfaces and protocols; 

• Performance and quality – based on the proven components of JASMINE 

System and SOA architecture it provides powerful platform for CID data 

exchange. 

CID JASMINE is a net-centric product and an element of NNEC compliant architecture 

of JASMINE System. It consists of hardware and software elements and therefore 

it is a complete product ready to use on the field, in particular in NATO operations. 

References 

[1] http://www.baesystems.com/capability/BAES_034933/combat-identification-iff 

[2] http://www.esg.de/ 

[3] “NATO Standard for Services to Forward Friendly Force Information to Weapon 

Delivery Assets”, Draft, January 2011, NATO Standardization Agency. 

[4] “NATO Standard for Services to Forward Friendly Force Information to Weapon 

Delivery Assets”, Draft, August 2011, NATO Standardization Agency.


[5] Join Warfighting Science and Technology Plan, February 2000, Department of Defence, 

http://www.wslfweb.org/docs/dstp2000/jwstppdf/00-title.pdf 

[6] Join Warfighting Science and Technology Plan, 1997, Deparment Of Defence, http:// 

www.fas.org/spp/military/docops/defense/97_jwstp/jw4c.htm 

[7] V. de Sortis, NFFI Service Interoperability Profile 3 (SIP3) Technical Specifications 

(VERSION 1.1.5). 

[8] STANAG 5527 NATO Friendly Force Information Standard for Interoperability 

of Force Tracking Systems. 

[9] STANAG 5516, Edition 6, TACTICAL DATA EXCHANGE – Link 16. 

[10] “Departament of Defence Interface Standard for the Joint Range Extension Application 

Protocol (JREAP)” MIL-STD 3011. 

[11] “Means for operational data exchange in JASMINE System”, Military Communications 

and Information Systems Conference MCC 2009, 29-30 September 2009, Prague, 

Czech Republic. 

[12] T.Z. Kosowski, Ł. Apiecionek, “JASMINE system: network centric concept and 

practical solution”, Military Communications and Information Systems Conference 

MCC 2009, 29-30 September 2009, Prague, Czech Republic. 

[13] W. Zawadzki, „JASMIN wkracza do armii”, Nowa Technika Wojskowa nr 5/2007. 

[14] H. Kruszynski, „Zastosowanie systemu JASMIN”, Nowa Technika Wojskowa nr 9/2006. 

[15] H. Kruszynski, L. Apiecionek, M. Dziamski, „JASMIN w warsztatach Combined 

Endeavor 2008”, RAPORT nr 06/2008. 

[16] Multilateral Interoperability Programme, The Joint C3 Information Exchange Data 

Model (JC3IEDM Main), 2007. 

[17] „Sposoby wymiany danych operacyjnych w systemie JAŚMIN”, XVII Konferencja 

Naukowa Automatyzacji Dowodzenia w Gdyni, czerwiec 2009 r. 

[18] „Practical Solution”, Nowa Technika Wojskowa – Future Soldier, 2010 r. 

[19] „Command and Control Portal as a unified way of collaboration of different staff cells 

in army headquarters on operational level as well as cooperation with external civil 

organisations”, proceedings of the Military Communications and Information Systems 

Conference MCC 2011, 17-18 October 2011, Amsterdam, Netherlands, p. 53-68. 

[20] „Reliable and effective management of hardware and software in battlefield 

environment”, proceedings of the Military Communications and Information Systems 

Conference MCC 2011, 17-18 October 2011, Amsterdam, Netherlands, p. 169-180. 

[21] “Portal systemu wspomagania dowodzenia, jako sposób współpracy różnych komórek 

sztabu szczebla operacyjnego oraz kooperacji z zewnętrznymi organizacjami cywilnymi”, 

XIX Konferencja Naukowa „Automatyzacji Dowodzenia”, 2011 r., współautor. 

[22] D.J. Bryant, D.G. Smith, “Impact of Uncertain Cues on Combat Identification 

Judgments”, Defence R&D Canada, Technical Report. 

[23] Joint Center For Lessons Learned, Rethinking Combat Identification, vol. IV, Issue 3, 

June 2002. 

[24] Combat Identification Systems, Strengthened Management Efforts Needed to Ensure 

Required Capabilities, United States General Accounting Office, June 2001. 

[25] “Technologia Web Portali we wspomaganiu pracy komórek sztabu z uwzględnieniem 

procesu tworzenia obrazu z rozpoznania”, Seminarium w AON, 2011 r.

Managing Lessons Learnt from Daily Missions 

– Methodology and Tool 

Witold Hołubowicz, Wojciech Dymowski, Tomasz Springer 

ITTI Ltd., Adam Mickiewicz University, Poznań, Poland, 

{holub, wojciech.dymowski, tomasz.springer}@itti.com.pl 

Abstract: The paper is aimed to present an approach to managing military experience and the software 

tool dedicated for this purpose. This approach (SIMS Lesson Learnt methodology) and 

the tool (SIMS Lesson Learnt tool) are some of the results of the European Defence Agency (EDA) 

funded SIMS project, which-focus on force protection issues. The developed methodology is based 

on a recurrent and continuous lesson learnt process where phases of acquiring, analyzing and 

applying experience can be distinguished. In order to improve dissemination of knowledge, each 

phase off the LL process is reached as soon as possible. Additionally, new information resulting 

from each phase is available for the widest possible range of all those concerned. To support lesson 

learnt process activities, a dedicated IT tool – SIMS LL – has been developed. The SIMS LL tool uses 

various methods of interactive, visual representation of the lesson learnt related data to enhance 

the operator cognition. The analysis of the data in terms of the SIMS LL tool refers mostly to identification 

of correlations between particular data entities (e.g. events, human terrain information) 

and drawing conclusions from such correlations. As a result of the analysis, a lesson learnt related 

data entity with relevant correlations is being created (e.g. an observation with correlated events, 

lessons identified). In the end a recommendation which is a key product of analysing lesson learnt 

related data can be defined. Such recommendations may be a proposition of a certain change in regulations, 

the system of training and doctrines, based on the analysed experiences and affecting 

directly safety and effectiveness of future military missions. 

Keywords: lesson learnt, military, experience, daily mission, SIMS, EDA, PDT, methodology, process, 

DOTMPLF, recommendation, observation 


Conducting recent military operations (e.g. Desert Storm, Iraq Freedom, 

Enduring Freedom) has emphasized the need for fast acquiring, analyzing and 

disseminating new information from the battlefield. This includes also soldiers 

experience, which is the most valuable source of information especially in terms 

of dynamically planned daily missions (e.g. convoys, patrols) in an asymmetrical 

environment. Therefore, as a part of EDA SIMS project, a structured approach 

to managing military experience and a dedicated for this purpose, have been 

developed.


The paper is aimed to present this approach (SIMS Lesson Learnt methodology) 

and the latest knowledge of the SIMS Lesson Learnt tool (SIMS LL tool) 

design and functional scope. 

During the SIMS project, the knowledge of military officers with substantial 

operational experience acquired during missions e.g. in the Balkan region, 

in Iraq and Afghanistan has been explored. On that basis, a coherent methodology 

that may be used for effective collection of lessons learnt based on experience 

of soldiers and civilians coming back from current and future missions has been 

prepared. A crucial aspect of this methodology is to enhance the information available 

in the process of mission planning and mission execution. Initially it focuses 

on gathering more and better information in order to finally allow SIMS system 

to provide “smarter” information. Apart from direct use of information in mission 

planning and execution processes, this methodology addresses also the concept 

of improving pre-deployment training and other aspects of DOTMLPF (Doctrine, 

Organization, Training, Materiel, Leadership and education, Personnel, and Facilities). 

The “smarter” information can be used for increase the effectiveness of training 

soldiers, planning and executing missions in a certain environment; and can also be 

used to verify and improve the concept of operations (CONOPS) e.g. operational 

procedures and even doctrinal documents. 

The SIMS LL tool supports the proposed methodology, especially the LL process 

closing the whole information loop and focusing on three levels: daily missions, 

pre-deployment training and procedures and doctrine. 

II. Lessons learnt methodology based on experience 

from daily missions 

The term Lessons Learnt was initially derived from the field of knowledge 

management, which comprises several theories on how to retrieve knowledge gained 

by experience in organizations. As far as the military point of view is concerned, 

there are two main institutions dealing with Lessons Learnt systems, which are 

The Centre for Army Lessons Learnt (CALL) and Joint Analysis Lessons Learnt 

Centre (JALLC), the latter representing NATO. The CALL LL approach 1 takes into 

account the idea of Lessons Learnt in the military which is the following: individuals 

and the organization itself can reduce the risk of making mistakes and improve 

chances of success. While the NATO LL states that lessons learnt are “results from 

the implementation of a remedial action that produced an improved performance or 

increased capability” [2]. Both approaches share the same idea which is to gather 

1 

[1] “Lessons Learnt are validated knowledge and experience derived from observations and the historical 

study of military training, exercises, and combat operations that lead to a change in behavior at either the tactical 

(standing operating procedures [SOP]), TTP, etc.), operational, or strategic level or in one or more 

of the Army’s DOTMLPF (doctrine, organization, training, materiel, leadership and education, personnel, 

and facilities) domains.”


333 

experiences in military operations that lead to identification of new methods, 

strategies, etc., validate them and distribute them across the army. 

In the LL field, a LL methodology is usually described as a set of processes, 

methods, techniques and tools that are employed as part of the common LL process. 

The methodology describes several processes that need to be followed to 

obtain a LL, and establishes the general aim of those processes. In the LL area, 

these processes are broken down into several sub-processes, involving a process 

for gathering data for possible LL, validating the data as a possible lesson, storing 

the LL and distributing it. For the purpose of developing SIMS LL methodology 

and supporting tool, various approaches, both military and civilian have been analyzed 

(e.g. SECI Model, Generic LL Process, AAR, NATO LL collection method). 

However this analyse does not provide a clear and common set of definitions. For 

that reason, the following definitions were introduced and used in order to describe 

SIMS LL process within the methodology: 

• Lessons Learnt process (LL process): the process in which the experience 

of a military organisation is used in order to enrich its knowledge, which 

is then used to improve the effectiveness of actions that are undertaken, 

• Observations: the information describing the events which are associated 

with the mission that has been executed. Observations can be gathered by 

using an IT system. 

• Lesson Identified (LI): an ordered set of observations and additional elements 

such as generalisations, recognised patterns, recommended actions 

and reactions. 

• Lesson Learnt (LL): any set of observations, LI and recommended actions 

that proved effective in practice. The knowledge based on LL is continuously 

used in the organization to ensure the success of the mission. 

• Lesson Learnt Officer (LLO): a person who processes the observations. 

LL Officer’s tasks can embrace all aspects of the process, starting from 

the analysis of observations up to preparation of recommendation. 

• Pre Deployment Training (PDT): the part of military training which is focused 

on preparation of soldiers for a specific operation e.g. ISAF operation 

in Afghanistan. 

• DOTMPLF: abbrev. Doctrine, Organization, Training, Materiel, Leadership 

and Education, Personnel and Facilities. 

The analysis of existing approaches to lessons learnt and military needs, allowed 

to identify key elements and characteristics which should be used in the defining 

the Lessons Learnt process for SIMS. Due to the nature of the SIMS project and 

its military purpose, the military methodologies are treated as more meaningful, 

and thus more important. 

The defined SIMS LL Process is a recurrent and continuous process. In relation 

to military organizations, the following phases of this process can be distinguished:


• Acquiring experience – the phase in which missions are conducted based 

on the mission plan. The LL process should begin with gathering all the raw 

data derived from observations made during the mission as well as from 

other possible sources and sensors. At this stage it comes down to mining 

the entire knowledge in possession of organisation, both explicit and 

tacit. In the military context, it is collecting all the observations made by 

individual soldiers during the mission and the data recorded by different 

sensors. Data collection should include all the available sources, if only 

the data might be potentially useful. 

• Gathering and analyzing experience – the phase where the information 

is gathered, analysing and processed. LI and/or LL are results of processing 

observations. Analytical operations will cover collecting, structuring, 

filtering and analyzing data, so that one can develop information on 

certain events and situations. This group of actions will develop certain 

patterns of behaviour/procedures, saying what should be done when 

certain circumstances occur. This means that collected observations and 

data are compiled and converted into information on certain situations, 

phenomena and objects. On the basis of this information, conclusions 

are drawn, and from the conclusions appropriate behaviour patterns and 

reaction models can be developed. An analysis can be carried out either 

by the LLO or other experts, at different levels of decision making. They 

can recommend changes in the relevant aspects of DOTMPLF. The LLO 

or another expert has access to information related to missions on each 

step of observations or LI analysis. Collected observations, LI and LL are 

available for planners (according to relevant procedures defining access 

to information). Recommendations prepared are related to either PDT 

or DOTMPLF. 

• Applying experience – the phase of taking advantage of the knowledge 

gained from experience by applying it to core activities performed by 

the military organisation (e.g. planning and executing daily missions). 

All respective LI should be taken into account during the training and 

preparation of soldiers for the next missions, but also when planning 

new missions and creating military doctrines. A LI is checked and tested 

in the operational environment during the training process. After being 

tested in the operational environment, the LI is further analysed. Then 

a detailed description is created, which contains all the elements like inputs, 

outputs, roles and responsibilities. Structured LI should be further 

tested in the live environment, either a combat mission or training. After 

being tested in the live environment, LI obtains the status of Lesson Learnt. 

The changes derive from LL, LI and regulations in PDT and DOTMPLF. 

The knowledge spreads faster in small organisations in contrast with more 

complex organisational structures like military ones. The formal process of data


335 

and knowledge updating on the basis of new experience is relatively long in military 

organisations. In order to improve this situation, one of the possibilities is to 

enable each phase of LL process to be reached as soon as possible. Additionally, 

new information resulting from each phase should be available for (but not necessarily 

distributed directly among) the widest possible range of all those concerned. 

The diagram below presents the implementation of the LL process which considers 

fast circulation of the information. 

Figure 1. The Lessons Learnt process in military organization 

The level of experience in the military organization increases within every 

iteration of the process. The level of experience could be estimated e.g. by the amount 

of observations identified and described. In the LL process the availability of information 

gives the opportunity to share the gained experience straightaway, even at 

the time of gathering the information. Thanks to this quick access, even to the information 

that has not passed the analysis step, the LL process especially supports 

the implementation of daily missions connected with asymmetric threats, where 

every piece of information can influence the success of the mission. Moreover 

mission planning and execution in an asymmetric threats environment is much 

more difficult because of unexpected actions of the opponents. In such a situation 

the most required ability is to learn the organization by itself to avoid making further 

mistakes and draw conclusions from the short-term history of the opponents actions. 

The most important thing, therefore, is the implementation of the LL process 

in military structures according to the presented model. 

III. Recommending – the output of the process 

Recommendations are one of the key products of the LL process. Recommend 

(in addition to collecting information about the observations and their analysis)


should be seen as one of the three main stages of the LL process. The recommending 

process involves three main stages: 

• preparation of recommendations, 

• implementation of recommendations, 

• monitoring and updating of the recommendations (recommendations 

management). 

Recommendations propose changes in regulations, the system of training 

and doctrines, based on the analyzed experiences (which are obtained as daily 

observations of the daily missions). The quality of recommendations is largely 

determined both by the competent collecting of information about events and 

the results obtained in a complete analysis of the collected observations. The development 

of appropriate recommendations to a large extent determines their use 

in theory and/or military practice. Each phase of this process is dependent on each 

other. Therefore, it is worth noting, that the major determinants of the generation 

of added value in the LL process is the interdependence of particular LL phases. 

Interdependence is manifested primarily through the presence of many couplings, 

mainly between phases. The results obtained from the preceding phase are the base 

point (input data) to implement the next phase. 

The primary objective is to produce a recommendation during the recommendation 

process. The intermediate objectives of this process are consistent with 

the objectives of the SIMS, project, i.e. improvement of the following processes: 

• mission planning, 

• and execution of missions. 

Achieving these objectives implies the development of a formalized document 

that contains a parametrised recommendation. This means that such a document 

(Recommendation) should include, among others the following content: 

• defined and measurable goal of recommendations, 

• tasks to be executed, 

• boundary conditions of these tasks. 

Expected results of implementatin of this phase of the LL process allow to: 

• increase the effectiveness of the mission, 

• increase the level of situational awareness in the daily missions, 

• verify and improve the methodology referring to the interpretation of documents 

concerning the operations of the army – in particular for recommending 

changes which will enhance soldiers capabilities: 

✓ tactical (following Rules of Combat ROC) 

✓ operational-tactical (the development of mission plans/planning process) 

✓ strategic (improving doctrine), 

• increase the effectiveness of training (for example, new content will be 

introduced in training programs, there will be more case-s, and many 

diverse instances of their use will be discussed).


337 

A recommendation shall be a formal document and should be composed 

of three main sections: 

• header, 

• body (appropriate recommendation), 

• signature/authorization. 

In the header section the following fields should appear: 

• name of the recommendation (e.g. streamlining procedures for the identification 

of ID), 

• reference of the recommendation (e.g.: Rec/14/2011/F2,F3,F4) 

✓ Rec – recommendation, 

✓ number of recommendation, 

✓ YYYY year in which the recommendation was developed, 

✓ a phase (phase) of the mission recommendation (optional): 

■ F1 – prior to the planning phase of the mission, 

■ F2 – the planning phase, 

■ F3 – the training phase, 

■ F4 – the execution phase, 

■ F5 – the mission evaluation phase, 

• the recommendations creation date, writens in a suitable format (e.g. YYYY. 

MM.DD/2011.04.18), 

• place of issue (e.g. Poland, Poznan), 

• originator of the recommendation, 

✓ rank, name and surname (e.g. Sgt. John Doe), 

✓ originating institution / organisational unit (e.g., the General Staff 

of Army / Department of Strategy and Defence Planning), 

• recipient (recipients) of recommendations: 

✓ Country / unit name (e.g. Afghanistan / 6 Logistic Base), 

✓ An institution / organisational unit (e.g., the General Staff of Army / 

Department of Strategy and Defence Planning), 

• a concise description (a few sentences of description what the recommendation 

refers to). 

General knowledge of the recommendation phase in the process of constnt 

learning at the stage of implementation manifests itself with specific problems 

which have a very complex structure and form an immense intellectual challenge. 

It seems obvious that organisations should benefit from processing the knowledge 

related to historical events. Such events should be well-documented and include 

both positive and negative aspects. 

IV. LL tool functions and architecture 

The SIMS LL tool is assumed to be used for effective gathering of observations, 

processing them and applying the results of this process within military structures.


The LL tool supports the SIMS Lesson Learnt process in the following way: 

• gives an instant access to the most recent information concerning planned 

missions, missions in progress and executed missions (e.g. information 

about the incidents, socio-cultural events, soldiers personal remarks, mission 

plans, debriefing notes). This access can be accomplished by the use 

of common information storage, database; 

• enables gathering of observations based on the information acquired from 

the common database. Centralization of the lesson learnt related data allows 

sharing the most recent knowledge and improves its management. By 

providing a set of predefined data filters, SIMS LL tool enables effective 

gathering and processing of only relevant data; 

• enables tracing the causes and effects of observations, lessons identified, 

lessons learnt and recommendations. Providing an easy way to indicate 

a cause (e.g. particular incidents) of the effect (e.g. observation) through 

the use of various tools and methods, supports the stage of analysis 

of the SIMS LL process. SIMS LL tool is capable of using different analysis 

methods available through additional plug-ins (additional LL related data 

visualisation methods); 

• enhances the process of recommending changes in regulations, the system 

of training and doctrines through the cause-effect analysis of observations 

and lessons identified. The SIMS LL tool enables creating correlations 

between lesson learnt related data; 

• enhances the process of dissemination of the lesson learnt related data 

among mission planning cells, unit commanders and soldiers through 

the centralization and flexible access to the data; 

• enables organising of the lesson learnt related data in hierarchical structures 

of dependencies; 

• provides a structured way of managing the lesson learnt data according to 

the SIMS LL process. The SIMS LL tool will guide a user through the process 

of creating such data, taking care of their completeness and consistency. 

• enables formalisation of recording lesson learnt related data. The SIMS 

LL tool provides templates for observations, lessons identified, lessons 

learnt and recommendations documents. 

• enables generating of formal electronic LL reports (in common file formats 

e.g. doc, rtf, pdf). 

The SIMS LL tool can support the analysis stage of the SIMS LL process. 

In order to provide such a support, SIMS LL tool uses interactive methods of visual 

representation of the LL related data to enhance the LLO cognition. The analysis 

of the LL related data in terms of the SIMS LL tool consists mainly in creating correlations 

between particular data entities (e.g. events) and drawing conclusions 

from such correlations. As a result of such analysis the LL related data entity with 

relevant correlations is created (e.g. an observation with correlated events). An ex-


339 

ample of a dependency tree graph analytical plug-in for SIMS LL tool is included 

in current version of the tool. 

The effectiveness of using the SIMS LL tool for the purposes of the analysis 

of lesson learnt related data, depends on the quantity and quality of the available 

source data for the LL process. The higher amount of input data (e.g. incidents, 

human terrain data) for the SIMS LL process might increase the total number 

of observations, and as a consequence the number of recommendations incresase 

as well, while the better quality of the input data (e.g. in terms of number of possible 

correlations, and completeness) might improve the observation and recommendation 

accuracy. 

The SIMS LL tool is a multiplatform standalone pure Java client application. 

The Java Swing components together with external Flamingo and Substance packages 

were used for implementing SIMS LL tool graphical user interface (GUI). In order 

to ease future development and tool upgrades, common design patterns were used 

while implementation (e.g. MVC). The tool is intended to be used together with 

PostgreSQL database as a data storage. However, the SIMS LL tool is open for the integration 

with other database types or even web-services technologies. 

V. The potential of the tool in mission planning, execution 

and training 

The SIMS project results are delivered in the form of a prototype which is far 

from being an operational tool guaranteeing reliability in the real world. Nevertheless 

SIMS LL tool currently could be used for historical data analysis and for training 

purposes – as an application used to collect and analyse information available from 

the past operations, missions. 

The main area of operation of the SIMS LL tool: 

• for debriefing purposes or Post Action Review, the tool provides the officers 

responsible for the LL the possibility to fill in data from the mission 

together with their comments and observations. 

• in the analysis stage the tool allows to: 

✓ browse the contents of the knowledge database using filters (filters are 

predefined, but users can configure them as well), 

✓ browse information on the analysed missions and other historic missions, 

✓ search missions and similar events (e.g. associated with the same area 

or type) 

✓ correlate events (e.g. incidents) and other information from the knowledge 

database and create observations from them, based on their similarity 

(e.g. the participation of soldiers in firing at a distance that is shorter 

than the one covered by the standard used during mission training, or a new 

kind of threat, like IEDs placed in a new location – behind the posters. 

✓ visualise the correlations between the objects (e.g. incidents, observations),


• at the recommendation stage to develop recommendations based on the collected 

observations and define the entity responsible for the approval or 

implementation of recommendations, 

• after preparing the recommendations the tool allows to browse them, and 

to easily find and view the observations and events (e.g. Incidents) that 

originated them; this feature can be used for example to update the training 

for future changes or as a support for introducing changes in procedures 

and doctrines. 

The following are considered potential uses of the developed methods and 

SIMS LL tool by polish military lesson learnt dedicated: 

• to develop and maintain LL training adapted to specific needs of polish 

military. 

✓ SIMS LL methods can be used to carry out the theoretical part of the training 

for officers, who may have the role of a LL officer, and who executes 

selected tasks from LL area at different stages of the LL process. 

✓ to use the LL tool to conduct LL workshops involving completing 

the information, their analysis and preparation. 

✓ to prepare the training which is similar to the course “Lessons Learnt 

Staff Officers Course” like e.g. training as an introduction to that course, 

or courses extending under specific local conditions. 

• to introduce modifications in the debriefing process or Post Action Review 

aiming at improving the information collection system to make a better 

use of the experience (LL) 

• to collect experience from operations and missions conducted by polish 

military and analyse them by combining different types of information. 

• to make use of the observation database as a basis for preparing recommendations, 

procedural and doctrinal changes. 

The implementation of the features mentioned above require to update the tool 

to the appropriate technological level in order to allow a stable operation in the real 

world, or operational training. 

VI. The use of LL tool 

The SIMS LL tool GUI consist of three main sections: 

• toolbar, where all the basic tools for managing lesson learnt data are placed. 

Additional plug-ins (e.g. analytical tools) as well as settings are also available 

in this section; 

• LL related data, where input (e.g. incidents, human terrain information) 

and output (e.g. observations, recommendations) data for the LL process 

are available for browsing and filtering. Data are organised in hierarchical 

structures and can be stored in the remote or local databases;


341 

• LLO workspace, where lesson learnt related data are being browsed, created 

or updated. 

The following pictures presents basic the LL tool GUI sections. 

Figure 2. Main LL tool window 

Figure 3. Lesson learnt related data trees section 

SIMS LL tool supports multi monitor display in order to provide bigger 

workspace for the LLO. Therefore it is possible to view LL related data in separate 

or detached windows (instead of internal LL tool tabs), and organised them 

in the preferable manner.


Figure 4. Lesson learnt related data correlations visualization – dependency tree 

graph plug-in in detached window mode 

VII. Future development 

SIMS LL tool is being constantly improved thanks to the extensive testing 

and evaluation. Due to the modular design, it is easy to add new functionalities 

in the future, or to adjust the tool to the needs of a particular army or even civil 

organisation. 

Currently, ITTI is working on extending LL tool capabilities to georeferenced 

data visualisation and analysis, using GIS components. Such functionality, will provide 

additional lesson learnt spatial analysis capabilities (e.g. analysis of events, incidents, 

observations etc. related to the places in a given radius around a certain point on 

the map). Moreover, improvements in the dependency tree graph visualization plugin 

will be made. Creating dependency graphs interactively (e.g. using drag and drop 

features), together with automatic nodes ordering into pattern groups might bring 

significant benefits to the process of lesson learnt related data analysis. 

In order to provide fast lesson learnt related data dissemination among soldiers 

in the battlefield, there is a need to adjust SIMS LL tool to the capabilities of modern 

mobile devices (PDA, tablet, smartphone etc.). Therefore, to make an effort 

to meet military expectations, SIMS LL tool lite version for Android compatible 

multi-touch devices is begin prepared. 

One of the very important aspects of the further development of Lessons 

Learnt methodology and tool is to focus on other specific application areas. Cyber 

Crime is one of many subjects not to be left out nowadays. An example of approach 

related to gathering factual material (and thus part of an lessons learnt ideology) 

in the area of cyber threats is the work on a software tool (Cyber Tool) that has been 

developed as part of EDA ATHENA project in the workpackage devoted to modelling 

physical threats. In this work authors have identified a need of defining a unifying 

methodology for gathering factual material on cyber threats. Following such 

approach will help gather and in turn analyse incidents in cyber layer in order to 

identify possible risks related to security of daily missions.


343 

References 

[1] CALL (Centre for Army Lessons Learnt), March 2009. Commander’s guide to 

operational records and Data Collection. Handbook 09-22. Chapter 4. Collection 

priorities. Available at: http://www.globalsecurity.org/military/library/report/call/ 

call_09-22-ch04.htm 

[2] NATO. NATO Lessons Learnt Handbook. First edition, October 2010. Joint Analysis 

and Lessons Learnt Centre Lisbon, Portugal. Available at: http://www.jallc.nato.int/ 

Documents/

Chapter 4 

Information Assurance & Cyber Defence

Federated Cyber Defence System 

– Applied Methods and Techniques 1 

Bartosz Jasiul 1 , Rafał Piotrowski 1 , Przemysław Bereziński 1 , 

Michał Choraś 2, 3 , Rafał Kozik 2, 3 , Juliusz Brzostek 4 

1 Military Communication Institute, Zegrze, Poland, 

{b.jasiul, r.piotrowski, p.berezinski}@wil.waw.pl 

2 ITTI Sp. z o.o., Poznań, michal.choras@itti.com.pl 

3 University of Technology and Life Sciences, Bydgoszcz, Poland, chorasm@utp.edu.pl 

4 NASK, Warszawa, Poland, juliusz.brzostek@nask.pl 

Abstract: In this paper implementation details of the Federated Cyber Defence System (FCDS) are 

presented. The main system components are described including their architecture, used protocols 

and security mechanisms. Moreover the benefits of the system are highlighted as well as recommendations 

and future work are proposed. 

Keywords: Cyber defence, cyber security, attack detection, Federation of Systems, Intrusion Prevention 

System, Intrusion Detection System 


Nowadays information exchange between companies as well as among common 

network users is natural. Internet as a global communication medium is used for 

business, social, personal but also criminal purposes. Cyber terrorism has become 

one of the most significant threats to public institutions using the Internet in everyday 

communication. Potential threats for a wide range of various networks and critical 

public infrastructures may be generated by both domestic and foreign users. Harmful 

activities cover broad spectrum of cyber threats and potential cyber attacks. They 

can influence communication links, data resources, their integrity, confidentiality 

and availability. According to the Open Web Application Project [1] nowadays top 

ten security risks in the Internet are: 1) Injection, 2) Cross-Site Scripting (XSS), 

3) Broken Authentication and Session Management, 4) Insecure Direct Object 

References, 5) Cross-Site Request Forgery (CSRF), 6) Security Misconfiguration, 

7) Insecure Cryptographic Storage, 8) Failure to Restrict URL Access, 9) Insufficient 

Transport Layer Protection, 10) Unvalidated Redirects and Forwards. 

Prototype of Federated Cyber Defence System (FCDS) is a developed to minimize 

number of threats and attacks that may affect the domain connected to the open


network. FCDS is the system that cooperates in Federation of Systems (FoS) in order 

to gain advantage over adversaries. FoS is an association of loosely coupled countries, 

states, companies, societies, or organizations, each retaining control of its own 

network. Domains in FoS are so connected or related as to produce results beyond 

those achievable by the individual systems alone. Recently, the concept of federated 

networks and systems has gained much attention in the context of military 

networks and NATO Network Enabled Capabilities (NNEC) [2]. 

Typical security solutions to prevent data and network infrastructures are 

firewalls, antivirus software, etc. They should be systematically updated according 

to the recommendations provided by vendors. Every network domain acts according 

to its own autonomous security policy which treats reaction to detected attacks 

as its internal activity. The lack of synchronization among network administrators 

causes that network security level depends on employed solutions and system 

administrator awareness and skills. 

Presented FCDS offers exchange of information related to security aspects 

(e.g. detected attacks and recommended reaction). This enables to achieve an effect 

of synergy where common reaction to identified malicious actions is more 

effective than many uncoordinated reactions realized by single domain. Exchange 

of information on threats, detected attacks and verified security metrics improves 

situational awareness in federated domains. Similarly, coordinated detection and 

reaction to attacks is more accurate, precise and adopted in timely manner. In this 

manner the federated networks resistance to attacks is increased. 

The advantage of FCDS is a capability to collect and correlate events aroused 

by various sensors spread in own and federated domains. In comparison, typical 

defense systems use only data provided by proprietary sensors. Heterogeneity 

of accepted events from various networks layers and domains allows to detect attacks 

and malicious actions faster that it was possible before joining the federation. 

In FCDS a response is prepared and applied to reactions elements of protected 

domain as fast as an attack is detected. 

II. System architecture 

FCDS is a system prototype designed for improvement of federated network 

cyber security. It consists of autonomous subsystems which are deployed in protected 

networks /domains (Figure 1). Each domain consists of FCDS elements: a number 

of sensors (S), one decision module (DM) and a number of reaction elements (RE). 

Sensors supply decision module with alarms about events observed in the network. 

Decision module performs reasoning and makes decision if the observed action 

is an attack and produces appropriate rules applicable to reaction elements. These 

rules include information how to respond to detected attack in order to minimize 

its undesirable effects. Decision modules deployed in autonomous networks share 

information about detected attacks and recommended reactions. It is assumed that

Chapter 4: Information Assurance & Cyber Defence 

349 

information exchange between them is voluntary as well as the use of recommended 

reactions depends on internal domain security policy and administrator decision. 

This approach enables to achieve synergy effect, when set of domains functioning 

together is able to produce a result not independently obtainable. 

Figure 1. FCDS architecture 

Proposed architecture consists of separated communication channels for 

the exchange of information between FoS partners. An advantage of this approach 

is the ability to decide which kind of information can be exchanged with a specific 

coalition partner. In contrast, the management of this structure is complex and 

error-prone. In case of a change in coalition membership, all domains have to update 

their communication relations. Thus, there is a huge management overhead 

for a large amount of 1-to-1 communication links [3]. 

III. Prototype implementation – applied methods and techniques 

Architecture described in previous paragraph was implemented in Java environment. 

For the purpose of testing there were created 3 domains, where functional 

elements are deployed. 

A. Sensors 

For every domain, a different set of sensors was used. Some of them are proprietary 

and some are widely used open source or commercial solutions. Each of them is deployed 

in a specific location (e.g. a network segment, a server) and acts in a different way. 

SNORT [4] is the most popular open source Network Intrusion Detection 

and Prevention System (NIDS/NIPS). It has the ability to carry out real-time traffic


analysis and packet logging on IP networks. SNORT performs protocol analysis, content 

searching, and matching. Detection mechanisms relay on signatures of known 

attacks. Both built-in and proprietary signatures for scanning, fingerprinting, reverse 

shell code execution etc. were used. SNORT was configured a bit differently in each 

domain, i.e., a different set of rules and modules was applied. 

OSSEC [5] is a widely used open source Host Intrusion Detection System 

(HIDS) and Security Information Event Management (SIEM) system. It performs 

log analysis, integrity checking, policy monitoring. In SOPAS, it was used mainly 

for log analysis. Both built-in and proprietary OSSEC log file decoders and rules 

for FTP (proFTPD, vsFTP) and WWW (Apache) servers were applied. 

ARAKIS [6] is a commercial system developed by NASK (FCDS project 

partner). It is an early warning system detecting novel network threats. ARAKIS 

uses low interaction server side honeypots and simulates a set of servers exposing 

most popular services, passively waiting for an attack. The system uses novel 

technologies to detect anomalies and generate on-the-fly accurate SNORT attacks 

signatures. It was installed in one of the SOPAS domains and it shares information 

with other domains. Dedicated Syslog [7] and WAPI [8] interface between ARAKIS 

and Decision Module was implemented and new methods of visualization were 

designed and applied. 

HoneySpider Network (HSN) [9] is another commercial system developed by 

NASK. It focuses on attacks involving the use of web browsers and it is based on 

client-side honeypots. HSN actively interacts with servers and processes malicious 

data. It engages a client honeypot solutions and a novel crawler application specially 

tailored for the bulk processing of URLs. Dedicated Syslog and WAPI interface to 

Decision Module was implemented. 

Proprietary Anomaly Detectors (AD) which address the problem of finding 

patterns in data that do not conform an expected behavior, were also deployed. 

First AD is a database traffic anomaly detector based on genetic algorithms. It learns 

normal (proper) database traffic e.g. SQL queries, saves its pattern in the form of best 

matching regular expressions and alerts as anomalous every query which does 

not match this pattern. Another AD is a network volume anomaly detector. It sets 

the threshold for normal traffic, e.g., FTP control connection traffic volume, and 

alerts as anomalous every traffic exceeding this threshold. For the above-mentioned 

FTP example, exceeding a threshold may indicate an FTP brute force or dictionary 

attack. Another AD examples are dedicated log file analyzers which are based on 

the knowledge what is normal and what is anomalous. 

Syslog [7] was chosen as an event exchange mechanism between Sensors and 

their local Decision Module. Syslog is standardized by IETF (RFC 3164, RFC 5424). 

It is supported by a wide variety of devices and applications across multiple platforms. 

Standard Syslog provides a transport via UDP, to allow a device to send event 

notification messages across IP networks to event message collectors. There is no 

confirmation of an event reception. The Syslog packet size is limited to 1024 bytes


351 

and carries the following information: categorized source called facility, severity 

(from debug to emergency), host or interface name, timestamp and message 

(unstandardized description of event). Syslog supports hierarchical network architecture. 

Lack of reliable transfer of events from Sensors to local Decision Modules 

was unacceptable in SOPAS; thus decision about using Syslog-ng [7] implementation 

which support transport using TCP was made. To make the communication 

secure, a built in TLS mechanism based on X.509 certificates provides encryption 

and mutual authentication between the host and the server. 

B. Decision Module 

Each DM is responsible for acquiring and processing network events coming 

from sensors distributed over the domain. If the attack or its symptoms are detected 

in one domain, the relevant information are disseminated to other cooperating 

domains so that appropriate countermeasures can be applied. 

Decision module in the proposed federated system is responsible for correlating 

network events in order to detect and recognize malicious events in the network. 

DM consists of the following components [10]: 

• Correlation Engine (e.g. based on the Borealis system), 

• CLIPS rule engine, 

• Ontology (in OWL format), 

• Graphical User Interface. 

The Decision Module components are presented in Figure 2, while the UML 

diagram is shown in Figure 3. 

Figure 2. Decision Module architecture and components [10] 

Borealis is a distributed stream processing engine and is responsible for 

gathering information generated by the network sensors [11]. Correlation engine


has mechanism that allows the Decision Module to efficiently execute multiple 

queries over the data streams in order to perform event correlation. The result 

of a correlation process is an intermediate event that is further processed by 

CLIPS rule engine [12]. CLIPS uses ontology that describes broad range of network 

security aspects (we use ‘’FCDS ontology’’ developed in our project). CLIPS 

engine identifies whenever some attacks or malicious network events have been 

discovered. The information describing the network incident and reconfiguration 

procedures (Common Decision Rule – CDR) are sent to Translator. Moreover, 

detailed information in human readable format are generated and visualized to 

network administrators via DM GUI. 

Figure 3. UML diagram of DM 

Data received from network sensors is arranged in streams. Each stream is built 

of multiple tuples (events). Each tuple, depending on sensor type, may have different 

schema. Borealis allows to process streams in order to correlate information 

coming from different sources and to detect network incidents more efficiently. 

The query that is executed over the multiple streams consists of operators. There 

are different kinds of operators provided by the Borealis engine that allow for aggregation, 

filtering and joining data coming from different streams. 

According to Figure 2. only intermediate events are matched with the knowledge 

stored in the ontology. The intermediate events are obtained via the Borealis 

query that is executed over the streams of a network events. Their names, types 

and schemas are maintained in the ontology. Each intermediate event received by 

CLIPS rule engine is considered as attack symptom and as such is matched with 

knowledge in the ontology in order infer the most probable attack [13]. 

The example of symptom matching is graphically presented in Figure 4. 

When the symptoms are received by CLIPS rule engine the most probable attacks 

are inferred. However one symptom could match several attacks, therefore CLIPS 

is responsible for computing the probability score and alerting about these attacks, 

for which the calculated score exceeds the detection threshold.


353 

Figure 4. Matching sensor events (symptoms) with knowledge in ontology [13] 

If the attack is detected it may have accompanying (described in ontology) 

general decision rule that will minimize consequences. There are several pre-defined 

general reactions such as blocking, traffic redirection (e.g. to a trap or back to 

the attacker), administrator notification or service disabling. 

The ontology defines different security policies (what reactions are recommended/allowed 

in the particular domain) for different domains, therefore CLIPS 

additionally matches this knowledge with appropriate general reaction rule to avoid 

policy violation. 

Each Decision Module can react to network events and attacks by sending 

information (CDR) to the Translator element and then to RE. The output information 

from DMs is the CDR describing attack symptoms (information about network 

events) and particular reaction rule to be applied by reaction elements. Translator 

has the knowledge about its subnet capabilities and can access the necessary reaction 

elements (e.g. firewalls, filters or IDS). Reaction elements can be reconfigured 

by Translator in order to apply commands sent by the Decision Module. 

All Decision Modules within the federation can also interact with each other 

and exchange security information. Particularly information about network incidents, 

like attack in one domain, may be sent to different Decisions Modules in order 

to block the attacker before the consequent attack takes place on another domain. 

Communication between domains and Decision Modules is based on P2P (Peerto-Peer) 

in order to increase communication resiliency and enable data replication. 

Moreover, P2P approach allows the proposed system to overcome IP addressing 

issues and minimize the configuration cost. 

The proposed approach allows the system to have redundant communication 

channels between Decision Modules. Particularly, when a physical connection 

is under attack or is congested, the communication packets still have an opportunity 

to reach the destination DM using a different path. 

The used communication channels are encrypted using the SSL algorithm. 

This allows to protect the communication against the packet sniffing (by third


persons). Additionally, payload is encrypted with different keys and it can be only 

decrypted by domains that belong to the same distribution group (nodes relaying 

the message can not read the payload). 

The visualization methods and Decision Module GUI will allow the administrator 

of the proposed system to increase the situational awareness. The goal 

of the Decision Module GUI is to visualize the network status and provide information 

about historical and current network events and security incidents. DM will use 

data about historical network performance, information from the underlying online 

system and reported network events. The tool will analyze and present the threats, 

provide support and guidance to the operator and will evaluate potential actions 

to be taken as well as decisions made by the administrator. 

One of the visualization examples is shown in Figure 5. 

Figure 5. GUI visualization 

Furthermore, GUI allows the administrator to visualize the network events 

currently processed by the Decision Module, manage the communication between 

different DMs and decide what types of decisions rules can be distributed and 

shared with other domains. 

Very important functionality of FCDS is the possibility of semi-automate prevention/reaction 

to attacks. Full CDR describes how RE should react to detected attack. 

This CDR is transformed by translator (Figure 3) into commands understandable by 

response elements (e.g. firewalls). Then translator sends them to selected RE. 

C. Reaction elements 

The FCDS architecture includes reaction elements. They are responsible 

for actions, which enable prevention, limitation or cut down hostile actions. It is 

obvious that response to certain attacks may be difficult and sometimes impos-


355 

sible (e.g. DDOS attack). Some reactions may be harmful from the point of view 

of protected domain business. 

In FCDS prototype there are implemented following open source reaction 

elements: 

• Firewall – iptabeles; 

• DNS blackholing – Bind; 

• Web Proxy – Squid. 

They were chosen after requirements definition for developed system. 

First of them iptables [14] is an application used to manage packet filtering. 

It enables creating Linux firewalls (stateful firewall) or NAT (Network 

Address Translation). System administrator defines chains including set of rules 

e.g. ACCEPT, DROP, REJECT (Figure 6). 

Figure 6. Definition of rules for iptables 

Each rule in a chain contains the specification of which packets it matches. 

Packets are processed by sequentially traversing the rules in chains. In FCDS iptables 

is used for dropping IP packets when source/destination address is recognized 

as intrusive. 

Second implemented RE is also open source software for DNS blackholing 

– Bind [15]. Bind publishes the Blacklist of IP addresses of zombie computers 

or other machines being used to send spam, listing the addresses of ISPs who 

willingly host spammers, or listing addresses which have sent spam to a honeypot 

system. In FCDS system the blacklist is created basing on HSN sensor (system 

Honey Spider Network [9] working as a sensor). In the case of FoS environment 

DNS blackholing is destined for user computer protection against visiting infected 

www portals. It requires proper user terminal configuration to enforce utilization 

of appropriate DNS server. 

As the Web Proxy as RE in developed system is used Squid [16]. Squid 

is a proxy which offers a rich access control, authorization and logging environment 

to develop web proxy and content serving applications. Squid is a highperformance 

proxy caching server for web clients, supporting FTP, and HTTP


data objects. Squid handles all requests in a single, non-blocking, I/O-driven 

process over IPv4 or IPv6. Squid supports SSL, extensive access controls, and full 

request logging. By using the lightweight Internet Cache Protocol, Squid caches 

can be arranged in a hierarchy or mesh for additional bandwidth savings. For 

the project purposes it acts as an intermediary for requests from clients seeking 

resources from other servers. As RE in FCDS system it is used for blocking access to 

a dangerous/infected web services and informing the invoker that the page/resource 

consists of harmful content. 

All described RE are deployed on the edge of each protected domain. Such 

solution enables total separation from other domains in extraordinary situation. 

Moreover it enables immediate reaction. In more sophisticated scenario it is feasible 

to place these reaction elements in front of each computer in the network. 

Such solution would enable precise reaction in the case when internal terminal 

within the domain is infected (eg. broadcasts spam) or the user starts unauthorized 

actions. Common reaction in the federation is also possible in order to counteract 

external attacks (from outside the FoS). In this case all incoming network connections 

should be filtered. 

It is worth noticing, that not for all detected attacks will be possible preparation 

of full CDR (with reaction). In such situation experienced administrators will 

be able to prepare the CDR manually and send it to RE. CDRs may be prepared 

for limited time interval as well as they may be deactivated when they are obsolete. 

IV. Recemmendations and future work 

Presented FCDS enables information exchange between cooperating domains 

and reaction against cyber attacks. In reality such cooperation requires high level 

of trust between network owners. The paper describes implementation details 

of FCDS system which enables security measures improvement by multi-sensor 

attack detection and joint reaction. Cooperation among federated domains and 

cyber information sharing is crucial to enable detection of distributed attacks. 

Reliable and secure communication is required for sensor data collection, CDR 

distribution and Reaction element remote control. 

Future work will cover continuous development of ontology, machine learning 

techniques and statistical anomaly based approach. These techniques will improve 

DM capabilities in the area of precise attack detection and possible response to 

minimize the attack effects. In order to provide cyber information sharing capability 

with other systems FCDS must employ commonly accepted format. Some proposals 

are decrscribed in [3] which should be considered in the future. Moreover, trust 

management aspects shall be studied.


357 

References 

[1] https://www.owasp.org/ 

[2] Network Centric Warfare: Developing and Leveraging Information Superiority, 

by Alberts, Garstka, and Stein, CCRP Press, 1999. 

[3] L. Beaudoin at all, Coalition Network Defence Common Operational Picture, 

NATO Information Systems and Technology Panel Symposium, Tallinn, Estonia, 

November 2010 http://ftp.rta.nato.int/public/PubFullText/RTO/MP/RTO-MP-IST-091/ 

MP-IST-091-P03.doc. 

[4] www.snort.org 

[5] www.ossec.net 

[6] www.arakis.pl 

[7] http://www.syslog.org/ 

[8] www.wombat-project.eu 

[9] http://www.honeyspider.org/ 

[10] M. Choraś, R. Kozik, R. Piotrowski, J. Brzostek, W. Holubowicz, Network 

Events Correlation for Federated Networks Protection System, In Abramowicz W. et al. 

(Eds).: Towards a Service Based Internet, LNCS, Springer-Verlag, 2011. 

[11] Borealis project homepage: http://www.cs.brown.edu/research/borealis/public/ 

[12] CLIPS project homepage: http://clipsrules.sourceforge.net/ 

[13] M. Choraś, R. Kozik, Network Event Correlation and Semantic Reasoning for 

Federated Networks Protection System, In Chaki N. et al. (Eds.): Computer Information 

Systems – Analysis and Technologies, Communications in Computer and Information 

Science CCIS, 48-54, Springer, 2011. 

[14] www.netfilter.org/ 

[15] http://www.bind9.net/ 

[16] http://www.squid-cache.org/ 

[17] www.balabit.com 

[18] www.cee.mitre.org

Identity and Access Services in NATO 

Federation Scenarios 

Robert Malewicz, Rui Fiske, Graeme Lunt 

Core Enterprise Services, NATO C3 Agency, The Hague, The Netherlands, 

robert.malewicz@ncia.nato.int 

Abstract: This paper describes an approach for the effective implementation of a standards-based 

solution for authentication and authorization services across user realms in NATO. 

Keywords: component: identity and access management, federation, SAML, XACML 


A. Background 

Identity and Access Management (I&AM) has gained a significant attention 

in NATO recently. NATO engages in missions that involve different types of partners 

ranging from NATO and Non-NATO nations through to international organizations 

and industry. 

The diversity of data sharing scenarios makes the boundaries of user and asset 

governance realms less obvious. Therefore, much more stress is put nowadays on 

trusted mechanisms to control access authorization, going beyond “local” domains, 

and even beyond the enterprise. The simultaneous application, in a balanced way, 

of two contradictory (by nature) concepts is required on a large scale in a multisecurity 

classification information processing environment, i.e. the Need-to-Share 

operational requirement and the Need-to-Know security principle. 

The problem itself is not new in classified computing environments. The Biba 

Model (from 70s), the Bell-LaPadula Model (from 90s) are just two examples of existing 

access control enforcement mechanisms. However, the scale of the required 

integration in the NATO scenario is what poses a new challenge for communities 

of Information Assurance (IA), Information Services (IS) and Information and 

Knowledge Management (IKM). 

In this context, a NATO-wide I&AM framework, coherent across both network 

and organizational boundaries, becomes a key enabler for extensive information 

sharing in different NATO federation scenarios.


B. NATO initiatives in the area of I&AM 

To date, following initiatives have been of significance in NATO within 

the I&AM area: 

• NATO Identity Management (NIDM) Workshop (2008-2009) – a combined 

effort of NATO Consultation, Command and Control Board (NC3B) 

Information Assurance Subcommittee (SC/4) and Information Systems 

Subcommittee (SC/5). As a result of this initiative, a NIDM Strawman [1] 

paper was published in 2009. The level of ambition for this document was to 

provide a framework for future work on NATO-wide Identity Management 

(IdM) concept, considering the federated nature on the NATO infrastructure; 

• NC3B SC/4 Security Management Infrastructure Ad Hoc Working Group 

addressed the IA view on different aspects related to identity, privilege, and 

access management. In 2010, this group produced a paper, aimed to provide 

a strategic plan for Identity Management developments in NATO [2] 

as well as Security Management Infrastructure Directive [3], currently 

being the only document where some identity and access management 

aspects are regulated in NATO; 

• The Alliance Command Operations (ACO) identified the issue of missing 

NATO-wide I&AM mechanism in the operational NATO Network 

and Information Infrastructure (NII) that would be adequate to support 

future Alliance Operations and Missions (AOM). As a result, a document 

was released in June 2011, describing a strategy to provide a capability 

of AOM Federated Identity and Access Management (AIDAM) [4]; 

• Anticipating the requirement to support NATO operations in federation 

scenarios, the Allied Command Transformation (ACT) supported a series 

of research programs in the area of I&AM, aimed to analyse possible solutions. 

Details can be found in [5]. 

C. AIDAM capability strategy 

Published by ACO in June 2011, the so called AIDAM is an excellent source 

of operational requirements and a vision for utilization of identity and access 

control services in the NATO federations. It also provides some recommendations 

on the solutions that should be adopted. The AIDAM view is in line with 

the recommendations provided through the ACT research programs, clearly indicating 

the most promising direction to achieve the information sharing capability 

in the environment of heterogeneous NII. 

The AIDAM makes the following statements: 

• I&AM are key to cross-domain protection and sharing of sensitive Command 

and Control (C2) information within federated Communities of Interest 

(CoI);


361 

• In the near term, the aim for web-based I&AM will pursue a claims-based 

I&AM; 

• In the mid-term IAM is to be arrived at by means of federated identity and 

rights translation; 

• In the long-term AIDAM is to be obtained through standardization of all 

I&AM capabilities. 

II. NATO-specific architectural constrains 

A. NATO Bi-SC AIS network topology 

The current (and evolving) Bi-Strategic Command (Bi-SC) network topology 

is summarized and visualized in Figure 1. 

Figure 1. NATO NII Interconnection Visualization 

Detailed analysis of the Bi-SC Automated Information System (AIS) NII topology, 

as in [6], confirms a significant complexity in terms of possible network 

interconnection scenarios. The current situation can be summarized in the following 

way: 

• In the NATO Secret (NS) segment of the NATO NII, the domain integration 

approach allowed the achievement of a good level of consolidation. 

Still, fully centralized management of the entire NS segment will not be 

possible; in some cases only limited (unidirectional) trust relationship 

can be enabled between domains;


• At the NU/NR level, the NATO NII is much more fragmented than NS. 

A concept of the NATO Enterprise Business Network (EBN) at the NR 

level is aimed to change this situation. The Public Access Network (PAN) 

network, currently operating on the NU level, will be promoted to the NR 

level, constituting the core of the future EBN. It will not be done overnight 

however. 

B. Two-dimensional NATO view 

Considering the governance realm aspect, which is particularly relevant 

when considering different federation scenarios, NATO can be seen in a twodimensional 

view [7]: 

• “NATO as an Enterprise” – consisting of NATO Headquarters (HQs), agencies, 

and other internal bodies, all together constituting a NATO enterprise; 

• “NATO as an Alliance” – understood as a federation of (currently) 28 NATO 

member nations, NATO partners (nations/international organizations/ 

industry), and the NATO enterprise itself. 

Depending on which NATO view is being considered, there are different 

requirements for the NATO identity and access services, having impact on the ultimate 

solution. 

III. Federated I&Am architecture decision points 

Taking into account the complex structure of the NATO NII in both the NU/NR 

and NS environments, it is proposed to use a Web-based federated approach for 

development of the NATO I&AM architecture. Typically, there are eight decision 

filters that are followed to decide how to implement federation in a way that meets 

the organization’s requirements [8]. These decision points are: 

• Identity Production and Consumption, 

• Federation Topology, 

• User Identification, 

• Operational Security, 

• Trust Relationships, 

• Attributes, 

• Compliance, 

• Standards. 

A. Identity production and consumption 

As in [8], after the federation scenario applicability validation, two key identity 

roles can be identified in the federated identity environment, and requires at least 

one of them to be applied to the domain:


363 

• Identity Producer, known as an Identity Provider (IdP) – if domain’s user 

identities must be asserted to other domains for access to “foreign” resources; 

• Identity Consumer, known as a Relying Party (RP) – if applications in a domain 

must identify users from other domains. 

The NATO Bi-SC AIS domains in both, NU/NR and NS, security zones will act 

as both an IdP and RP simultaneously. The decision about roles of other domains, 

federated with Bi‐SC AIS, will be determined at the implementation stage, after 

a thorough analysis of the business model of the domain joining the federation. 

B. Federation topology 

There are three basic topology models, applicable for a Web-based federation 

[8]: 

• Point-to-point, 

• Hub, 

• Network topology (shared federation services). 

The federation topology has a significant impact on the overall governance 

posture of the identity and access services. Therefore the options have to be analysed 

very thoroughly. 

Federation between NS and NU/NR is not achievable nowadays whilst policy 

restrictions limit the possible interconnection between those security domains 

to data-diode based solutions (Figure 1). Therefore, NS federation with NU/NR 

networks is not considered as a valid scenario in this study. However, the tendency 

can be currently observed to launch integration processes at all levels of the NII. 

It is an indication of the evolution path in long term, giving solid foundations to 

anticipate federation scenarios including enhanced forms of interactions between 

NS and NU/NR environments as well. 

1) Federation Topology for NS Bi-SC AIS: a Two (+One) “trust broker topology” 

is the recommended approach (Figure 2). Normally, it is applied in scenarios 

with a more centralized infrastructure, such as the one that can be found 

in the Secret environment. 

For a federation within the NATO as an Alliance” scenario, it is not recommended 

to directly federate the NATO Trust Broker with components from domains 

that operate under a governance realm different from NATO, as it might 

raise security issues. 

In such a case a federation should be established through a component located 

in the NATO Enterprise NS Gateway Zone. From the NATO as an Enterprise point 

of view, this component would operate as 

• NS Federation Shadow for scenarios including direct interactions of the NA- 

TO-external partners (e.g. national, mission domains) with NATO enterprise 

NS domains;


• NS Federation Proxy, to control the policy compliant flow of the identity 

and access attributes. It should be noted that identity and access data 

processing is not explicitly addressed in the current NATO policy, which 

should be noted as a potential problem when defining policy rules at 

the Proxy. 

Figure 2. Federation Topology at the NS Level 

From the NATO as an Alliance point of view, the federation component 

in the Gateway Zone would operate as the Alliance Federation Broker, enabling 

federation services in the NATO Alliance. 

2) Federation Topology for NU/NR networks: taking into account a significant 

defragmentation in the NU/NR environment, the “Point-to-Point” option 

seems to be more accurate. A consequence of this approach will be an overall 

mesh-topology (Figure 3). Although more flexible, this topology is more 

difficult to manage and control. Accountability for the establishment and 

maintenance of trust relationships with external parties is pushed down to 

the level of a single domain. 

The mesh topology should be adopted as an interim solution. It is anticipated 

that with implementation of the EBN concept at the NU/NR level, NATO will follow 

the same evolution path as the one delimited by the NS environment. When 

it happens, the “trust broker topology”, as proposed for the Bi-SC AIS NS area 

(Figure 2), would be more appropriate at the NU/NR level.


365 

Figure 3. Federation Topology at the NU/NR Level 

C. Public key operations and infrastructure 

In the Web-based federation solutions, asymmetric cryptography techniques 

are used to underpin trustful identity and access data flows. This implies the use 

of public-key operations. In sensitive, classified, policy-driven environments, like 

the NATO organization, the requirement to utilize public-key operations has to 

be translated into the requirement to deploy a Public Key infrastructure (PKI). 

In NATO, it means a use of the NATO Public Key Infrastructure (NPKI), providing 

an assured foundation on top of which the NATO federation trust topology 

can be built. Without integrating with the existing NPKI, the federation services 

in NATO environment may not be considered as a valid solution. 

Currently, NATO is planning to deploy NPKI on two separate PKI branches, 

one on NS domain and the other one in support of NU/NR services. This structure 

reflects directly the NATO Security Policy identified sensitiveness levels of information 

assets as well as, in a sense, the current NATO network topology logic. 

From the federation services point of view, there are a number of challenges 

the NPKI needs to meet: 

• the management and distribution of certificates and private keys, which 

will be solved by the NPKI itself; 

• the validation of certificates. There are a number of approaches to this 

problem, e.g.:


✓ Certificate Revocation List (CRL) – from a distribution point that 

is specified in the certificate. This places a fair amount of work on 

the validating machine, and can involve the distribution of CRLs that 

are many megabytes in size. 

✓ Online Certificate Status Protocol (OSCP) responder, which can validate 

an individual certificate, and return a response without having to return 

the entire CRL. 

✓ XML Key Management Specification (XKMS) service that provides 

a mechanism for validating certificates through a Simple Object Access 

Protocol (SOAP) web service interface; 

• the distribution of the certificates themselves, particularly the public key 

associated with a certificate that is used for digital signatures, and – where 

necessary – encryption. Again, these can be retrieved from a directory, 

or may be manually distributed to entities that rely on them, so that certificates 

are held in a local certificate store on the machine. 

It should be noted that XKMS supports the validation of digital signatures 

and X.509 certificates as well as the distribution of public keys to relying parties. 

It also supports the registration and renewal of private keys for entities, and so 

should be considered as an integral part of any NPKI deployment. 

D. SAML token claims for entity identification 

In a federated system, such as is being described in this paper, attributes, also 

known as “claims” in Security Assertion Markup Language (SAML) terminology, 

describe an entity within a system. It is envisioned that the collection of claims will 

be represented in a digitally signed Security Token, which can be passed across 

organizational boundaries, and will have originated from an IdP. Other federation 

components can add further claims to the token from different sources, can map 

one attribute to another by changing the attribute’s Uniform Resource Identifier 

(URI) or even modify the value of the claim to one that can be processed by 

the target system. 

The collection of claims about an entity (either a user or a component of the system) 

in a security token represent entity’s identity in a specific context, and are 

used to make authorization decisions about what actions an actor is able to make 

on a particular resource. 

In order to achieve interoperability at the federation level, or even within 

a single domain, it is essential that the claims are unambiguously specified and 

standardized, implying necessity of a standardization effort. It is recommended to 

utilize SAML standard. It is not only a standard protocol for stating assertions but 

also is widely accepted and used in diverse scenarios, demonstrating its suitability 

for federated environments.


367 

In addition to that, claims standardization will also be required, including 

definitions of claims. It is because the semantic relationship between domains needs 

to be agreed, so claims mapping and processing rules can be effectively implemented 

on the claim receiving side for authorization decisions. 

This process of “Identity Mapping” is probably the most complex and expensive 

aspect of federation. It is recommended to development a Federation Profile 

that can be used by all partners in the federation, which specifies the metadata, 

attribute usage, and constraints on protocol option use as required [8]. Although 

NATO has started to develop “Service Interface Profiles” (SIP) for service interaction, 

the federation profile has not yet been issued. An analysis of the federation 

profile specified by the Transglobal Secure Collaboration Program (TSCP) [11] for 

adoption in NATO is a recommended approach. 

1) Management of claims: 

In order to successfully use claims for the identity of the actor within the system, 

and to ensure that they are unambiguous, each attribute has a unique identifier 

assigned to it, in a form of URI. These URIs must therefore be managed, to 

ensure that duplicate identifiers are not assigned for attributes that are not identical. 

Many common attributes, such as email address, CommonName, and Surname 

have already been defined by xmlsoap.org, an industry body that proposed many 

of the original SOAP and Web Services (WS)-* standards, and these are widely 

understood by Security Token Service (STS) implementations from many different 

suppliers. However, in case of attributes specific for a classified environment, 

such as Clearance, URIs must be registered with the appropriate body, e.g. NATO’s 

Naming and Addressing Registration Authority. 

2) Distribution of claims: 

Claims contain information about the entity which is to be shared with federation 

partners, and some consideration needs to be given to which attributes 

can be distributed outside NATO. Certain claims may be too sensitive to share with 

partners, and in some cases privacy issues must be respected to prevent personal 

information being distributed beyond organizational boundaries. One way to 

protect this information in transit is to encrypt the security tokens, and STSs must 

therefore be able to handle encrypted tokens, but the scope of individual claims also 

needs to be specified. It is proposed, for example, that a user’s group membership 

at the domain level is not distributed outside NATO. 

In this context it is worth noting that the control of personal data and the protection 

of privacy are better guaranteed through the use of assertions rather than allowing 

shared access to identity information between domains.


3) Types of claims: 

Two key classes of claims have been identified concerning entities within 

the system: 

• Organizational claims, described as “Custodial Identity” in [8], are issued by 

the IdP of the entities, and represent their organizational role independent 

of the applications to be accessed. This includes common attributes such 

as nationality, clearance, email address, etc. A unique identifier should be also 

included, for which a common format has to be agreed. NATO unique identifiers 

will be generated by the NATO Enterprise Directory Service (NEDS), 

when deployed in the operational environment (mid 2013); 

• Application specific claims, described as “Contextual Identity” in [8], are 

issued by the relying party STSs and contain application-specific attributes 

to support authorization, and have little or no validity outside the scope 

of the application or service being consumed. These attributes are most likely 

to be retrieved from local attribute stores, such as directories or databases, 

and contain data about the roles of the actor in the application. 

In addition, Context claims describe the environment in which the entity is acting, 

and may be used as further parameters for evaluating authorization decisions. 

4) Modality of claims: 

When categorizing the requirement to include a claim in a token, modality 

values are proposed as follows: 

• Mandatory – only the Unique Identifying Claim should be mandated; 

• Recommended; 

• Optional; 

• Not Recommended; 

• Forbidden. 

5) Unique Identifying Claim: 

The Unique Identifying Claim should be used to identify the source of an entity 

as well uniquely identify the entity in all application-specific attribute stores. 

Therefore this unique identifier will be an organizational, rather than application 

claim. There is still some debate as to what the format of this attribute should be, 

though some requirements have been identified: 

• it will uniquely identify all entities (users, services, devices, etc.); 

• it will allow the identification of the source domain; 

• it will be semantically abstracted from the underlying data through the use 

of a NATO-specific URI. i.e. even though it may be the user’s email address, 

it will have a URI that identifies it as a unique identifier (ID) rather 

than email address; 

• it may be multi-valued, i.e. it may contain more than one attribute value. 

This will allow the use of other values (then e.g. an e-mail address) like


369 

the NATO Enterprise Identifier (NEDS terminology). Where multiple 

values are used for the identifying claim, then each value should be verified 

(at least by the federation broker) to ensure that it has been issued by 

the correct STS; 

• it will be a primitive data-type, i.e. a string value. 

E. Operational security 

This decision point covers the following areas: 

• Assertion-Based Authentication and Authorization Assurance – it is imperative 

that in a classified environment, such as the NATO enterprise, 

the identity of the subject is cryptographically bound to the message that 

is being sent. Therefore, when for example consuming or providing web 

services, it is required that some sort of proof of possession mechanism 

is used, such as one of the WS-Security Token Profiles; 

• Secure Communications – the aim of secure communications is to “provide 

mutual authentication and protect the integrity and confidentiality 

of communications channels”. In the case of browser-based sessions, it recommends 

the use of mutual authentication using client certificates over 

Hypertext Transfer Protocol Secure (HTTPS). However, within a NATO 

environment, confidentiality is provided at the lower levels of the stack, 

and the use of HTTPS, while not forbidden, is not preferred, in order to 

allow real-time monitoring by Intrusion Detection Systems; 

• Assertion-Level Security – assertions issued by the STS MUST be digitally 

signed to ensure that they are trusted by the relying parties. Although 

the confidentiality of the token in the NATO environment is again provided 

by the lower layers of the stack, Encrypted Assertions MAY be used 

to further protect the contents of SAML assertions that are distributed by 

the STS. Therefore, any STS MUST be able to issue both encrypted and 

unencrypted tokens, and any Policy Enforcement Point (PEP) MUST be 

able to process both encrypted and unencrypted security tokens; 

• Audit and Forensics – regardless of the NATO dimension being considered 

(“NATO as an Enterprise” vs. “NATO as an Alliance”), the NATO applications 

require tight controls within the domains where they are used. 

It implies a requirement to use strong detective controls, not just the preventive 

ones. Currently, NATO is executing the NATO Computer Incident 

Response Capability (NCIRC) project, aimed to deploy the cyber defence 

capabilities (including audit and forensic functions) in both NS and NU/ 

NR environments. In the context of the “NATO as an Enterprise” scenario, 

the task would be to identify the interfaces and mechanisms through which 

the federation services can be controlled and secured by the operational 

security infrastructure provided with the NCIRC project. The situation


is more difficult in the context of the “NATO as an Alliance” scenario, implying 

operations across governance realms. Apart from standard technical 

solution and internally developed procedures, it is necessary to develop 

templates for business agreements and processes for cross-domain forensic 

measures in order to facilitate auditing and ensure that investigative authorities 

have access to necessary information and can correlate information 

across domains as part of a detective control or for incident response. 

F. Trust relationships 

This decision point should determine the terms on which a domain may 

establish federations with partners. Depending on the federation scenario, trust 

relationships require agreements at a subset or at all the three levels as follows: 

• technical, proving technical framework of security specifications that can be 

derived from specifications defined in operational security, 

• business, describing functional aspects derived from the business case 

of the federation as well as the governance framework, 

• legal, proving the legal framework for the federation. 

Detailed analysis of the business and legal aspects are out of scope of this investigation. 

They seem, however, to be more relevant in the context of the “NATO 

as an Alliance” scenario. Specific regulations should address at least: 

• purpose of the federation, 

• required assurance levels, 

• use cases, 

• required security practices, 

• identity data usage limitations, 

• audit or assessment criteria for compliance with the federation regulations. 

Compliance validation with the federation rules is addressed in section H. 

G. Authorization and attribution 

This decision point is aimed to provide an answer to the following questions: 

• What attributes are going to be used for authorization decisions 

• How should attributes be exchanged between domains 

1) Federated authorization position: 

The current approach in NATO for authorization services is either to rely 

on Microsoft Active Directory (AD) capabilities or to utilize application specific 

authorization modules. As a result, NATO has to deal with highly decentralized 

(and often internally incoherent) policy infrastructures. It does not seem to be 

possible to easily change this approach. However, the upcoming service-oriented 

business processing pattern in NATO will pose new security challenges. Therefore,


371 

it is necessary to build the foundations for a future security policy infrastructure, 

capable of protecting efficiently the service-based interactions. If the centralized 

authorization service approach, as described below, is not followed in the “NATO 

as an Enterprise” scenario, it will not be possible to efficiently perform authorization 

actions in the “NATO as an Alliance” scenarios. 

The eXtensible Access Control Markup Language (XACML) specifications [10] 

identify key components of the policy infrastructure in support of the authorization 

decisions: 

• Policy Enforcement Point – gathers all the relevant data from the request, 

the request context or environment, and the state of the service, 

before submitting an authorization decision request to Policy Decision 

Point (PDP); 

• Policy Decision Point –responsible for authorising a particular entity (or 

“identity”) to perform an action on a resource. Once an authorization 

request is received from the PEP, then the matching policy is retrieved 

from the Policy Administration Point (PAP), where it may be cached, and 

evaluated against the request. This results in a decision that is returned to 

the PEP, which may be “permit”, “deny”, or “unresolved”; 

• Policy Administration Point – supports the management of policies as well 

as the retrieval of policies for use by the PDPs; 

• Policy Information Point (PIP) – allows the further retrieval of attributes 

about entities within the system for use by the PDP, if required. The PIP 

will essentially be an interface to a repository (NEDS in the NATO NII), 

which stores attributes about all users, or to the local application-specific 

attribute store, either directly through Lightweight Directory Access Protocol 

(LDAP), or wrapped using a web services interface. 

2) Identity and access data repositories: 

Currently in NATO, there is no coherent approach applied to address the issue 

of identity and access data processing throughout its whole life-cycle. As a result, 

there are many identity repositories in NATO, maintaining pieces of identity data and 

access data independently from each other. This situation causes serious problems 

in daily business operations but it also introduces a security flaw (e.g. uncontrollable 

privilege escalation, inactive accounts, etc.). 

The on-going deployment of NEDS, scheduled to be fully operational by 

mid-2013, will provide a meta-directory capability, aimed to synchronize the portions 

of identity and access data shared by different repositories and applications 

in the NS NII. In the mid/long term vision, NEDS would constitute a cornerstone 

of NATO-wide identity management processing. As such, it is anticipated to play 

a critical role also in the utilization of the federated identity capability. 

Identity and access data synchronization in the Secret space will be organized 

based on NEDS capabilities, as presented in Figure 4.


Figure 4. Directory Services Topology in Secret Environment 

NEDS is not meant to interconnect with any identity store operating in a different 

security zone and/or governance realm. In the NEDS project, the role of directory 

data synchronization repository for external parties is assigned to a (not 

yet deployed) Alliance Replication Hub (ARH). It will be deployed in the NS 

demilitarized zone (DMZ). 

It is recommended to use the ARH as an identity data store for the federation 

proxy component (Figure 2) in support of SAML-token issuance processes and 

controlling functions. 

An option of the NEDS project will be executed in the future, aimed to deploy 

the directory data synchronization mechanism at the NU/NR level. 

3) Data (Attribute) types: 

Identity data can be categorized in the following way: 

• Biometrics, 

• Personally Identifiable Information, 

• Qualifications, 

• Tokens, 

• Roles, 

• Privileges. 

NATO specified the Allied Communications Publications (ACP) 133 directory 

services standard. It provides foundations for NEDS directory schema definition. 

However, ACP 133 is not capable to support all the categories listed above. Therefore, 

extensions of the ACP 133 standard may be required.


373 

4) Attribute processing – implementation considerations: 

Two approaches are considered for utilization of SAML token claims in the authorization 

process: 

• A SAML token includes only a unique identifier of an entity (e.g. user, 

service). In this case, utilizing the ID extracted from the token, the RP 

local identity store has to be queried for other identity attributes required 

at the authorization process, 

• Apart from a unique identifier of an entity, additional claims are provided 

in a SAML token, required to perform the authorization. The additional 

attributes can be provided either by the IdP, or can be derived 

from the identity store in the DMZ area (if the “NATO as an Alliance” 

scenario is in a consideration), or from the local identity store of the RP 

(like in the previous case). 

The first option would be the recommended one. However, there might be 

cases when the other option, requiring additional attributes in tokens, will be 

more appropriate. This might be the case e.g. when the authorization component 

in the RP domain is not able to query the identity store, or the identity store is not 

available in RP’s domain. 

H. Compliance 

Federation trust relationships have to be verified in order to maintain the agreed 

(in a federation) business scope and level of protection. 

The compliance aspects should be considered separately in both NATO scenarios 

(NATO Enterprise vs. Alliance) as the means to ensure the compliance will 

differ for both scenarios. 

Normally, for low-risk and some medium risk applications, self-assessment 

and certification by a domain’s internal audit function may be sufficient. 

For some medium-risk and all high-risk scenarios, a periodic external audit will 

be necessary. In the “NATO as an Alliance” scenario, the federation agreement 

should clearly specify the following: 

• roles, 

• responsibilities, 

• procedures and standards, 

• liabilities in contracts 

I. Standards 

The wide variety of federation use cases imply a variety of standards and 

specifications that can be utilized. For the architecture proposed in this document,


it is recommended for NATO to address the following categories of the federation 

standardization aspects: 

• Federated authentication standards, to provide an input on which standards 

should be used for authentication among federated domains; 

• Attribute exchange standards, to provide an input on which standards 

should be used to conduct and control attribute exchange among federated 

domains; 

• Security standards, to provide an input on the coherent protection mechanisms 

to be applied in order to achieve the same protection level in the whole 

federation; 

• Federation-specific profiles, to provide an input on what a federation profile 

should specify; 

Depending on which NATO scenario is considered (NATO Enterprise vs. 

Alliance), the specific decisions in all the four identified areas may vary. 

Under the ACT Program of Work, several service interface profiles (SIP) have 

been proposed that should be utilized in the NATO federated identity and access 

service architecture specification. 

IV. Conclusions 

Achieving a successful implementation of the federation capability is strongly 

dependent on the IdM governance, currently missing in NATO, so that centralized 

administration of I&AM will be capable to overcome a lot of ad hoc solutions on 

the present. The IdM governance must include rigidly defined processes, supported 

by appropriate regulations in the NATO policy. 

The approach for cross-organizational authentication and authorization solution, 

proposed in this paper, provides foundations for a technical implementation 

of federation capabilities in NATO NII. It is not meant to replace the main authentication 

mechanism, based on Kerberos, being in use in NATO systems currently. 

Federation solutions are only meant to enhance a local authentication mechanism 

in user’s governance realm in support of information sharing capability across 

network and organizational boundaries. 

This enhancement aspect (instead of replacement) is very important to properly 

understand how the federation capability should be utilized in NATO. In this 

context, it should be also noted that the authentication method used in a user 

“local” environment does not have any impact on the overall approach presented 

in this paper. Therefore, there is no contradiction between having the federation 

capability built-in the NATO systems core functionality package and for example 

the strong authentication capability required by the IA community through the Cyber 

Defence Action Plan [9]. 

It should be noted that the strong authentication capability in the NATO 

Enterprise is desired but insufficient to meet collaboration requirements in com-


375 

plex user and information assets environment. The federation capability adds user 

authentication provisioning functionality, utilizing component-to-component 

authentication with the use of asymmetric cryptography techniques (X.509 certificates) 

and therefore it should be considered as an integral part of the future NATO 

I&AM framework. 

Finally, there are two sides of the “information asset protection coin”, i.e. information 

asset “Access” and “Release”. Both are equally important in more challenging 

scenarios, like operations across security domains. In this paper, providing 

the full capability to address the “Access” to an information asset is addressed. 

This is what is expected from the colloquially understood Identity Management. 

At the moment the “Access” capability is in place, however, it becomes apparent that 

it is insufficient to support the conduct of operations in a complex collaboration 

environment, as the “Release” aspect of information assets has to be also covered. 

Therefore, research should also be directed into the challenges of information object 

tagging, normally provided through labelling mechanisms. 

References 

[1] NC3B, “The NATO Identity Management Framework”, EAPC(AC/322-SC/4) 

N(2009)0002, March 2009. 

[2] NC3B, “NATO Identity Management Strategic Plan”, AC/322-D(2010)0054, December 

2010. 

[3] NC3B, “Information Assurance Technical and Implementation Directive on Security 

Management Infrastructure (SMI)”, AC/322-D(2010)0055-AS1, January 2011. 

[4] ACO, “Alliance Operations and Missions (AOM) Federated Identity and Access 

Management (AIDAM) Capability Strategy”, 3800/SPTCIS/CFOISM/2011/94 

– TT280649, June 2011. 

[5] R. Malewicz, M. Lehmann, “A Coherent Approach Towards NATO-Wide Identity 

and Access Management Concept”, NC3A RD 3266, July, 2011. 

[6] R.B. Arkis, M.J. Diepstraten, “Operational View and System View for an Alliance 

Information Infrastructure at NATO Restricted Classification Level”, NC3A RD 2659, 

July 2008. 

[7] M. Lehmann, R. Malewicz, “Concept And Architecture For Identity Management 

Test Campaign”, NC3A RD 2909, December 2009. 

[8] Burton Group, “Federated Identity – Reference Architecture Decision Point”, 

G00206782, December 2010. 

[9] NATO Security Committee, “NATO Cyber Defence Action Plan”, AC/35-N(2011)0003, 

August 2011. 

[10] OASIS, “eXtensible Access Control Markup Language (XACML) Version 2.0”, February 

2005. 

[11] TSCP, “Identity Federation Assertion Profile v.1.2”, 27 March 2012.

Development of High Assurance Guards for NATO 

Konrad Wrona, Geir Hallingstad 

Cyber Defence and Assured Information Sharing, 

NATO Communications and Information Agency, The Hague, The Netherlands 

{Konrad.Wrona, Geir.Hallingstad}@ncia.nato.int 

Abstract: High assurance guards are central to the ability to exchange information between federated 

partners, both in the battlefield and between strategic commands. The guards play important role 

in development of the NATO Network Enabled Capability and the NATO Future Mission Network. 

In this paper we present current activities within NATO related to the development of High Assurance 

Automated Guards and discuss possible use cases, evolution, and underlying design principles. 

Keywords: high assurance design; information sharing; multi-domain security 


The effective and efficient conduct of modern joint military missions increasingly 

relies on network-centric operations. The NATO Network-Enabled Capability 

requires eliminating air-gap and swivel-chair solutions in a coalition environment. 

The Alliance Information Exchange Capability is an on-going set of activities within 

NATO, which focuses specifically on the information exchange across security 

boundaries. The objective of an Information Exchange Gateway (IEG) is to provide 

a solution for mediation of cross-domain information exchange. In particular, 

the so-called IEG Scenario D (IEG-D) focuses on information exchange between 

NATO and non-NATO partners involved in a mission. 

The High Assurance Automated Guard, or HAAG in short, is a critical element 

of the IEG in the scenarios involving connection from NATO systems to mission 

systems, so-called IEG Scenario C (IEG-C), and between NATO and non-NATO 

nations or international organizations (IEG-D). The HAAG is an interim solution 

on a path towards a fully integrated and distributed High Assurance Separation 

Service (HASS). The HAAG is a cross-domain gateway, which relies on the use 

of XML-based metadata describing content properties for making decisions about 

release of information. Its intended function is to enable automated information 

sharing between different information security domains and to provide a strong 

separation between different communities of interest and to support dynamic and 

flexible enforcement of need-to-know principles.


Information security domains can be implemented as both physically separated 

network domains or as virtual domains, using same network infrastructure 

and relying on cryptographic separation. Cryptographic separation means here 

encryption of all information belonging to particular information domain, making 

it inaccessible from other information security domains. In a simple scenario, which 

is analogous to the scenario addressed in [1], the guard separates two information 

security domains located in two physically separated network domains. In such 

scenario, one network enclave is typically denoted as high and the other as low. It is 

important to stress that in some of the HAAG usage scenarios the concepts of high 

and low information security domain may not mean high and low classification 

levels, as in many cases no order function can easily be defined between the classification 

levels (and thus information security domains) belonging to different 

organizations or nations. 

In a simple HAAG implementation scenario it can be further assumed that 

the guard is connected to the low and the high information security domains (and 

thus low and high network enclaves) using separate physical network interfaces. 

However, this limiting assumption will not be necessary true in a more general 

case, where the information security domains can be virtualized. 

The HAAG limits the data flow between information security domains through 

enforcement of mandatory security policies. These security policies include information 

flow control policy, access control policy, and information protection 

policy. The set of these security policies is collectively called as Content-based 

Protection and Release (CPR) policy [2]. The CPR policy is being currently specified 

at the NCIA as a part of 2012 Allied Command Transformation (ACT) Scientific 

Program of Work (SPoW). 

A cross-domain information exchange introduces two major threats to security 

of involved information security domains: (1) leakage of confidential information 

from one information security domain to another information security domain; 

and (2) degradation of the integrity or availability of resources in one information 

security domain as a result of actions originating from another information security 

domain. The purpose of the HAAG is to enable, together with other components 

in the IEG, an effective and efficient cross-domain information exchange, while 

offering sufficient protection against the threats mentioned above and enforcing 

an appropriate information flow control policy. 

II. Use cases 

Classical use cases for information sharing between NATO Secret systems 

and non-NATO partners and unclassified networks involve document and email 

release. The capability to reliably and timely share information across the security 

domains is one of the desirable operational requirement in the current NATO operations, 

e.g., need for information sharing between NATO forces and non-NATO


379 

nations including Government of the Islamic Republic of Afghanistan (GIRoA), 

as well as between NATO forces and international organizations such as the United 

Nations World Food Programme. 

These classical use cases are expected to constitute the main source of traffic 

mediated by the HAAG in the NATO Future Mission Networks (FMN) and 

of the NATO Network Enabled Capability (NNEC). However, future networks will 

also likely need to support real-time sharing of information between functional 

services running in different security domains. Two examples of such emerging 

use cases, i.e. cyber defence information exchange and civilian-military cooperation 

(CIMIC) in passive missile defence applications, are discussed in more 

details below. 

A. Cyber defence information exchange infrastructure 

Cyber defence is quickly becoming one of the critical tasks as the military 

operations rely more and more on capabilities provided by the Communications 

and Information Systems (CIS). Not only must the CIS be protected before going 

into operation but there must also be a capability to respond and recover from attacks 

targeting these systems during their operation. In federated environments, 

where no one has control over the entire system, collaboration between different 

parties is critical in order to ensure effective cyber defence. However, exchange 

of the relevant information is often sensitive, and requires careful control of release. 

At the same time relevant information from public sources should be automatically 

imported. 

Therefore, the cyber defence information exchange infrastructure (CDXI) 

must support both the ability to import information from public sources as well 

as partners, and also ability to selectively share information. This requires a strict 

control of boundary such as the one provided by the HAAG. Further, the ability 

to automatically release information based on the associated metadata is critical 

in order to support the strict timeliness requirements in cyber defence. An example 

of CDXI architecture is shown in Figure 1. 

As shown in the Figure 1, the control barrier is needed in order to ensure that 

only authorized data is shared, and that only quality assured information is imported 

into the organizational domain. As some of the data sources on the low side typically 

will be public sources, the assurance level of the control barrier must be high. 

The type of information exchanges can include vulnerability and exploit information, 

incidence information, as well as a number of other types of information 

that potentially could be very useful in federated incidence handling. The format 

of the information should allow automated processing, as manual processing is not 

time effective when trying to combat cyber-attacks. 

The actual format depends on the type of information, and a number of standardization 

efforts are currently underway to support such information sharing


formats, including the Incident Object Description Exchange Format (IODEF) [3], 

OVAL [4], as well as some open source formats such as Snort rules [5]. The HAAG 

may not need to understand all these formats – the only requirement is that they 

can be labelled using the signed NATO XML labelling format [6, 7]. The NATO 

XML labelling can be applied even in the case when the format itself is not XML, 

although XML formats would allow better granularity of release control and would 

allow the HAAG to automatically redact the information to be released. 

Figure 1. Cyber Defence Information Exchange Infrastructure 

Without the HAAG, the information sharing will be limited as it will be difficult 

to combine all sources in an effective manner. Public information would likely 

have to pass an air-gap, which is both labour intensive, slow, and introduces itself 

a number of security problems. 

B. Civilian-military collaboration in passive missile defence 

The passive ballistic missile defence (BMD) scenario is illustrated in Figure 2. 

The geographic coordinates of the predicted missile impact area are calculated by 

the BMD system located in the NATO Secret domain and shared in the Keyhole 

Markup Language (KML) format with a GIS system installed in the information 

system belonging to a civilian authority. Open Geospatial Consortium (OGC) 

KML [8] is used to display geographic data in GIS such as Google Earth. This 

information can be used for crises response planning and disaster preparation. 

As KML is XML-based, it can be easily integrated with the NATO XML-Labelling 

specification.


381 

Figure 2. Passive missile defence information exchange scenario 

III. Security requirements 

The security requirements introduced by the HAAG have been captured 

in a form of protection profile (PP) compliant with the Common Criteria (CC) 

Version 3.1 Release 3 framework [9]. This approach has been taken by the authors 

already earlier, when designing the medium assurance XML-Labelling Guard 

(XLG) [1]. 

Although the HAAG PP is based on the XLG PP, the HAAG introduces 

several new functional and assurance requirements when compared to the XLG. 

New functional security requirements are related, e.g., to need for authentication 

of originators or requestors of mediated information flows, in order to provide 

stronger accountability when compared to XLG. Other new security functional 

requirements are related to integration with the cyber defence framework and to 

use of more complex CPR security policies. 

When compared to [1], most of the new security assurance requirements 

(SARs) are related to the need to assure secure lifecycle for the HAAG. The approach 

taken in the HAAG PP in order to assure the trustworthiness of the HAAG throughout 

its lifecycle is largely compatible with the U.S. Government Protection Profile 

for Separation Kernels in Environments Requiring High Robustness (SKPP) [10]. 

The main conceptual difference is that SKPP focuses on operating system and does 

not address trustworthiness of the application software running on top of the operating 

system. The HAAG PP applies the paradigms adapted from the SKPP to 

the application layer. In the HAAG PP, the assumption is that underlying operating 

system can be trusted (e.g., because it was evaluated according to the SKPP) and 

the focus is on providing sufficient evidence that functionality implemented on top 

of the OS, i.e. the HAAG application, configuration and other TOE components, 

can be also trusted to a level commensurate with the value of protected resources. 

In addition to this conceptual difference, the formal differences are related mainly 

to the fact that SKPP v 1.03 was based on the CC v. 2.3 and the HAAG PP is based 

on the CC v. 3.1 R3. Some of the SARs, which were predefined in the CC v. 2.3 and 

used within the SKPP, were removed in the CC v. 3.1 [9].


IV. Evolutionary approach 

The phased approach has been proposed to implementation and deployment 

of the HAAG in order to address both urgent operational requirements and provide 

a robust and flexible solution to cross-domain information sharing for the NNEC 

and FMN infrastructure. 

The approach consists of 3 phases that incrementally improve information 

sharing capability. Phase 0 is a cascading design that provides an immediate response 

to the urgent requirements for information sharing between NATO and international 

organizations / non-NATO nations. Phase 1 uses the HAAG as a gateway 

that enforces authentication, authorization, and accountability of all end-users. 

Phase 2 uses the HAAG to provide a service where information is released based 

on security and protection requirements derived from a dynamic policy. 

A. Phase 0: Cascading design using XLG 

Phase 0 represents an incremental development path for the existing NCIA medium 

assurance XML-Labelling Guard (XLG). The proposed solution, applicability 

of which shall be confirmed case by case through an extensive security risk assessment, 

attempts to partially compensate lower security assurance level of the XLG 

by introducing an intermediate, NATO Restricted (NR), security domain between 

IO/NNN and the NATO Secret (NS) system. The XLG is located between the NR 

and the NS domain. Several reactive security services, such as intrusion detection 

and malware protection are redundantly deployed in the NR and NS domains 

in order to provide increased security assurance via a cascading architecture. 

Figure 3. Example of a cascading design for IEG-D Phase 0 implementation


383 

B. Phase 1: High assurance automated guard as a gateway 

A logical evolution of the Phase 0 design is to replace the cascade with a single 

high assurance guard used as a gateway, an architecture shown in Figure 4. 

Figure 4. High assurance automated guard (HAAG) as a gateway 

This architecture uses the HAAG as a dedicated information flow control 

device between the domain with a lower and a higher trustworthiness. In addition, 

the HAAG must be accompanied by, and usually collocated with, additional 

security tools, such as firewalls and malware detection software. 

Compared to the Phase 0 architecture, there are two important differences. First, 

the HAAG authenticates users from both low and high domains, whereas only network 

interfaces were authenticated in Phase 0. The authentication is mainly for auditing and 

accountability purposes, but can also constitute an input for an authorization of access 

to the data (e.g. basic enforcement of need-to-know principle). Second, the required 

assurance level for the HAAG design and implementation is significantly higher. 

Phase 1 improves the assurance and information flow capabilities in a short 

to medium time-frame. It relies on support for cross-domain authentication, e.g. 

by implementing a claims-based identity and access control [11]. This architecture 

allows also a gradual introduction of elements of the CPR security policies. The CPR 

security model is envisaged to replace in the long term an inflexible Bell-LaPadula 

security model, which is not suitable for a modern dynamic and federated coalition 

environment. 

C. Phase 2: High assurance automated guard as a separation service 

In Phase 2 of the HAAG development a more radical approach is taken toward 

solving the information sharing challenges. This approach is based on a complete 

rethinking of the security model used within NATO and utilizing implementation 

of advanced cryptographic mechanisms. In this architecture, depicted in Figure 5, 

the concept of security domains is abandoned, and the information flow is controlled 

through a HAAG service implemented in a distributed fashion.


Figure 5. HAAG as a separation service 

The HAAG service is responsible for enforcing access control based on advanced 

security policies, taking into account the properties of users (e.g. clearance 

level and his role in the organization), properties of devices (e.g. hardware cryptographic 

modules, trusted computing platform), and properties of the information 

(e.g. its validity time, sensitivity and area of application). 

In this phase, the traditional characterization of information through simple 

metadata (or so-called security label e.g. NATO Secret releasable to Australia), 

is replaced by a more detailed (and complex) metadata describing the information 

(e.g. logistic data relevant to transport of goods to Australian troops based 

in Afghanistan). Similarly, instead of being characterized only by a clearance level, 

the end-user would be characterized by metadata describing his role, affiliation, and 

trustworthiness. The terminal would also have to be characterized by additional 

metadata describing its trustworthiness, such as none, basic, normal, enhanced and 

high, instead of being just characterized by the network domain in which it is located. 

The required separation of information flows in Phase 2 can only be achieved 

by using advanced cryptography, including encryption of both data at rest and data 

in transfer. Recently, several relevant new cryptographic techniques have been 

developed, including homomorphic encryption enabling processing of encrypted 

data [12] and wild-carded identity-based encryption [13], potentially enabling 

encryption of data for groups of user, e.g., users playing the same role within organization, 

and effective key management. 

V. High level design 

One of the current activities coordinated by the NCIA is development of high 

level design (HLD) for the HAAG. The target of the HLD is Phase 1 and Phase 2 

of the HAAG as described in the previous section.


385 

The purpose of the HLD is twofold. First of all, the HLD shall enable evaluation 

of completeness and appropriateness of the functional and security capabilities 

of the HAAG by all stakeholders, i.e. NATO bodies, NATO nations, and prospect 

non-NATO partners in the information sharing scenarios to be supported by 

the HAAG. Secondly, the HLD is to be used as guidance for the industry during 

the implementation of the HAAG solution for NATO. 

During the design study several dependencies with information assurance 

services offered by the external components have been identified. The basic design 

of the HAAG substantially extends architecture and functionality implemented 

within the NCIA Medium Assurance XML-Labelling Guard (MAXLG) [1]. 

In order to ensure proper integration with the NATO infrastructure, the HLD 

is described in terms of the NATO Architecture Framework (NAF) version 3 [14]. 

The HLD describes a subset of various possible views defined in the NAF v.3, 

including Capability, Operational, Service Oriented, System, Technical, and Programme 

Views. 

A. System overview 

The design of the HAAG introduces five main concepts, as depicted in Figure 6: 

Figure 6. Design principles for the HAAG


1. An information object container, including meta-data describing content 

properties 

2. Set of security policies, including information flow policy and access control 

policy 

3. Cyber defence system, monitoring system and users’ activities and providing 

responsive security measures. 

4. Release decision and enforcement service, which is the central component 

for enforcing security requirements for exchange of information between 

different information security domains. It is a custom-developed software 

application that enforces the information flow control and the access control 

policies. 

5. End user interface, enabling end users or services to submit information 

access request to the HAAG. The request contains meta-data describing 

user’s and end terminal properties. 

B. Service-Oriented Architecture 

The HAAG design is based on a service oriented architecture. The main services 

included in the HAAG Target of Evaluation (TOE) as well as services required from 

the operational environment of the HAAG are depicted in Figure 7. 

Figure 7. HAAG service environment


387 

C. HAAG services 

The services described in this section belong to the HAAG TOE and are to 

be implemented and evaluated as a part of the HAAG development. The Content 

Inspection Policy Enforcement (CIPE) Service represents a special case, where 

the CIPE framework is a part of the TOE and the individual Content Filters constitute 

part of the Operational Environment. The rationale behind this division 

is the effort to reuse content filters developed and maintained by the third party 

providers, such as antivirus and malware scanners. 

1) HAAG Core Services 

The HAAG Core Services, describe below, provide core functionality 

of the HAAG. 

a) NATO Metadata Binding Service 

From the HAAG perspective, the most important service provided by 

the NATO Metadata Binding Service (NMBS) is the Bind Service. The Bind Service 

is responsible for verifying the binding between metadata and the data object. 

The HAAG relies on the Bind Service in order to validate integrity of the binding 

and thus ensure that the metadata can be safely used in decision process related to 

information release. The NMBS is also a required as an external service, enabling 

binding of metadata to information. 

b) Policy Reasoning and Rules Analysis Service 

The aim of Policy Reasoning and Rules Analysis Service is to perform logical 

reasoning about fulfilment of the requirements stated in the security policies. 

As the CPR policies can be potentially complex and involve semantically reach 

metadata, the proper reasoning process is critical for ensuring proper enforcement 

of security policies. 

c) CPR Information Flow Policy Enforcement Service 

The CPR Information Flow Policy (IFP) Enforcement Service ensures enforcement 

of the security policy governing the information release between the security 

domains mediated by the HAAG. This service make use of Policy Reasoning and 

Rules Analysis Service, takes a decision about potential release or denial of the release, 

and configures content filters and content sanitization rules which have to 

be applied prior to the release. 

d) Access Control Policy Enforcement Service 

The role of the Access Control Policy (ACP) Enforcement Service is similar 

to the CRP IFP Enforcement Service; however the ACP focuses on enforcement 

of the security policy governing the user’s access to the HAAG. This service uses


Policy Reasoning and Rules Analysis Service in order to make a decision about 

potential granting or denial of the access. 

2) Trusted Platform Services 

Several TOE services play a role in establishing the initial secure state for 

the TOE Security Functionality (TSF). After secure initialization, the TSF enforces 

the configured security policy. The non-TSF functions playing role in establishing 

the initial secure state of the TSF include Trusted Delivery, Trusted Load, Trusted 

Initialization, and Trusted Configuration. 

3) Content Inspection and Policy Enforcement (CIPE) 

Content Inspection Policy Enforcement (CIPE) is a capability that enables 

the inspection of structured data that is to be mediated by the HAAG. The goal 

is to identify and remove malicious software (such as viruses, network worms 

and Trojan horses) and active content, combined with a verification of file format 

type and a white list of allowed file formats. The CIPE capability is to be provided 

as a component of the HAAG in order to improve the protection for confidentiality, 

integrity and availability of NATO CIS against malicious software and active 

content that may be imported from other information systems. 

Figure 8. Relationship between the Content Inspection Policy Enforcement and the HAAG PP 

The CIPE capability is provided by the CIPE Service which is one of the components 

of the Information Exchange Architecture. The CIPE Service consists 

of the following components, which are illustrated in Figure 8: 

• Content Inspection Policy Enforcement Framework (CIPEF) 

• Content Filters for supported data format content types 

• Content Filter Rules for each content filter


389 

• Interfaces between the CIPEF and the content filters 

• Proxy Interfaces 

The main element of the CIPE Service included in the HAAG TOE is the CI- 

PEF. The CIPEF is responsible for the management and scheduling of data objects 

as they are routed through the content filters. The route through the content filters 

depends on the identified data object(s) and any embedded data objects and is adjusted 

dynamically. The CIPEF provides interfaces for data objects to be input into 

the CIPEF and output from the CIPEF. Any suspect, malicious or unsupported 

data objects are quarantined for further investigation and appropriate authorised 

handling. 

The Identification, Verification and Transformation capabilities are implemented 

in CIPE Service by means of the Content Filters. The Content Filters constitute 

a part of the HAAG operational environment and are discussed in section 

dealing with external supporting services. 

A Proxy Interface is the boundary between the CIPE Service and the HAAG and 

can handle protocol and content mediation between the data source and the CIPEF. 

4) Local Security Policy Repository Service 

The Local Security Policy Repository Service provides access to all security 

policies, which are enforced within the HAAG. It provides a management interface 

enabling configuration of the policies, including possible synchronization with 

centralized security policy repository. The policies stored within the local repository 

include both IFP enforced by the HAAG on the mediated data and an access 

control policy for the HAAG users. The IFP is provided by so-called Content-based 

Protection and Release Policy (CPR). The CPR policy consists of two specific policies: 

Content-based Protection Policy and Content-based Release Policy. The Contentbased 

Protection Policy defines the technical protection measures, which have to 

be enforced by the user’s operational environment (i.e. network and user’s host) 

in order for the information to be securely released. The Content-based Release 

Policy defines the required user’s attributes, such as security clearance and associated 

security domain for allowing an information release. 

D. External Supporting Services 

This section briefly introduces the services, which are provided by the operational 

environment in support of the HAAG capability. These services are not part 

of the HAAG target of evaluation, and as such their assurance level and functionality 

will not be evaluated during the HAAG evaluation. However, it is recommended 

that their implementation should provide a level of assurance equal or higher to 

the level provided by the HAAG.


1) Security Management Infrastructure and Information Assurance 

Services 

The NATO security management infrastructure (SMI) services and information 

assurance (IA) services are described in [15] as depicted in Figure 9. 

Figure 9. NATO security management infrastructure services and information 

assurance services as defined in [15] 

Both types of services typically require the use of the other for their own functionality. 

A security management service might use an IA service to ensure the secure 

handling of its own information, e.g. the Digital Policy Management Service 

might use a confidentiality service and an integrity service to secure the renewal 

of policy for system-wide access rights (its own function). An IA service might 

rely on a security management service for proper continuation of its own function, 

e.g. a confidentiality service might use the Crypto Key Management Service 

for policy-mandated periodic keying material changes. 

The Identity Management and Credential Management Services rely on 

the NATO Public Key Infrastructure (NPKI) [16]. The exchange of the relevant 

PKI information between NATO and Nations during NATO operations and missions 

is discussed in [17]. 

2) Secure Transport Layer Services 

Secure transport layer services might be required in some scenarios to provide 

a secure (i.e. cryptographically protected) communication channel between the user 

and the HAAG. A typical example of scenario where such channel is required 

is remote management of the HAAG. However, also in the case of end-users using 

the HAAG for data transfer, a secure communication channel might be required 

in order to both protect privacy of the end user and provide additional layer 

of confidentiality and integrity protection for the exchanged information. The use


391 

of the secure transport layer services can also provide additional protection for 

availability of the HAAG by introducing additional controls for allowed connections 

and resource consumption. 

3) Cryptographic Services 

The main Cryptographic Services required by the HAAG are related to integrity 

protection and authentication. The public key encryption module provides 

functionality required to verify digital signatures of the XML security labels. This 

functionality includes implementation of appropriate public-key cryptographic 

algorithms, hash functions, and certificate validation mechanisms. It can be also 

used in order to provide PKI-based authentication of the HAAG users. 

Additional Cryptographic Services might be required for authentication 

of the users and securing the communication channel between the HAAG and 

the user (if applicable). These additional cryptographic services include message authentication 

codes (e.g. keyed hash function) and symmetric encryption algorithms. 

4) Cyber defence component 

In order to provide an adequate security and assurance level for information 

exchange between security domains, the HAAG relies on preventive and reactive 

services provided by the NATO cyber defence infrastructure. The NATO Cyber 

Defence Services of particular relevance to the HAAG include monitoring, data 

fusion, dynamic risk assessment and alert generation. 

The feedback from the Cyber Defence Services can be used to influence and 

reconfigure the security policies enforced by the HAAG. The possibility of dynamic 

update of system security policy based on the identified threat level has been 

studied in [18]. In [19] an approach for integration of alerts, generated based on 

information received from various cyber sensors, with contextual security policies 

has been investigated. The alerts, received in the Intrusion Detection Message 

Exchange Format (IDMEF) [20], are mapped to contexts and response strategies 

involving changes to the enforced security policy. 

5) CIPE Content Filters 

The CIPE Content Filters are separate modules of the CIPE architecture, which 

can be provided by the third party. As opposed to the CIPE Framework, which 

is part of the HAAG TOE, the Content Filters are therefore treated as external 

services provided by the HAAG Operating Environment. 

The CIPE Service provides for separation of the CIPEF from the Content 

Filters. The Content Filters, the only CIPE Service component that directly handles 

the contents of a data object, must be separated and managed outside of the other 

components of the CIPE Service due to the potential threats and vulnerabilities 

that may be exposed by the handling of data objects. The CIPEF communicates 

with the Content Filters via the Content Filter Interface.


Within the CIPE Service each individual Content Filter is explicitly identifiable 

by its type. A Content Filter may be of an Identification, Verification or Transformation 

type, or any combination of the three: 

1. Identification Content Filter is responsible for correct identification 

of the type(s) of a data object. 

2. Verification Content Filter is responsible for enforcing that the data object 

conforms to the claimed type and that no malicious or confidential content 

is present in the data object. This Content Filter also performs as a content 

exploder and a content flattener for data objects which contain embedded 

data object(s). 

3. Transformation Content Filter is responsible for mitigating the potential 

threat of malicious content by either removing the active content that 

was found by the Verification Filter, or by transforming the content to another 

format. This Content Filter can also transform content by obfuscating 

or removing data attributes or values that should not be released across 

the information system boundary. 

The types of data formats that are allowed for import or release across the HAAG 

are specific to a CIPE Profile. Each data format type has its own set of Content Filter 

Rules. A set of Content Filter Rules represents a subset of the CIPE Profile security 

and assurance requirements specified for a given data format type. The Content 

Filter Rules are asserted by the Content Filter(s). 

E. Trusted Base Platform 

Trusted Base Platform consists of the operating system (OS) kernel, the tools 

and applications, which are part of the OS, and the hardware, on which the OS runs. 

Security requirements related to user roles and user authentication are implemented 

in the OS. The base OS and hardware also provide the isolation of the security 

components from other components of the HAAG. 


The development of the high level design and the protection profile for 

the HAAG is the first step on a path to achieve effective information sharing between 

NATO and its external partners. 

One of the important aspects of the future work is the development of a formal 

model for the CPR security policies. We are aiming at specifying a basic CPR policy 

in a natural language, translating it into a formal representation and validating 

it using some well-known tools, such as Isabelle [21]. 

The recently established the NATO Science and Technology Organization 

(STO) Information Systems Technology (IST) Task Group on Trusted Information 

Sharing for Partnerships (IST-114) aims at advancing the IEG Scenario D


393 

and the Object Level Protection concepts. The focus of the group includes high 

assurance guards, as well as extensions to the existing security labelling specifications. 

The results of IST-114 can potentially influence the requirements and design 

of the HAAG. 


This research has been sponsored by the NATO Allied Command Transformation 

Scientific Programme of Work 2011/2012. 

References 

[1] K. Wrona, S. Oudkerk, and G. Hallingstad, “Designing medium assurance 

XML-labelling guards for NATO,” in Proceedings of the Military Communications 

Conference (MILCOM), San Jose, CA, USA, 2010. 

[2] K. Wrona and G. Hallingstad, “Controlled Information Sharing in NATO 

Operations,” in Proceedings of the IEEE Military Communications Conference 

(MILCOM), Baltimore, 2011. 

[3] R. Danyliw, J. Meijer, and Y. Demchenko, “The Incident Object Description 

Exchange Format,” Request for Comments RFC 5070, 2007. 

[4] J. Baker, M. Hansbury, and D. Haynes, “The OVAL Language Specification Version 

5.10.1,” The MITRE Corporation, 2012. 

[5] L. Ward, “Improving your custom Snort rules,” Sourcefire, 2010. 

[6] S. Oudkerk, “NATO Profile for the ‘Binding of Metadata to Data Objects’ – version 1.0,” 

The Hague, Technical Note TN-1455, 2011. 

[7] S. Oudkerk, “NATO Profile for the ‘XML Confidentiality Label Syntax’ – version 

1.0,” The Hague, Technical Note TN-1456, 2011. 

[8] T. Wilson, “OGC KML Version 2.2.0,” Open Geospatial Consortium Inc., OGC 

Standard OGC 07-147r2, 2008. 

[9] Common Criteria, “Common Criteria for Information Technology Security Evaluation 

Version 3.1 Revision 3,” CCMB-2009-07-001, 2009. 

[10] IAD, “U.S. Government Protection Profile for Separation Kernels in Environments 

Requiring High Robustness, Version 1.03,” 2007. 

[11] D. Baier et al., A Guide to Claims-Based Identity and Access Control – Authentication 

and Authorization for Services and the Web.: Microsoft Corporation, 2010. 

[12] Nigel P. Smart and Frederik Vercauteren, “Fully Homomorphic Encryption with 

Relatively Small Key and Ciphertext Sizes,” in Public Key Cryptography, 2010, 

pp. 420-443. 

[13] M. Abdalla et al., “Wildcarded Identity-Based Encryption,” Journal of Cryptology, 

vol. 24, no. 1, pp. 42-82, 2011. 

[14] NC3B, “NATO Architecture Framework v3,” Brussels, Belgium, ANNEX 1 TO 

AC/322-D(2007)0048, 2007.


[15] NC3B SC/4, “Information Assurance Technical and Implementation Directive on 

Security Management Infrastructure (SMI),” AC/322(SC/4)WP(2010)0008, 2010. 

[16] NAC, “NATO Policy for the Implementation of a PKI for NATO Communication 

and Information Systems,” Brussels, Belgium, AC/322-D(2003)005, 2003. 

[17] NAC, “Directive for NATO Public Key Infrastructure (NPKI) Interoperability with 

the Nations,” Brussels, Belgium, AC/322-D(2005)0025-REV1, 2010. 

[18] K. Wrona, G. Hallingstad, and S. Oudkerk, “Risk-aware and policy-compliant 

approach to network configuration,” in Proceedings of the 12th Military Communications 

and Information Systems Conference (MCC), Wroclaw, Poland, 2010. 

[19] H. Debar, Y. Thomas, N. Boulahia-Cuppens, and F. Cuppens, “Using Contextual 

Security Policies for Threat Response,” in Proceedings of the DIMVA, vol. LNCS 4064, 

2006, pp. 109-128. 

[20] H. Debar, D. Curry, and B. Feinstein, “The Intrusion Detection Message Exchange 

Format (IDMEF),” IETF, RFC 4765, 2007. 

[21] T. Nipkow, L. Paulson, and M. Wenzel, A Proof Assistant for Higher-Order Logic.: 

Springer-Verlag, 2011.

Network Traffic Characteristics 

for Detecting Future Botnets 

Jonathan P. Chapman 1 , Felix Govaers 2 

1 Elmar Gerhards-Padilla, Research Group Cyber Defense, Fraunhofer FKIE, 

Friedrich-Ebert-Allee 144, 53113 Bonn, Germany, chapman@cs.uni-bonn.de 

2 Department for Sensor Data and Information Fusion, Fraunhofer FKIE, 

Neuenahrer Str. 20, 53343 Wachtberg, Germany, felix.govaers@fkie.fraunhofer.de 

Abstract: Botnets are and are likely to remain the main vehicle for online crime for the foreseeable future. 

To protect their business models, botnet operators constantly improve their protocols and 

applications to harden them against detection, analysis and takedown efforts. Our analysis suggest 

that future botnets will use proper encryption for their protocol messages, rendering them invisible 

to most deployed network intrusion detection systems. Therefore, we identify properties of botnet 

communications that will not be obscured by these measures. This allows us to design features which 

can be derived by measuring these properties and used as input to an approach for detecting systems infected 

with a botnet client. First measurements on network traffic generated by legitimate applications 

and a botnet client suggest that our features are capable of reliably discriminating between the two. 

Keywords: botnet; intrusion detection; netflow 


Over recent years, botnets have reached an increasing degree of attention 

of both general and academic public. Their versatility proved to be an enabler for 

a wide range of criminal business models ranging from spam delivery to phishing, 

blackmail and espionage, triggering counteractions by those operating networks 

or responsible for securing information infrastructures. Since infected machines 

participating in botnets are often owned by a large and diverse group of individuals 

and organisations, scattered over a large number of jurisdictions, their efforts were 

often focused on denying the operator control over its botnet, usually by shutting 

down their command and control servers [1]. 

Early botnets relied on simple centralised mechanisms for command and control, 

such as an IRC channel that botnet clients would join, rendering the technical 

part of shutting a botnet down rather simple. However, botnet operators learned 

that losing control over their botnets would prevent them from executing their 

business models. Thus, we are observing a constant evolution of their protocols 

and methods, trying to complicate detection, mitigation and takedown efforts.


In this paper, we identify cornerstones of the protocol design for future botnets. 

Besides using peer-to-peer-based mechanisms to avoid a single point of failure, they 

will employ cryptographic methods that are also used in many legitimate applications. 

Particularly, their command and control channel will use strong encryption 

and integrity checks to prevent reading or altering messages in transit and authentication 

for commands and updates. As a side effect, messages will no longer be 

available to network intrusion detection systems that rely on deep packet inspection, 

i.e. analyse packet payloads to detect the presence of malicious applications. Since 

this is the main mode of operation for most deployed network intrusion detection 

systems, we also analyse which properties cannot be obscured by these methods and 

explore how they can be used to achieve botnet detection in the future. 

The rest of this paper is organised as follows. In section II, we provide the definitions 

for netflows and botnets as a base for the following elaboration. The next 

section briefly discusses related approaches, followed by our analysis of future botnet 

designs in section IV. Section V provides the background for the detection of botnets 

by measuring features described in section VI. We then briefly summarise the host 

models required for our projected approach and provide measurement results for 

the named features. In sections IX and X, we provide an outlook on future work 

and summarise the conclusions derived in this paper. 


A. Netflows 

Typically, network protocols are developed following the OSI layer model, 

encapsulating higher level protocols in the payload section of the next lower layer’s 

protocol. In inter-networking, OSI layers 3 and 4 are of particular concern, where 

the former is responsible for transferring data between hosts in different networks 

and the latter provides services such as error correction or packet reordering to 

applications on those hosts. Nowadays, the only wide-spread implementations for 

layer 3 are the IP protocol versions 4 and and 6 (IPv4 and IPv6, respectively) and 

layer 4 is dominated by the TCP and UDP protocols. 

Applications using the latter protocols are identified by a 16 bit integer (or port), 

i.e. a tuple (IP address, type, port) identifies an endpoint that a particular application 

instance on a particular host may send or receive data at. Given two applications 

A and B communicating through a network, the conversation can be identified 

by a combined tuple (IP A , port A , type, port B , IP B ). Such a conversation is called 

a “netflow” or a flow for short. 

B. Botnets 

For the purpose of this paper, we define a botnet as a malware with access 

to a command and control (C 2 ) channel allowing a group or an individual to is-


397 

sue commands to an infected system. While such a channel could use a different 

medium in theory, we further narrow this definition down to such botnets where 

the C 2 channel is implemented using the Internet or a similar wide area network. 

This is the case for all botnets deployed for commercial purposes and, while apparently 

designed to bridge an air-gapped system, even the Stuxnet malware provided 

an Internet-based C 2 channel [2]. We will use the term bot herder when referring 

to the group or individual controlling a botnet, without any further implications 

on how or why the herder acquired control over the botnet. 

III. Related literature 

Detecting botnets can be considered a special case of network-based intrusion 

detection. The most prominent examples in that field are Bro, first presented 

in [3], and Snort [4]. While allowing different levels of complexity for defining 

signatures, both are focused on discovering known malicious packet payloads 

described by the user. To some extent, an administrator with deep insight into 

the environment and applications she or he supervises may define signatures that 

describe abusive behaviour but generally this technique can only be used when 

the payload generated by a particular piece of malicious software is known to 

the user. [5] alleviates this requirement by introducing a system that is able to 

generate signatures from malware communication patterns learned from repeatedly 

executing a sample in a secure environment. However, in order to be able to 

generate a signature, an infection has to be detected and a sample of the malware 

be obtained first. 

Gu et al. follow a different approach [6], collecting data for each system in two 

domains, one for netflow data and another one for malicious activities. They then 

cluster data in each of these domains individually and treat co-occurrences of hosts 

in activity and netflow clusters as an indicator for those hosts being part of a botnet. 

While this eliminates the requirement for obtaining a sample for a malware, obtaining 

data for malicious activity requires the ability to detect such activity. I.e. while 

their approach shifts the focus, it will still work only when the attacks a botnet will 

carry out have been analysed and described appropriately before. 

The authors of [7] introduce an approach which measures several features 

for each observed flow. Based on their assumption that these features are normally 

distributed, they are able to assign an anomaly score to a measurement and visualise 

the expectation and actual measurement for a system. In contrast to the approaches 

described above, this does not require any knowledge of a malware that 

should be detected, but requires that both the distribution for an observed feature 

is Gaussian and that it will be affected by the malware’s traffic. Thus, feature selection 

is a critical element, as underlined by the author’s statement that for features 

with a distribution not fit well by a Gaussian curve, the accuracy of their approach 

was not satisfying.


At this point, we want to leave the field of traditional intrusion detection 

and take a look at a small set of approaches from the field of traffic classification. 

The first is BLINC [8], which tries to infer the applications running on a particular 

host only from basic properties of netflows, describing the behaviour of applications 

with graphlets. These graphs describe for a specific IP address the volume 

of destination IP addresses, source and destination ports and transport protocol 

expected for a given type of application. Graphlets can also be combined to characterise 

a host running several applications at the same time. While the authors 

present examples for some attacks, they do not provide general models for malicious 

activities. Also, often the graphlets provided refer to a coarse class of application 

rather than a specific protocol, indicating that the feature set may be too small to 

provide more accurate discrimination. 

Bernaille et al. [9] demonstrated that with only considering the size and direction 

of the first few packets of a flow with application payload, you can achieve 

a significant level of accuracy with regard to which protocol the flow’s payload 

belongs to. A similar approach by Crotti et al. [10] uses a superset of features that 

do not require access to the payload and are aggregated for a complete flow to 

reliably assign one of four classes, including an “other” class, to a particular flow. 

They later extended their method to detect tunnelling through other protocols [11]. 

Instead of manually designed application signatures, these approaches rely on 

correctly preclassified training sets that allow them to determine the distribution 

functions of the observed features for each of the applications they are designed 

to discriminate. 

The selection of features to observe is a critical part in some of the above but 

also our own approach. An essential part of identifying the most promising features 

is to analyse the behaviour of the applications we want to detect and how it will 

differ from other applications. Thus, our starting point is the bot herder’s intent 

of hiding and securing their botnets’ C 2 channel and we explore the design which 

is likely to emerge from this intent in section IV. This, together with an analysis 

of the relation between observations on the network layer and the application that 

generated it in section V, provides a background for identifying the features we 

want to observe for detecting future botnets. 

IV. Future botnets 

Bot herders generally aim for improving the resilience of their botnets against 

takedown, takeover and detection efforts. Thus, we expect more sophisticated approaches 

for protection and obfuscation, in particular in regard to the C 2 channel. 

These approaches may include measures in the three domains we discuss in this 

section, custom protocols or protocol implementations (section IV.A), steganography 

and cryptography (sections IV.B and IV.C and, respectively). Section IV.D 

summarises the conclusions implied by our analysis.


399 

A. Custom network or transport layer implementations 

Bot herders may and have in fact already written their own implementations 

for network or transport layer protocols (cf. e.g. [12]) to avoid detection. 

Since packets sent by these implementations have to traverse networks consisting 

mostly or only of non-infected systems, the design space for these implementations 

is however strongly limited. With IPv4 and IPv6 dominating wide area networking, 

a layer 3 implementation has to be compatible with these protocols, where IPv4 

is predominant in most regions and end-user systems are often not configured to 

permit using IPv6 in a second stack. 

This comes with a second side-effect, a non-representative study [13] revealed 

that 90% of a large European carrier’s DSL users were connected to the Internet via 

a NAT gateway. NAT rewrites transport layer headers to provide Internet access 

for several hosts which have to share a single public IPv4 address. Thus, unless 

a bot herder considers the inability of a significant portion of potential clients 

to access the C 2 channel acceptable, a custom transport layer protocol has to 

survive forward and backward translation by a NAT gateway. Effectively, this 

leaves little options other than tweaking the TCP or UDP protocols at this time. 

In fact, the malware described in [12] used a standard-conform implementation 

of the TCP protocol only to bypass firewalls and intrusion detection mechanisms 

installed on the infected host. 

A manipulation not yet addressed above is the spoofing of layer 3 addresses. 

Spoofing destination addresses makes little sense unless the sender does not care 

whether the recipient will actually receive a packet or can ensure that the intended 

destination can be reached through a given address – which would however no 

longer meet our understanding of the term “spoofed”. Spoofed source addresses 

have on the other hand been observed in the wild and may actually hinder attribution 

efforts. However, the analysis presented in [14], the only wide-scale effort to 

detect filtering of spoofed addresses we are aware of, concluded that only about one 

quarter of the autonomous systems observed in 2005 were vulnerable to spoofing. 

Thus, relying solely on a communication mechanism that uses spoofed addresses 

may again deny a bot herder access to a significant fraction of its infected systems. 

In addition to that, when an infected system is behind a NAT gateway, the gateway 

will simply follow its mode of operation and translate the packet, writing the legitimate 

address to the packet sent through the wide area network. 

B. Steganography 

Steganography is the art of hiding communication channels. Since the observation 

of C 2 channels is a prominent part of detection and takedown efforts, 

a bot herder may be tempted to use techniques developed in this field to hide 

its botnet’s C 2 channel. Approaches such as the one described in [15] use fields


in the IP header that are left unchanged by intermediate systems to hide a few, 28 

in the named approach, bits in otherwise legitimate IP packets. Similar approaches 

are conceivable for transport layer protocols, but we do not expect these to provide 

a significantly larger count of bits per packet. 

For IPv4 or TCP, the header length can be adjusted to allow adding additional 

options. In principle, a bot herder could use the extra space obtainable by adjusting 

the length field to increase the bandwidth of a steganographic approach. This 

highlights however an issue which also appears, though with a different nature, 

in the approach described in the previous paragraph. The use of additional options 

is very rare for both TCP and IPv4, i.e. while the attacker is free to choose 

an unsuspicious payload, using oversized headers may attract even more attention 

than simply transferring the steganographic payload in the application layer section 

of the packet. For the approaches that do not inflate the size of the header, the minuscule 

steganographic payload will require that a significant number of packets 

is transferred for any significant botnet protocol payload. Thus, differences in communication 

patterns may again be similarly or even more striking than without 

such an attempt to obfuscate the C 2 channel using these techniques. 

C. Use of cryptography 

Cryptographic protocols are designed to provide three core properties: 

• Confidentiality 

• Integrity 

• Authenticity 

Confidentiality ensures that messages cannot be read in transit. Integrity allows 

a peer to verify that messages have not been modified in transit and authenticity 

provides proof of identification or approval by a verified entity. 

The Storm botnet employed a custom encryption algorithm, its supposed 

successor, the Waledac botnet, the standardised AES algorithm but both implementations 

employed static keys [16]. When a static key is used, a network intrusion 

detection system may either decrypt an observed payload with the known 

key and then apply its pattern matching algorithm or sometimes it may even be 

enough to match on the encrypted message. 

Duqu could be considered an example for correct use of cryptography 

in that it can connect to its C 2 server through a legitimate HTTPS connection, 

however the C 2 server uses a frequently replaced self-signed certificate, rendering 

the connection subject to man-in-the-middle attacks. This appears to be 

acceptable from the malware author’s point of view since the actual payload 

is encrypted with a symmetric key stored in its binary, illustrated also by that 

a second method for establishing a C 2 channel exchanges the same data but 

using plain HTTP [17].


401 

Finally, bot herders can use digital signatures on updates and C 2 messages 

to ensure that only the owner of a specific private key, i.e. the bot herder itself, 

can assert control or roll out applications in the botnet. Without authentication, 

an attacker with an understanding of the botnet’s protocol may issue commands 

or roll out updates on a bot, e.g. to install a software it would otherwise have to pay 

the bot herder to run on infected machines, thwarting the bot herder’s business 

model. Authenticated messages and/or updates have are used by several botnets 

at this time, including Duqu, but also Sality [18] or Miner [19]. 

D. Conclusions 

Our analysis suggests that while changes to protocols below the application 

layer are labour intensive, they provide little potential for benefit to a bot herder 

with regard to avoiding network intrusion detection. Steganographic approaches 

that require changes in these layers suffer from the same drawback given that obfuscation 

in one domain results in anomalies in a different domain and are thus 

equally unlikely to prevail. We do however expect steganography in the sense that 

botnet protocol messages will resemble or be encapsulated in legitimate protocol 

messages. This is already the case with both Miner and Duqu, which encapsulate 

their messages in an apparent HTTP-session. 

Cryptography will play a major role in both rendering a botnet’s traffic invisible 

and asserting the bot herder’s control over it. Most botnets we are aware 

of encrypt their protocol messages, obstructing payload based network intrusion 

detection, and at least some use digital signatures to prevent unauthorised access 

to their command and control channels. Concepts and implementations however 

display weaknesses that reduce the effectiveness of these safeguards. Symmetric 

encryption often uses custom algorithms and fixed shared keys without any initialisation 

vector instead of generating session keys. While the RSA algorithm 

often used for generating signatures is considered secure, implementation details 

such as key lengths, selected hash functions or data to authenticate limit their 

effectiveness. 

We can only guess why malware authors prefer custom but often imperfect 

designs over standardised approaches, but botnet operators have proven that they 

are capable of evolving their designs, particularly when their botnet’s vulnerabilities 

have been exploited to interfere with their businesses. Thus, botnets will not only 

increasingly rely on tunnelling all of their C 2 traffic through legitimate protocols such 

as HTTP and HTTPS, but will also make a better use of cryptography. The payload 

of packets transmitted or received by these botnet clients will therefore no longer 

carry any features that could be exploited for deep packet inspection, motivating 

a need for approaches that can detect botnet communication without relying on 

any immediate properties of the payload.


V. Network layer observation of future botnets 

In this section, we analyse the properties that will remain observable given 

the expected design of future botnets discussed in section IV. We start with describing 

the properties that remain directly observable in section V.A, followed by 

an analysis of how the behaviour of applications correlates with them. Finally, we 

motivate a granularity below traditional netflows as the base for further analysis 

and ultimately detection in section V.C. 

A. Observable features 

While OSI layer 2 is persistent in local networks only, i.e. its header does not 

contain any information written by the source of a layer 3 packet unless the point 

of observation is within the very same local network, we can learn the size of its 

payload and the observation time from it. The former will be equal to the size 

of the layer 3 packet transmitted by the source unless layer 3 fragmentation occurs. 

We suggest however to disregard this special case and treat fragments of a packet 

as if they were individual packets sent with the observed size. 

For the latter, i.e. the observation time, a simple relation to the timestamp t source 

at which an observed packet was transmitted by the source holds. With m denoting 

the mean time needed for traversing the links until reaching the observation point 

and j the jitter introduced by differences in network load and routes, we can characterise 

an observation timestamp t as: 

t = t source + m + j 

Thus, while we cannot determine t source exactly without knowing m and j, we 

can infer that the delay between two consecutive observations differs from the delay 

at the source only by the differences of the jitter applied to these observations. I.e. 

the smaller j in the equation given above, the better we can approximate that delay 

by observing the delay at our observation point. 

Based on the analysis provided in section IV, we assume that headers at layer 3 

and 4 will generally be genuine, but at least allow associating observed packets with 

a particular flow. Note that forged source addresses, where possible, may serve to 

complicate attribution but would not impede with gathering and attributing data 

for the destination system. 

Our analysis further suggests that while OSI layer 5 and up data may be available 

technically, it will not contain exploitable features due to the combination 

of proper encryption and tunnelling through legitimate protocols. Note that with 

what we would call “not proper encryption”, using payload signatures may still be 

possible, as pointed out in [5].


403 

B. Relations between application behaviour and observations 

on the network layer 

Typically, when a server application receives a request from a system running 

a client application, it processes the request, generates the answer and then transmits 

it to the client. Generating and transmitting an answer can be interleaved or 

executed in parallel. Thus, when an application generates data at the same speed or 

a higher speed than the capacity of the link that must be traversed when sending 

the data through the network, the respective packets will be as large as possible and 

emitted at a constant rate, i.e. the maximum rate permitted b y that link. 

On the other extreme end, an application may need considerably more time 

to generate a particular chunk of data than for transmitting it through the network. 

Therefore, a delay occurs between a request and the transmission of the answer. 

Finally, an application generating a fixed amount of data in each timestep, such 

as a voice over IP application, can be considered a special case of the latter type 

of application. We suggest however to consider this a class of behaviour on its own, 

leaving us with a total of three classes of observable behaviour: 

• Data transfer 

• Computationally expensive/varying data rate 

• Constant bitrate 

Figure 1 visualises the network layer observation of these features. Each box 

refers to a packet sent by an application, where the size of a box corresponds to 

the size of the respective packet and white spaces between boxes indicate that no data 

was sent by the application in the respective time frame. In this example, the first five 

packets fall into the data transfer class, saturating each except the very last packet. 

Following that, five packets are generated by a mechanism which generates data at 

a varying rate, observable through the variation of packet sizes and inter-arrivaltimes. 

Finally, the last five packets in figure 1 are generated at a constant rate and 

carry the same amount of payload. 

Time → 

Application behaviour 

Data transfer Computationally expensive answer Constant rate 

Figure 1. Packets observed for different kinds of application behaviour. Wider boxes indicate 

larger packet size, requiring more time for transmission 

While the varying data rate mode can easily be identified since it will result 

in a large variance of either packet sizes, inter-arrival-times or both, the other two 

classes will both result in a small variance for each of these properties. Thus, to 

be able to distinguish between them, we have to introduce a third metric. Such 

a metric should relate to properties of the link traversed in order to reveal whether


it appears to be saturated, indicating a data transfer, or not, implying that data 

is being generated at a constant rate. 

We suggest estimating the maximum size of a packet for the respective 

link, e.g. by observing maximum packet sizes for flows between two systems, and 

check whether the mean packet size of a given flow converges towards it. This 

would indicate saturated packets as we expect to observe for a data transfer. While 

estimating the maximum capacity available to the flow for each attached system 

would be another valid metric, mismeasurements may occur due to several reasons. 

First, a system may communicate outside our field of view, i.e. its network connection 

may be saturated but we may not be able to observe that. Secondly, even 

though the effect may be questioned, many applications introduce rate limiting to 

improve quality of service, thus the observed flow could fail to saturate a correct 

estimate for the capacity of each system's network connection even when we are 

able to observe all flows for both systems. 

C. Multiple types of behaviour in a single flow 

The behaviour described in the previous section will provide a classification 

into data transfer, fixed rate data and varying rate data for a single direction 

of a network flow. Obviously, a flow, including a single direction of a flow, may carry 

data generated through different kinds of mechanisms. Consider e.g. an HTTPS 

connection where the first packets are used to establish a shared secret key, i.e. by 

a computationally expensive mechanism generating data at varying rates, followed 

by a or even several data transfers when HTTP pipelining is used. Thus, using 

a single label for the whole flow may misrepresent the nature of the flow. 

To correctly represent the nature of such flows, we introduce the notion of a subflow, 

i.e. a portion of a single direction of a netflow that fits into one of the above 

categories. We explicitly allow two succeeding subflows to belong to the same 

category, given that their nature changes in a way suggesting they were generated 

by a different mechanism or another instantiation of the same mechanism. This 

would apply for instance to the HTTP pipelining case mentioned above, where 

a time gap between two file transfers occurs, caused by the client-server interaction 

and the need for additional processing by the server for providing the second file. 

VI. Observations for botnet detection 

We want to exploit features that can be observed or derived from observations 

described in section V. Since the described feature space is very limited and reveals 

only basic properties of the communicating applications, we cannot expect a single 

observable feature to reveal the presence of a botnet client, nor do we expect that 

a single observation for a given feature will provide sufficient evidence for such 

a conclusion.


405 

To sidestep this issue, we want to employ statistical methods developed 

in the field of sensor data fusion for analysing measurements from physical sensors. 

These methods require that we can not only define features that we expect to 

distinguish botnet traffic from other traffic, but also that we are able to describe 

and formalise the difference between the two. In this section, we describe three 

features that both provide evidence of botnet activity and can be described in regard 

to how the presence of a botnet client will affect the measurement for a given 

system. We expect that this list is not exhaustive, i.e. additional features exist which 

have the desired properties and can be used to discriminate between benign and 

infected systems. Identifying these will be part of our future work. 

First, we introduce a feature based on measuring the delay between two 

consecutive flows supposedly initiated by the same application. Following that, we 

discuss the failed flow count as an indicator for peer-to-peer based botnets in section 

VI.B and finally we describe how to interpret the volume of bytes transferred 

in a flow for our purposes in section VI.C. 

A. Inter-flow-initiation delay 

A given type of client application usually interacts with another class of applications, 

using an appropriate transport layer protocol. Typically, the latter application 

would be called the server counterpart for the application but may be 

identical in the case of peer-to-peer applications. Internet traffic is dominated by 

standardised protocols many of which use a registered TCP or UDP port for their 

server application. Thus, a given application usually interacts with servers listening 

on the same port. When adding the assumption that a system usually runs only one 

application for a given protocol, this becomes “two flow initiations with a given 

destination port and originating from a given IP address are usually generated 

by the same application running on the system identified by the address.” While 

this conclusion may not hold in some cases, particularly when several hosts that 

run a popular application share an IP address through NAT, the loose association 

provided may already be enough for our purpose. 

Based on the assumption described in the previous paragraph, we can measure 

the delay between two successive attempts of an application to contact another 

application. Again, we analyse the distribution function for the measured delays, 

if an application tries to initiate a flow in regular intervals, the distribution function 

will exhibit a local maximum at the configured interval value, i.e. the existence 

of a local maximum can be treated as an indicator for an automated process 

initiating flows. Note that we may not be able to measure the conspicuous intervals, 

if the malware’s flow initiations are mixed with a legitimate user’s. However, once 

the user ceases interaction with the application disguising the malware traffic for 

a sufficiently long time span, the interval can be observed. We would also like to 

point out that when only considering traditional netflows, this mechanism would


fail once a system would initiate and maintain a single C 2 flow over a prolonged 

time, even if that flow would carry periodic requests for updates or status reports. 

Using subflows, as suggested in V.C, allows us to distinguish between idle times and 

message exchanges, particularly to reveal the periodic nature of subflow initiation 

in the described case. 

B. Failed flow count 

Botnets with peer-to-peer functionality such as Storm or Miner use a list of addresses 

hard coded in the malware or distributed as a separate file to allow infected 

hosts to connect to other peers. Since keeping such a list up to date is a hard problem, 

a significant fraction of the addresses in the list will no longer be available at 

the time the malware initiates operations. Research conducted at our institute [19] 

revealed that on average only about 23% of the addresses advertised in the Miner 

botnet’s peer lists would respond to connection requests, i.e. a client will usually 

have to initiate flows to a significant number of addresses before finding one that 

would respond to its request. We want to exploit this by taking failed connection 

attempts into consideration for detecting botnets with peer-to-peer functionality. 

Observing an explicit failure of a flow initiation attempt is only possible 

if the contacted system signals a rejection through ICMP. Otherwise, e.g. if the packets 

initiating the flow are filtered by a firewall, we have to infer the failure from 

what we can observe. Since few Internet protocols use strictly unidirectional 

communication, we interpret flows for which we did not observe any packet from 

the responding to the initiating system as failed. This will however also be the case 

when a system sends packets to a multicast address, since such an address does not 

represent a single system that could generate a response. Multicast transmissions 

are however often filtered by ISPs and thus we do not expect them to have any 

significant effect regarding this feature. Besides that, treating multicast addresses 

differently regarding this feature would be a valid option if significant changes 

in usage patterns would render it useless otherwise. 

C. Flow volume 

For a typical protocol providing users with access to data stored at a central 

location such as HTTP, the client to server direction of the flow will consist 

of a small or series of small requests and one or several large responses. Following 

the methodology introduced in sections V.B and V.C, each request and response 

would correspond to a single subflow. 

We do not expect that this will be fundamentally different for a botnet protocol, 

however we want to exploit one feature that distincts regular and botnet client 

behaviour. A botnet client will usually request a few pieces of data, either using 

fixed requests or building them from a template. While live users’ requests may


407 

be dominated by a static part, users will access a larger variety of resources from 

a given server, usually resulting in varying lengths for the respective requests and 

responses. A bot requesting data in the described manner will however generate 

evenly lengthed requests and a system answering such requests will exhibit little 

variation in the size of its responses. 

Thus, we want to analyse the payload byte counts of subflows for an unusual 

distribution function, more particularly one with very distinct local maxima. For 

a botnet client, these will correspond to the length of requests for updates or commands, 

when considering a system serving those to infected hosts, they will reveal 

the sizes of the commands or updates provided through peaks in their distribution 

function. While the total count of bytes transferred in a flow is strongly correlated 

with the length of the transferred application payload, the measured values may 

differ between flows that traverse different links, if the smallest maximum payload 

size for the layer 2 protocols for those links differ. Thus, we suggest measuring 

the payload size directly. 

VII. Host models 

Our projected system will use the features described above to classify observed 

systems as belonging to a given host model, describing the behaviour patterns 

expected from a system fitting that model. The models we describe here include 

legitimate clients and servers, indicating that the system is benign, and a model for 

systems that may have been infected with a botnet client. In the following sections, 

we describe our current definitions for these models in that order. 

A. Client model 

Non-infected clients as part of a network system mostly behave in a noisy 

manner. Though timely regular activities such as checks for new email and updates 

of the operating system are part of our client model, we assume that these are superimposed 

by user activities such as web browsing. This infers a wide spectrum 

in measurements of the features given above. For example, the inter-flow-initiation 

delay of activities that come from a user is modelled to have a wide bandwidth 

in the frequency domain. The same holds for the flow volume as the down-stream 

to the client underlies a great variety of requested data objects. Failed flows on 

the other hand may occur but are rare since users reject applications that frequently 

fail to provide their service. 

B. Server model 

A system providing services for clients is strongly affected by user actions. 

More particularly, the noisy patterns of diverse user interaction propagates to


the measurements for our features concerning legitimate servers. To distinguish 

between servers and clients, we can also exploit their sinkhole structure in terms 

of the network flow direction. 

C. Infected 

The malicious behaviour of an infected host can possibly only be observed 

in interference with benign user actions. However, we assume that the malware 

activities have a significant impact on the features described above. As the malicious 

activities are machine-controlled, they might be assumed to occur in timely 

regular patterns [20]. This implies needle-like bandwiths in the frequency domain. 

Again, the same holds for the flow volume. This is due to the fact that the number 

of possible actions of a malware is very limited [19]. 

VIII. First results 

In the preceding sections, we described the foundations for a system that distinguishes 

between regular client or server systems and systems that have been infected 

with a botnet client. Our prototype implementation does not cover all of these concepts 

yet but provides a base for estimating whether our assumptions were correct. 

The Waikato traces briefly described in section VIII.A provide our baseline for 

network traffic predominantly generated by benign systems. In the section thereafter 

we describe our method for obtaining a network trace from a live botnet client by 

executing it in a secure environment. Finally, we discuss the feature distributions 

observed for these traces in section VIII.C. 

A. Waikato 

We use network traces provided by the Waikato Internet Traffic Storage 

(WITS) of the University of Waikato, New Zealand as a baseline for “normal” traffic. 

The traces were captured at the university’s Internet exchange, between June 

and September 2007. They do not include layer 4 payloads and IP addresses have 

been anonymised by XOR’ing them with a key which would be changed once every 

week. Please refer to the WITS website [21] for additional details on the trace files. 

Since considering the whole dataset would be unlikely to provide any insight 

beyond that provided by a well-chosen sample, we selected two trace files from 

consecutive weekdays, the 4th and 5th of September 2007 for this evaluation. We 

could not use traces from different weeks since the anonymisation may result 

in systems with different roles being mapped to the same address, possibly distorting 

measurements. 

Also, anonymisation prevents the use of legacy methods for detecting malicious 

traffic. Thus, we cannot ensure that the traffic observed in these traces does


409 

not include any traffic generated by malware. To select a subset which should at least 

be clearly dominated by user interaction, we only consider flows initiated towards 

a server listening on TCP port 80 (HTTP). While some of the respective flows 

may have been initiated by a malware, we suspect that a very dominant majority 

corresponds to legitimate use of the HTTP protocol. 

When analysing this subset, we noticed that a single IP address (anonymised 

to 249.5.77.77) would contribute almost 57% of the respective measurements. Our 

best guess is that this address refers to a proxy server, i.e. a system relaying HTTP 

requests for an unknown number of end users. While the respective measurements 

neatly fit our expectations for the features described earlier, we decided to exclude 

them from the results presented in section VIII.C to avoid introducing the skew 

of the distribution caused by such a system, particularly with respect to the interflow-initiation 

feature. 

B. Miner 

Evaluating our feature set for actual malware turned out to be a difficult task. 

To achieve an acceptable level of significance, we would have to run a malware for 

a prolonged time span. Doing so while giving the malware full access to the Internet 

would be unethical and could result in liability for damages. We thus use a setup 

where a malware runs in a virtual machine without access to the Internet. 

To be able to observe C 2 traffic, we had to provide the malware with a peer or peers 

that it can interact with. This implied reverse-engineering the malware’s C 2 protocol, 

a very labour- and thus time-consuming task on its own. Therefore, we rely on our 

colleagues’ implementation of the reverse engineered Miner botnet C 2 protocol. In our 

setup, this implementation would run in one virtual machine, providing the interfaces 

described in [19] to a second virtual machine infected with the Miner botnet client. 

The Miner uses a list of bootstrapping IPs and an additional list of peers for 

a peer-to-peer component. For our setup, we ensured that each address in the first 

list would be available, providing data to the botnet client, including a modified 

version of the second list. We generated the latter list such that each entry would 

be selected from a pool of reachable addresses with probability 1 / 3 and from another 

pool of unreachable addresses otherwise. This is a significant improvement 

over the 23% of responding hosts in Miner peer lists determined in the wild. Since 

the Miner client scans the peer list linearly, we randomised the order of addresses 

in the peer list to avoid any bias. 

The results we present below were obtained by sniffing on the virtual network 

link between the two virtual machines for 24 hours. We started with an uninfected 

system but initiated an infection right after starting to listen on the virtual link. 

Other than for the infection, no user interaction occurred. 

With just a single malware to verify our observations against, we cannot derive 

conclusions regarding the generality of our approach, yet. However, it allows us to


test whether our hypothesis’ hold for a particular malware indicating whether or 

not investing further research in the area may be feasible. 

Fraction of All Observed Delays 

0.00 0.02 0.04 0.06 0.08 

Waikato 

Miner 

0 1 2 3 4 

Delay Between Flows Initiated to the Same Port 

Fraction of All Observed Hosts (logscale) 

5e−07 2e−06 5e−06 2e−05 5e−05 

Waikato 

Miner 

0 500 1000 1500 2000 2500 3000 3500 

Failed Flow Initiations Per Hour 

Figure 2. Inter-flow-initation delay for flows to 

the same destination port 

Figure 3. Mean of failed flow initiations per hour 

and host. A red vertical line indicates the value 

for the Miner botnet client. Note that the y-axis 

is logarithmically scaled 

Fraction of All Observed Flows 

0.0 0.1 0.2 0.3 0.4 0.5 

Waikato 

Miner 

0 200 400 600 800 1000 

Count of Bytes Transfered in a Flow, from the Responder to its Initiator 

Fraction of All Observed Flows 

0.00 0.05 0.10 0.15 0.20 0.25 0.30 

Waikato 

Miner 

0 200 400 600 800 1000 

Count of Bytes Transfered in a Flow, from its Initiator to the Responder 

Figure 4. Payload byte count of the initiator 

to responder direction of a flow. Values larger 

than 1000 were cut off with respect to the long 

tailed distribution 

Figure 5. Payload byte count of the responder to 

initiator direction of a flow. Again, values larger 

than 1000 have been omitted 

C. Results 

Figure 2 shows a Gaussian kernel based approximation of the probability 

density function for the delays observed according to the description given in section 

VI.A. The black line corresponds to the measurements for the Waikato traces, 

a thick red line indicates the results for the Miner trace obtained as described above. 

While the distributions share a spike very close to 0 and a very long tail, which 

we left out for clearness of the presentation, the Miner trace’s distribution exhibits 

a very distinct spike at about 3 seconds. This reflects the Miner botnet client’s waiting 

period of 3 seconds between consecutive executions of an online check and 

confirms that this feature is able to reveal such periodic events. 

We provide a plot of the probability density for a given mean of failed flows per 

host and hour in figure 3. To provide some level of detail for lower values, the figure 

uses a logarithmically scaled y-axis. The numbers for the Waikato traces include 

a total of 570 hosts for which the first and last connections initiated to TCP port


411 

80 were at least one hour apart. Only 46.2% of these hosts achieved a rate of more 

than one failed connection per hour, 30 hosts had a rate of 10 or higher with two 

hosts exhibiting about 105 failed TCP connections to port 80 per hour. The Miner 

on the other hand initiated well above 3500 failed flows per hour, standing out very 

clearly as a red line on the right hand side of figure 3. 

In figures 4 and 5, we provide the probability density for the count of payload 

bytes transferred from an initiator to the responder of a flow and vice versa. 

A function will not produce a plot in the figure, if its value is exactly zero. Again, 

results for the Miner botnet client are indicated by a thick red line, Waikato trace 

results by a thin black line and we cut of the distributions’ long tails at 1000 bytes. 

While the Waikato traces do exhibit some spikes in both distributions, they are far 

less distinctive than those of the Miner bot. Also, only a rather limited set of values 

actually occurs for the Miner botnet client, while the clients in the Waikato traces 

produced almost any value in the whole spectrum. 

Since the Miner bot creates a significant count of failed flows but also successfully 

established connections answered by a zero-lengthed reply, its distributions are dominated 

by flows with zero lengthed payload in each direction. The size of the request 

and replies generated by Miner or the tool mentioned in VIII.B are clearly visible 

as spikes or a group of similar values where their size varied. Some of these connections 

are attempts to determine whether the bot has Internet access by requesting 

the home page of some major websites. Since the Miner does not verify the result 

in any way, our tool simply returns a static reply, visible as a very distinct spike just 

below 200 bytes in figure 5. We would like to point out that a legitimate website may 

however serve different content over time or even for each request, i.e. the feature 

might produce less distinctive measurements in the wild. Nevertheless, we consider 

our results as a clear indication that the feature achieves its goal of revealing significant 

volumes of identical or nearly identical requests and replies. 

IX. Future work 

A. Model-based host classification 

This paper presents selected features to measure for future botnet detection 

and experimental results. These features shall be used for host classification using 

the models described in section VII. To this end, an expected behaviour for each 

model in terms of measurements of the features as a state has to be determined. 

Then, an iterative likelihood ratio test will be used to classify flows observed for 

particular systems. This iterative update scheme has been used widely for hypothesis 

testing of any kind. The critical task will be to define well suited transition models 

of the state in time. As a first step, the aforementioned data traces of Waikato and 

the Miner bot will be used to examine the consistency and performance of this approach. 

However, we are convinced that this scheme has the potential to succeed


in higher level fusion of multiple information sources for a general detection of bot 

behaviour in network traffic. 

B. Guide railing features 

In section IV, we discussed the expected design for future botnets, focusing on 

the most promising approaches from a bot herder’s point of view and then described 

an approach for detecting botnets following the implied design principles. We are 

aware however, that a protocol may be designed particularly to evade approaches 

as the one presented in this publication, e.g. by using oversized transport headers 

for messaging to simulate packets without any application payload. As pointed 

out in section IV.B, this would constitute a more striking anomaly than the ones 

we aim to detect with the described features, but could nevertheless reach the goal 

of evading detection in the described feature space. For a practical deployment, our 

model should thus include additional features that indicate such evasive behaviour, 

i.e. provide strong evidence of malicious activity. 

C. Signatures 

As pointed out in section VII, legitimate applications may to some degree 

exhibit the behaviour associated with botnet clients. To avoid false alarms without 

allowing botnets with a loose C 2 channel to go undetected, it may be helpful to allow 

incorporating signatures matching the behaviour of these applications regarding 

our feature space so that the measurements they generate can be filtered. 

X. Conclusions 

In this paper, we discussed key elements of the botnet design which is likely to 

emerge from their ongoing evolution. Our analysis suggests that future botnets will 

use proper encryption and integrity checks for their protocol messages and authentication 

for commands and updates. Those measures, potentially complemented by 

tunnelling through legitimate protocols, would render them invisible to payload based 

approaches currently dominant in network intrusion detection. Based on careful 

analysis of the relationship between properties that remain observable to a network 

intrusion detection system under these circumstances and the behaviour of applications 

communicating through a network, we suggested to observe the delay between 

flow initiations to a similar protocol endpoint, the count of failed flow initiations 

and the count of payload bytes transferred for botnet detection. We drafted a system 

which exploits the measurement of these and possibly additional features as an input 

to an iterative likelihood ratio test for assigning one of three classes of hosts to each 

observed system. These classes include a model for hosts that have been infected 

with a botnet client, i.e. the classification reveals a malware infection.


413 

While our prototype implementation does not cover all aspects of our approach 

yet and some issues remain open for further research, we were able to verify 

that the suggested features were affected by the Miner botnet client in the predicted 

manner. Single measurements will however not provide the level of certainty traditional 

payload signatures can provide for today’s botnets. Thus, detection has to 

be carried out as an iterative process, taking into account a series of measurements 

for each observed system. Similar problems have been studied in the field 

of sensor data fusion and thus our current and future research is part of a joint 

effort to migrate the methods and algorithms developed in that field into network 

intrusion detection. 


We would like to thank our colleagues at the FKIE Cyber Defense and Sensor 

Data and Information Fusion departments, the University of Bonn Computer Science 

Department 4 and the Singapore DSO National Laboratories for our fruitful 

discussions and their advice. Our special thanks go to Daniel Plohmann of FKIE 

Cyber Defense for providing a reverse engineered implementation of the Miner C 2 

protocol and his support in setting up our evaluation environment. 

References 

[1] D. Plohmann, E. Gerhards-Padilla, and F. Leder, “Botnets: Measurement, detection, 

disinfection and defence.” Technical Report published by the European Network and 

Information Security Agency (ENISA). Editor: Giles Hogben, 2011. 

[2] N. Falliere, L.O. Murchu, and E. Chien, “W.32 Stuxnet dossier,” Technical Report 

published by Symantec, 2011. 

[3] V. Paxson, “Bro: A system for detecting network intruders in real-time,” in Proceedings 

of the 7 th USENIX Security Symposium, 1998. 

[4] “Snort Official Website.” Available: www.snort.org 

[5] K. Rieck, G. Schwenk, T. Limmer, T. Holz, and P. Laskov, “Botzilla: Detecting 

the ‘phoning home’ of malicious software,” in Proceedings of the 2010 ACM Symposium 

on Applied Computing, 2012. 

[6] G. Gu, R. Perdisci, J. Zhang, and W. Lee, “BotMiner: Clustering analysis of network 

traffic for protocol- and structure-independent botnet detection,” in Proceedings 

of the 17 th USENIX Security Symposium, 2008. 

[7] M. Celenk, T. Conley, J. Willis, and J. Graham, “Predictive network anomaly 

detection and visualization,” in IEEE Transactions on Information Forensics and 

Security, vol. 5, no. 2, 2010. 

[8] T. Karagiannis, K. Papagiannaki, and M. Faloutsos, “BLINC: Multilevel traffic 

classification in the dark,” in Proceedings of the 2005 ACM Conference on Applications, 

Technologies, Architectures, and Protocols for Computer Communications, 2005.


[9] L. Bernaille, R. Teixeira, and K. Salamatian, “Early application identification,” 

in Proceedings of the 2006 ACM Conference on emerging Networking eXperiments and 

Technologies, 2006. 

[10] M. Crotti, M. Dusi, F. Gringoli, and L. Salgarelli, “Traffic Classification Through 

Simple Statistical Fingerprinting,” in ACM SIGCOMM Computer Communication 

Review, 2007. 

[11] M. Dusi, M. Crotti, F. Gringoli, and L. Salgarelli, “Detection of Encrypted 

Tunnels Across Network Boundaries,” in Proceedings of the 2008 IEEE International 

Conference on Communications, 2008. 

[12] H. Stern, “The rise and fall of Reactor Mailer,” in Proceedings of the 2009 MIT Spam 

Conference, 2009. 

[13] G. Maier, F. Schneider, and A. Feldmann, “NAT Usage in Residential Broadband 

Networks,” in Passive and Active Measurement, ser. Lecture Notes in Computer Science, 

N. Spring and G. Riley, Eds., vol. 6579, 2011. 

[14] R. Beverly and S. Bauer, “The Spoofer Project: Inferring the extent of source address 

filtering on the Internet,” in Proceedings of the 2005 USENIX Workshop on Steps to 

Reducing Unwanted Traffic on the Internet, 2005. 

[15] E. Cauich, R. Gómez Cárdenas, and R. Watanabe, “Data Hiding in Identification 

and Offset IP Fields,” in Advanced Distributed Systems, ser. Lecture Notes in Computer 

Science, F. Ramos, V. Larios Rosillo, and H. Unger, Eds, vol. 3563, 2005. 

[16] J. Calvet, C.R. Davis, and P.-M. Bureau, “Malware authors don’t learn, and that’s 

good!” in Proceedings of the 2009 International Conference on Malicious and Unwanted 

Software (MALWARE), 2009. 

[17] “W32.Duqu: The precursor to the next Stuxnet, Version 1.4,” Technical Report 

published by Symantec, 2011. 

[18] N. Falliere, “Sality: Story of a peer-to-peer viral network,” Technical Report published 

by Symantec, 2011. 

[19] D. Plohmann and E. Gerhards-Padilla, “Case Study of the Miner Botnet,” 

in Proceedings of the 4th International Conference on Cyber Conflict, 2012 (in press). 

[20] C. Zhang and V. Paxson, “Detecting and Analyzing Automated Activity on Twitter,” 

in Passive and Active Measurement, ser. Lecture Notes in Computer Science, N. Spring 

and G. Riley, Eds., vol. 6579, 2011. 

[21] “Waikato Internet Traffic Storage Website.” Available: www.wand.net.nz/wits

Methodology for Gathering Data Concerning 

Incidents in Cyberspace 

Adam Flizikowski 1, 2 , Jan Zych 2 , Witold Hołubowicz 2 

1 University of Technology and Life Sciences, Bydgoszcz, Poland, adamfli@utp.edu.pl 

2 ITTI Sp. z o. o., Poznań, Poland, {holub, jan.zych}@itti.com.pl 

Abstract: This paper introduces a cyber incident observation sheet. It is meant to support the process 

of gathering cyber incident data from attacks targeted against military missions. An effective method 

of gathering factual data is in the authors’ opinion one of the biggest challenges and show-stoppers 

in the process of learning adhering to a lessons learnt paradigm (especially considering negative 

experiences). 

While developing Cyber Tool with the aim of cyber threats modeling in the frame of EDA (Europe 

Defense Agency) Athena project, authors have identified a serious need to introduce a well shaped 

and structured observation form in order to enable and foster data analysis and automated processing 

in subsequent steps. In contrary to civil world, cyber incidents against military systems are not reported 

publically, nor traced back to unveil the actual vulnerabilities that have been exploited by an attack. 

Authors describe a formal point of view in the area of factual data collection in the area of cyber- 

-attacks on communication resources. The proposed method (and recommendations) of collecting 

information about incidents can be a valuable input into the process of continuous improvement 

of security level in the cyberspace. 

Keywords: EDA, Athena project, factual data, data acquisition, sensors, cyber threats, asymmetric 

threats 1 , cyber attacks 


The EDA ATHENA project is a research project responding to the JIP-FP 

(Joint Investment Programme on Force Protection) call in the area of mission 

planning and modeling of asymmetric threats. Aside from ITTI (Poland) there 

are five other participants from four member countries of the European Union: 

TNO – the leader (Netherlands), FFI (Finland), Cassidian (France), TUT (Estonia) 

and WAT (Military University of Technology) (Poland). Undoubtedly such 

composition of consortium partners with great research potential, experience 

1 

“Asymmetry” – this term describes different forms of disproportion, differentiation and disharmony, which 

are naturally or intentionally coexist in the environment of opposite realities. In the area of military conflicts, 

asymmetric operations appear in tandem with terrorists attacks. Today’s military systems are equipped with 

electronics and information technologies to such an extent, that cyber attacks seem to pose significant threats 

to military missions’ success.


and domain knowledge, is expected to gain significant results while working on 

the project. The project is preparing – among other models/tools for enhanced 

mission planning/training in asymmetric conflicts – the Athena IT (Information 

technology) tool (the Cyber Tool) for intelligence analysts. 

The availability of knowledge about past incidents in military cyberspace 

(particularly identification and extraction of related incidents from the factual data 

available) is crucial requirement for further processing of factual data. In subsequent 

steps of processing, it provides an important input for analysis and preparation 

of cyber-defense models in order to successfully prevent future threats. 

The paper focuses on describing cyber-attacks against military resources 

and especially highlights selected issues of the process of factual data acquisition 

(related to these attacks, events). 

Tools such as the Cyber Tool developed for cyber threats identification and 

ranking (based on vulnerability assessment) strictly depend on the availability 

of suitable input data (e.g. vulnerabilities repository). The problem of the lack of such 

data causes serious complications: on the military IT systems vulnerabilities causes 

any decision support system or training tool low suitability. 

Figure 1. Extraction of cyber incidents from repository of past incidents 

Validated and well recognized good/best practices, which are developed by 

information science are strongly considered in this study. These practices include 

(but are not limited to): 

• gathering information about incidents in cyberspace using a formal observation 

sheet (unified way of collecting information about incidents); 

• on-the-fly validation – which prevents introducing the data that is not valid, 

i.e. for bit rate parameter, only specified, numerical digits can be entered, 

from the minimal and maximal value range, values out of the defined scope 

will be rejected; 

• usage of “dictionaries” – all the data being introduced should be picked-up 

from within the dataset of well-defined set of dictionaries; 

• exploitation of dynamic/contextual observation sheet for introducing 

the data sequentially (with contextual hints).


417 

In this article, the formalised sheet for collecting factual data related to cyberspace 

is introduced. The data from such a sheet would in turn constitute one 

record in a repository of past incidents from cyberspace (Figure 1). Some number 

of incidents collected in a repository will evidence information about security 

breaches in telecommunication and IT systems – namely cyber security incidents. 

For sake of clarifying nomenclature used in this article the following concepts 

definitions are given: 

• factual data – is a set of facts and/or activities in the area of: collection, selection 

and assessment of usability of information being stored and further 

used in respect of reflecting past incidents in an overall picture; 

• cyber security incident – this notion should be understood as an overall set 

of events that threatens network security, that is each activity that results 

in a direct threat to security level. 

Especially the following list of events is considered here: 

• threats to the availability of networked services (e.g. DoS attacks), 

• intrusion and/or attempt of intrusion to telecommunication and information 

technology system, 

• spamming, 

• spreading of malicious codes, viruses. 

It is important to notice that only limited set of (carefully processed) past cyber 

events registered in a repository will eventually get the status of security incidents. 

This paper is structured as follows – first authors introduce motivation that 

has led them towards publication of this paper. In chapter III the subject of “cyber 

incidents collection” for military is introduced. Eventually the collection process 

of factual data is proposed in chapter IV. Methodology of collecting information 

about cyber incidents is introduced in Chapter V. Finally conclusions are drawn and 

a sample cyber observation sheet is delivered filled with exemplary information. 

II. Motivation 

In the process of designing the Cyber Tool software component in the EDA 

Athena project authors have faced serious exploitation-oriented challenges related 

to the lack of data about vulnerabilities required as an input for the tool. In order 

to be able to deliver expected benefits attributed to the tool, the following showstoppers 

need to be resolved: 

• lack of (ready-to use) repositories containing verified knowledge about 

vulnerabilities of IT systems used in military. On the other hand, existing 

civil repositories of vulnerabilities (e.g. SCADA systems – Supervisory 

Control And Data Acquisition) are publicly available. However, it is difficult 

to determine their relevance to the military domain 

• unavailability of knowledge (or lack thereof) about existing methodology, 

that would allow gathering of information about cyber threats in the mili-


tary domain, as well as analyzing such information. Such methodology 

should cover following aspects: gathering an information / data; structuring, 

analysis (filtering, finding the correlations, etc.) and building the new 

knowledge (rules) 

• challenging definition of realistic scenario that could show impact of cyber 

security issues on training, in the area of asymmetric threats. 

Unavailability of above mentioned items could limit the benefits of using 

the ATHENA Cyber Tool in the context of: 

• identification of networks’ and systems’ threats, 

• training, including an identification of given network topology vulnerabilities, 

• decision support capabilities. 

III. Cyber threats in military missions 

One must realize the fact that security is indivisible. With respect to e.g. 

network centric warfare concept it is sometimes said that the cumulative impact 

of new relationships among war fighting organizations (due to existence of new 

network connections) is the source of increased combat power as suggested in [1]. 

In situations where people lives and health are threatened (military missions fall 

into this group) this assumption is significant. Identification of incidents/events, 

which can cause disruption or termination of military mission is one of the key 

problems in present military asymmetric conflicts. The new NATO Cyber Defense 

Policy, treats cyber security with a high priority [2]. It is related to known, 

but still unsolved problems in acquiring, collecting and exploiting factual data 

in cyber defense domain, including effective usage of sensors (both people and 

specialized devices). 

There is a great amount of well known (and unknown) groups of incidents, 

which may lead to a disruption and/or prevent military mission from completion. 

Appearance of such an incident during execution of a military mission may lead to 

severe consequences (ultimately losses of people’s life or health). Thus the ultimate 

goal of collecting information about incidents in cyberspace is achieving increased 

level of cyber security, which in turn takes effect in an increase of military security. 

It is of key importance to consider the following set of information: 

1. Identification of information sources. 

2. Definition of the means used for data collection. 

3. Preparation of the information gathering method. 

4. Preparation of the concept for storing information about incidents. 

The points 1-4 above provide a fundament for the stage of collecting factual 

data about incidents in cyberspace. Elementary goals of military missions can be 

achieved in many ways. While defining this process we should focus on:


419 

• recording of any information about incidents, both positive (i.e.: Best and 

Good Practices) and negative (Lessons Learned), 

• ordering recorded items according to some predefined criteria (e.g. ranking). 

The results which should be delivered at the end of the process after collecting 

an appropriate amount of complete data about incidents, on one hand lead directly 

to an increase in analysis quality and on the other (indirectly) to: 

• increase in the training effectiveness (for e.g. through updated syllabuses 

of training programs, discussing more comprehensive cases in the area 

of cyber security, etc.); 

• wider use of observations and experiences from mission (e.g. through visualization 

of cyber risk on the map, predicting the threat levels for a given 

region and period of time, ...); 

• cross-validation and improvement of the methodological documents 

fundamental for military service (recommending changes that aim at 

improving soldiers’ performance) on a tactical level (in warfare rules), 

operational-tactical level (mission plans), to a strategic level (improvement 

of doctrines). 

A successful execution of a process of gathering factual data (information 

about incidents) is a necessary condition to be able to apply advanced methods 

of analysis of data in subsequent steps e.g. to identify relevant: 

• correlations (mutual qualitative and quantitative relations); 

• coincidences (simultaneous occurrence of incidents, which are not related 

to each other by the root cause); 

• associations (association, combining facts pairwise and identifying relations 

between them); 

• cause-effect relations (direct and indirect). 

An interesting case study on the analysis of communication networks reliability 

in crisis management and military missions is presented by authors in [3]. 

The way to identify and analyse the critical resources, search for the optimum 

communications network layout (relative to the adopted criterion) and identifying 

cause-effect relationships of objects and processes in the area of communications 

is presented there with use of game theory approach. 

IV. Factographic data collection process 

The proposed method of collecting factual material in cyberspace is specific 

and as such can be characterized by: 

• underlying goal of inferring information from data and further turning 

it into explicit knowledge; 

• multi-staged approach (gaining experience e.g. from daily missions, collecting, 

analysing and then applying it in a given context);


• permanence and periodicity (every daily mission, which is realized usually 

during one combat day (24 hours) is focused on new experiences, every 

completed cycle of processing creates a foundation for next iterations); 

• incremental construction (every cycle generates added value in the form 

of extended/qualitative and quantitative changes in repository of experiences 

gained) and exploiting new experiences (experiences gained can be 

used as a request for change of warfare regulations, add new content to 

training program/syllabuses and eventually justify changes in doctrines). 

A. Classification of factual data 

Classification of factual data and especially of the extracted incidents in cyber 

defence domain is necessary to perform a statistical analysis of the data. Rules/ 

guidelines/methods for classifying factual data (especially incidents) in cyber defence 

domain are presented in this subsection. Proper taxonomy should be created 

considering rules below e.g.: 

• Ockham's razor – reduce additional duplicable entities; 

• divisibility of categories – entity classified to one category cannot be classified 

elsewhere; 

• completeness – all categories comprise entire set of possible categories; 

• unequivocal – classification criteria should be precise enough so that 

the result of classification is always the same, no matter who is responsible 

for performing it; 

• repeatability – classification process is repeatable, no matter how many 

times it will be repeated; 

• acceptability – target taxonomy is commonly accepted; 

• usability – has high informative value. 

Statistical analysis of particular incidents occurrence is helpful in determination 

of appropriate defense system against cyber attacks. Factual data collected 

should be starting point for identification of e.g.: 

• the weakest elements in military network topology, 

• vulnerabilities of these networks on cyber attacks, 

• trends, 

• cycles, 

• regularities, 

• deviations, 

• anomalies. 

B. Aims of collecting factual data in cyberspace 

Cyber terrorist attack can manifest itself in the intrusion on target’s software 

or information technology systems and hardware. There is plenty of methods to


421 

implement this kind of activities. It results in lack of one, unified classification, 

because different authors use different criteria of cyber terrorist attack description. 

Applying the above mentioned Ockham’s razor rule, the following classification, 

according to CERT Poland (Computer Emergency Response Team), is proposed 

(in alphabetical order): 

• attack on email subsystem, 

• attack on operational system, 

• attack on a server (for e.g.: WWW, DNS – Domain Name System), 

• illegal software, 

• denial of service, 

• dissemination of illegal and insulting, abusive content, 

• scanning, 

• social engineering, 

• spamming. 

It can also be handful to differentiate attacks and intrusions following categories: 

• reconnaissance activities before an attack (intrusion) 

• passwords cracking methods 

• exploiting vulnerabilities and security holes (using characteristics of applications, 

operating systems and protocols) 

• malicious code attacks (Trojans, viruses, worms) [4]. 

V. Methodology of collecting information about cyber incidents 

A. Characteristic of data sources and registration process 

Among variety of events identified during military missions some can be 

registered and observed by human senses (soldiers’ and civilians’ participating 

in mission) and some other only by means technical devices (Figure 2). 

Considering the scope of the ATHENA project and the characteristics of typical 

military mission, which are among all: 

• occurrence of asymmetric threats, 

• occurrence of sudden events, 

• time deficit, 

• incomplete and unsure information, 

• high pressure for completion of the tasks assigned and the overall goal 

achievement, 

it is difficult to perform a comprehensive (and complete) observations by soldiers 

and civilians (e.g. the main sources of information about incidents) in the timeframe 

of a mission. As a result a factual data about incidents is usually limited and 

fragmentary. Thus some auxiliary sources of information should be considered: 

• correctly constructed models – simulation environments, (e.g. simulation 

models, war games, battlefield simulators)


• information distributed through mass media, (e.g. TV, radio, press, Internet) 

• information resulting from the initial analysis of factual data (at the stage 

of processing – before and during their storage in the repository). 

Main sources of information can be identified with respect to the following 

stages of military mission: 

• mission planning stage (produces mission plan), 

• mission execution stage (reports and notification from the battlefield), 

• directly after the end of the mission (report generated during debriefing). 

It can be reasonable to discern different sources of information about incidents 

between primary and secondary ones: 

Figure 2. Mission execution stages and relevant types of sensors 

• primary sources of information (observations of people directly participating 

in mission; technical sensors (devices)) 

• secondary sources of information (observations made by personnel who 

acquires the information about incidents, initial analysis of the information 

about incidents that is stored in repository). 

This distinction seems relevant because it presents a potential for reducing 

information processing overhead (number of stages). A primary information 

is more reliable, it is directly authorized by the source. Secondary information 

is pre-processed already. At every stage of processing an information is improved, 

validated, completed etc. However every activity of this kind (during process-


423 

ing) is also potential source of information changes (corruption). In example 

the missile guidance systems rely only on primary information, which proves how 

important primary information can be considered. Within the process of cyber 

incidents data acquisition a multiple limitations (boundary conditions) have to 

be considered: 

• this process relies on a very formal set of (field) documents, e.g: OPORD 

(OPerational ORDer, operational order), FRAGO (FRAGmentary Order, 

more specific, fragmentary OPORD), 

• incorrect (inappropriate) training of personnel responsible for implementation 

of an observation process (for e.g. too high/low sensitivity threshold), 

• time limitation during debriefing, 

• presence of typical psychological barriers of a soldier/civilian during 

the AAR (After Action Review) stage 

• lack of contextual knowledge, needed to associate events to each other, 

• most of the factual data is rather plain text than reach multimedia content. 

The example of typical psychological barriers of a soldier during AAR stage 

can be among all: 

• details, which can negatively influence opinion, assessment of activities 

of other soldiers, 

• observations, which seem to be irrelevant, infantile, 

• emotional states, which may indicate weaknesses of soldiers and result 

in lack of acceptance or ridiculousness (abnormal, excessive fear, caution, 

tendency to recklessness, taking excessive risk), 

B. Formalization of the process of collecting information about cyber 

incidents in cyberspace 

The incident observation control sheet, which is an integral part of the method 

of collecting information about incidents consists of four main sections: start, event/ 

incident itself, status of the observer and the end (Figure 3). 

The following information should be included in particular sections of such 

sheet: 

1. Indication of the starting point of the observation (location, time) 

2. Event/incident itself, description of observation with parameters 

3. The status of an observer (data, which could be combined for the purpose 

of identification of a person, who formalizes observation materials and 

information, which makes possible to assess the level of competence of this 

person); 

4. The endpoint of the observation (location, time). 

Proposed methodology covers both – the AAR (After Action Review), debriefing 

and other materials acquired automatically through technical devices (both 

civilian and military).


Figure 3. Division of the incident observation sheet onto two basic parts: observed incident 

and status of the observer 

The universal character of proposed methodology stems from the fact that 

particular sections of the incident observation sheet are also valid for describing 

parameters with observations from every other sources of information both civilian 

and military (from mission plans and mission reports) and technical devices 

used for collecting factual data. The stage of collecting cyber incidents ends by filling 

particular sections of the observation sheet with content. Underlying information 

sources consist of a set of: 

• factual data about incidents in civilian security domain (registered for e.g. 

by NASK – Research and Academic Computer Network). 

• military documents about planning, execution and debriefing of a mission 

• factual data reported by ICT systems, which covers e.g. network traffic, 

reports from port scanning, number and size of transferred batches. 

Every single entry inserted into incident database can be packaged as paper or/ 

and an electronic form. Proposed information structure (parameters) of database 

records is presented in the following sub-section. All information which will not 

be selected for inclusion into the observation sheet are considered to be irrelevant. 

This way information from the data sources about single cyber incident is carefully 

selected (Figure 4). 

C. Recommendations for the gathering process 

Every role involved in the process of cyberspace data gathering should obey 

a well-defined set of rules in order to assure reliability of results. These rules concern 

among all: 

• focusing on particular objects (e.g. central, base station, access to active 

network elements, type of software) and processes (e.g. way of communication, 

activities coordination), 

• omitting irrelevant details (they are defined separately for every mission 

and type of event), 

• using one or a well-defined set of recording techniques (paper notes, photos, 

videos, mind mapping, other)


425 

Figure 4. Factual data processing 

The issues of an “Analysis” and “Recommendations” will be described in a separate 

publication of the authors. 

• in the case auxiliary technical equipment/devices are concerned for recording, 

appropriate procedure of event registration should be obeyed, 

• level of details of registered events 

• structure (common structure/template should be applied for every event), 

• parameterization (specified parameters in every section of observation 

sheet), 

• accountability (every section of observation sheet should be described by 

attributes). 

In order to cover key items related to an incident the following levels of elementary 

objects should be included: 

• system (name of the system), 

• sub-system (name of the sub-system), 

• object (name of the object), 

• sub-component (name of the sub-component), 

• unit (name of the unit), 

• fragment of the unit/process. 

D. Time and place (location) of collecting information about incidents 

in cyberspace 

The proposed methodology is thought for particular tasks aligned in certain 

time frame and location: 

• during mission planning in headquarters (mission plan specification), 

• during mission execution (reports from battlefield), mission location 

and command and control centres,


• immediately after the end of the mission (e.g. during debriefing), 

• debriefing session in briefing hall/in headquarters, 

• at any time by querying/processing factual data repositories gathered by 

sensors/IT systems, 

• at any time based on the open source intelligence (OSINT – Open Source 

Intelligence) data acquired from civilian system (e.g. NASK), which can considered 

a source of information about incidents from the cyberspace. 

E. Methodology of information gathering 

Direct benefits of applying proposed methodology are as follows: 

• common structure for data retrieved from various sources of information 

• identification of structural incompleteness within particular observation 

sheet, in order to assure updated information handling in the future, 

• preliminary validation of the collected information about incidents 

in order to: 

▷ protect from improper values (and e.g. dates out of range), 

▷ account for inertia and physics of the registered phenomenas/processes 

(e.g. the time required to power on/off a device, initiate/terminate given 

process), 

▷ process the source information to structure it into the form required 

for later storage in a database, e.g.: divide all the information into types 

(digital, text, graphical, other). 

Regarding the structure for data from various sources of information, data 

from respective reports and notifications will be parameterized and classified into 

particular blocks/sections in observation sheet. Thanks to such ordering it will 

be possible to assign attributes to data contained in particular blocks/sections 

of the observation sheet: 

• status of the mission concerned by the collected observation (date, type 

of the mission, cryptonym, code name, composition of the unit, final assessment 

of the mission, other), 

• type of incident (good practice, negative experience), 

• every single incident should be described related to its location (geographical 

coordinates with the highest possible accuracy, according to different 

notations: WGS – World Geodetic System, NATO, ...), time (operational 

time, calendar time), 

• does the information directly influences soldiers’ health/life (yes/no), 

• information about the mission (currently executed, mission planned to 

execution, accomplished mission), 

• is information confirmed/not confirmed by other soldier participating 

in a given mission, 

• information status: up-to-date/out-of-date (specify this date),


427 

Figure 5. Main stages of populating data base of invents 

• information related to stationary/mobile object, 

• means by which an information was captured – human senses / additional 

sensors, 

• should the information be public/ or restricted, read only, or possible to 

modify, 

• quantity and quality of information sources (including personal information) 

that have confirmed particular elements of information about incident, 

• is the information new in repository or it is an update of existing one. 

To summarize above structure of an observation sheet a sample has been 

provided in the annex to this paper. 


The proposed methodology of collecting information about incidents in cyberspace 

mapped into a particular group of military activities should enable answering 

questions about (risk of) certain threats existing in today’s battlefield (especially 

incidents in the area of cyber security). Such method (of collecting information 

about cyber incidents) introduces its own identity. 

In this paper authors propose a comprehensive method that can be applied to 

collecting information about incidents based on the incidents observation sheet. 

An effective method of gathering factual data is in the authors’ opinion one 

of the biggest challenges and show-stoppers in the process of learning adhering 

to a lessons learnt paradigm (especially considering negative experiences). Thus 

the authors believe that the proposed method (and recommendations) of collecting 

information about incidents can be a valuable input into the process of continuous 

improvement of security level in the cyberspace.



Authors would like to acknowledge the funding received from the R&T Joint 

Investment Programme on Force Protection (JIP FP) which focuses on technologies 

for protecting EU armed forces against threats. The programme has been launched 

under the umbrella of the European Defence Agency and is financed by twenty 

European governments: Poland, Austria, Belgium, Cyprus, Czech Republic, Estonia, 

Finland, France, Germany, Greece, Hungary, Ireland, Italy, the Netherlands, Norway, 

Portugal, Slovakia, Slovenia, Spain and Sweden. 

REFERENCES 

[1] D. Alberts, J. Garstka and F. Stein, Network Centric Warfare, 2nd Edition ed., 

CCRP, 2000. 

[2] NATO, “NATO Policy on Cyber Defence,” NATO, 2011. 

[3] A. Flizikowski, J. Zych, “Using game theory to reliability research for communication 

systems in crisis management and military operations (case study),” in The functioning 

of the company during the crisis, P. Bartkowiak, Ed., Poznań, Scientific Society for 

Organization and Management, 2011, pp. 50-60. 

[4] D.L. Shinder, Cyberprzestępczość: jak walczyć z łamaniem prawa w Sieci 

(ang. Cybersecurity – how to fight against breaking the law in Internet), Gliwice: 

Wydawnictwo Helion, 2004. 

ANNEX – Observation sheet (Cyber Space) 

Observation sheet duly completed to facilitate the gathering of factual data 

in the repository. The essence of fulfillment of this worksheet is to: facilitate 

dealing with parameterized observation process. An observation sheet should 

be filled to be aware of the fact that each of the fields in the spreadsheet is usually 

filled with a parameter in the record in the database / repository. Please 

endeavor to do so would not generate. garbage at the entrance. It I not necessary 

that all the fields in the observation sheet were filled. The completed observation 

sheet contains the sample data. Below it is presented how the most important 

fields can be filled.


429 

Mission Name (codename): TANGO – 01 

Observed phase of the mission 

planning 

execution 

debrifing 

(before the mission) 

(after the mission) 

☑ 

☐ 

☐ 

Date of observation (YYYY.MM.DD) 2012.04.16 

place of observation 

KABUL 

A concise description of the mission, the essence of the mission (a few sentences) 

PREPARATION FOR SUPPLYING AMMUNITION AND EQUIPEMENT FOR MILITARY 

BASE IN KABUL 

Characteristics of cyber events and consequences: 

System: 

1. system (system name) AFGAN-WAN 

2. subsystem (subsystem name) LOG 

3. the object (object name) SERVER, ACCESS POINT IN MILITARY BASE 

Categories of information: 

1) information confirmed / unconfirmed by another soldier: CONFIRMED 

2) the information current / out of date (the date of obsolescence): CURRENT OBSERVATION 

3) associated with the object of a stationary / mobile: MOBILE 

4) identified human senses / sensors technical: TWO SOLDIERS WITH MOBILE EQUIPE- 

MENT, PROBABLY PERFORMING WI-FI SCANNING 

5) will be available for all peoples / only for selected people: SELECTED PEOPLE 

6) categories of accessibility (read only, modify, delete): POSSIBLE ALL CATEGORIES 

7) how many and which sources (who) confirmed a piece of information about the event: SEN- 

TRY IN FRONT OF BASE, PATROL 

8) The category of information in the repository (new or additional Supplementary): NEW 

Direct impact on the health / lives of soldiers 

Yes 

No 

I cannot define 

Type of cyber event: 

positive 

negative 

neutral

Problems of Detecting Unauthorized Satellite 

Transmissions from the VSAT Terminals 

Przemysław Bibik 1 , Stanisław Gradolewski 1 , Wojciech Zawiślak 2 , 

Jacek Zbudniewek 2 , Radoslav Darakchiev 3 , Jerzy Krężel 3 , 

Mateusz Michalski 4 , Krzysztof Strzelczyk 4 

1 The Institute of Aeronautics and Applied Mechanics, 

Warsaw University of Technology, Warsaw, Poland, 

{pbibik, sgrado}@meil.pw.edu.pl 

2 WOOD System Integrator, Warsaw, Poland, 

{wojciech.zawislak, jacek.zbudniewek}@wood.com.pl 

3 Astri Polska Sp. z o.o., Warsaw, Poland, 

{Jerzy.Krezel, Radoslav.Darakchiev}@astripolska.pl 

4 Military Communication Institute, Zegrze Płd., Poland, 

{m. michalski, k.strzelczyk}@wil.waw.pl 

Abstract: This paper presents a project proposal aimed at developing a set of components in the form 

of methods and tools supporting the process of detecting unauthorized satellite transmissions, realized 

with the VSAT (Very Small Aperture Terminal). With its help it will be possible to draw radio 

(spectral) maps of the existing satellite system, both for the design of new satellite system as well as for 

identifying unauthorized changes to the radio spectrum showing the appearance of unauthorized 

emissions. The results of the project may be interesting for governmental offices or security services, 

that deal with detection of illegal emissions, as well as manufacturers and global integrators. 

Keywords: component; satellites; VSAT; detection 


Commonly observed development of information technology also applies to 

satellite services sector, both in the two-way communication systems and broadcast 

systems – mainly television and radio broadcasting. While the information 

transmission systems develop very rapidly, whereas in the systems to safeguard 

the proper use of satellite transmission resources no development is being practically 

observed. Current status of satellite information technology security resembles 

a situation of the early stages of the dynamic development of the Internet, when 

all network systems operated on the principle of mutual trust. There were no actions 

aimed at stealing confidential data, or taking control of servers and portals. 

Over time the situation has radically changed, and today much attention is given


to the protection of information resources. Experience gained with development 

of the Internet shows that it is reasonable to take dynamic action to develop methods 

and tools to protect satellite information resources. 

Services responsible for monitoring the proper usage of radio spectrum and 

the services responsible for national security, have tools to monitor the terrestrial 

radio, but currently they are not in the possession of any system supporting detection 

of law violations in the field of satellite techniques. 

Developing a set of components in the form of methods and tools supporting 

a detection process of unauthorized satellite transmissions sent using VSAT 

terminals has become the object and purpose of the project TransSat proposed by 

a consortium composed of Military Communication Institute, Institute of Aeronautics 

and Applied Mechanics Warsaw University of Technology (ITLiMS), 

Astri Poland (APL), WOOD System Integrator (WOOD). 

II. Activities affecting safety of the satellite communications 

Unauthorized activities, affecting the security of satellite communication are 

meant as any action whose effects are inadequate in terms of relevant legislation, 

both Polish and international. Unauthorized activities can be classified into two 

main groups: 

• intentional actions – involving the aware crossing of the law and acting to 

the detriment of other persons or institutions, 

• accidental (unintentional) activities – as a result of mistake of human, 

equipment or software that controls devices. 

For unauthorized activities in the area of TransSat project interest there are 

included following types of events: 

• intentional actions like: 

✓ interfering with legitimate transmissions by broadcasting on the same 

uplink frequency, 

✓ interfering with the official communication channels of satellites waiting 

for a command from the control center to continue the mission, 

✓ activities similar to "hacking" ones, to take control over portal – e.g. 

taking control over TV channel, 

✓ transmission realization on free frequency bands, without the consent 

of the satellite operator, 

✓ transmissions to the detriment of national security: civilian (jurisdiction 

of the Internal Security Agency) and military (jurisdiction of Military 

Counterintelligence Services). 

• unintentional activities like: 

✓ entry into occupied by another user uplink frequency, as a result of an error 

in handling VSAT satellite terminal or as a result of Coordination 

Center employee error,


433 

✓ increasing the broadcast power by VSAT terminal over fixed level, causing 

distortion of the transponder receiving circuits, 

✓ VSAT antenna azimuth change, resulting in disrupted work of a satellite 

neighbouring to other satellite, with which communication is established. 

III. Proposed methodology for detecting unauthorized satellite 

transmissions 

Detection of unauthorized transmission using VSAT terminals, especially 

in the case of deliberate acts, require secrecy, and so to carry out an imperceptible 

procedure of monitoring and in general it is a multistage operation. 

The first step will be an identification and selection of active transmitters 

among observed VSAT transmitting terminals and transceivers. Initial selection 

of broadcasting VSAT terminals will be conducted by an experienced observer, 

based on remote viewing. This observation will be assisted with photography and 

thermography data analysis procedures. As a result of the identification there will 

be determined not only the antenna that has transmission capabilities, but also 

the antenna, which is currently active. The next step will be to obtain information 

leading to the detection of the satellite, to which it was connected, in order to 

identify potential recipients. Determination of the satellite, which was connected 

to the terminal, will be possible by determining the geographic location and azimuth 

of the terminal. The proposed method of azimuth determination is to analyze 

the VSAT terminal images taken from different directions, with knowledge 

of the position and orientation of the imaging system, as well as to determine its 

distance from the observer using for example range-finder. 

In the next stage there will be an important task: to determine the approximate 

geometry of the antenna, in particular the shape and profile of the antenna system 

mirror and the position of the radiator brackets, which will allow to determine 

the approximate characteristics of the radiation. The determination of this characteristic 

will enable to determine the optimum listening point, and thus determine 

the optimal location of the observer, which may be Unmanned Aerial Vehicle or 

a man with a measuring equipment, and the directions of the wave emitted by 

VSAT terminal. A crucial element of this stage is to apply the methods of increasing 

the energy of compromising radiation by unstable modification of radiator 

set, e.g. by a local change of temperature using the laser beam, in order to enhance 

its detection. 

The last stage of detecting unauthorized satellite transmissions will be radiation 

detection and listening conduction.


IV. Methods and tools used to detect unauthorized satellite 

transmissions 

An important components used in procedures for detecting unauthorized 

satellite transmissions will be: 

• algorithms for automatic image analysis in both visible and infrared light. 

Method of image analysis used in the project will enable: 

✓ VSAT terminal activity detection and pre-determination whether in a period 

of time this activity was legal or not; 

✓ designation of the satellite, which a terminal is directed to; 

• numerical modeling allowing the determination of the approximate geometry 

of the antenna (Figure 1). Determination of this parameter will allow 

to calculate the distribution of the emitted radiation (Figure 2), which will 

be required for: 

✓ analysis of the possibility of radiator parameters remote modification, 

waveguide and waveguide connectors to increase the compromising 

radiation energy; 

✓ determination of optimal location of observation points to carry out 

listening. 

• algorithms for the calculation of the emitted radiation distribution, which 

is required to determine the best observation points to carry out listening. 

Figure 1. Example of numeric model of monitored 

object 

Figure 2. Example of VSAT antenna radiation 

characteristic. 

Due to the assumed location discretion of monitored VSAT terminals (terrestrial 

stations, on the roofs of cars or buildings) in the project is expected to use 

an Unmanned Aerial Vehicle (UAV), acting as a remote observer. The most common 

structures are vertical take-off UAV quadrotor or octocopter (Fig. 3a and 3b), 

in which lift force is generated by turning propellers on four, six or eight arms. 

These devices are controlled only by varying speed of motors driving propellers.


435 

This approach excludes the need for other mechanical elements for the flight control. 

This type of UAV will permit to move closer to the test object and the “flotation” 

in the air for the time needed for data acquisition. 

The project also examined analogous to planes flying ships (Fig. 3c), for which 

the data acquisition will have to take place during movement, from a significant 

distance from the object. In this case it will be possible to collect multiple images 

(photography and thermography) during the approach to the VSAT antenna and 

the circulation, while in the middle there is a monitored object. 

a) b) 

c) 

Figure 3. Examples of Unmanned Aerial Vehicles: (a) Quadrotor TARKUS (WB Electronics), 

(b) Octocopter SKYJIB (DROIDWORX), (c) Unmanned Plane FlyEye (WB Electronics) 

UAV used within the TransSat project will require a implementation and 

integration of the following equipment/components: 

• measuring head, 

• video recorder/camera, 

• thermographic video recorder, 

• radiation detector in the bands used in VSAT terminals, 

• GPS receiver, 

• UAV remote control systems, detection and navigation devices. 

The use of UAV as a remote observer requires the development of: 

• positioning methods of a thermographic camera, camcorder/camera, 

listening device and navigational equipment; 

• platform to record and store information in different phases of VSAT 

terminal monitoring; 

• data acquisition system of the observation unit to the operator.


V. The possibilities of using the methods and tools in other projects 

Developed in the TransSat project automatic image analysis algorithms in both 

the visible and infrared light can be used in other areas, such as mine protection 

of routes, where move patrols and convoys during a realization of peace missions 

abroad. The images obtained from the daily “test flight” route by an unmanned aircraft 

will be taken automatically, based on the algorithm developed in the TransSat 

project, compared with the reference image of the area recorded in the database. 

In case of discovering of disturbing differences, in the suspected place will be sent 

an engineer patrol to conduct a detailed reconnaissance. 

Another purpose of the project will be to develop numerical models of the socalled 

radiated emissions interference, emitted by the complete VSAT systems. Currently, 

manufacturers of VSAT systems provide information about the directional 

characteristics of the mirror of the VSAT antenna. Rarely there are information about 

radiation characteristics of the complete antenna with tie parts to hold the radiator, 

and the exceptions may include directional characteristics of complete VSAT 

systems, taking into account the impact of installation of all elements of the signal 

path, on the radiated interference emissions by the VSAT system. The lack of such 

information generates problems with the so-called co-located compatibility, appearing 

in the case of having to install several VSAT systems in close proximity 

to each other, such as satellite centers (called teleport, hub), or the work of several 

informational agencies in the given location. Developed in the TransSat project 

radiated noise emission models in VSAT systems, will allow to analyze in advance 

the possibility of appearing interference of several co-located VSAT terminals. 

TransSat will be applied with methods and tools supporting the process of detecting 

unauthorized satellite transmissions, and thus the radio emission in the frequency 

range 7-38 GHz can be successfully used in the preparation or updating 

of maps of the radio and radiolines installations. Screenshot of part of such a map 

was shown in Figure 4. 

Figure 4. Example of radiolines map


437 

VI. Summary 

Currently it is not possible to effectively detect unauthorized emissions of satellite 

signals, and the more its overhearing or recording. There are measurement 

stations in the market, but they operate in a very limited bandwidth. For example, 

Mobile Measuring Station made by KenBIT company operates in 20 MHz–3 GHz, 

while the signals are transmitted by satellite also at higher frequencies, such as DVB-S 

takes the band from 10.7 GHz to 14.5 GHz, or Teledesit that works at about 29 GHz. 

The result of this project will be a unique solution to examine the full range 

of satellite frequencies – from a few hundred MHz to 32 GHz. Owing to this it will 

be possible to draw radio (spectral) maps of existing satellite system, both for 

the design of new satellite system as well as for identifying unauthorized changes 

to the radio spectrum, indicating the appearance of unauthorized emissions. 

For the purpose of the project it is expected to call TransSat consortium, 

that will be composed of research units (Military Communication Institute 

and the Institute of Aeronautics and Applied Mechanics of Warsaw University 

of Technology), and the companies involved in the subject of converging with 

the problems of the project, namely: Astri Polska (APL) and WOOD System 

Integrator (WOOD). 

In the results of the project may be interested: Office of Electronic Communications, 

which deals with the detection and analysis of radio signals and 

the detection of illegal emissions, the state security services such as The Internal 

Security Agency and the Military Counterintelligence Services, as well as manufacturers 

and global integrators such solutions for the detection and interception 

of unauthorized satellite emissions. 

References 

[1] http://www.kenbit.pl/kenbit/rsp.php 

[2] http://www.antenna-theory.com 

[3] http://www.wb.com.pl/pl,Rozwiazania,Systemy-C4ISR,Systemy-rozpoznania/Fly- 

Eye,46.html 

[4] http://www.wb.com.pl/pl,Rozwiazania,Systemy-C4ISR,Systemy-rozpoznania/ 

Tarkus,3.html 

[5] http://aerobot.com.au/octocopter.html 

[6] http://www.aerodes.pl/samonit.htm 

[7] http://mapasieci.pl/ 

[8] http://www.skw.gov.pl/ 

[9] http://www.uke.gov.pl/ 

[10] http://www.abw.gov.pl/

On Multi-Level Secure Structured Content: 

A Cryptographic Key Management 

– Independent XML Schema for MLS Content 

Mikko Kiviharju 

Electronics and Information Technology Division, 

Finnish Defence Forces Technical Research Centre, Riihimäki, Finland, 

mikko.kiviharju@mil.fi 

Abstract: Multi-Level Security, MLS, refers to handling information from different levels of security 

classification securely by people from different levels of clearance. We propose a structured document 

format to host data from different classification levels (e.g. RESTRICTED and SECRET) in the same, 

modifiable document. The document access control is enforced cryptographically – content and access 

control information is encrypted and digitally signed, but the document structure itself is independent 

of the adjoining key management architecture. We detail the different security-related metadata and 

sanitization procedures needed for passing data from a common storage to a user with lower clearance. 

Keywords: MLS; CBIS; XML; cryptography; key management 


Handling classified information in today’s networked world with conflicting 

needs to hide and to share both in homeland and in coalitions with dynamically 

shifting boundaries is becoming increasingly more cumbersome. 

Large information leaks from classified networks (e.g. the one described in [22]) 

are partly possible only because the concept of system-high networks has been 

stretched to its limits: it makes no sense to classify data (to e.g. MISSION SECRET), 

if most of the personnel are cleared to the highest level anyway. This is, however, 

currently the only economical solution dictated by the existing technology in use. 

Technologies that take full use of the security classification spectrum without 

trivial physical separation (and duplication) in hardware are called Multi-Level Secure 

(MLS). There have been a number of solutions aspiring to be MLS in the past, 

and the work is still ongoing. 

Our work concerns the cryptographic approach to enforce MLS. We envision 

structured documents (i.e. XML), with content from multiple different classifications, 

which is then encrypted, signed, and eventually filtered from the most 

sensitive items before given to the end user. We propose an XML schema based on


the cryptographic access control paradigm to canonize this structure, and elaborate 

how the different aspects of permissions and eventual MLS sanitization affect 

the structure and can be realized in our setting. 

This paper is structured as follows: in chapter II we introduce the necessary 

background and review the related work; in the third chapter we view the setting 

more carefully in the format of environment assumptions; the fourth chapter lists 

the design principles and some of the operational details; chapter V is reserved 

for the schema itself and finally chapter VI concludes the paper. 

II. Background and related work 

A. Multi-Level Security (MLS) 

Multi-Level Security (MLS) refers to a concept, where information from different 

levels of security classification is allowed to coexist and be processed securely 

by personnel not necessarily cleared to the highest level. The term stems from 

a formalization of DoD security policy [3] and related risk analysis [16]. However, 

detailed definitions vary widely. In military vocabulary the most common definition 

binds MLS to a “security mode” and the access rights of end users. The defining 

part here is the user clearance, or right-to-know (RTK). 

RTK is more formally defined than need-to-know (NTK), as RTK is most 

often defined on the legislature level. Due to the mandatory nature of RTK and 

the high-risk scenarios with which the MLS concept is endowed, the assurance 

level for “true MLS” components is often very high. 

MLS employs a multitude of functions. Our main concern here is the information 

flow separation, or the isolation of information from different classification 

levels: generally it is desired to keep data (flows) from e.g. SECRET separate from 

data (flows) from RESTRICTED. Due to the high assurance levels required for this 

isolation, only two types have been used: physical (galvanic) and cryptographic 

separation. High-assurance virtualization techniques are also making their way to 

selected MLS sub-areas [9]. 

Enforcing the isolation with cryptography has been used and tried in multitude 

of systems and models, such as CBIS discussed in ch. II-B, but the main problem 

in these systems is key management: encrypted data itself is considered to be sufficiently 

well protected for the purpose of MLS isolation, but there are no formal 

models for key management, nor even satisfactory heuristic implementations 

suitable for large scale cryptographically enforced MLS systems. 

B. Content-Based Information Security (CBIS) 

The CBIS-concept (Content-Based Information Security) experimented by 

US DoD between 2000 and 2005 as an Advanced Concept and Technology Dem-


441 

onstrator [15, 18] was aimed at the cryptographic solution of MLS. In CBIS, all 

the information is encrypted and signed, protecting the confidentiality and integrity 

of the document. 

The original CBIS effort was, however, abandoned as too expensive, possibly 

due to the constraints and difficulties in key management [1] and user authentication. 

The concept was revived in (at least) the Finnish military [12], where a different 

public-key management architecture (PKMA) was substituted for the PKI. 

The PKMA substituted in [12] was called identity-based cryptography 

(IBC, [6]). In IBC the identity itself acts as the public key, removing the need for 

certificates, enabling natural hierarchies and delayed creation for the private key. 

With IBC extensions, such as attribute-based encryption (ABE), it is possible to 

encode access structures directly to the ciphertexts. 

In the later CBIS concept, the actual content is endowed with different levels 

of metadata that can be used to embed security related information to the document 

itself, distributing the protection information from the reference monitor to 

the data itself. 

Adding metadata to the protected data blob implies the need to protect 

the metadata as well, and thus further levels of metadata. An obvious framework 

for dealing with intergrated data and metadata is eXtensible Markup Language 

(XML) framework. 

The work in [12] laid out several steps from moving traditional referencemonitor-based 

access control to cryptographically enforced, MLS-capable access 

control. These are depicted in Fig. 1. 

Figure 1. Moving from traditional access control to CBIS ([12]) 

In Fig. 1, the steps are not wholly sequential: e.g. attribute-based cryptography 

access control is trialled already as such ([17]), but it was deemed infeasible to leap 

to mostly academic technologies straight away. As can be seen, there will be a change 

of public-key cryptography paradigms, or key management architectures at some 

point. This alone places restrictions on how the actual hierarchical data should be 

structured, but it is also otherwise prudent to (functionally) separate content from 

security, and cryptographic key management from the rest of security functions 

as separate modules.


When we experiment with technologies in Fig. 1. from the third step onward, 

it is a prerequisite to fix essential parts of the actual structure of the content. This 

was our main motivation in creating an XML-schema for a CBIS document. 

C. The XML-framework 

The XML-framework refers here to set of standards and best practices of handling 

structured content based on the W3C standards around eXtensible Markup 

Language (XML, [19]). XML itself is a markup language using user-defined tags 

representing rules to encode documents [19]. 

XML schemas [7] represent a sort of grammar for certain types of documents, 

and can be used to check, whether a certain document conforms to a pre-specified 

rule-set (in this context: check if the document contains sufficient information to 

enforce and transmit parts of a security policy). 

XML encryption, XML signatures and XML key management ([11], [2] 

and [8]) are W3C standards to embed encrypted data blobs and digital signatures 

into an XML document, with the associated key management. 

Reference [5] presents an infrastructure and technologies for a similar trust 

model we are using. Basically, the model in [5] assumes several distinct roles, 

Owner, Publisher and Subject (producer, storage and reference monitor, and consumer 

of documents, respectively). The Publisher enforces access control of XMLdocuments 

with respect to the Subjects according to security policies provided 

by the Owner. The subject is able to verify that the documents are complete and 

unforged. The construction uses Merkle hash trees to compute per-element- and 

per-attribute hashes attached to the “security-enhanced” document. 

We use a similar construction to enforce integrity, however the approach 

is purely cryptographic. The approach in [5] involves filtering of documents based 

on the policies, such that the Subject is only delivered those parts of the document(s) 

she is entitled to. However, to be able to check the authentication values, the Subject 

needs to recompute the combined hash of all the nodes, whether or not she has access 

to them. This is enabled by providing the user with the structure of the immediate 

neighbourhood of her stripped subtree. The neighbourhood information 

not covered by the Subject policy is hidden with a hash-function. 

This approach is applicable for static, publish-only documents, where the Publisher 

does not have a data custodian role and there is no need to authenticate 

sub-document parts. In our setting, it is required to be able to revoke rights to 

the XML-document by editing the metadata containing symmetric cryptographic 

keys, change the document (and trace the changes), all of which in turn change 

the metadata-related hashes. We thus use the authentication model in [5] for content, 

but choose a different setup for the administration metadata. 

The approach in [5] also involves describing the subject policy in a separate 

structure obtained from the data owner and enforced with attribute certificates.


443 

In our approach, the subject policy is assumed to be encoded in the cryptographic 

metadata and handled by key management, without the need of a separate subjectowner 

negotiation. 

Embedding access control information in the XML-document itself has a number 

of possibilities, such as the policy-tag in [5] and specific XML-derivative languages 

[4]. The responsibility to enforce this information lies, however, with the data 

storage, and is usually insufficient with MLS. Of the XML-derivative languages it is 

stated in [21] that the whole concept of RBAC for XML is still immature. 

The XML framework is originally not designed to be used for MLS [20]. MLS 

in XML is somewhat tied to the data management systems available, but our work 

is independent from this. 

III. Environment assumptions 

A. Cryptographic Access Control 

Our work attempts to solve parts of the cryptographic access control (CAC) 

paradigm, in which traditional access control enforcement method with (implicitly 

trusted) reference monitors are replaced by cryptography. This shift is motivated 

by the high assurance demands on the enforcement method and the inherent lack 

of high assurance in the majority of the real-life reference monitors (such as commercial 

OSs) as well as by cloud computing. 

The CAC-paradigm benefits include more solid theory (and thus assurance) 

behind the actual implementations, and easier distributability of encrypted content 

into the cloud. Especially from the perspective of MLS, standardized encryption 

algorithms provide an accepted means of protecting classified data [10] and enforcing 

the isolation of different classes. 

Enforcing access control cryptographically requires a shift in the mindset 

as well: cryptography is not by itself able to enforce much anything. It has mainly 

two premises (in this context): 

• Cryptography can disable the READ-permission by making the material 

incomprehensible (it can not permit viewing per sé) 

• Cryptography can disable WRITE-permission by making it possible to 

detect unauthorized changes; it can not prevent bit-flips or deletions / 

insertions as such. 

Thus anything enforcable cryptographically should be able to be reduced to 

a set of read- and write-operations. 

B. Publish-Subscribe model 

We adopt the model depicted in [5] for third-party distribution of XMLdocuments, 

and introduce a “smart edge” acting in between the user and the cloud. 

The architecture is shown in Fig. 2.


The data is assumed to be stored in the “cloud”, i.e. somewhere else than where 

the actual creators, modifiers, viewers and removers of the data reside. This cloud 

has several storage providers, which collectively are assumed to have the following 

properties: 

The cloud focuses on availability, and there is always one “clean” copy of a desired 

document available (after some time or a number of checks). The cloud is not 

able to discern between clean and corrupted documents. The cloud is also able to 

push authorized changes to a document eventually to other copies throughout its 

sphere of influence 

Figure 2. Environment for the CBIS documents 

The roles related to handling of data are as follows: 

• Data Owner is responsible for the data and decides the access control policy 

and approves its change policy. Each document has a unique owner, who 

controls all the sub-elements of the document. 

• Users are the “consumers” of the data blob. A User has READ- and/or 

WRITE-permissions to a set of element. If the user has READ-permissions, 

she is able to decrypt the content; if she has WRITE-permissions, her edits 

can be considered valid via her digital signature. Some users can act on 

the behalf of the Owner, and have ADMIN-permissions (permissions to 

order changes to the permissions from the Filter) 

• Storage is one element in the cloud where the documents physically may 

reside. Storage servers are not trusted to view or modify (including filtering 

and other reference monitor duties) content, but they are trusted to handle


445 

versioning and storage functions. Storage does not perform high-assurance 

authentication of document requests, so it is assumed to be easy to bypass 

the Filter-edge of the cloud. 

• Filters form the “smart edge” of the cloud. They relay the functions between 

Users, Owners and Storage. Filters are semi-trusted in that they are 

allowed to perform administrative functions inside a document, but they 

are not trusted to see or alter the actual content or the security policy. Filters’ 

primary objective is to exercise RTK-level control to the content, and 

remove those parts of the document the User is not cleared to. User must 

be able to check the completeness of the document, so Filter must provide 

her with sufficient verification information. 

IV. Schema design principles 

A. Previous work 

The definition work on CBIS, [12], identified some necessary elements and their 

interrelations on the structured document. However, these were purely motivated 

from the CBIS needs, and not very detailed or standard-oriented. 

The actual structured format was canonized and integrated into other data 

models in an internal work together with Finnish defence industry [14]. This 

resulted in an actual schema, but too heavily tied to existing PKI and referencemonitor-based 

thinking (it could not enforce actual CAC). Furthermore, the first 

version of the schema did not elaborate the effect of dynamic compound signatures 

resulting from the need to restructure the document passing an MLS-filter (which 

removes classified parts exceeding the User’s clearance). 

B. Design principles: key managent architecture independency 

The main motivation for this work was to establish a concrete and canonized 

specification for the CBIS document structure that would last over the different 

developmental phases and public-key management architectures. Thus there 

is a type of cryptographic interface the schema should comply to. This interface 

is constructed based on the least common denominator (of the PKMAs): 

• Content is enciphered with a block cipher and the block cipher key (block 

key) itself is encrypted. The schema should not make more reservations 

than this to the key management. 

• Content can be represented by the output of a secure hash-function 

• The content integrity is enforced by signatures (but their exact type is not 

specified) 

• If the permission type is WRITE, the space occupied by the block key is used 

to host the public key needed for verification. Note that the User Agent


may or may not use this key – this depends on the exact trust model tied 

to the PKMA. 

• If the PKMA mandates the use of certificates, these are included in the signature-element. 

Certification information required for delegation are 

an exception for this rule (discussed below). 

• The schema may make provisions to embrace extensions of a certain PKMA 

type, provided they do not exclude other PKMAs from the same function. 

In practice, these include: 

✓ The block key may be encrypted several times by different public keys, 

and these listed independently. The encrypted data blob should not give 

preference to any of these. 

✓ The role information may be a single identifying string, a list of roles, 

or a (propositional) logic expression involving roles, activities and other 

restrictions. 

C. Design principles: signing 

The construction of our CBIS schema follows the principles outlined 

in [12], with one major distinction about the signatures. The distinction concerns 

the signatory role: whereas in [12] this role was always equated with the key 

management center, we implement three different roles: Owner/ADMIN-User, 

WRITE-User and Filter. In the structured document itself this is reflected 

as content-signatures and metadata signatures, which must thus be independent 

of each other. 

The trust model used here dictates that the administrative restructuring 

of the document should not reveal or modify the actual content, thus the content 

and administrative signatures (data vs. metadata) should be independent. However, 

in [12] it was not clear how to automatically compute compound signatures for 

restructured content with the authority of the Owner. The book suggested using 

delegation with attribute certificates. 

The work in [5] presents a brilliant solution to retain the compound signatures 

constant throughout the whole tree-structure of an XML document. Using this 

approach, we are able to keep the content signatures unmodified (by administrative 

components). 

In addition to the Owner, WRITE-Users are allowed to legally modify the data. 

This is accomplished through a list of users with WRITE-permission on an element. 

Technically this means that upon opening a document, the User Agent 

checks at least the content signatures, and if the signatory is either the Owner 

(the only completely trusted party) or another user with WRITE-permissions 

listed in the metadata, the signature is accepted as valid. 

To enforce the WRITE-permissions list, the whole element containing the list 

(cbis:securityAttribute) is signed by an ADMIN-user.


447 

The Filter signs parts of the document security metadata (History-related). 

As the Filter is only semi-trusted, and ADMIN-users may have conflicts of interests, 

different public keys need a validity certification from the Owner. 

The Filter validity certification is required irrespective of the PKMA. We assume 

for simplicity that the correspondence between Owner and a document is oneto-many 

(instead of many-to-many). Thus the validity certification can be placed 

in the per-document metadata element. Furthermore, the schema doesn’t specify 

the form of the certification – it could be a PKI certificate, IBC-based delegation (e.g. 

with a public key of the type “Owner X grants admin privileges to 

Filter Y”, which is verifiable with the Owner X public parameters and the claimed 

string only), or something else, as long as it contains sufficient cryptographic strength. 

In order to separate the administration and content, some cryptographic 

conventions need to be observed: 

• The need to separate non-repudiation and basic integrity signatures 

is PKMA-dependent, so the number of signatures is left open here, and 

the types of signatures are listed as widely as needed. 

• Layered encryption (super-encryption, encrypting already enciphered content) 

is not used. Opening administrative metadata would require additional 

layers of filters and/or key management. In [12] and [11] super-encryption 

is defined – the purpose here could be embedding other documents or hiding 

the access control information – but we leave it out here for simplicity. 

D. Design principles: versioning 

The main document is assumed to be modifiable. There are two types of modification 

possibilities: content modification and permission type modification. 

In each case, the CAC paradigm entails that since the actual modifications cannot 

be prevented (only detected), there should be a possibility of rollback and attribution 

(finding the perpetrator). 

Rollback requires versioning and storage of the previous versions. Content 

versioning is considered to be outside the scope of this paper – it can be done 

by creating a separate document per committed modification and transferring 

the versioning burden to the Storage (as it should be optimized for availability). 

Per-element versioning does affect the CBIS schema itself, and this is considered 

more of a document management than a security issue. Per-element versioning 

should bind the content signature together with the content – thus we do not consider 

content signature versioning either here. 

Attribution has two facets: illegal modifiers of content and security policy. 

If content is modified meaningfully, it implies than legal keys of some user are 

used. This in turn can be traced back to the user identity by comparing different 

versions and signature information. Thus content modification attribution is built 

in to the signatures (enforcing non-repudiation) and versioning.


Attribution in the context of security policy breaks requires keeping a log 

of the changes made to the permissions. A security policy break translates into 

unauthorized insertion, removal or modification of security metadata. This can include 

(but are not limited to): Insertion of additional block keys (to leak information); 

Insertion of additional public keys (to enable modification); Downgrading 

the (MLS-related) classification labels; Changing or adding administrator information 

and certification. 

To enforce attribution and rollback of the security metadata, we introduce 

per-element metadata-history to the schema. Rollback cannot naturally be fully 

realized, if the whole history-information is deleted from the document, but this 

is left for the availability-function of the Storage (cloud), and outside the scope 

of the schema. 

The metadata history is always signed as a whole by the Filter itself. This is because 

of the principle of separation of duties: roles administering security policy 

should not also track the changes made by themselves. 

Metadata history contains copies of the security metadata appended with 

a timestamp and identity of the original signatory of that particular instance 

(an ADMIN-User or the Owner). 

The ADMIN-user or (originally) the Owner is responsible for creating and 

changing the security policy reflected in the security metadata. The principle 

in the modification is to create a new copy based on the old metadata and move 

the old copy to the history. The responsibility for the metadata is reflected in a subelement 

of the security metadata structure, containing the list of the administrator 

roles, and finally a signature by one of these administrators. Administrator role 

information must include a PKMA-dependent certification from the Owner. 

E. Design principles: MLS considerations 

Multi-level security is considered here from the document perspective only. 

The CBIS-schema presented here does not account for the User clearance – if IBCbased 

PKMA is used, the user clearance can be encoded in the encrypted block 

key, but for other PKMAs this is left for the application. (Which is why we recommend 

using IBC to achieve a fuller cryptographic enforcement of the security levels 

than just key management.) 

The security label exists in the document metadata. Its correctness is enforced 

by an ADMIN-user’s signature (together with a delegation certification from 

the Owner) and it is bound to the content by the compound signatures of the content 

and metadata. (Signed by the Filter, as this is an administrative function). 

The security label presents a performance issue in the XML-document tree 

hierarchy, if the structure is very fine-grained ([12, 14]): in order to establish 

if a user has clearance to the lowest levels of the hierarchy, all of the nodes need 

to be traversed. To enable more efficient processing, two strategies are possible:


449 

• Structure the document according to the security labels, leaving the natural 

structuring to be automated “somehow” or, 

• Include additionals elements for informational purposes, which declare 

the highest and lowest classification levels of the subelements. If the User’s 

clearance is higher (or equal) than the highest classification of the subelements, 

the whole subtree can be copied to the filtered document. However, 

if the user’s clearance is lower than the lowest element, the whole subtree 

can be pruned. If these are left unspecified or user clearance lies in between 

these two, the subtree needs to be traversed at least one level further. 

The first alternative provides simpler bookkeeping on the security levels, but 

would likely result in a nightmare in recreating the original document. Thus we 

chose the latter alternative, even though it requires some bookkeeping in the document 

creation and modification phase. 

The correct enforcement of MLS is checking that information does not leak 

from “high” to “low” domains, which in this context means: 

• Labels are correctly bound to their content: this is partly the responsibility 

of the original document creator; after that it is enforced by a per-element 

compount signature by the Filter and the per-security attribute signature 

by an ADMIN-user 

• No highly classified information can be viewed by persons with lower 

clearance: the contents are cryptographically separated, and if the lower 

clearance user is not allowed the keys of the content out-of-her-bounds, 

the probability of leaks reduces to that of breaking the cryptographic primitives 

or incorrect key management. 

F. Design principles: hierarchy 

As the CBIS document includes multiple types of signatures, their characteristics 

may become blurred, if the signature types and their targets are not pinned 

down in the XML document tree hierarchy. We then make the following hierarchical 

conventions (Fig. 3): 

• There is one main element type hosting the main body of CBIS-related 

information (cbis:element), and another type hosting all the security 

metadata (cbis:securityMetadata). 

• The content is an immediate child of cbis:element 

• Security metadata is an immediate child of cbis:element 

• The content-related signatures are immediate children 

of cbis:securityMetadata. 

• The compound signature of all the subelements of an cbis:element 

is an immediate child of that element’s cbis:securityMetadata. 

The signed subelements include also possible children of the type 

cbis:element.


Figure 3. Hierarchical conventions of the CBIS schema 

If super-encryption would be used, it would also make sense to define access 

control lists for the first-order access control information (metadata of metadata, 

or meta-metadata). Even in more theoretical work ([12]), the metalevels are recommended 

to be restricted to at most two, and we are using only one level. 

For versioning purposes, it is not necessary to archive all security metadata. 

More specifically, if signatures concern the content as well, they were considered to be 

out of scope. Thus we introduce yet another level, cbis:securityAttribute, 

which hosts all the data meant to be archived. 

The XML-document and architecture model [5] consider only hashes of the elements, 

and only the hash of the document whole is eventually signed. Our 

model considers a more interactive setting, and allows the document to be more 

fine-grained. We then sign each level (certain types of elements) individually, and 

the compound sub-documents hierarchically. 

V. The CBIS schema 

The actual schema is presented here with Fig. 4. for brevity. The Figure depicts 

what an XML-formatted CBIS-document would look like, but with element and 

type names, enumerations and type definitions. 

Legend for Fig. 4 is as follows: 

• Multiple labels “behind” the first one indicate that multiple instances are 

allowed 

• Dashed line round the label indicate a set of optional elements. If there are 

multiple dashed-line labels, there can be more than one optional element 

• ENUM labels represent XML schema restriction on a specific type 

• TYPE labels represents inheritance from another type, depicted the way 

a C-language structure would: the parent type is included in the child type


451 

Although we do not consider them here, the possible additional levels of metadata 

are easily added as another (recursive) children of cbis:securityMetadata. 

The new type cbis:Signature is inherited from W3C XML-signatures 

type ds:Signature by adding a type qualifier. It should be noted that while 

ds:SignatureMethod requires fixed mandatory and a number of optional 

implementations, user-specified algorithms may be used as well, and this allows 

also n-tuple signature-values (though under one identifier only). 

The following (extra) namespaces are used: 

• xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”, 

the XML-signature types (specifically, ds:Signature). This is the base 

type of cbis:Signature, and is used mainly to differentiate between 

different versions of integrity, if the public key management architecture 

so requires (in addition to containing the actual signature value). 

• xmlns:xenc=”http://www.w3.org/2001/04/xmlenc#”, 

the XML-encryption types (specifically, xenc:encryptedData and 

xenc:encryptedKey). It should be noted that we use one-to-many 

relation from the encrypted data blob to the encrypted key, which may not 

directly be supported by standard implementations. Thus we leave the link 

from the encrypted key to the actual element one-way only, and leave it to 

the application (here: the user agent or filter) to decide which key to use 

based on the related information in cbis:AccessSet. 

• wsml=”http://www.wsmo.org/wsml/wsml-syntax#” 

the cbis:roleExpression is extended from a single role-identifier 

to a propositional logic formula (to support more expressive PKMAs). 

Actually, the wsml:logicalExpression – schema checks for first 

order logic, but the application-level function should ignore any quantifiers 

it finds. 

In the application space, the decrypting / verifying component (most commonly 

the User Agent) must interpret the cbis:permission to mean how to 

use the associated cryptographic key: 

• If the permission is READ, that particular role’s (or a logical expression 

involving roles and activities) private key is able to open the block key. 

• If the permission is WRITE, the encryptedKey-structure contains 

information about the public key related to the role or logical expression 

involving roles and activities, or the public key itself (in unencrypted 

form). In either case, the public key indicated by the role is only one 

of the possibilities used to verify the element’s content signature. There may 

be only one such, but in general case it could be anyone’s who is granted 

the write-permissions to this particular element. The verifier should try 

to verify the signature with all those public keys, which have a permission 

of type WRITE. If any one of them passes, the element should be 

accepted as valid.


Figure 4. The CBIS XML schema structure 

Filtering means the process of stripping the document clean from those 

elements to which the user’s clearance does not entitle her. This is performed on 

the element-granularity level, and based on the cbis:elementClassification 

element (and derivatives). If a cbis:element does not pass the Filter-component, 

it is first checked if the cbis:element lies on a direct path from the document 

root to an allowed element or is a sibling of such a cbis:element. 

In such a case, the cbis:element is included, but it is stripped of all optional 

fields and mandatory fields are set to empty, NULL or default values. The content- 

Signature-element of the type UNSIGNED CONTENT HASH, is however included. 

This signature type is assumed to contain the compound hash of the element and its 

subelements in the form of Merkle hash tree nodes (see [5] for details). 

According to [5], the compound hashes can then be used on the documentlevel 

to calculate the original signature, and compare that to the cbis:docume 

ntIntegritySignature of type CONTENT INTEGRITY. This way the User 

Agent can first verify that the content in general is complete and valid, and after 

that check individual elements’ validity. 

Writing changes to a partial document and integrating them back to the original 

is partially versioning a document, but mainly requires a reasonable amount of book-


453 

keeping from the Filter, which needs to 1) Fetch a latest version of the whole document 

from the Storage (cloud); 2) Identify changed elements by their UNSIGNED 

HASH CONTENT signature-elements and their correct location in the tree – it is 

assumed the User Agent makes use of the tree structure it received from the Filter 

(it cannot, for example, remove or relocate parts that contain subelements inaccessible 

to it); 3) Replace contents, and their respective WRITE-User and ADMIN-user 

signatures; 4) Update security attribute history (recompute the signature as well); 

5) Create a new document version (if versioning is in use); and 6) Recompute 

the compound element integrity signatures, where elements are merged; recompute 

all compound hash values. 

VI. Conclusion 

In this paper we introduced and canonized a structured content format complying 

to multi-level security practices and the cryptographic access control paradigm. 

The format was aligned with the XML-standard. We explored the motivation 

behind different types of elements and their relatios, as well as the operation with 

such a structured document. Our approach was independent of the keying architecture. 

Future work includes e.g. many open questions from the re-construction 

of a modified document. On a different track, there is also the task to implement 

a schema validator and appropriate Filter components for the document. 

References 

[1] E. Barker, W. Barker, W. Burr, W. Polk, and M. Smid, “Recommendation for Key 

Management – Part 1: General (Revised)”, NIST Special Publication 800-57, NIST, 

March 2007. 

[2] M. Bartel, J. Boyer, B. Fox, B. LaMacchia, and E. Simon, “XML-Signature Syntax 

and Processing, W3C Recommendation 12.2.2002”, in http://www.w3.org/TR/2002/ 

REC-xmldsig-core-20020212/Overview.html, World Wide Web Consortium, 2002 

(retrieved 23.4.2012). 

[3] D. Bell, L. LaPadula, “Secure Computer Systems: Mathematical Foundations”, 

MITRE Technical Report 2547, vol. I, 1.3.1973. 

[4] E. Bertino, S. Castano, and E. Ferrari, “On Specifying Security Policies for Web 

Documents with an XML-Based Language,” in Proc. Sixth ACM Symp. Access Control 

Models and Technologies, pp. 57-65, 2001. 

[5] E. Bertino, B. Carminati, E. Ferrari, B. Thuraisingham, and A. Gupta, “Selective 

and Authentic Third-Party Distribution of XML Documents”, in IEEE Transactions 

on Knowledge and Data Engineering, vol. 16, no 10, pp. 1263-1278, October 2004. 

[6] D. Boneh, M. Franklin, “Identity based encryption from the Weil pairing, extended 

version”, in SIAM J. of Computing, vol. 32, no. 3, pp. 586-615, 2003.


[7] D. Ezell et al. “XML Schema”, in http://www.w3.org/XML/Schema, World Wide 

Web Consortium, 2004 (retrieved 23.4.2012). 

[8] W. Ford, et al., ”XML Key Management Specification (XKMS), W3C Note 13.3.2001”, 

in http://www.w3.org/TR/xkms/ World Wide Web Consortium, 2002 (retrieved 

23.4.2012). 

[9] W. Harrison, N. Hanebutte, P. Oman and J. Alves-Foss, “The MILS Architecture 

for a Secure Global Information Grid”. in CrossTalk 18 (10): pp. 20-24. http://www. 

crosstalkonline.org/storage/issue-archives/2005/200510/200510-Harrison.pdf, 

October 2005 (retrieved 23.4.2012). 

[10] L. Hathaway, “National Policy on the Use of the Advanced Encryption Standard 

(AES) to Protect National Security Systems and National Security Information”, http:// 

csrc.nist.gov/groups/ST/toolkit/documents/aes/CNSS15FS.pdf, June 2003 (retrieved 

23.4.2012). 

[11] T. Imamura, B. Dillaway, and E. Simon, “XML Encryption Syntax and Processing, 

W3C Recommendation 10.12.2002”, in http://www.w3.org/TR/xmlenc-core/, World 

Wide Web Consortium, 2002 (retrieved 23.4.2012). 

[12] M. Kiviharju, Content-Based Information Security (CBIS): Definitions, Requirements 

and Cryptographic Architecture, Riihimäki: Defence Forces Technical Research 

Centre, 2010. 

[13] M. Kiviharju, “Towards Pervasive Cryptographic Access Control Models”, in Proc. 

SECRYPT 2012, in press. 

[14] J. Lamminmäki, “DR201R01: CBIS-skeema, Loppuraportti.” Final Report for Finnish 

Defence Forces, Insta DefSec, 8.12.2010. 

[15] S. McGovern, “Information Security Requirements for a Coalition Wide Area 

Network”, Thesis in Naval Postgraduate School, Monterey, California (June 2001), 

http://cisr.nps.edu/downloads/theses/01thesis_mcgovern.pdf, NPS/CISR, 2001, 

(retrieved 23.4.2012). 

[16] NIST-CSRC, “CSC-STD-004-85, Technical Rational Behind CSC-STD-003-85: 

Computer Security Requirements (Yellow Book)”, in http://csrc.nist.gov/publications/ 

secpubs/rainbow/std004.txt, CSRC, NIST, pp. 9-13, 25.6.1985 (retrieved 23.4.2012). 

[17] M. Pirretti, P. Traynor, P. McDaniel, and B. Waters, “Secure Attribute-Based 

Systems”, in Proc. Of CCS 2006, pp. 99-111, ACM, 2006. 

[18] J. Savoie, “A Strong three-factor authentication device: TrustedDAVE and the new 

Generic Content-Based Information Security (CBIS) architecture”, Technical 

Memorandum TM 2004-198, DRDC Ottawa, http://pubs.drdc.gc.ca/PDFS/unc32/ 

p522843.pdf, DRDC Canada, November 2004 (retrieved 23.4.2012). 

[19] C. Sperberg-McQueen et al., “Extensible Markup Language (XML)”, in http:// 

www.w3.org/XML/Overview.html, World Wide Web Consortium, September 2006 

(retrieved 23.4.2012). 

[20] B. Thuraisingham, Building Trustworthy Semantic Webs, Boca Raton, FL: Auerbach 

Publications, 2008. 

[21] ibid. p. 118. 

[22] K. Poulsen, K. Zetter, “U.S. Intelligence Analyst Arrested in Wikileaks Video 

Probe”, in ‘Threat Level’ blog, http://www.wired.com/threatlevel/2010/06/leak/, Wired, 

6.6.2010 (retrieved 23.4.2010).

Generation of Nonlinear Feedback Shift Registers 

with Special-Purpose Hardware 

Tomasz Rachwalik, Janusz Szmidt, Robert Wicik, Janusz Zabłocki 

Cryptology Division, Military Communication Institute, Zegrze, Poland, 

t.rachwalik@wil.waw.pl 

Abstract: The nonlinear feedback shift registers (NLFSR) are used as primitives in cryptographic 

algorithms. Their theory is not so complete as that of the linear feedback shift registers (LFSR). 

In general, it is not known how to construct NLFSRs with maximum period. The direct method is to 

search for such registers with suitable properties. We used the implementation of NLFSRs in Field 

Programmable Gate Arrays (FPGA) to perform a corresponding search. We also investigated local 

statistical properties of the binary sequences generated by NLFSRs of order 25 and 27. 

Keywords: Nonlinear feedback shift registers. Maximum period. Linear complexity. Hardware implementation. 

Randomness properties 


Feedback shift registers (FSR) sequences have been widely used in many 

areas of communication theory, as key stream generators in stream ciphers cryptosystems, 

pseudorandom number generators in many cryptographic primitive 

algorithms, and testing vectors in hardware design. Golomb’s book [5] is a pioneering 

one that discusses this type of sequences. A modern treatment of the subject 

is contained in Golomb and Gong [6]. 

The theory of linear feedback shift registers (LFSR) is understood quite well. 

In particular, it is known how to construct the LFSRs with maximum period; 

they correspond to primitive minimal polynomials over the binary field GF(2). 

The primitive LFSRs have a drawback as their linear complexity is equal to their 

order. In recent years, nonlinear feedback shift registers (NLFSR) have received much 

attention in designing numerous cryptographic algorithms such as stream ciphers 

and lightweight block ciphers to provide security in communication systems. In most 

cases, NLFSRs have much bigger linear complexity than LFSRs of the same order. 

However, not much is known about cyclic structures of NLFSRs; most of the known 

results are collected in Golomb’s fundamental book [5]. 

We used the implementation of NLFSRs in Field Programmable Gate Arrays 

(FPGA) to perform a search of NLFSRs of the order up to n = 27, the maximum


period equal to 2 n − 1 and a possibly simple algebraic structure of the feedback 

function. We also investigated local statistical properties of the binary sequences 

generated by NLFSRs of order 25 and 27. We hope to continue this research further. 

II. Feedback Shift Registers 

In this section, we give definitions and basic facts about feedback shift registers 

(FSR). We use GF(2) to denote the binary finite field. GF(2)[x] denotes the ring 

of polynomials in the indeterminate x and with coefficients from GF(2). Let V n 

be the n-dimensional vector space over GF(2) consisting of the n-tuples of elements 

of GF(2). Any function from V n to GF(2) is referred to as a Boolean function 

on n variables. A sequence of elements s = (s 0 , s 1 , ...) of GF(2) is called a binary 

sequence. A sequence s = ( s i 

) 

i 

is called periodic if there is a positive integer p 

such that s i+p = s i for all i ≥ 0. The least positive integer with this property is called 

a period. 

A binary n-stage feedback shift register is a mapping F from V n into 

V n of the form 

F : (x 0 , x 1 , ..., x n−1 ) → (x 1 , x 2 , ..., x n−1 , f(x 0 , x 1 , …, x n−1 ), 

where f is a Boolean function on n-variables which is called the feedback function. 

The shift register is called a linear feedback shift register (LFSR) if F is a linear transformation 

from the vector space V n into itself. Otherwise, the shift register is called 

a nonlinear feedback shift register (NLFSR). The shift register is called nonsingular 

if the mapping F is a bijection. Further, we will consider only nonsingular and mostly 

nonlinear feedback shift registers. It can be proved (see e.g. [5]) that the feedback 

function of a nonsingular feedback shift register has the form 

f(x 0 , x 1 , …, x n−1 ) = x 0 + g(x 1 , ..., x n−1 ), (1) 

where g is a Boolean function on n − 1 variables. 

Consider a binary sequence s = ( s i 

) 

whose first n terms s i 0, s 1 , ..., s n−1 are 

given and whose remaining terms are uniquely determined by the recurrence relation 

s i+n = f(s i , s i+1 , ..., s i+n−1 ) for all i ≥ 0. (2) 

We call s an output sequence of the feedback shift register given by (1). 

The binary n-tuple (s 0 , s 1 , ..., s n−1 ) is called the initial state vector of the sequence 

s or the initial state of the feedback shift register. The recurrence relation (2) 

can be implemented in hardware as a special electronic switching circuit consisting 

of n memory cells which is controlled by an external clock to generate the sequence 

s (see Figure 1).


457 

Figure 1. A block diagram of a Feedback Shift Register 

The period of an output sequence of a binary n-stage nonsingular FSR is at 

most 2 n . There are some sequences with maximum period. 

Definition 1. The de Bruijn sequence of order n ( , ..., a n 

2 

) of elements 

1 

from the binary field GF(2) is a sequence of period 2 n in which all different n-tuples 

appear exactly once. 

It was proved by Flye Sainte-Marie [3] in 1894 and independently by de 

Bruijn [1] in 1946 that the number of classes of cyclically equivalent sequences 

satisfying the Definition 1 is equal to 

n 

2 n 

. 

(3) 

B n 

Definition 2. The modified de Bruijn sequence of order n ( , ..., a n 

2 

) 

2 

is a sequence of period 2 n − 1 obtained from the de Bruijn sequence of order n by 

removing one zero from the tuple of n consecutive zeros. 

In 1990 Mayhew and Golomb [10] investigated sequences satisfying the Definition 

2 and their linear complexity. These sequences were called by Gammel 

et al. [4] the primitive sequences. In the case of linear feedback shift registers these 

sequences are generated by primitive polynomials and their theory is understood 

quite well [8]. The primitive sequences are very important in cryptographic applications 

since: 

1. They exist. There are B n primitive sequences altogether (the linear and nonlinear 

ones). The number of primitive LFSRs is equal to 

n 

(2 1) , 

n 

where φ denotes the Euler phi function, hence there are much more NLFSRs 

than LFSRs. 

2. The primitive sequences have good statistical properties. They satisfy Golomb’s 

main postulates. The linear complexity of a NLFSR (the order of a LFSR generating 

the same sequence) is much bigger than 2 n−1 and many of them have 

the most possible linear complexity equal to 2 n – 2. Let us recall that the linear 

complexity of a primitive LFSR of order n is just equal to n.


3. There are primitive NLFSRs for which the Algebraic Normal Form 

of the Boolean function g in formula (1) is quite simple; it has low algebraic 

degree and a possibly small number of terms. Since there are 2 2n−1 different 

Boolean functions on n – 1 variables, hence the probability that a randomly 

chosen function of the form (1) is a primitive NLFSR is equal to 

n1 

2 n 

and as n grows it becomes smaller. 

2 1 

n1 

 

2 

n 

2 2 

The task is to find primitive NLFSRs with a possibly simple algebraic form and 

this is much more difficult. A method how to construct such primitive NLFSRs is not 

known and we have to search for them. Gammel et al. [4] found simple primitive 

NLFSRs up to the order 33 and they used them in the design of the stream cipher 

Achterbahn, but neither the method of searching nor the average time needed to 

find such good NLFSRs have been revealed. 

It is also an open problem to prove lower bounds of the linear complexity 

of NLFSRs. Mayhew and Golomb [10] investigated all modified de Bruijn sequences 

of order 5 and 6; there are 2 11 = 2048 and 2 26 of them, respectively. It appears that 

there is a very small number of such sequences with low linear complexity. In the case 

of n = 5, there are no NLFRSs with linear complexity equal to 10 and there are only 

10 sequences with linear complexity equal to 15. One can form a conjecture that for 

the order n of NLFSR being a prime number the lower bound of the corresponding 

linear complexity is equal to 3n. It is implied by a more general conjecture formed 

in Kyureghyan’s paper [7] and the results of [10]. The upper bound of the linear 

complexity of NLFSRs is 2 n – 2 and this bound is tight. We calculated the linear 

complexity of the NLFSRs no 1÷4 given in section V and it is equal to 2 25 – 2 for 

all of them. There is a recent interest in searching for and constructing primitive 

NLFSRs suitable for cryptographic applications, see [2], [9], [13]. 

III. The FPGA implementation 

We implemented an algorithm for searching nonlinear feedback shift registers 

of order n having maximum period 2 n − 1 using hardware devices from our previous 

projects. They were equipped with Altera EP3C80 Field Programmable Gate 

Arrays. We used Altera Quartus II v.9.0. design software to simulate and compile 

the current project. 

The random NLFSR searching module (RNSM) consists of a random number 

generator (RNG), a coefficients selector (CS), a coefficients buffer (CB), multiplexers 

and XOR block (M&X), a shift register (SR), and a verification machine (VM). 

Random numbers are taken from the RNG. Coefficients are downloaded byte by 

byte into the CS, where their values and repetitions are controlled. Then the bytes


459 

go to the CB, whose task is to store combinations of coefficients during the test. 

The multiplexers define the feedback function of NLFSR according to the data 

buffered in the CB. Their outputs are connected to the XOR gate. Next, the output 

of the XOR function feeds the SR. The SR is set with a seed value at the beginning 

of a searching process by the VM and it starts to shift. After the first repetition 

of the seed the test is finished. A positive result is sent to the Ethernet Interface (EI), 

which is the same for all implemented modules. A negative result starts a new 

process of random generation and testing. 

Figure 2. A single module of the searching machine 

The attempts to find NLFSR were made by drawing 32 taps. Four of them 

feed a four-input AND gate. There are also two three-input AND gates and four 

two-input AND gates. We also implemented a version with 40 taps but there are 

not any results up to now. 

Figure 3. The structure used to generate NLFSR 

A single RNSM provides a superior search compared to the application 

of the same functionality embedded in a fairly efficient PC. For example, to obtain 

NLFSRs of order 15 with period 2 15 – 1, we had to wait on average 3 seconds 

using the RNSM, whereas working on a PC it took 5 minutes. During our search for 

NLFSRs of order 25 and 27 with maximum periods 128 RNSMs were implemented 

in four physical devices. The 32 modules implemented in a single device worked


and stored results independently. The four devices were connected to a hub and 

a personal computer (PC) with the Wireshark sniffer. The FPGA was clocked with 

65.536 MHz, although the maximum possible clocking is 128 MHz. The average 

time to find one NLFSR of order 25 was 4 hours and the average time to find one 

NLFSR of order 27 was 21 hours, respectively. 

IV. Randomness properties 

The purpose of this section is to check experimentally the randomness properties 

of subsequences of the sequences generated by NLFSRs of section V. The modified 

de Bruijn sequences of order n have period 2 n −1 and all different n-tuples appear 

only once, except the all-zero tuple. The whole sequence generated by NLFSR 

should have good statistical properties; since there is a nonlinear feedback, we also 

decided to check the statistical properties locally, for subsequences generated by 

NLFSR starting from randomly chosen initial state vectors. Let s = (s 0 , s 1 , ..., s m−1 ) 

be a binary sequence of length m. We test the randomness using seven basic statistical 

tests from [11], [14]. These are: 

1. Frequency test – the purpose of this test is to determine whether the number 

of 0’s and the number of 1’s in the investigated sequence s are approximate 

the same, as it would be expected for a random sequence. 

2. Serial test – the purpose of this test is to determine whether the number 

of occurrences of 00, 01, 10, 11 as subsequences of s are approximate 

the same, where the subsequences are allowed to overlap. 

3. Two bit test – it verifies whether the number of occurrences of subsequences 

00, 01, 10, 11 are approximate the same, where the subsequences are not 

overlapping. 

4. 8-bit poker test – it verifies whether bytes of each possible value appear 

approximate the same number of times in the sequence s. 

5. 16-bit poker test – it verifies whether 16-bit words of each possible value 

appear approximate the same number of times. 

6. Runs test – the purpose of this test is to determine whether the number 

of runs of either zeros or ones of various lengths (here from 1 to 22 bits) 

in the sequence s are as expected for a random sequence. 

7. Autocorrelation test – the purpose of this test is to check for correlations 

between the sequence s and shifted versions of it (here by 1,2, ..., up to 8 bits). 

The tests 1÷6 use as a reference distribution the chi-square distribution 

with suitable number of degree of freedom and the seventh test uses the standard 

normal distribution. The observed frequencies of events are compared with their 

expected frequencies. We do not use hypothesis testing in a classical manner, 

where the hypothesis H 0 is verified using the calculated statistics. All events are 

possible, so we split the calculated statistics into 8 classes from A to H according 

to the range of significance level. The class A identifies a group of the best statistics


461 

and the class H identifies the worst case in terms of randomness, but all cases are 

possible with suitable probabilities as it is shown in the Table I. 

Table I. Percentages of appearances of classes 

Classes A+B+C A B C D E F G H 

% 95 80 10 5 2.5 1.5 0.5 0.4 0.1 

We tested subsequences produced by NLFSRs of section V starting from 

randomly selected initial states. First, we generated the full period sequences and 

then each sequence was divided into subsequences of 2 20 bits each: 

• 4 . 2 5 = 128 binary subsequences for NLFSRs of order 25 (NLFSRs no 1÷4) 

• 3 . 2 7 = 384 binary subsequences for NLFSRs of order 27 (NLFSRs no 5÷7) 

The obtained results of experiments are given in Table II. The column 

No contains numbers of NLFSR from section V. Columns % of classes contain 

percentages of appearances of classes A÷H of statistics for examined subsequences 

taken from 7 NLFSRs. It shows that the percentages of classes for 

1 Mbit subsequences are similar to the expected appearances of classes for random 

sequences (see Table I). These results indicate that the examined NLFSRs 

have good statistical properties. 

Table II. Percentages of appearances of classes of subsequences 

% of classes 

No 

A+B+C A B C D E F G H 

1 94.64 81.70 8.04 4.91 1.79 2.23 0.89 0.45 0.00 

2 94.20 81.25 8.04 4.91 3.13 1.34 0.45 0.89 0.00 

3 95.98 86.61 5.80 3.57 1.34 2.68 0.00 0.00 0.00 

4 96.43 82.14 8.93 3.36 2.23 1.34 0.00 0.00 0.00 

5 94.64 78.79 10.16 5.69 2.68 1.23 1.00 0.33 0.11 

6 95.98 80.25 11.94 3.79 2.23 0.67 0.78 0.33 0.00 

7 95.20 82.59 8.71 3.91 3.01 1.00 0.22 0.22 0.33 

V. Examples of NLFSRs 

The NLFSRs of order 25: 

1 : x 0 + x 8 + x 9 + x 10 + x 11 + x 19 + x 20 + x 21 + x 23 + x 6 x 21 + x 10 x 14 + x 12 x 20 + 

+ x 19 x 20 + x 4 x 18 x 21 + x 11 x 18 x 22 + x 1 x 5 x 7 x 23 

2 : x 0 + x 6 + x 7 + x 8 + x 11 + x 14 + x 15 + x 18 + x 19 + x 5 x 10 + x 7 x 21 + x 11 x 16 + x 12 x 17 + 

+ x 1 x 10 x 18 + x 15 x 17 x 22 + x 8 x 10 x 15 x 18


3 : x 0 + x 6 + x 12 + x 13 + x 16 + x 20 + x 21 + x 22 + x 3 x 18 + x 13 x 19 + x 13 x 20 + x 5 x 12 x 20 + 

+ x 8 x 18 x 22 + x 12 x 15 x 21 

4 : x 0 + x 6 + x 11 + x 14 + x 16 + x 17 + x 18 + x 19 + x 23 + x 4 x 19 + x 4 x 21 + x 5 x 22 + x 9 x 19 + 

+ x 1 x 17 x 23 + x 5 x 7 x 18 + x 5 x 12 x 19 

The NLFSRs of order 27: 


+ x 22 x 23 + x 7 x 8 x 24 + x 12 x 14 x 26 + x 6 x 11 x 19 x 22 

6 : x 0 + x 1 + x 8 + x 10 + x 11 + x 12 + x 17 + x 19 + x 21 + x 22 + x 23 + x 6 x 25 + x 9 x 15 + 

+ x 18 x 23 + x 23 x 26 + x 2 x 20 x 21 + x 13 x 21 x 23 + x 5 x 18 x 19 x 23 


+ x 16 x 25 + x 24 x 25 + x 15 x 25 x 26 + x 8 x 10 x 25 x 26 


We used the implementation of Nonlinear Feedback Shift Registers in Field 

Programmable Gate Arrays to perform a search of NLFSRs of the order up to 

n = 27, the maximum period equal to 2 n – 1 and a possibly simple algebraic form 

of the feedback function. The structure of the Algebraic Normal Form of the feedback 

function was fixed in our search. We put the algebraic degree of ANF equal to four 

and randomly chose linear and higher order terms. The hardware implementation 

of NLFSRs and verification modules enabled to speed our search about 100 times 

up comparing to software implementation on current PCs. The future task would 

be to find NLFSRs with bigger number of stages n. This requires an improvement 

of searching methods and the use more hardware resources. 

References 

[1] N.G. deBruijn, A combinatorial problem. Indag. Math., 8(1946), pp. 461-467. 

[2] E. Dubrova, A list of maximum period NLFSRs. Cryptology ePrint Archive, 2012/166. 

www.iacr.org 

[3] C. Flye Sainte-Marie, Solution to question nr. 48. L’Intermédiaire des Mathématiciens 

1(1894). pp. 107-110. 

[4] B.M. Gammel, R. Goetffert, O. Kniffler, Achterbahn 128/80. The eSTREAM 

project, www.ecrypt.eu.org/stream/, www.matpack.de/achterbahn 

[5] S.W. Golomb, Shift Register Sequences. San Francisco, Holden-Day, 1967, revised 

edition, Laguna Hills, CA, Aegean Park Press, 1982. 

[6] S.W. Golomb, G. Gong, Signal Design for Good Correlation. For Wireless 

Communication, Cryptography, and Radar. Cambridge University Press, 2005. 

[7] G.M. Kyureghyan, Minimal polynomials of the modified de Bruijn sequences. 

Discrete Applied Math., 156(2008), pp. 1549-1553.


463 

[8] R. Lidl, H. Niederreiter, Introduction to Finite Fields and their Applications 

(Revisited Edition). Cambridge University Press, Cambridge, 1994. 

[9] K. Mandal, G. Gong, Probabilistic generation of good span n sequences from 

nonlinear feedback shift registers. University of Waterloo, preprint, 2012. 

[10] G.L. Mayhew, S.W. Golomb, Linear spans of modified de Bruijn sequences. IEEE 

Trans. Inform. Theory, 36(5)(1990), pp. 1166-1167. 

[11] A.J. Menezes, P.C. van Oorschot, S.A. Vanstone, Handbook of applied cryptography. 

CRC Press, 1997. 

[12] T. Rachwalik, J. Szmidt, R. Wicik, J. Zabłocki, Generation of Nonlinear Feedback 

Shift Registers with special-purpose hardware. Cryptology ePrint Archive, 2012/314. 

www.iacr.org 

[13] J. Szmidt, On Kyureghyan’s Conjecture. In preparation. 

[14] M.S. Turan, On the nonlinearity properties of maximum-length NFSR feedbacks. 

Cryptology ePrint Archive, 2012/112. www.iacr.org 

[15] R. Wicik, M. Borowski, Randomness testing of some random and pseudorandom 

sequences. Military Communication Conference, Prague, 2008.

Effective Generation of Cryptographic Material 

for Large Hierarchical Communication Networks 

Marcin Grzonkowski 1 , Jacek Jarmakiewicz 2 , Wojciech Oszywa 2 

1 Cryptography Division, MCI, Zegrze, Poland, 

m.grzonkowski@wil.waw.pl 

2 Communication Systems Division, C4I Systems, MUT – MCI, Warszawa, Poland, 

jjarmakiewicz@wat.edu.pl, j.jarmakiewicz@wil.waw.pl 

Abstract: In this paper, the problem of increasing the efficiency of cryptographic material generation 

for communication networks of large IT systems is presented. As it results from the conducted 

tests, it is possible to improve the performance of the cryptographic data generation several times, 

after multi-core/multi-process computer systems are applied and appropriate parallel cryptographic 

data generation system is designed. The IT network class described in the paper corresponds to, e.g. 

a system for the public administration purposes, where numerous IT relations between the system 

components within the superior-subordinate relationship are present. 

Keywords: electronic key management systems, parallel key generation 


Experiences related to cyber-attacks on information systems of various countries 

(Georgia, Estonia, Germany, Great Britain) indicate that the destabilization 

of information services has a real impact on national security and the public [1-7]. 

Organized cyber-attacks are often stimulated by political forces which transfer 

international policy to cyber space which is characterized by not precisely defined 

aspects of responsibility for unauthorized operations [8]. The attacks resemble typical 

spy activities for the technical, military, political and economic spheres, which 

leads to real and critical national security threats. The examples of unauthorized 

operation sources include cyber-spy organizations such as GostNet, Zeus, SpyEye [7]. 

Therefore, the security within the IT systems, in particular those that provide 

services to citizens, is very important. Information services of public administration 

authorities (PA) are particularly important in the context of public life and security 

of citizens, which is why actions aimed at ensuring the security of information flow 

in organized networks for the PA are necessary [6]. 

One of the effective manners for avoiding unauthorized information flow is to 

organize the data encryption in PA networks, thus eliminating the possibility of un-


controlled movement of data streams from inside and outside of the PA networks. 

The organization of large networks protection mechanism through encryption is not 

easy. Effective cryptographic tools and a number of organizational operations that 

allow safe and punctual distribution of cryptographic data are necessary for this 

purpose [9]. Cryptographic tools should not impact the deterioration of the communication 

services of an IT system. In order for these devices to work correctly, 

it is necessary to regularly deliver the cryptographic data (symmetric/asymmetric 

keys, random sequences and other) [10]. 

Modern communication networks consisting of several hundred or even several 

thousand devices require huge amounts of cryptographic data. The generation 

of cryptographic data entails the performance of large amount of time-consuming 

calculations and does not only relate to the problem of generation of cryptographic 

keys, but also to their appropriate protection against errors, disclosure, labeling 

and storage. 

The currently applied systems and tools for generating cryptographic data 

are not very efficient for large communication networks, where symmetric keys 

are used. For every information relation, appropriate cryptographic data should 

be assumed, e.g. if there is n=100 stations, at least n*(n-1)/2, i.e. nearly 5 thousand 

cryptographic data for the “peer-to-peer” information relation model should be 

prepared. The planning, generation and distribution of cryptographic data for such 

a large network is a technically complicated system. 

II. Architecture of an information system 

Let us consider the example PA system environment. The primary basis 

for determining the structure of an information system is the territorial division 

of the country. Within the division, the voivodeships along with the administration 

authorities that report to governmental institutions are important. The country 

is divided into 16 voivodeships which are created by poviats. 

We assume that the information system in question comprises management 

centers (MC) that may be duplicated given the need to achieve sufficiently high 

survival level. The composition of an example voivodeship MC is presented in Table 

1. In accordance with the administrative division of the country, 16 such MCs 

are present within the Republic of Poland. 

The central element of the state management is the president of the Republic 

of Poland (PRP), however, the majority of information processes will be addressed 

to the Prime Minister and the PM MC. 

It was assumed that information reports from the authorities subordinate 

to the PM will deliver information to the PM MC. Only the information already 

edited and aggregated will be delivered to the PM MC. 

An exemption may constitute the information reports delivered by the Ministry 

of Interior and Administration and Ministry of National Defense. Depending


467 

on the situation, information reports from the ministries of interior and defense 

might be provided both to the PM and PRP. It was proposed to classify the elements 

directly subordinate to the relevant ministries as internal elements. These 

are central authorities not belonging to the GA (Governmental Administration) 

and central authorities of the GA that will be joined through information relations 

with the relevant ministries. 

Figure 1. Architecture of the PA Information System 

As a result of the above analyses, the architecture of the PA system can be 

identified. It is graphically shown in Figure 1. The total number of the MCs for that 

particular information system equals 867 nodes. Probably there will be as many 

nodes in an communication network that will transfer information streams within 

the system. Not all nodes will exchange information between themselves, thus,


the information relations will be less in number than it results from the simple 

calculation being 867*866/2 = 375 411. 

Unfortunately, the amount of cryptographic data needed to ensure the system 

security will be equal to the number of information relations (assuming 

the symmetric encryption methods). The calculation of information relations 

is presented in Table 1. The number of information relations is not as dramatically 

high as for the “peer-to-peer” system, nevertheless their number amounts 

to nearly 20 thousand. 

Table I. Estimation of information relations in a system 

No. Relations Calculations Subtotal 

1 Central (57*56)/2 +(57*15)/2 + (15*14)/2 2128 

2 Including voivodeship level 2128*16 17024 

3 Voivodeship relations (11+15)*16 208 

4 Between voivodeships (16*15)/2 120 

5 Voivodeship-poviat relations 16*24/2 193 

Total 19673 

III. Generation of cryptographic data for large IT systems 

The cryptographic information generation subsystem for special networks 

consists of one or several combined computer station. These center perform various 

functions within a system: 

• Center for Special Network Planning and Cryptographic Data Distribution. 

Proper functioning of a secret data information system requires designing 

of a network made up of encryption devices and software as well as providing 

cryptographic data to every device and user (keys, passwords). This 

operation is carried out regularly at certain time intervals (every few/ 

several months). When planning, the need to immediately generate data 

in particular emergency situations should be taken into account. Once 

generated, the cryptographic data should be combined into sets and distributed 

to loading stands or directly to the devices. The data ought to be 

delivered in a safe manner, so as to preclude its disclosure and unauthorized 

modification. 

• Cryptographic Data Generation Center (CDGC). The station serves 

the cryptographic data generation for every cryptographic device operating 

within a communication network. The data is secured within the distribution 

period.


469 

Figure 2. Cryptographic Data Generation Model 

The Cryptographic Information Generation Center is most often built based 

on a personal computer with attached external devices such as the hardware 

random sequence generator, order station and data preparation for distribution 

in the system (Fig. 2). 

Cryptographic Data Generation Center should generate data necessary for 

the operation of various cryptographic algorithms such as coding, message signing 

and different passwords for cryptographic devices and systems. 

IV. Types of cryptographic data generation testbeds 

Cryptographic data sequential generation station 

In presently applied implementations, cryptographic data is generated sequentially, 

which results in a relatively long period of its generation for the entire 

network (Fig. 3). In a sequential model, it is necessary to perform random sequence 

generation processes. It is also needed to test it in terms of statistics, cryptographic 

key generation for information relations, relation keys protection and secure storage 

of the keys on data carriers. Many of these operations may be executed parallel. 

Figure 3. Components of a Data Sequential Generation Testbed Cryptographic data parallel 

generation station


The generation of the appropriate amount of cryptographic data for the particular 

system components for presently used large communication networks often 

requires several days. 

The time needed to generate data in emergency situations is too long, which 

may lead to a system downtime. Most of the currently used applications have been 

developed for single-core processors. The conducted tests show that the start-up 

of these applications on multi-core systems does not proportionally improve their 

performance. 

A simple transfer of data generation algorithms to multi-core systems does 

not improve their performance, despite the fact that these applications require high 

processing capacity systems. Therefore, it is necessary to design, for the purposes 

of cryptographic data generation, new effective tools that will operate in multiprocess 

and multi-core systems, ensuring the implementation of tasks in parallel 

and allowing for delivering and equipping the communication networks in a short 

time (Fig. 4.) 

Due to safety reasons, the data should be generated at the CDGC as a singlestation. 

Distributed generation of data is difficult, as there is a need to exchange 

information between the generation processes. Additionally, at a distributed station, 

cryptographic data that occur in an overt form cannot be sufficiently protected. 

Figure 4. Components of a Parallel Data Generation Testbed 

When designing, the cryptographic data generation process at the CDGC 

should be disintegrated and adapted to the parallel generation using multiple 

processors and cores at the same time. The parallel generation method should use 

the properties of the hardware platform on which it is implemented. 

At the proposed CDGC, the data is generated simultaneously on the particular 

cores (processors) which allows for reducing the overall time of the data generation 

(Fig. 5). At the CDGC, the problem of cryptographic data parallel generation


471 

for large communication systems has been solved and data was designed so as to 

be prepared concurrently and efficiently in terms of time. 

In order to illustrate the efficiency of the proposed mechanism, the time of selected 

cryptographic data generation depending on the number of processes (which 

it was generated by) was tested. The results enabled the preparation of evaluation 

of the mechanism efficiency. 

Figure 5. Model of the built Cryptographic Data Generation Center 

V. Results of the implemented CDGC efficiency 

Additionally, at the built CDGC, the mechanism for measurements of selected 

cryptographic data generation time was implemented. The system enables 

the generation of: 

• linear registers longer than 500 bits; 

• protected symmetrical keys (generation, integrity execution, encryption, 

saving to a disk); 

• pseudo-random files encryption (generating files from the pseudo-random 

generator, integrity execution, encryption and saving to a disk); 

• large prime numbers (1024 bits). 

The results of the selected performance metrics of the CDGC efficiency 

as the number of cryptographic data generation threads are presented in the graphics 

below (Diagram 1, 2). 

Long registers are necessary for the stream ciphers operation. As shown 

in Diagram 1, parallel generation increases the station efficiency. The set of registers 

was generated on a single core in less than 4 minutes, whereas the average time 

of data generation for registers on a 4-core processor is approximately 1 minute.


Diagram 1. Average time of non-linear register and 10 prime numbers generation 

Diagram 2. Generation time for a set of 10 devices, 100 keys each and encryption 

of 10 files with pseudo-random numbers, 10 KB each 

The performance metric of generating large prime numbers necessary for 

the proper operations of public key systems is presented on Diagram 1. The efficiency 

of prime numbers generation depends on the number of generation threads. 

The best results were achieved with four generation threads. The generation of prime 

numbers is a complex process in terms of calculation and does not require using 

disk resources. Therefore, it can perfectly enable increasing the number of generated 

numbers while increasing the number of threads. 

Symmetric keys are necessary for the operations of block ciphers. The generation 

of symmetric keys is not a complicated process in terms of calculation because 

they constitute random sequences. However, in the process of keys generation, 

their integrity should be secured by calculating the abbreviation and ensuring 

confidentiality through encryption. Once generated and secured, the keys are 

saved to the stand disk. The generation of symmetrical keys is not as susceptible 

to turning parallel as the disk generation, although their generation efficiency may


473 

be increased twofold. The time of data generation using a single thread amounts 

to ca. 1.5 minutes, whereas the average time of a set generation using 2 threads 

is reduced by half. 

Afterwards, the encryption performance and shortening of files containing 

sequences of pseudo-random numbers was tested. In the encryption time, the files 

are saved in blocks of a few hundred bytes on the disk. As the main problem 

consists in the saving time of a large number of short blocks to a disk, the increase 

in the generation threads number does not improve the generation station 

performance. 


Although the test comprised merely a few performance metrics, it was sufficient 

to confirm that the processes complicated in terms of calculation are prone 

to turning parallel and improving the generation time. Poorer results were obtained 

for operations that required saving of large amount of data to a disk. It seems 

that it will be possible to eliminate the restriction through the use of its buffering 

in the operational memory. 

The CDGC stand was installed on a multi-core computer using the parallel 

cryptographic material generation method. This solution is well suited to be used 

in cryptographic data generation systems for the currently operated and future 

communication networks. This will allow for increasing their performance several 

times. At the same time, this method will not deteriorate the security of the generated 

data, what is more, it will improve it by being able to perform additional 

procedures to verify this data, e.g. constant testing of the random sequence quality 

derived from the random generator. 

References 

[1] J. Kirk, Estonia recovers from Massie denial of service attack, IDG News Service, 

Inforworld, http://www.infoworld.com/article/07/05/17/estonia-denial-of-serviceattack_1.html, 

May 17, 2007. 

[2] C. Wilson, Computer Attack and Cyberterrorism: Vulnerabilities and Policy Issues 

for Congress, CRS Report RL32114, Updated April 1, 2005, p. 18. 

[3] N. Granado, G. White, Cyber security and government fusion center, Center for 

Infrastructure Assurance and Security, The University of Texas at San Antonio, 41st 

International Conference on System Science, Hawaii 2008. 

[4] October Cyberattacks on Poland, www.rp.pl/artykul/2,375962_Cyberatak_ na_Polske. 

html, 2009. 

[5] A.J. Menezes, P.C. van Oorschot, S.A. Vanstone, Applied cryptography, WNT 2005.


[6] B. Schneier, Applied Cryptography: Protocols, Algorithms, and Source Code in C, 

Second Edition, J. Wiley & Sons, 1996. 

[7] A. Grama, G. Karypis, V. Kumar, A. Gupta, Introduction to Parallel Computing 

(2nd Edition), PEARSON, Addison Wesley 2003. 

[8] T. Mattson, B. Sanders, B. Massingill, Patterns for parallel programming, Addison- 

Wesley Professional, 2004.

Improving the Efficiency of Cryptographic 

Data Management by Using an Adaptive 

Method of Planning 

Tomasz Czajka, Wojciech Oszywa, Michał Gawroński, Rafał Gliwa 

Cryptology Department, Military Communication Institute, Zegrze, Poland, 

{t.czajka, w.oszywa, m.gawronski, r.gliwa}@wil.waw.pl 

Abstract: The Electronic Cryptographic Data Management System (ECDMS) is designed for secure 

and correct preparation of cryptographic data. The process of preparation consists of three stages 

generally: planning of secure connections, generation of required keys and distribution of produced 

data to points of exploitation. These steps have to be perform sequentially. The planning can be realized 

by “according to needs” or “each to each” method. First method is inconvenient in use while 

second one extends time of data generation significantly. However the distribution process takes still 

the most of time. Till now distribution was realized by couriers. Nowadays, thanks to available secure 

telecommunication infrastructure, distribution can be realized in electronic way. A replacement 

of courier distribution with electronic one enables to improve efficiency and flexibility of ECDMS. 

Time of delivery data to devices is negligibly short and, in consequence, processes of planning and 

generation became a bottle neck in this case. In the article we will prove that in extreme situations 

method “according to needs” is impracticable and use of “each to each” method causes that time of data 

generation is unacceptably long. In answer to these difficulties we propose new method of secure 

connections planning called adaptive method. It combines advantages of two previous methods and 

eliminates disadvantages. One, crucial requirement for using this method is availability of communication 

infrastructure that will allow ECDMS to monitor work of supported devices. 

Keywords: Cryptographic data management, key generation, adaptive method 


A correct operation of data protection systems depends on an appropriate 

preparation of cryptographic data. There are special dedicated systems, called 

Electronic Cryptographic Data Management Systems (ECDMS), which are responsible 

for realization of this goal. An example of such system is commonly 

known American EKMS i.e. Electronic Key Management System. The specific tasks 

of the ECDMS can be very different and depend on the requirements of the concrete 

data protection system. Additionally, development of data protection systems 

implies the need of increasing an efficiency of ECDMS.


In the article we present the way of modification of management process 

which allows to improve the efficiency of ECDMS. 

II. Characteristics of special data protection systems 

and cryptographic data management systems 

in our considerations we take into account the special systems of data protection. 

The term “special systems” is quite general. For the purpose of our article we 

assume term “special systems” means systems processing classified information, 

that is information particularly important and sensitive. The priority is the security 

of their data, sometimes with cost of processing speed or ease of use. Below 

we will discuss the main features of the special systems, which directly determine 

the requirements for ECDMS. 

1. Communication between any two elements of the system (users, devices) 

is protected by encryption with a unique key, called the session key. Session 

can be a single conversation. It can also be defined by the unit of time or 

the size of transmitted data. 

2. Information must be protected not only currently but also a long time 

after use. The more sensitive information the longer period of protection 

is required. Implemented cryptographic mechanisms must therefore be 

strong enough to ensure the security now and in the future. 

3. The conclusion above applies also to the protocol of the session key agreement. 

In many solutions the key is agreed using the Diffie-Hellman protocol. 

It can be considered sufficiently secure today, but there is no guarantee that 

it will be quite secure in the future. For this reason, such key agreement 

protocols can not be used in special systems. 

4. Not all connections between system’s users are allowed e.g. in the army, 

where every person on any command level should be provided with communication 

with their immediate superiors, subordinates and people with 

the same level. 

5. Development of the system that is adding new users (devices) must be 

strictly controlled. 

Taking above requirements into account the following principles of cryptographic 

data management can be specified: 

– session keys, instead of agreeing, should be derived from the base key; 

– base keys (relations keys) should be different for each pair of communicating 

devices; 

– establishing who with who can communicate in secret mode must be possible; 

the set of established relations determines the configuration of communication 

system; 

– relations key are being prepared for a fixed period, called the period 

of validity; after that period, they should be replaced by new keys; periodic


477 

keys exchange enhances security and it is an opportunity to reconfigure 

the system; 

– cryptographic relations are established according to the needs known 

at the time of planning. In the moment keys comes to use or during 

the validity period, these needs may change. It must be possible to 

join the system devices that were not included in the communication 

plan. For this purpose, sets of spare data are prepared. Spare data, after 

uploading the devices, enable secret communication with all other devices: 

working or spare; 

– relations key should be supplied to the operation places in a reliable and 

secure way before beginning of validity period, which they have been 

prepared for, starts. 

From above assumptions it follows that ECDMS performs the tasks associated 

with planning, generation and distribution of cryptographic data. These processes 

must be executed sequentially. Result of one stage constitutes the input for 

the next stage. But the entire life cycle of the key includes the following key stages: 

needs analysis, preparation, waiting for entry to use, activation, work: session 

keys generation, deactivation, archiving or destruction. The process of preparing 

the data can be presented in a transparent way on the timeline. The essential 

points are: the beginning and end of the validity period (B and E), the beginning 

and end of the data preparation process (Bp and Ep). The period between Bp and 

B is designed to analyze the needs for secure communications to the next period. 

The period between Ep and E is the reserved time required against unexpected 

events. The shorter time of data preparation compared to the length of the validity 

period, the management is more flexible. During validity period the following 

steps are held simultaneously: data preparation for a future, using current data and 

destruction of the previous keys. 

III. Efficiency 

Speed of processing can be regarded as the measure of efficiency. The speed 

is connected with the time of the processing. Because of planning, generation 

and distribution are realized sequentially the time of date preparation is equal to 

total time of component processes. Time of planning depends on the planning 

method one applies: “according to the needs” or “each to each”. Time of generation 

depends on the number of established relations and the throughput of the source 

of keys – usually hardware random generator. Time of distribution depends 

on the kind of the distribution method, which can be courier (traditional) or 

electronic one. 

The kind of distribution is very essential for future conside-rations. In the case 

of the courier distribution, cryptographic data are delivered to the points of exploitation 

by persons (couriers). This process can last from several days to several


weeks depending on number of couriers, number of served devices and devices 

network topology. In the case of the electronic distribution, secure communication 

infrastructure used to transfer of the data is available. So the time of the distribution 

can be treat as negligible in this case. 

The graphs presented in Fig. 2 show the example of timing dependencies 

of the whole process of the data preparation in case of courier (1) and electronic 

distribution (2). 

The mutual proportions of the time of planning and time of generation can be 

different depending on the applied method of the planning. However in the first 

case their total time will certainly be much smaller than the time of courier distribution. 

The efficiency of planning and generation have no bigger meaning, because 

the distribution is the bottleneck. 

In second case, the whole process of the data preparation become significantly 

shorter. In this situation new profitable possibilities appear (presented 

in Fig. 3): giving more time for analysis process and shortening the validity period. 

The second solution increases security for data protection system. In both 

solutions the planning is more effective because the needs for cryptographic 

relations known at the beginning of planning are more adequate to real needs 

existing in the moment of introducing the keys to use. In this case the planning 

and generation become bottleneck. 

It is necessary to determine if optimization of planning time and generation 

time is possible. Let’s begin from generation process. The total time of generation 

is equal to the product of generation time of single key and number of required 

keys. The time of generation of single key follows from the property of random 

generator and, for concrete solutions, is a fixed value. Let’s assume that generation 

of one key lasts 1 second. 

Figure 1. Life cycle of cryptographic data 

Figure 2. Timing dependencies in process of data preparation


479 

Figure 3. Timing dependencies in case of electronic distribution 

The number of keys is equal to the number of cryptographic relations established 

in planning process. The number of relations depends not only on real needs 

but also on applied method of planning: “each to each” or “according to needs”. 

IV. Each to each method 

In the method each to each all possible cryptographic relations are set, which 

means that each device can communicate with any other in secret mode. Assume 

that R is the number of relations and the N – the number of users. Then: 

R = ½ * N * (N-1). 

In this case, the planning process is reduced to producing the order for 

the cryptographic data. Basing on the order, the generation subsystem will produce 

the required keys. The table 1 gives the total generation time for different numbers 

of devices (assuming that the generation of a single key takes 1 second). 

Advantages: The planning process is very easy to implement and its execution 

time is negligibly short. 

Disadvantages: Generation of a large number of keys (many of them will 

probably never be used). Too long generation time, in some cases unacceptable. 

V. Pareto principle 

The alternative for “each to each” method is “according to needs” method. 

However, can we expect significant shorte-ning of generation time, when a concrete 

system and its needs in range of cryptographic relations are unknown 

At the beginning we can refer to our own life experiences. Probably each 

user of mail or mobile phone can find in his address book a few such contacts 

which added long time ago and were never used after. From second side the same 

user could mention a few such contacts which are used definitely more often then 

the others. As confirmation of this what follows from experiences it is worth to 

quote the conclusions of Italian economist Pareto. Vilfredo Pareto observed in 1906 

that 80% of the land in Italy was owned by 20% of the population. This rule called 

Pareto principle (also known as rule 80-20), has many expressions concerning


economy, business, daily life etc. But generally it states that roughly 80% of the effects 

come from 20% of the causes. 

Table I. Time of generation in each to each method 

Number of devices Time of data generation 

100 1 h 22 min. 

200 5, 5 h 

500 34 h 40 min. 

1000 5 days 8 h 

2000 23 days 

5000 145 days 

Applying this rule to communication system we can assume, that from point 

of view of single user, 80% realized connections are addressed to only 20% of other 

users. For the simplification of further considerations let’s assume that each user 

communicates with only 20% of other users. It lets us for applying “according to 

needs” method. 

VI. According to needs method 

In this method, only the required relations are established. In this case, 

the number of relations satisfies the condition: 

½ * N ≤ R < ½ * N * (N – 1). 

Examples of generation times for different numbers of devices and for the case, 

which is consistent with our assumption (arising from the Pareto principle) are 

given in the table 2 in column 2. For comparison, column 1 shows the generation 

times using the each to each method. Column 3 presents generation times, assuming 

that each user communicates with at most 100 other users. In practice, the relations 

are defined manually, using a symmetric table whose rows and columns are 

identified by numbers of devices. Table entries on the diagonal are unavailable, 

because establishing relation with the device itself has no practical meaning. Placing 

the symbol X in a cell at the intersection of row i and column j means establishing 

a relation between devices i and j. 

The efficiency of this method depends on the ability of perception of the operator. 

To imagine the scale of difficulty one can compare this process to lay the puzzle, 

where the number of elements corresponds to the number of devices. If the image 

consists of 1000 items such task seems not feasible in a short time. Suppose that 

a large screen monitor (e.g. 21’’) can fit a part of table with the dimension 40 x 40 

devices. If 1000 devices in the system works, such a part is just one of 625 parts. 

Advantages: Number of relations adapted to real needs. The relatively short generation 

time. Adequate for the institution, where some connections are not allowed.


481 

Disadvantages: Complicated and time consuming planning. Too large risk 

of doing mistake (no necessary relations). For a large number of devices, error-free 

planning is practically impossible. 

Table II. Time of generation for different methods of planning 

Number 

of devices 

Generation time 

Case 1 Case 2 Case 3 

100 1 h 22 min. 16 min. 1 h 22 min. 

200 5, 5 h 1h 6 min 5,5 h 

500 34 h 40 min. 7 h 15 h 53 min. 

1000 5 days 8 h 27 h 36 min. 31 h 46 min 

2000 23 days 4 days 15 h 2 days 15 h 

5000 145 days 29 days 6 days 14 h 

In conclusion, it should be noted that in extreme situations (large networks) 

both methods in its pure form are not acceptable. Therefore, our solution is in some 

sense a combination of both methods of planning. 

VII. Adaptive method 

General idea 

This method is iterative. Iteration is single validity period. The method starts 

from a network set up on each to each. The method is called adaptive, because 

in subsequent iterations the network connections are modified in such a way, as to 

adapt to the real needs for connections. The aim of this method is to obtain such a 

set of cryptographic relations that will not require further modification (of course 

apart from the modifications related to exceptional situations, such as the introduction 

of new user). 

Additional requirements 

The method requires all active connections to be registered by devices 

of the management system. Thanks to this, the planning subsystem will know 

which relations are necessary. In a minimum variant, to record only the first call 

within a relation is sufficient. For this purpose, an existing electronic distribution 

channel can be used. 

Initial conditions 

Before the first iteration, the relations are established on each to each. Prior 

to initiating the system there is not time regime yet, so it does not matter that


the data preparation process can be long-term. Each to each method will be used 

just this one time only. 

First iteration 

During operation of the system, achieved connection are registered. For 

the next validity period, only those relations that have been registered are established. 

Additionally, one should prepare adequate number of spare data sets. Determining 

the adequate number is crucial to the success of the method. If the number of spare 

data sets is too small, the algorithm will fail and the data protection system will be 

unable to perform their tasks. Too large number of spare data sets has no meaning 

for the speed of progress, but it prolongs the time of data generation. 

Next iteration 

If it turns out that the device needs to realize the connection for which 

the key has not been prepared, the data loaded into the device will be replaced 

with spare data. One should then re-addressed the device and from this moment 

the device is identified by a number of spare data set. Information about the change 

of the number must be sent out to other devices. Set of relations is updated by 

adding the missing relation. 

Evaluation criterion 

If in a given iteration, all spare data sets are used, it means the negative result 

of the algorithm. If in subsequent iterations the number of used spare data sets 

is similar, it means that the method is not effective. If the number of used spare 

data sets becomes smaller and smaller, it means the positive result of the method. 

Probably the number of used spare data never reaches zero, but it is obvious, because 

unexpected situations occur always. 

VIII. Summary 

The proposed adaptive method of cryptographic relations planning combines 

advantages of two methods discussed earlier: each to each and according 

to needs. The first planning is realized with using each to each method. In subsequent 

iterations the set of relations is updated i.e. unnecessary relations are 

omitted and necessary ones are included. As the result, the final set of relations 

is established, which is realization of “according to needs” conception. The adaptive 

method enables to avoid main difficulties connected with previous methods 

i.e. manual planning of relations and/or too long time of key generation for all 

possible connections.


483 

The proper selection of number of spare data sets for next iterations seems 

to be crucial for the success of the method. This is the drawback of the method 

that its result can be known just after several iterations. Here, the single iteration 

is one validity period (lasting from 3 to 6 months typically). That is why the time 

of expectation for the result is not acceptable. Therefore, it is necessary to apply 

simulation to evaluate the progress of the method as quickly as possible. 

The next stage of our work will be a choice of a simulating environment. It is 

very important to correctly specify the parameters of simulation, so the simulation 

task imitates the work of the real system faithfully. Particularly interesting is such 

feature of system which describe a size and a changeability of sets of users with 

whom the chosen user communicates in safe mode. According to such criterion we 

can distinguish a few types of systems. The simulation enables evaluation of usefulness 

of adaptive method for each of these types of systems. Alternatively, result 

of simulation will help to establish an optimum values of method’s parameters 

(such as: number of spare data sets, length of validity term). 

References 

[1] B. Schneier, “Applied cryptography”, John Wiley & Sons, 1994. 

[2] A. Menezes, P.C. van Oorschot, S.A. Vanstone, “Handbook of Applied 

Cryptography”, CRC Press LCC, 1997. 

[3] N. Ferguson, B. Schneier, “Practical Cryptogaphy”, John Wiley & Sons, 2003.

Modern Usage of “Old” One-Time Pad 

Mariusz Borowski, Marek Leśniewicz 

Cryptology Division, Military Communication Institute, Zegrze, Poland, 

{m.borowski, m.lesniewicz}@wil.waw.pl 

Abstract: Top commands of the arm forces and some special military and government institutions 

need perfect security for exchanging between them “TOP SECRET” information. Security of such 

information is not limited by time. Only the one-time pad (perfect) cipher may be used to fulfill 

the requirements. Realization of OTP cipher machines has changed for decades. Now capability 

to hardware generation of binary random sequences with the potential output rate 100 Mbit/s 

eliminates the restriction connected with availability of very long one-time keys. Continuously 

generating the sequence (or one-time keys) with a bit rate 100 Mbit/s and its direct, lossless 

recording to mass storage, the new hardware generator will be able to produce a little more 

than 1 TB per day. OTP cipher machines have to be supported by a trusted data management 

and couriering system. 

Keywords: a one-time pad, a hardware random bit generator, entropy, randomness, Markow chains 


Diplomacy, military top commands and some special government agencies 

need ever lasting absolute security and privacy. Interception of some 

“TOP SECRET” plaintext by hostile state or organization can prove destructive 

in two months as wall as in a hundred years. The requirement of the perfect cipher 

usage is obvious for the institutions. It is important to recall that messages that 

were encrypted in the 1950’s with ‘state of the art’ imperfect cipher machines, and 

were kept archived by the adversary (which actually happened) are now generally 

broken within a few seconds, minutes or some hours at the most. On the other hand 

the messages that were sent 60 years ago with any realization of perfect ciphering 

will stay unbreakable for ever if the keys have been destroyed. 

Methods of realizating the perfect ciphering have changed by decades from 

a pencil-and-paper version to a today’s PC computer system equipped with modern 

software and provided other then confidentiality cryptographic services. It is 

interesting that all the methods of realizating the perfect ciphering have the same 

perfect security. Obviously perfect security is not for free. The perfect cipher requires 

random keys as long as the plaintext, a data management system and a robust, 

trusted key distribution system. Shown in chapter 4 the possibility for hardware


generation of binary random sequences with the potential bit rate 100 Mbit/s 

eliminates the restriction connected with availability of very long one-time keys 

for the perfect ciphering. Unfortunately, other than the trusted couriering key 

distribution system still requires an effective and reasonably priced solution. 

II. Vernam cipher or One-Time Pad 

The one-time pad (OTP), also called Vernam-cipher or the perfect cipher, 

is a crypto algorithm where plaintext is combined with a random key. The one-time 

pad was developed in 1917 by Gilbert Vernam for the use in telex machines. Each 

transmitted 5-bit Baudot code was mixed with a random 5-bit code on a paper 

tape. Such tapes contained a large number of these random 5-bit codes and were 

called one-time-tape. The one-time tape ran synchronously on both the sender’s 

and the receiver’s telex. Vernam’s invention was the basis for several pencil-andpaper 

versions. The name one-time pad refers to the notepads on which the keys are 

printed as shown in Fig. 1. In general, these pads are small booklets or microfilms 

with groups of five numbers or letters. 

Figure 1. Example of one time keys in a paper form 

A. One-Time Pad in practice 

We can only talk about OTP if four important rules are followed. When rules 

are applied correctly, the one-time pad can be prove unbreakable (see Claude Shannon’s 

“Communication Theory of Secrecy Systems”). However, if only one of these 

rules is disregarded, the cipher is no longer unbreakable. 

1. The key is as long as the plaintext. 

2. The key is truly random (not generated by simple computer Rnd functions 

or whatever!).


487 

3. There should only be two copies of the key: one for the sender and one for 

the receiver (some exceptions exist for multiple receivers). 

4. The keys are used only once, and both sender and receiver must destroy 

their key after use. 

III. Advancement of OTP cipher machines 

Electro-mechanical OTP cipher machines were manufactured in the fifties and 

the seventieth and widely used in diplomacy and army on the highest levels of command. 

A famous example of one-time pad’s security is the Washington/Moscow 

hotline with the ETCRRM II (Fig. 2) installed in 1963, a standard commercial 

one-time tape mixer for telex. Although simple and cheap, it provided absolute 

security and unbreakable communications between Washington and the Kremlin, 

without disclosing any crypto technology secret. 

Figure 2. Electronic Teleprinter Cryptographic Regenerative Repeater Mixer (ETCRRM) 

 

Some other cipher machines that used the principle of one-time pad are 

the American TELEKRYPTON, B-2 PYTHON and SIGTOT, the British BID-590 

NOREEN and 5-UCO, the Canadian ROCKEX, the Dutch ECOLEX series, 

the Swiss Hagelin CD-57 RT, the German Siemens T-37-ICA and M-190, the East 

German T-304 LEGUAN, the Czech SD1, the Russian M-100 SMARAGD and 

M-105 N AGAT and the Polish T-352/T-353 DUDEK. There were also many teletype 

or ciphering device configurations in combination with a tape reader, for one-time 

tape encryption or superencipherement [12].


Until the 1980’s, one-time-tapes were widely used to secure Telex communications. 

The Telex machines used Vernam’s original one-time pad principle. The system 

was simple but solid. Russian M-100 SMARAGD is an example of one-time pad 

crypto machine for telex communications. The key was perforated on a paper wire, and 

a plaintext was also perforated on a paper wire. The machine summed mod 2 information 

with the key from the two wires and transmitted the ciphertext to the line. When 

transmission had ended, the wires with the keys and the plaintext were automatically 

cut. The machine M-100 SMARAGD was widely used in diplomacy and in Soviet Army 

on the highest levels of command to the end of the nineties. The machine ensured perfect 

confidentiality of information. Other cryptographic services were not supported. 

Wide usage of microprocessor, personal computers, magnetic data storage 

made it possible to replace electro-mechanical crypto machines in the nineties. 

Newly designed OTP cipher machine invariable application should ensure unconditional 

information confidentiality by the use of the OTP cipher. Moreover, 

it should provide additional cryptographic services: 

• integrity of messages; 

• cryptographic confidentiality of one-time keys; 

• integrity of one-time keys; 

• secret sharing of keys needed to use the machine; 

• authentication of correspondent machines; 

• authentication of the key generation station; 

• authentication of operators 

• an automatic key generation and a secure connection planning station. 

The newly designed OTP cipher machine should also support: 

• compression of data to be ciphered; 

• electronic accountability; 

• electromagnetic emanation protection; 

• wide usage of COTS electronic parts and applications. 

An example of realization of the OTP cipher machine in today’s PC technology 

is shown in Fig. 3. 

Figure 3. Today’s realization of the OTP cipher machine


489 

IV. Development of the 100 Mbit/s hardware generator 

as “infinite” source of one-time keys 

Binary random sequences have numerous applications in many fields of science 

and security (military) usage. Due to the lack of trusted sources of truly random 

sequences Military Communication Institute (MCI) researched, implemented and 

developed a family of hardware random bit generators. The generators can generate 

random sequences with an output rate 115.2 kbit/s up to 8 Mbit/s and they were 

certified by the Polish national security authority according to “The Protection 

of Classified Information Act” and can be used in cryptographic systems up to 

“TOP SECRET” level [6]. 

In 2012 MIT decided to start the project of 100 Mbit/s hardware generator. 

The theoretical goal of the project is to developing mathematical and technical 

methods of generation, giving rise to the physical structure of the generator, implementing 

the hardware generation of binary random sequences with the potential 

throughput (amount of data per unit time) 100 Mbit/s, supported by a mathematical 

proof of their randomness, which guarantees a set of sequences with required 

probabilistic characteristics and parameters, confirmed by statistical research [1]. 

The generator (a practical part of the project) will have a “certificate of type” issued 

by the national security authority according to “The Protection of Classified 

Information Act” issued 05-th of August 2010. After obtaining the certificate it will 

be allowed to be used in cryptographic systems up to “TOP SECRET” level. It will 

also be able to be used in any scientific and technical applications. 

A. The SGCL-100M generator as a scientific tool 

Binary random sequences have numerous applications in many fields 

of science and technology. The most important ones are applied in such fields 

as cryptography, statistics, numerical computation, stochastic simulations using 

the Monte Carlo method, and many others. Unfortunately, due to the lack 

of sources of truly random sequences in above applications, pseudo-random 

algorithmically generated sequences are used routinely, which often leads to 

bad results of the applications, because such sequences do not have even mathematically 

proven statistical properties and parameters, and their probabilistic 

characteristics are usually unknown. 

As a scientific tool the SGCL-100M generator will be used in advanced 

researches in the field of probability theory, the theory of stochastic signals and 

information theory. Assumptions of such high bit-rate output of the generator 

is caused by the fact, that in the most modern applications very large samples 

of random sequences are required, reaching gigabytes on one calculation or 

simulation. At the rate 100 Mbit/s a sample of 1 GB size is generated in approximately 

90 seconds.


B. The SGCL-100M generator as “infinite” source of one-time keys 

OTP cipher machines use one-time keys as long as a plaintext (and only once) so 

key accessibility is critical [4]. Possibility for hardware generation of binary random 

sequences with the potential bit rate 100 Mbit/s eliminates the restriction connected 

with availability of very long one-time keys for the OTP cipher. The SGCL-100M will 

be able to generate continuously the one-time keys with bit rate 100 Mbit/s. The keys 

can be recorded by a data management system for OTP cipher machines to mass 

storage. The generator will be able to produce a little more than 1 TB one-time keys 

per day and act as a practically “infinite” source of one-time keys. 

The prototype of the generator and the necessary documentation will be forwarded 

to the certification in accordance with the Polish “The Protection of Classified 

Information Act” issued 05-th of August 2010. The generator will have to 

possess a “certificate of type” issued by the national security authority according 

to “The Protection of Classified Information Act”. After obtaining the certificate 

it will be allowed to be used in cryptographic systems up to “TOP SECRET” 

level. Data management system for OTP cipher machines is a perfect place to use 

the SGCL-100M generator. 

C. Theory of hardware generation of binary random sequences with very 

high throughput 

Military Communication Institute has already an outline of theory of hardware 

generation of binary random sequences, which involves generation of many binary 

imperfectly random component sequences and their post-processing using XOR 

sum to the form of perfectly random output sequences, then their superposition 

into one sequence. MIT has published reviewed monograph [3]. The monograph 

describes the problem of generating sequences of 8 Mbit/s rate. 

An introduction to the work will be dedicated the analysis and synthesis 

of the mathematical basis of the theory of perfect and imperfect binary random 

sequences and impaction of requirements for generated sequences. Further work 

will be devoted to the analysis of selecting a source of randomness, conducted 

on the basis of analytical investigations and results of the author’s experience 

in the practical generation of random sequences. Theoretical support of the analysis 

is the theory of analog and binary stochastic noise signals. As a result of these 

studies, conditions for selection of potential sources of randomness will be indicated, 

leading to a physical source of randomness in the form of avalanche diodes 

batteries, which generate Poisson signals with controlled randomness. The target 

theory of generation, however, there will be formulated on the basis of the author’s 

approach, using the original theory, based on integrated considerations, resulting 

from the above experiences. Experimental support for the scientific tools will be 

resulted from the experiments and statistical measurement.


491 

Proof of randomness of generated sequences will be based on the analysis 

and synthesis of Poisson signals, modeled as stochastic, binary Markov chains. 

The methodology of the proof will be based on the probabilistic-signal risk analysis 

of imperfectly random sequences generation [1]. In addition to assessing the quality 

of sequences in the above sense, the security analysis of the generator operation will 

be made from the viewpoint of electromagnetic compatibility and electromagnetic 

leakage of information. 

Theoretical part of the work also requires to formalize the mathematical description 

and to show what properties and parameters will have such a sequence. 

Then, the prototypes of three generators will be constructed, which will be used 

for the practical verification of the theory. 

D. Hardware and software realization of the SGCL-100M generator 

Technical design problems connected with the SGCL-100M generator are encountered 

on two levels – the electronics and the programming. The electronic board 

of the generator will consist of 48 generators (Fig. 4), which must be calibrated to 

generation state consistent with the Poisson signal theory. The stability of the properties 

and parameters of such a signal as a function of time and climate-mechanical 

exposures must be tested. The electronic system will also consist of a programmable 

chip, in which all post-processing operations will be performed, including 

formatting of the sequence before its sending. Transmission of the sequence from 

the generator to the computer will take place through a standard 100Base-TX 

Ethernet. As handling of this interface with full throughput is a very difficult task, 

the dedicated Ethernet interface controller will be used and it will be controlled 

by RISC microprocessor that will perform the data transfer between the programmable 

chip and a controller in DMA (Direct Memory Access) mode. In practice, 

only such solution allows to achieve full throughput of 100 Mbit/s. 

Figure 4. The model of 100 Mbit/s hardware generator SGCL-100M 


The generator, even though its hardwareness is a very complex object, requires 

software. The software is generally required by two circuits – a programmable chip 

(a program in AHDL, a VHDL language in the corporate version of Altera) and 

RISC microprocessor (programs in C/C++ with “inserts” in the assembler). The both 

softwares must be optimized due to the efficiency of data transfer, to avoid a conflict 

with the essential functions of a random sequence generation. The correctness 

of theoretical assumptions and the correctness of technical solutions – including 

software – will be confirmed experimentally by statistical testing of generators 

in any case at all stages of the development. 

Since the generator is a quite complex and costly device with a very high output 

rate it can be assumed that it could be used as a source for random sequence 

servers in R&D centers. 

V. Data management for OTP crypto machines 

Data management systems have been subject to big changes over the time 

of cryptographic systems development. At the beginning they were simple elements 

producing only keys in open (not encrypted) form – key generators. The other 

operations connected with data processing (i.e. protecting, storing) were carried 

out by a person. Such kind of the key management system was used by the OTP 

cipher machines in the seventieth [7]. 

In the next stages tasks of system development generators were widened to recording 

results, protection (ciphering), and authentication. Such extended systems are 

called generation systems. As a result of a rising number of cryptographic devices and 

development of computer systems, generation systems were equipped with mechanisms 

of planning secure connections and an element responsible for distribution. Only 

such systems can be called cryptographic data management systems. These complex 

management systems has been built since the middle of the nineties. They raised efficiency 

of data processing and security. The data management systems are intended 

to deliver correct and reliable key data to proper cryptographic devices. OTP cipher 

machines demand a data management system [4]. The system consists of: a secure 

connecting planning station and a key generation station. OTP cipher machines machine 

can work in two modes: ”in a direction way” and “in a circular way” These two 

modes of operation should be introduced by the secure connecting planning station. 

A. The secure planning connection station 

The main aim of the secure planning connection station is to implement only 

really necessary connections in an OTP cipher machines net. The OTP cipher 

machine uses one-time keys and time of generating keys is an important factor 

of a key generating process. “In a direction way” mode needs generation of unique 

keys for each direction therefore an automatic making connection “each to each”


493 

is disabled in the planning station. “In a circular way” mode needs only generation 

of unique keys for a whole circular. The information about the OTP cipher machine 

planned networks includes the number of OTP cipher machines, types of directions, 

number of one-time keys. Then the information goes to the key generation station. 

The secure connecting planning station should be built with the use of a hardened, 

electromagnetic emanation leakage resistant computer set. 

B. The key generation station 

The key generation station generates keys on the basis of the information 

obtained from the secure connecting planning station. The keys are generated 

for all algorithms used by the OTP cipher machine. Of course the longest time 

is needed for generating one-time keys. One-time keys are automatically generated, 

ciphered and signed by the key generation station. Cryptographic keys do not 

leave the station unprotected: ciphered one-time keys are copied on One-Time Key 

(OTK) modules and symmetric and asymmetric keys needed to fulfill additional 

cryptographic services of OTP cipher machines are transferred to temper-resistant 

smart cryptographic modules. 

The quality of keys generated by the key generation station depends on 

a random keys generator. The key generation station uses a hardware random 

bit generator. Basic characteristics and parameter of the generator: 

• generation of random binary streams with speed up to 100 Mbit/s; 

• good statistical quality of generated binary random streams confirmed by 

appropriate statistical tests [5, 8, 9, 10]; 

• user-friendly utilisation and maintenance of generated bit streams quality; 

alarm activation while statistical defects are detected [6]; 

• full electromagnetic emanation safety – lack of penetration. 

The random bit generator will have the “certificate of type” issued by the national 

security authority. The certificate must determinate that generator is suitable 

for generating data for usage in cryptosystems up to “TOP SECRET” level. 

VI. One-Time Pads in today’s world 

In the PC computer era, modern algorithms such as symmetric block ciphers 

and asymmetric public key algorithms replaced one-time pads because of practical 

considerations and solutions to key distribution problems. Modern crypto algorithms 

provide practical (not proved) security and privacy, essential to our economy and 

everyday life. However, top commands of the arm forces and some special military 

and government institutions need ever lasting absolute security and privacy, and 

that is only possible with one-time encryption. 

Some experts argue that the distribution of large quantities of one-time pads 

or keys is impractical. This was indeed the limitation in the era of paper tapes on


reels and paper pads (Fig. 1). However, today’s electronics, as the SGCL-100M 

generator shown in Fig. 4 and described in chapter 4 of the article will be able to 

act as a practically “infinite” source of one-time keys. Capability to one-time keys 

generation will be no limitation any longer. Today’s realization of OTP cipher machines 

(Fig. 3) with embedded current one-time encryption software can process 

large quantities of data at high speed. 

Current data storage technology such as USB sticks, DVD’s, external hard 

disks, solid-state drives or dedicated OTK modules to enable the physical transport 

of enormous quantities of truly random keys. Actual sensitive communications 

are often limited to a small number of important users. In such cases, one-on-one 

communications with the associated key distribution, possibly in configuration with 

a star topology, is no longer a practical problem, especially considering the security 

benefits. By using a so-called sneakernet (transferring data on removable media by 

physical couriering), you can reach a throughput of one-time keys that is greater 

than what a network can process on encrypted data. In other words, it could take 

a few hours to drive a terabyte of key material, stored on an external drive, by car 

to someone, but it will take days or even weeks to consume that amount of keys on 

a broadband network. A terabyte sized key can easily encrypt e-mail traffic of special 

(military or diplomacy users) for a year, including attachments. 

Therefore, one-time key encryption is still well-suited in specific circumstances 

where absolute security is preferable to practical considerations, regardless 

of the cost of secure physical transport of keys by couriering. 

In the future quantum key distribution (QKD) may be helpful as an alternative 

for secure physical transport of keys by couriering. The security of quantum 

key distribution relies on the foundations of quantum mechanics, in contrast to 

a traditional key distribution protocol which relies on the computational difficulty 

of certain mathematical functions. An interesting and promising method 

of QKD was presented in [2] with usage of Professor Artur Ekert type of QKD [11]. 

But at present the ability of efficient QKD usage is still an open question. 

References 

[1] M. Leśniewicz, “Sprzętowa generacja ciągów losowych z przepływnością 100 Mbit/s. 

Hardware generation of binary sequences with throughput 100 Mbit/s,” Przegląd 

Telekomunikacyjny nr 11/2011. 

[2] W. Nowakowski, “O kryptografii kwantowej. About quantum cryptography,” 

Elektronika, nr 2, Warszawa 2010. 

[3] M. Leśniewicz, Sprzętowa generacja losowych ciągów binarnych. Hardware generation 

of binary random sequences, WAT, Warszawa 2009, ISBN 978-83-61486-31-2. 

[4] M. Borowski, R. Wicik, “A one-time cipher machine for Polish Army,” Military 

Communication Conference,” Prague, 2008.


495 

[5] R. Wicik, M. Borowski, “Randomness testing of some random and pseudorandom 

sequences,” Military Communication Conference, Prague, 2008. 

[6] P. Komorowski, M. Leśniewicz, “Sprzętowy generator binarnych ciągów losowych 

o wyjściowej przepływności 1 MB/s. A hardware binary genertaor with output 

throughput 1 MB/s,” X Krajowa Konferencja Zastosowań Kryptografii ENIGMA 2006. 

[7] W. Oszywa, M. Gawroński, T. Czajka, “Hierarchic cryptographic data management 

system,” Bulletin of Military Communication Institute, 2005. 

[8] R. Gliwa, M. Leśniewicz, R. Wicik, “Testing of hardware-based random bit generators 

utilized in cryptography”, National Telecommunication Symposium, Bydgoszcz, 2002. 

[9] W. Schindler, W. Killmann, “Evaluation Criteria for True (Physical) Random 

Number Generators Used in Cryptographic Applications,” Workshop on Cryptographic 

Hardware and Embedded Systems CHES,2002, Springer-Verlag Berlin Heidelberg 2003. 

[10] A.J. Menezes, P.C. van Oorschot, S.A. Vanstone, Handbook of applied cryptography, 

CRC Press, 1997. 

[11] A.K. Ekert, “Quantum cryptography based on Bell’s theorem,” Physical. Review 

Letters, 1991. 

[12] D. Rijmenants’, Cipher Machines and Cryptology, Historical and Technical Information 

about Crypto Machines, Cryptology and Free Software Simulations, http://users.telenet. 

be/d.rijmenants/index.htm

Acoustic Steganographic Transmission Algorithm, 

Using Signal Coherent Averaging 

Krzysztof Wodecki, Zbigniew Piotrowski, Jarosław Wojtuń 

Military University of Technology, Faculty of Electronics, Warsaw, Poland, 

{kwodecki, zpiotrowski, jwojtun}@wat.edu.pl 

Abstract: The paper discusses the algorithm of hidden data transmission, using acoustic signal 

as carrier. The perceptive transparency of hidden data was obtained with the use of psychoacoustic 

model of the Human Auditory System (HAS). Spectrum differential coding of binary patterns 

was used to add the hidden data to the host signal. The synchronous data decoding is enabled by 

the use of signal spectrum coherent averaging procedure and drift correction procedure for frequency 

and time. The diagrams present the efficiency of the algorithm both in terms of accuracy of hidden 

transmission synchronization, its robustness against degradation by noise and the efficiency of hidden 

data extraction. 

Keywords: steganography, audio watermarking, data hiding, drift correction modulation, Human 

Auditory System 


Steganographic systems allow for transmitting data in the host signal with 

specific binary bitrate. The host signal carrying additional, hidden data, can be 

the TV signal, video stream, radio music or speech transmitted by the telephone 

line. One of the requirements of such systems is the imperceptibility (inaudibility or 

invisibility) of hidden data within the host signal. The robustness against degrading 

factors in the telecommunications chain: additive white Gaussian noise (AWGN), 

resampling, lossy compression, etc. is less important than in the watermarking 

systems. Also in use are acoustic steganography systems utilizing the wavelet 

transform and LSB coding to hide the additional data [1][2]. LSB coding has also 

been used to hide compressed data in audio signals [3]. Audio steganography 

uses spread spectrum methods, which utilize statistical moments and distance 

metrics [4]. Steganography also faces the issue of ensuring synchronous data 

decoding. In terms of frequency, the phenomenon of signal carrier frequency 

drift occurs, as well as sampling frequency drift on the receiving side [5][6][7][8]. 

The algorithm in question uses spectrum coherent averaging to establish the correction 

factor for the undesirable angle phase drift, as well as to determine the signal


shift against the start of data decoding. In the described steganographic system 

data are modulated with the use of differential coding of binary patterns in the host 

signal spectrum. 

II. Description of algorithm 

A. Watermark embedder – principle of operation 

The schematic of the watermark embedder is provided in Fig. 1. 

Figure 1. The watermark embedder 

Embedding the watermark in the background of the host audio signal 

takes place on the level of frequency. The binary symbols (0 or 1) generated 

in the Binary Signature (BS) unit are assigned specific patterns, dividing 

the host signal spectrum into 5 subspectra. Depending on the specific pattern, 

the spectral line values of the host signal in particular subspectra increase or 

drop. In terms of the robustness of steganographic signal against blurring it is 

desirable for the spectrum amplitude modification to be as high as possible. On 

the other hand, in order to ensure the transparency of the watermark signal 

in the background of the host signal, the modification of spectral line values 

cannot take place indiscriminately. This problem has been solved by correcting 

the host signal spectrum amplitude to the level of Just Noticeable Difference (JND). 

In psychoacoustics the JND level is defined as the distortion level noticed in audio 

tests by 50% of listeners with normal hearing. In the presented algorithm, 

the JND level is determined with the use of the Human Auditory System (HAS) 

model by establishing the minimum masking threshold for the host signal LT min , 

using the MPEG psychoacoustic algorithm. Establishing the masking threshold 

for the host signal was carried out on the basis of an 8-stage signal processing procedure, 

compliant with ISO CD 11172-3 (MPEG–1) standard, and a single-stage 

correction process, compliant with the description in [10]. Detailed descriptions 

of the stages of establishing the masking threshold are provided in table 1.


499 

Table I. Signal processing stages in MPEG psychoacoustic algorithm 

Step I 

Step II 

Step III 

Step IV 

Step V 

Step VI 

Step VII 

Step VIII 

Calculation of the FFT for time to frequency conversion 

Determination of the sound pressure level for each subband 

Determination of the threshold in quiet (absolute threshold) 

Finding of the tonal and non-tonal components of the audio signal 

Decimation of the maskers, to obtain only the relevant maskers 

Calculation of the individual masking thresholds 

Determination of the global masking threshold 

Determination of the minimum masking threshold in each subband 

Fig. 2 presents the method of correction of spectral lines of the host signal 

for hiding bit ‘0’. 

Figure 2. Watermark embedder – principle of operation 

Clearly visible is the binary pattern corresponding to bit ‘0’. In this case, it is 

the alternating sequence of the {1 0 1 0 1} pattern, where {1} stands for the increase 

of the spectral line amplitude and {0} stands for the reduction. For the sequence 

of the ‘0’ pattern and in the case of the spectral line value being lower than LT min level, 

the host signal is clearly damped. 

As previously mentioned, the correction of spectral lines is determined by 

the value of the LT min level. However, such manner of correction would not include 

all spectral lines in the analyzed subspectra. In the proposed algorithm the values 

of spectral line amplitudes that cannot be corrected against the LT min level are increased/reduced 

by the experimentally established value of 0.4 dB. 

The signal generated in the Orthogonal Frequency Division Multiplexing 

(OFDM) is a composite of 14 harmonics. A single harmonic is generated in accordance 

with:


j 2 

 

i t i j ft 

x t Ae Ae 

i 

i 

(1) 

i i i 

where: 

A i – amplitude of i – harmonic, 

f i – frequency of i – harmonic, 

φ i – starting phase of i – harmonic. 

In order to ensure the imperceptibility of the OFDM signal in the background 

of the audio signal, the amplitude value of each harmonic is determined by the corresponding 

LT min level. 

Fig. 3 presents the amplitude and phase spectrum of the OFDM signal. 

The values of the 0 rad/s angle phase are assigned to spectral levels with indexes 

of (1,4,7,8,11,14). Amplitudes of lines in fig. 3 are marked in red. 

Figure 3. Amplitude and phase spectrum of the OFDM signal 

Of 14 harmonics presented in fig. 3, 6 harmonics (marked in red) are utilized 

on the receiver side to determine the correction values of the angle phase drift. 

The necessity to determine the correction of the angle phase drift arises from 

the differing stability of clocks tacking the sampling circuits in the transmitter 

and the receiver. The remaining 8 harmonics (marked in blue) are utilized on 

the receiver side to reproduce the time synchronization. The harmonics used for 

determining the correction of the angle phase drift are assigned the angle phase 

value of 0 [rad/s], whereas the lines responsible for time synchronization are assigned 

the angle phase values of π/2 and –π/2. 

Furthermore, in order to improve the efficiency of watermark signal extraction, 

the embedder utilizes the differential coding mechanism [9]. The principle 

of the mechanism is that the coding of the same bit takes place in two adjacent frames 

(subframes) of the host signal, but using opposing patterns. The manner of pattern 

selection is provided in fig. 4. Assuming that the subframes contain 512 samples each,


501 

the coding of a single bit will require 1024 signal samples which, given the sampling 

frequency of f s = 44 100 Hz, allows for creating a hidden transmission channel with 

the bitrate of 43 bps. In particular the data bit rate of the proposed algorithm: 

where: 

f s – sampling frequency, 

N – number of samples. 

f s 

bit rate [ bps] 

(2) 

N 

B. Watermark extractor – principle of operation 

The schematic of the watermark extractor is provided in Fig. 5. The extraction 

mechanism of binary signature belongs to the class of algorithms using the socalled 

blind decoding method, i.e. the receiver side does not require the host signal. 

The watermarked signal first encounters the angle phase drift scanner, which corrects 

the angle phase drift for the pilot samples (cf. red-marked lines in fig. 3). The angle 

phase drift is caused by differing stability of clocks tacking the sampling circuits 

in the transmitter and the receiver of the watermark (e.g. in the case of a watermark 

signal transmission in a VHF circuit). As previously mentioned, the watermark 

embedder has 6 pilot spectral lines with the assigned angle phase value of 0[rad/s]. 

The same angle phase value is expected on the receiver side. The angle phase scanner 

allows for reproducing the drift value of the angle phase by analyzing the values 

of the virtual line module, which is the sum of pilot line modules. In the proposed 

algorithm the individual increment of the angle phase Δφ 1 is Δφ 1 = 0.000767 [rad/s]. 

Figure 4. Pattern selection method for differential coding


Figure 5. The watermark decoder (extractor) 

The angle phase scanner searches for the drift values in the following set: 

1 

rad 

 

1: : 1 100 

s 

(3) 

 

Let us mark the number of watermark signal frames fed to the extractor input 

as M. Then, we can formulate the expression for the collective value of F iΔφ of i – 

pilot line after M of iterations (averagings): 

M 

F ReF 

ImF 

 

i 

ik ik 

k1 k1 

M 

(4) 

The averaging occurs separately for the real and the imaginary part, with 

the established value of correction of Δφ angle phase, whereby the value of Δφ 

is constant for the entire set of M of iterations. The value of the virtual line module 

is derived from the following correlation: 

F 

v 

6 

F 

(5) 

i1 

Having the information on the value of Δφ by which the current angle phase 

is corrected, we can read the value of the F vΔφ virtual line module from M iterations. 

i


503 

The obtained maximum value of this line for set (3) enables us to determine the angle 

phase by which the phase has shifted against the host signal. After establishing 

the drift correction for frequency, the pilot samples used for reproducing the time 

synchronization undergo coherent averaging. Meeting the coherence requirement 

results in an increase of the spectral line amplitudes by reducing the noise deviation 

(of the host signal) for each iteration. Therefore, it can be demonstrated that, 

with the coherence requirement met, the value of the signal/noise ratio depends 

on the number of iterations (M) and is expressed by the following correlation: 

SNR dB 20log SNR 10log M 

 

(6) 

coh 

10 coh 

10 

In order to correctly extract the binary signature on the receiver side it is necessary 

to divide the assayed signal frame into two subframes, whereby the moment 

of division should conform to the moment of division of the frame in the transmitter. 

Therefore, the receiver side requires time synchronization. The synchronization 

mechanisms used 8 pilot lines presented in fig. 3 (marked in blue). According to 

the proposed algorithm of time synchronization [9], in order to determine the time 

shift between the transmitter and the receiver of the watermark, two adjacent spectral 

lines are used (e.g. lines 16 and 17). In order to improve the accuracy of time shift 

determination, the synchronization procedure is repeated 4 times and the results 

undergo averaging. Assuming that the analyzed frame contains N = 1024 samples 

and the time shift between the transmitter and the receiver is m samples, the phase 

of the two adjacent linear samples will change by: 

2 km 2 

1 

k 

, 

k 

m 

k1 

(7) 

N 

N 

while the difference between those phases will be: 

2m 

k 

1 k 

(8) 

N 

Measuring the value of Δχ we can precisely determine the value of the time 

shift m between the transmitter and the receiver. Assuming that one signal period 

per signal frame with the established cardinality N is required to reproduce synchronization, 

then, in theory, the time shift value can be determined using only 

one harmonic – the first harmonic in the DFT spectrum. However, with N = 1024 

and f s = 44 100 Hz, the first harmonic in the spectrum has the frequency of 43 Hz. 

With such low frequency value the signal degrades in the telecommunications 

channel; therefore, it is recommended to use two adjacent harmonics with higher 

frequencies, as explained in [9]. Furthermore, as pointed out in [9], the relative 

frequency difference between two adjacent spectral lines is exactly 2π; therefore, 

we can unequivocally assign the length of the N frame to this value. Fig. 6 presents 

the phase vectors for two adjacent harmonics (lines 16 and 17) in the transmitter 

and the receiver with the time shift m = 16 samples.


Figure 6. Time synchronization mechanism 

After completing the time and frequency synchronization, the proper procedure 

of binary signature extraction takes place. Since the same bit is embedded in two 

adjacent frames (subframes) of the host signal, on the receiver side each assayed 

signal frame is divided into two further frames. The next step (9) is the determination 

of the scalar product value between the difference of amplitude spectra for 

two adjacent frames and the following formulation: 

where: 

R 

N1 

2 1 

Xi Xi Pi 

(9) 

i0 

10 

 

 

 

 

k 

k 

X 10log DFT x 

(10) 

P i – pattern. 

On the basis of the scalar product value (9) the value of the bit hidden in the given 

portion of the signal is determined: 

0, R 0 

BS 

(11) 

1, R 0 

III. Results of the analysis 

The first analysis concerned the efficiency of operation of the synchronization 

algorithm. Figs. 7 and 8 present the accuracy of synchronization in the function of drift


505 

and time of the analyzed signal on the receiver side. The principle of the synchronization 

algorithm is based on the measurement of the value of angle phase difference between 

two adjacent harmonics (8). For low values of drift m (or high, approaching N) the phase 

difference value approaches 0 (or 2π). Therefore, the determined drift is encumbered 

with high error. The best results are obtained for drift falling within 50-950 samples. 

Synchronization accuracy can be improved by extending the time of the analyzed 

signal on the receiver side or increasing the pilot line power (increasing the power 

by 3 dB above the LT min level does not deteriorate the audio signal). 

Figure 7. Synchronization accuracy in the function of drift 

Figure 8. Synchronization accuracy in the function of signal analysis time 

The results for extraction efficiency in the function of signal analysis time 

on the receiver side are provided in Fig. 9. The analysis was carried out for drift 

m = 10 samples and m = 300 samples, for two watermark signal power correction


variants – correction to LT min level and LT min + 3 dB level. In the case of watermark 

signal power correction to LT min + 3 dB level, the bit error rate is approximately 

2.5%, regardless of the signal analysis time. This value can be corrected with the use 

of detection and correction codes. 

Figure 9. Extraction efficiency in the function of signal analysis time 

As previously mentioned, the present algorithm allows for creating a hidden 

transmission channel with the bitrate of 43 bps (with the division of the 1024-sample 

frame into two subframes of 512 samples). Algorithm modification in the form 

of dividing the frame into subframes allows for increasing the transmission rate. 

Fig. 10 presents the results for signature extraction efficiency after increasing 

the bitrate to 86 bps and 172 bps. The watermark power was corrected to the level 

of LT min + 3 dB. In both cases the bit error rate is below 10%. 

Figure 10. Comparison of extraction efficiency for different transmission rates


507 

The final test was the verification of extraction efficiency after prior addition 

of white Gaussian noise with specific power to the assayed signal. Fig. 11 presents 

the signature extraction efficiency results in the function of the assayed signal power 

to noise power ratio. With the reduction of the noise power (increase of the SNR 

factor value) added to the signal, the signature extraction efficiency increases. 

Figure 11. Signature extraction efficiency results in the function of the assayed signal power 

to noise power ratio 

IV. Conclusions 

The article discusses the algorithm for creating a hidden transmission channel 

in audio signals. Depending on the selected variant, the achievable bitrates are 

43 bps to 172 bps. Also discussed was the angle phase correction algorithm, based 

on coherent averaging, and time synchronization mechanism. The experimental 

results are satisfactory. Further studies of the subject should focus on implementing 

the detecting-corrective embedding module and performing a number of experiments 

on the extraction efficiency during signal transmission in various telecommunications 

links (VoIP, VHF). 


This paper has been financed from science funds granted within the years 2010- 

2012 as a research project of the Polish National Centre for Research and Development 

No. 0181/R/T00/2010/12.


References 

[1] H.I. Shahadi, R. Jidin, High capacity and inaudibility audio steganography scheme, 

Proceedings of the 2011 7th International Conference on Information Assurance and 

Security, IAS 2011, 2011, Article number 6122803, pp. 104-109. 

[2] D.M.L. Ballesteros, J.M.A. Moreno, Highly transparent steganography model 

of speech signals using Efficient Wavelet Masking, Expert Systems with Applications, 

vol. 39, Issue 10, 2012, pp. 9141-9149. 

[3] M. Baritha Begum, Y. Venkataramani, LSB based audio steganography based on 

text compression, Procedia Engineering, vol. 30, 2012, pp. 702-710. 

[4] W. Zeng, R. Hu, H. Ai, Audio steganalysis of spread spectrum information hiding 

based on statistical moment and distance metric, Multimedia Tools and Applications, 

vol. 55, Issue 3, December 2011, pp. 525-556. 

[5] M. Sliskovic, Sampling frequency offset estimation and correction in OFDM systems”, 

Proceedings of the IEEE International Conference on Electronics, Circuits, and 

Systems, vol. 1, 2001, Article number 957773, pp. 437-440. 

[6] P.H. Moose, Technique for orthogonal frequency division multiplexing frequency 

offset correction, IEEE Transactions on Communications, vol. 42, Issue 10, October 

1994, pp. 2908-2914. 

[7] P. Gajewski, J. Łopatka, Z. Piotrowski, A New method of frequency correction 

using coherent averaging, Journal of Telecommunications and Information Technology, 

1/2005, pp. 142-146. 

[8] Z. Piotrowski, Drift correction modulation scheme for digital audio watermarking, 

Proceedings – 2010 2nd International Conference on Multimedia Information 

Networking and Security, MINES 2010, 2010, Article number 5670982, pp. 392-397. 

[9] P. Dymarski, R. Markiewicz, Time and sampling frequency offset correction in audio 

watermarking, International Conference on Systems, Signals, and Image Processing, 

2011, Article number 5977417, pp. 291-294. 

[10] Z. Piotrowski, Precise psychoacoustic correction method based on calculation 

of JND level, Acta Physica Polonica A, vol. 116, Issue 3, September 2009, pp. 375-379.

Index

A 

Abut Fatih 161 

Akcaoglu Ismail 11 

Andersson Jon 179 

Apiecionek Łukasz 49 

Ax Markus 305 

B 

Baranowski G. 71 

Barz Christoph 161 

Bereziński Przemysław 83, 347 

Bibik Przemysław 431 

Bloebaum Trude H. 117 

Borowski Mariusz 485 

Bret Norbert 161 

Brose Margrete A. 179 

Brzostek Juliusz 347 

Bystricky Radek 93 

C 

Cetinkaya Orhan 11 

Chambers Dale 37 

Chapman Jonathan P. 395 

Charlish Alexander 281 

Choraś Michał 347 

Connah Jessica 37 

Czajka Tomasz 475 

D 

Dalecki Tomasz 83 

Darakchiev Radoslav 431 

Dedera Ľubomír 209 

Diefenbach Anne 105, 161 

Duda Damian 239 

Dymowski Wojciech 331 

F 

Fiske Rui 359 

Flizikowski Adam 415 

Fongen Anders 131 

Franke Markus 105 

G 

Gawroński Michał 475 

Ginzler Tobias 253 

Gleba Kamil 239 

Gliwa Rafał 475 

Głowacka Joanna 239 

Goode Rob 61 

Govaers Felix 281, 395 

Gradolewski Stanisław 431 

Grądzki P. 71 

Grzonkowski Marcin 465 

H 

Hallingstad Geir 377 

Harmsen Edgar 61 

Hauge Mariann 179 

Hecking Matthias 265 

Hołubowicz Witold 331, 415 

J 

Janu Premysl 93 

Jarmakiewicz Jacek 465 

Jasiul Bartosz 347 

Jordan Fred 61 

K 

Kiviharju Mikko 439 

Koch Wolfgang 281 

Kosowski Tomasz 49 

Kozik Rafał 347 

Krenc Ksawery 295 

Krężel Jerzy 431 

Kruszyński Henryk 49, 317 

L 

Langerwisch Marco 305


Leśniewicz Marek 485 

Lund Ketil 117 

Lunt Graeme 359 

M 

Maesel Syvert 61 

Malas Atilla 11 

Malewicz Robert 359 

Małowidzki Marek 83 

Mazur Michał 83 

McInnes John 37 

Michalski Mateusz 431 

Muchewicz Krzysztof 317 

N 

Noubours Sandra 265 

O 

Okur Yavuz 11 

Oszywa Wojciech 465, 475 

P 

Palka Robert 49, 317 

Piotrowski Marek 49, 317 

Piotrowski Rafał 347 

Piotrowski Zbigniew 497 

Pyda Piotr 239 

R 

Rachwalik Tomasz 455 

Remmersmann Thomas 305 

S 

Sander Jostein 179 

Seifert Hartmut 105 

Sevenich Peter 105, 161 

Simon Pierre 161 

Skarżyński Paweł 71 

Smaal Jan-Willem 61 

Solomon Abigail 37 

Springer Tomasz 331 

Steinmetz Philipp 149 

Strzelczyk Krzysztof 431 

Szmidt Janusz 455 

Ś 

Śliwa Joanna 221, 239 

T 

Thamke Stefan 305 

Thorsen Einar 61 

Tiderko Alexander 305 

Tolk Andreas 201 

Turksoy Hasan 11 

U 

Urban R. 71 

Uysal Mutlu 11 

W 

Wicik Robert 455 

Wilgucki Kamil 71 

Wilmes Matthias 161 

Wodecki Krzysztof 497 

Wojtuń Jarosław 497 

Worthington Olwen 37 

Wrona Konrad 377 

Wrzosk Arkadiusz 21 

Z 

Zabłocki Janusz 455 

Zawiślak Wojciech 431 

Zbudniewek Jacek 431 

Zych Jan 415

Military Communications and Information Technology: A Trusted ...

Create successful ePaper yourself

Delete template?

Save as template?