lara - eda.europa.eueda.europa.eu/docs/documents/lara_executive_summary.pdf · lara layered...

France The Netherlands Italy Italy Norway

EUROFINDER PROGRAMME Europa MoU

LARA Layered Architecture for Real-time Applications

Contract EUROPA CEPA 6

N° 05 / 106 . 039 / 012

LARA Executive Summary

Document reference: LARA.WP1.D18

Document revision: 1.0

Authenticated by Approved by (Contracting agency) (Contractor)

Date Date

Project Number Deliverable Number Revision Classification Format Page

05 / 106.039 / 012 LARA.WP1.D18 1.0 WEU Unclassified A4 1/34


Change Record

Edition Date Writer Modification

Draft 26/07/2007 D. THEBAULT Document creation

Revision 1.0 09/08/2007 D. THEBAULT Modification after review by the consortium

Revision 2.0 18/09/2007 D. THEBAULT Addition of a LARA abstract




LARA Abstract

The LARA project aimed at improving radio networking technology by demonstrating how modern networking technology and protocols, such as IP, could enable distributed real-time applications in a joint military context. The resulting network was expected to allow information sharing, which is required to improve situational awareness in the real-time domain, and to provide a backbone to support a common engagement capability using distributed sensors and weapons networks - all in real-time.

The capabilities that were researched under the project are the key underpinning technologies required to enable progress towards the future military vision of a flexible, integrated NCW (also known as NEC, NCO or NBD) capability which can be used for Joint, NATO, Allied and Coalition operations.

The LARA architecture that came out of the project is a generic IP-based architecture that combines: • data and voice traffic; • real-time and elastic data; • point-to-point and point-to-multipoint traffic.

The LARA architecture follows a structure in four layers, as summarized below: • a transmission layer made of Network Elements (NE) which can be as various as

satellite links, radio networks, telecommunication operator backbones, etc.; a NE represents a collection of homogeneous nodes making up a connex network and sharing the same technical characteristics (waveform, routing protocols, session control protocols, COMSEC and TRANSEC crypto algorithms, etc.) and configuration parameters (frequency plan, addressing plan, COMSEC and TRANSEC crypto keys, etc.);

• a connectivity layer which acts as a federating IP transit network (or IP backbone) on top of the NEs;

• a communication services layer comprising service networks (possibly of different security levels); a service network provides “addressed” communication services, i.e. services where end-user addresses or identifiers are explicitly used to communicate over the network; examples of such services are voice/video sessions, real-time data sessions, file transfer, web browsing, etc.;

• a dissemination layer comprising dissemination networks seen as extensions to service networks; a dissemination network provides “group” services, i.e. services where group identifiers are used over the network irrespectively of the actual users present in the groups; examples of such services are voice/video conferences, instant messaging, web content distribution, application data exchanges based on the publish/subscribe interaction pattern, etc.

A demonstrator was produced as part of the LARA project. The demonstrator covers the whole LARA architecture and implements the four networking layers and an additional application layer. It comprises six platforms connected through a radio network made of radio prototypes operating in ad hoc mode with radio relay.




Appropriateness of the LARA architecture for deployment of up to 20 platforms was addressed through simulation. The project outcome represents innovation in several technical fields: • Quality of Service (QoS):

Classification of traffic in LARA merges QoS recommendations from the French procurement agency and NATO QENI phase 2. A new class of service, named ‘real-time’, was introduced to characterise those flows that need guarantee of bounded, low latency. The LARA QoS approach is essentially based on the combination of DiffServ and IntServ architectures. DiffServ principally targets elastic data flows and IntServ sensitive real-time flows. QoS guarantee is given through session setups and reservation mechanisms in terms of bandwidth only, or with maximum end-to-end latency.

• Security Gateway: Resource reservation requests are initiated in the red enclaves. By propagating the reservation requests through a security gateway, physical resources can be allocated in the black radio network based on bandwidth and latency requirements expressed by the applications in the red enclaves.

• MAC Layer: The LARA MAC layer was designed to be independent of the physical radio (with the assumption however of a mono-channel TDMA-based radio). It implements a dynamic slot allocation mechanism triggered by the resource reservation requests received from the IP layer. The slot configuration for a session flow is computed from the requested bandwidth (minimum number of slots) and the maximum radio access time afforded in the radio node (maximum slot spacing).

• Data Dissemination: Data dissemination in LARA is provided to two data applications: FDF (Force Data Fusion) and CE (Common Engagement). The objective of the FDF application is to disseminate available sensor-based information within a task force to provide each combatant with the opportunity to produce the same Common Tactical Picture of the surrounding battle space. The objective of the CE application is to minimize the own damages using the resources available in the Force as effectively as possible against threats. The LARA dissemination infrastructure extends the LAN data distribution between platforms. It is based on the publish/subscribe paradigm to provide a loose coupling between producers and consumers of information so that independence between them is possible.

LARA proved that latency can be bounded and jitter minimized in an IP radio network. However for real-time flows with hard latency constraints, bandwidth over-reservation may be necessary to guarantee end-to-end latencies.

Some LARA results will lead to normalisation actions towards NATO, IETF and INRIA. Further studies could be initiated to e.g. address management in LARA (crypto key management, radio silence management, sensor management, QoS management, network management, etc.).




Table of Contents

1. SCOPE OF APPLICATION .......................................................................................................................... 7 1.1 IDENTIFICATION........................................................................................................................................ 7 1.2 SCOPE OF THE SYSTEM.......................................................................................................................... 7 1.3 SCOPE OF THE DOCUMENT.................................................................................................................... 8

2. REFERENCE DOCUMENTS........................................................................................................................ 9 2.1 APPLICABLE DOCUMENTS ...................................................................................................................... 9 2.2 RELATED DOCUMENTS............................................................................................................................ 9 2.3 SOURCE DOCUMENTS............................................................................................................................. 9

3. OVERVIEW OF THE LARA ARCHITECTURE .......................................................................................... 10 3.1 SCOPE OF THE LARA ARCHITECTURE................................................................................................ 10 3.2 LARA OVERVIEW..................................................................................................................................... 10 3.2.1 CONTEXT OF THE LARA PROJECT....................................................................................................10 3.2.2 OVERVIEW OF THE LARA ARCHITECTURE LAYERS....................................................................... 11 3.2.3 OVERVIEW OF THE LARA SECURITY ARCHITECTURE................................................................... 12 3.2.4 LARA NODE ARCHITECTURE SUMMARY.......................................................................................... 13

4. TECHNICAL CONSIDERATIONS.............................................................................................................. 15 4.1 QUALITY OF SERVICE ............................................................................................................................ 15 4.2 SECURITY GATEWAY ............................................................................................................................. 17 4.3 MAC LAYER.............................................................................................................................................. 19 4.4 DATA DISSEMINATION ........................................................................................................................... 21 4.5 DEMONSTRATOR.................................................................................................................................... 23 4.6 SIMULATION ............................................................................................................................................ 27

5. CONCLUSION ............................................................................................................................................ 30

6. LIST OF ACRONYMS AND ABBREVIATIONS......................................................................................... 32




List of Figures

Figure 1: LARA network architecture overview .................................................................................................. 11 Figure 2: LARA red and black networks............................................................................................................. 12 Figure 3: LARA node architecture summary ...................................................................................................... 13 Figure 4: LARA layers overview ......................................................................................................................... 14 Figure 5: Cascading and propagation of RSVP signalling ................................................................................. 17 Figure 6: Standard resource reservation over a security association ................................................................ 18 Figure 7: Proposed resource reservation over a security association ............................................................... 19 Figure 8: TDMA structure summary ................................................................................................................... 20 Figure 9: Session slot allocation......................................................................................................................... 21 Figure 10: Illustration of the FDF application objective ...................................................................................... 22 Figure 11: Illustration of the CE application process .......................................................................................... 22 Figure 12: Transmission layer topology in the international demonstrator......................................................... 24 Figure 13: Demonstrator configuration............................................................................................................... 24 Figure 14: LARA international demonstrator ...................................................................................................... 25 Figure 15: Example of an FDF/CE scenario....................................................................................................... 26 Figure 16: LARA node simulation model ............................................................................................................ 27 Figure 17: 6-node scenario evolution ................................................................................................................. 28 Figure 18: 20-node scenario in OPNET ............................................................................................................. 29

List of Tables

Table 1: LARA CoS mapping ............................................................................................................................. 16 Table 2: Characteristics of the LARA radios ...................................................................................................... 25




1. SCOPE OF APPLICATION

1.1 IDENTIFICATION

This document is the executive summary produced as part of Work Package 1 of the LARA project. The document is referred to as LARA.WP1.D18.

1.2 SCOPE OF THE SYSTEM

The LARA project is aimed at improving radio networking technology by demonstrating how modern networking technology and protocols, such as IP, can enable distributed real-time applications in a joint military context. Such a network allows information sharing, which is required to provide improved situational awareness in the real-time domain (force data fusion) and can provide a backbone to support a common engagement capability using distributed sensors and weapons networks - all in real-time.

The capabilities being researched under the project are the key underpinning technologies required to enable progress towards the future military vision of a flexible, integrated NCW (also known as NEC, NCO or NBD) capability which can be used for Joint, NATO, Allied and Coalition operations.

The goal of LARA can be formulated as a balance between the co-operative application requirements and the communication capabilities.

The main objectives are summarized hereafter:

• Define the required network and transmission layer, - To support real-time and if possible near real-time and non real-time

applications (segmented if required), - With IP-oriented services, - Giving consideration to security aspects in all layers, - And allowing dynamic reconfiguration & access.

• Assess feasibility and performance through simulation, - Based on scenarios from the air defence domain, - Using network, transmission, security and applications models, - With enough confidence to make it the main tool for network validation with a

large number of nodes.




• Validate critical aspects through demonstration, - Based on a configuration with a limited number of physical nodes and links, - Using RF simulators and possibly real High Capacity Data Radios (HCDR) or

WiMax devices for the transmission segment, - In order to:

1. Validate the simulation models, 2. Gain confidence in the developed architecture.

1.3 SCOPE OF THE DOCUMENT

This document is the executive summary of the LARA project. It is one of the deliverables of the WP1 work package.

This document is organised in several parts.

The first part presents an overview of the LARA architecture.

The second part details some technical results of LARA, and is further decomposed around the following items: • Quality of Service • Security gateway • MAC layer • Data dissemination • Demonstrator • Simulation

The third and last part draws some conclusions on the LARA project.




2. REFERENCE DOCUMENTS

2.1 APPLICABLE DOCUMENTS

ID Document Reference Issue Date

AD 1

2.2 RELATED DOCUMENTS


RD 1

2.3 SOURCE DOCUMENTS


SD 1




3. OVERVIEW OF THE LARA ARCHITECTURE

3.1 SCOPE OF THE LARA ARCHITECTURE

The LARA architecture encompasses multiple technical goals, namely:

• Support of time-sensitive applications: - real-time (< 50 ms, e.g. voice), - near real-time (between 500 ms and 1 s), - non real-time (< 30 s);

• Using and providing interoperability with civilian technologies: - IP-oriented protocols (OSPF, OLSR, RSVP, DiffServ, …), - data dissemination (Web Services, XML, SOAP, …), - VoIP services (SIP, …);

• Giving consideration to security aspects in all layers;

• Supporting Quality of Service: - guaranteed services (in terms of data rate and/or latency) for sensitive flows, - aggregated QoS (DiffServ) for the other flows;

• Allowing dynamic reconfiguration and access (MAC) above the LARA physical radio;

• Optimising the radio resources;

• Supporting radio silence and platform mobility.

3.2 LARA OVERVIEW

This paragraph aims at summarising the outcome of the LARA architecture activity.

3.2.1 CONTEXT OF THE LARA PROJECT

Data applications in their current definition are organised above a platform LAN and interact through a DDS-type interface (Data Distribution System).

The DDS interface is based on the concept of a global data space that is accessible to all interested applications within the LAN through Publish and Subscribe operations (data-centric architecture). These operations rely on a data model which specifies how publishers and subscribers refer to portions of the global data space they have to exchange. Data structures in the data model are identified by topics. Applications in a




DDS environment are attached to a domain. A domain is another concept that links all the applications able to communicate with each other within the LAN. It represents a communication plane: only the publishers and the subscribers attached to the same domain may interact.

The LARA network is intended to provide an extension of the LAN data distribution between platforms. That extension is referred to as dissemination infrastructure. Dissemination services are invoked through a dissemination interface. In the LARA environment, some adaptation between the DDS interface and the dissemination interface is deemed necessary. This adaptation is assumed to be processed by a dissemination gateway (whose analysis was outside the LARA scope).

Besides the dissemination services, the LARA network also provides communication services for e.g. VoIP, file transfer and other well-known applications. The very analysis of those services was not part of the LARA scope; only their impact on the LARA architecture was addressed.

The following figure depicts the context in which the LARA architecture was defined; it also presents the different interfaces and layers involved:

Pub Sub

Gateway

Service NetworkTCP/UDPIP Routing

RadioIndependent LayerRadio Specific MAC

Dissemination Interface

Physical Radio

Securi ty

Security

Pub Sub

Gateway

Data Distribution System (DDS)

TCP/UDP IP

Ethernet

Pub Sub

Publish/Subscribe Mechanism

Scope of LARA analysis

TCP/UDP IP

Ethernet

Pub Sub

Publish/Subscribe Mechanism

Application Application

Data Distribution System (DDS)

TCP/UDPIP Routing

Radio Specific MACPhysical Radio

RadioIndependent Layer

LARA Node LARA Node

Dissemin. Network

Service Network

Dissemin. Network

Figure 1: LARA network architecture overview

3.2.2 OVERVIEW OF THE LARA ARCHITECTURE LAYERS

The LARA architecture follows a structure in four layers, as summarized below:

• a transmission layer made of Network Elements (NE) which can be as various as satellite links, radio networks, telecommunication operator backbones; a Network Element represents a collection of homogeneous nodes making up a connex network and sharing the same technical characteristics (waveform, routing protocols, session control protocols, COMSEC and TRANSEC crypto algorithms,




etc.) and configuration parameters (frequency plan, addressing plan, COMSEC and TRANSEC crypto keys, etc.); a particular NE is the LARA Radio NE;

• a connectivity layer which acts as a federating IP transit network (or IP backbone) on top of the NEs;

• a communication services layer comprising service networks (possibly of different security levels);

• a dissemination layer comprising dissemination networks seen as extensions to service networks.

For completeness, an application layer gathering the applications connected to Local Area Networks (LAN) can be added. This fifth layer is not part of the LARA architecture as such, but is necessary to have a complete architecture description.

It must be noticed that this layer decomposition is not an OSI model view, even though each layer offers services to the upper-level layer (as meant by the OSI model). A layer may indeed involve a full protocol stack from OSI layer 1 to OSI layer 7.

3.2.3 OVERVIEW OF THE LARA SECURITY ARCHITECTURE

The LARA network is made of two types of sub-networks:

• a red edge network where user data and control data are exchanged in clear mode. The red network is also referred to as Secure Enclave (SE);

• a black core network where user data is protected and ciphered, and control data is protected as a minimum. The black network namely includes the radio network.

The interface between the red and black networks is hosted by a security gateway.

The LARA security architecture is illustrated in Figure 2 hereafter:

FDF Application

LAN

VoIP

Red Network

CE Application

Red LARA Node

Security Gateway

Black Network

LARARadio

Black LARA Node

LARARadio

Black LARA Node

Radio Network

CE Application

LAN

VoIP

Red Network

FDF Application

Red LARA Node

Security Gateway

Figure 2: LARA red and black networks

The security architecture also involves local functions like COMSec, TRANSec, firewalling, etc.




3.2.4 LARA NODE ARCHITECTURE SUMMARY

The networks introduced in 3.2.2 are built upon a set of nodes:

• Transmission Stations (TS) in the Network Elements;

• Transit Nodes (TN) in the IP transit network;

• Service Nodes (SN) in the service networks;

• Dissemination Nodes (DN) in the dissemination networks.

A LARA node represents a set of the above-mentioned nodes located on a same platform (e.g. a vessel or a land base). It generally comprises one or several Transmissions Stations, one Transit Node, one or several Service Nodes and one or several Dissemination Nodes. This is illustrated by Figure 3 hereafter.

TS_RadioTS_Router

TS - LARA Radio NE

TS - Additional NE

TN_QoSManager

TN_Router

SN_Security

SN_Router

SN_TechServer

LAN

SN_Security

SN_Router

SN_TechServer

LARA Dissemination Networks

LARA Service Networks

LARA IP Transit Network

LARA Transmission Networks

Local Area Networks

LAN

TS_TAD TS_MAC

SN

SN

TN

TS_QoSManager

DN_Security

DN_Server

DN_TechServer

DN_Mediation

DN

Figure 3: LARA node architecture summary




The positions of the different architecture elements (NE, TN, SN, DN) with respect to the four LARA architecture layers are illustrated in Figure 4 below. An application layer has been added for completeness.

Dissemination

Transmission

Connectivity

Communication Services

Applications

LARA Radio NE

NE

NE LARA

Radio NE

DN DN

SN SN

SN

TN

TN

TN TN

LARA Node Figure 4: LARA layers overview




4. TECHNICAL CONSIDERATIONS

4.1 QUALITY OF SERVICE

Quality of Service (QoS) is intended to lead to more predictable usage of network resources and less volatile contention for these resources.

QoS impacts all the LARA architecture layers, i.e. dissemination, communication services, connectivity and transmission layers. LARA defines sophisticated traffic control mechanisms that take into account security and resource management.

The main QoS aspects involved in LARA are the following: • Classes of Service; • Differentiated services; • Integrated services and resource reservation; • Dynamic resource allocation; • QoS routing.

Classification of traffic in LARA merges QoS recommendations from the French procurement agency (DGA) and NATO. A new Class of Service (CoS), named ‘real-time’, was introduced to characterise those flows that need guarantee of bounded, low latency.

DSCP allocation for LARA follows NATO QENI’s recommendation for mid-term implementation (i.e. QENI phase 2) with a few additions coming from the French procurement agency (DGA).

CoS Usage DSCP DSCP value Decimal value

Real-time • Low-latency data dissemination GF 110010 50

Network • Routing protocols (OSFP, OLSR, …) • MPLS path establishment • SNMP alarms • ICMP error messages

CS6 110000 48

Voice • VoIP • Circuit emulation over IP

EF 101110 46

Signalling • VoIP signalling • Video signalling

CS5 101000 40

Video • Videoconference AF4i 100xx0 34, 36, 38

Tactical • Tactical data dissemination (plots, tracklets) CS4 100000 32

Streaming • Video streaming • Audio streaming

AF3i 011xx0 26, 28, 30

Keyboard • Interactive transactions • Instant messaging • Web browsing

AF2i 010xx0 18, 20, 22




CoS Usage DSCP DSCP value Decimal value

Bulk • File transfer • Electronic messaging • Database update

AF1i 001xx0 10, 12, 14

Normal • Best-effort traffic BE 000000 0

Table 1: LARA CoS mapping

The LARA QoS approach is essentially based on the combination of DiffServ (Differentiated Services) and IntServ (Integrated Services) architectures.

DiffServ principally targets elastic data flows, and IntServ sensitive real-time flows. Elastic data flows are not given any QoS guarantee on a per-flow basis, but an aggregate QoS based on the class of service they belong to. Sensitive real-time flows on the other hand are allocated dedicated resources in the network through session setups.

A secure enclave in LARA is a DiffServ-capable source domain, with the SN_Router component playing the role of a DiffServ boundary node. The LARA IP transit network and the LARA radio Network Element are considered as a single DiffServ domain, with TN_Router components acting as DiffServ boundary nodes and TS_Router components as DiffServ interior nodes.

LARA introduces a new DiffServ PHB, referred to as Guaranteed Forwarding (GF), to support the new ‘real-time’ Class of Service.

Integrated Services are based on the RSVP protocol. Through session setups and reservation mechanisms, LARA guarantees QoS to sensitive real-time flows (also referred to as session flows) like voice and some data dissemination traffic. Guarantee is given in terms of bandwidth only (RSVP’s OP mode) or with maximum end-to-end latency (RSVP’s OPWA mode). Guarantee applies to both unicast and multicast types of flows.

RSVP sessions are initiated in the communication services layer (i.e. in the red domain). RSVP requests are cascaded into the connectivity layer through the security gateway and IPSec tunnels, and relayed into the RSVP-capable Network Elements (NEs). This cascading and propagation of RSVP signalling is illustrated on Figure 5 hereafter:




Security Association

TN layer

SN layerRed Network

Black Network

DN layer

RSVP regeneration

PATH messages

RSVP

RSVP

TS layer

RSVP

TDMA resource reservation

requests

RESV messages

Figure 5: Cascading and propagation of RSVP signalling

Route pinning ensures that packet routing is performed in accordance with the reservations made. LARA recommendation is to base route pinning on UDP encapsulation in the communication services layer and on MPLS in the connectivity and transmission layers. The security gateway must then support RSVP on the red interface and RSVP-TE on the black interface.

The LARA radio NE is RSVP-capable. RSVP requests are propagated to the TDMA-based MAC layer and translated into slot allocation requests exchanged between neighbours for negotiation. The LARA MAC layer implements a dynamic slot allocation algorithm for session flows. Around 70% of the total slot capacity are dedicated to sessions and are managed as a pool of available resources.

The LARA MAC layer also implements a pre-emption mechanism based on session precedence. Session re-routing upon topology change, as well as extension to new participants in the multicast groups, are supported by the RSVP refresh mechanism.

The global resource consumption is minimized by performing a routing simply based on the number of hops. Additionally, MAC relaying is performed for session flows.

LARA recommends an OLSR persistent source routing of RSVP messages to avoid path instability so that session re-routing is only performed upon shorter path discovery. Impact of QoS on the OLSR routing protocol is also limited thanks to the dynamic slot allocation.

4.2 SECURITY GATEWAY

RSVP requests are initiated at communication services level by the SN_Router component.

Those requests, coming from the red network, are then propagated to the black network through the LARA security gateway which allows the propagation of specific signalling messages. More precisely, the security gateway intercepts the RSVP PATH and RESV messages and regenerates them in a controlled way into the black network.




For security considerations, it shall be made clear that some controlled information passes from the red network to the black network to allow proper resource reservation; this concerns the traffic profile of the application (found in the TSpec object of the PATH message) and the required bandwidth (found in the RSpec object of the RESV message).

For the OP (One Pass) mode of RSVP that provides QoS guarantee in terms of bandwidth only, the RSVP cascading is standardised by an RFC, namely RFC 2746 (RSVP operations over IP tunnels). Figure 6 below illustrates the cascading mechanism:

Black Network

(1) PATH Reservation A to B

(7) PATH (8) “PATH“ (9) “PATH” (10) PATH

(12) RESV(15) RESV (14) “RESV” (13) “RESV”

(2) PATH

(5) RESV

(3) PATH

(4) RESV

(11) PATH (with SESSION_ASSOC)

(6) RESV

SN_Security A decides how to

map the red flow into a tunnel

A

SN_Security B associates the red flow with the tunnel

B

SN Router A

SN Security A

SN Router B

TN QoSManager

TN QoSManager NE

SN Security B

Figure 6: Standard resource reservation over a security association

The mechanism presented in Figure 6 allows to cascade RSVP signalling in OP mode. Unfortunately, RFC 2746 does not support the OPWA (One Pass With Advertising) mode of RSVP that provides QoS guarantee in terms of bandwidth and maximum end-to-end latency. There is indeed no way to collect the end-to-end path’s characteristics (in particular the RSVP AdSpec parameters). The actual reservation will only take into account latency characteristics of the red domain, and not those of the black domain, while latency in LARA mainly comes from the black radio network.

Since the OPWA mode is essential in LARA, an extension of RFC 2746 is proposed. This extension consists in collecting the AdSpec objects of both the red and black PATH messages received in the security gateway and in aggregating them in the red PATH message that is propagated into the destination red enclave. The general mechanism is illustrated on Figure 7 hereafter:




Black Network

(1) PATH Reservation A to B

(3) PATH (4) “PATH“ (5) “PATH” (6) PATH

(12) RESV (15) RESV (14) “RESV” (13) “RESV”

(2) PATH

(10) RESV

(8) PATH

(9) RESV

(7) PATH (with SESSION_ASSOC)

(11) RESV

SN_Security A decides how to

map the red flow into a tunnel

A

SN_Security B associates the red flow with the tunnel and aggregates red and black AdSpec characteristics

B

SN Router A

SN Security A

SN Router B

TN QoSManager

TN QoSManager NE

SN Security B

δ max

δ max

Figure 7: Proposed resource reservation over a security association

Note: for security considerations, it shall be made clear that some controlled information passes from the black network to the red network; this concerns the latency characteristics of the black network (found in the AdSpec object of the PATH message).

4.3 MAC LAYER

The LARA MAC layer is designed to be independent of the physical radio (with the assumption however of a mono-channel TDMA-based radio). The LARA TDMA framing is based on four types of structures:

• Packet Data Units (PDU): A PDU is the MAC allocation unit.

• Slots: A slot is the radio allocation unit; it can be seen as a container of MAC PDUs. A slot is allocated to a single transmitter due to the mono channel characteristics of the LARA radio. Three types of slots have been identified in LARA: control slots, elastic data slots and session slots. Control slots are fixed slots assigned to each node for MAC signalling (node discovery, node synchronisation, slot allocation protocol). Elastic data slots are fixed slots assigned to nodes for forwarding elastic data flows; all the radio nodes are assigned by configuration the same number of elastic data slots. Session slots are part of a pool shared among the radio nodes; they are allocated to a node on demand taking into account bandwidth and latency requirements; they are used to forward session flows.




• Basic frames: A basic frame is a structure of k successive slots where k is determined by configuration. A basic frame contains 1 control slot, p elastic data slots and k-p-1 session slots.

• Frames: A frame is a structure of n successive basic frames where n is the number of nodes in the radio network. The LARA TDMA is a recurrence of frames.

Figure 8 below summarizes the TDMA structure.

mono channelTDMA

Slot

Frame

Frame

Basic frame

Basic frame

BF1 … BFn BF1 … BFn

Slot

PDU

Slot

PDU Figure 8: TDMA structure summary

Elastic data slots are globally interleaved in the frame to provide elastic data flows with an homogeneous access delay to the radio and a reduced maximum access delay.

The LARA MAC layer implements a dynamic slot allocation mechanism triggered by requests from RSVP. A minimum number of needed slots is computed from the requested bandwidth, while a maximum time slot spacing is derived from the maximum radio access time afforded in the radio node. Both constraints are used to calculate a slot configuration for the session flow in the radio node. Firstly session slots already assigned to the radio node are used to the largest extent possible to avoid unnecessary negotiations. Secondly session slots from the pool are used as necessary to complete the slot configuration. If enough resources cannot be found to comply with the QoS constraints, local pre-emption is performed against lower priority sessions to free resources when possible. If the slot configuration requires session slots from the pool, a negotiation is initiated with the direct neighbours (i.e. 1-hop neighbours) to confirm the allocation.




The allocation process is twofold: sessions slots are first allocated to radio nodes; MAC PDUs in the allocated session slots are then assigned to session flows. A same session slot can be used to forward different session flows. To optimize the resource consumption in the radio network, it is possible for the LARA MAC layer to fill each slot with elastic data flows up to the maximum transfer unit. A resulting allocation for a session slot is given in Figure 9 below.

Session 1 MAC PDUs

Session 2 MAC PDUs

Elastic data MAC PDUs

Figure 9: Session slot allocation

To optimize stability and forwarding of session flows, route pinning is performed in the LARA MAC layer. Session flows are relayed between the ingress and egress points directly at MAC level rather than invoking the IP forwarding. Session packets are identified by a session identifier (e.g. MPLS label) provided by RSVP and are relayed by the LARA MAC layer based on this identifier. Packets that are received without identifier or with an unknown identifier are routed from node to node by the IP layer. This is in particular the case of elastic data flows, since no identifier is attached to the flows.

The global topology is maintained at IP level. The LARA MAC layer only maintains a 2-hop visibility table. Spatial re-use of slots is performed beyond 3 hops.

When a node enters the radio network, it first listens to the LARA MAC messages exchanged in the network to synchronise its TDMA with the other nodes. After TDMA synchronisation, it receives from the other nodes snapshots of their local slot allocation tables.

4.4 DATA DISSEMINATION

Data dissemination in LARA is provided to two data applications: FDF (Force Data Fusion) and CE (Common Engagement).

The objective of the FDF application is to disseminate available sensor-based information within a task force to provide each combatant with the opportunity to produce the same Common Tactical Picture (CTP) of the surrounding battle space. Figure 10 hereafter illustrates this objective. The FDF application consists in a distributed multi-platform fusion process that generates the CTP with a consistent track labelling between platforms and an improved track continuity. Compared with a single-platform fusion process, the distributed sensor functionality allows an extension of the surveillance volume and a reduction of the sensitivity to disturbing phenomena




(e.g. jamming, weather) and line-of-sight blocking obstacles (terrain, objects). Track initialisation time is also reduced, tracks are more accurate and a higher track update rate is possible.

Platform 2Platform 1

Composite Track

All Platforms

Platform 3

Composite Track

All Platforms

Composite Track

All Platforms

Multi-platform fusion

All Platforms

Composite Track

Figure 10: Illustration of the FDF application objective

The objective of the CE application is to minimize the own damages using the resources available in the Force as effectively as possible against threats. It is characterised by a distributed approach that improves the survivability and response time of the Force. It prevents redundant threat engagements and friend/neutral kills. The engagement plan is updated upon detection of a new threat, upon kill assessment, etc. Figure 11 below provides an illustration of the CE application process.

FDF, Recognition & Identification

Threat Evaluation

CTP Engagement

Plan Threat

List Weapon

Sensor

Weaponassignment

Sensor allocationTask Force mission

Allocation plan

Kill assessment

Figure 11: Illustration of the CE application process

Both FDF and CE applications are deployed in a platform LAN and interact through a DDS interface. To extend the LAN data distribution between platforms, some adaptation is necessary between the DDS-based LAN and the LARA dissemination infrastructure. The adaptation is processed by a dissemination gateway, and consists in mapping the DDS topics to dissemination channels/flows with QoS prerogatives such as traffic profile, latency constraint, message size, etc.




The LARA dissemination infrastructure is based on the publish/subscribe paradigm where producers of information announce their productions, and subscribers advertise their centres of interest, dynamically. The dissemination gateway introduced earlier acts as a producer and a subscriber of FDF and CE data.

The LARA dissemination infrastructure provides a loose coupling between the producers of information and the subscribers so that independence between them is possible. Information can be obtained without knowing where it is, nor who produces it. Likewise, information can be produced without knowing whether there are subscribers to this information, nor where they are. Dissemination brokers are deployed between the producers and the subscribers to guarantee this independence.

The LARA dissemination infrastructure is based on the definition of dissemination channels/flows with attached technical properties (QoS, security, etc) that are used by the underlying service network to adequately process the related application flows. In particular, the service network is able to: • trigger resource reservation in the IP network; • translate the application CoS into IP DSCP; • compress/encode messages; • cipher (some parts of the) messages for confidentiality; • sign (some parts of the) messages for authentication, integrity and non repudiation; • label messages to cross security guards between different security domains; • etc.

The LARA dissemination infrastructure relies on the underlying service network to perform message routing. Group management and mapping onto IP multicast groups is also achieved in the service network.

4.5 DEMONSTRATOR

Six platforms make the LARA international demonstrator: three naval platforms (referred to as Smart-L1, Smart-L2 and APAR), one land platform (referred to as Smart-L3) and two helicopters (referred to as Heli1 and Heli2). The six platforms connect to each other through the LARA radio network, and an emulated satellite link is also available between Smart-L1 and Smart-L3.

Figure 12 hereafter gives an illustration of the demonstrator’s transmission topology. Topology of the LARA radio network is defined either by configuration or by scenario. In the latter case, when the scenario runs, platforms’ positions are retrieved by a network controller that dynamically computes line-of-sight information. This information is then pushed to the LARA radio nodes that filter incoming traffic accordingly.




Smart-L3

APAR

Smart-L2

Heli1

Smart-L1

Heli2

TS1

TS2

TS3

TS5

TS4

TS6

Island

Hill

LARA radio link Satellite link

Figure 12: Transmission layer topology in the international demonstrator

The following applications are deployed in the LARA international demonstrator: • for real-time data flows: FDF, CE • for multimedia flows (SIP-based VoIP): NGIN, CAFES • for preferred elastic data flows: chat • for elastic data flows: file transfer, web browsing

The demonstrator configuration is depicted in Figure 13 below. Two service networks are deployed, one supporting web browsing only, the other one supporting different types of voice and data applications.

NGIN

NGIN

NGIN

CAFES

Web browsing

Web browsing

Web browsing

FDF/CE

FDF/CE

FDF/CEFDF/CE

Node 6

Node 3

Node 4

Node 1

Node 5

Node 2

Chat

Chat

Chat File transfer

File transferCAFES NGIN

Web browsing

FDF/CE

VoIP sessions

Chat File transfer

Service network AService network B

LARA node

LARA radio link Emulated satellite link

: real-time data sessions : preferred elastic data : elastic data : elastic data

Figure 13: Demonstrator configuration

The LARA international demonstrator covers the whole architecture as summarized in Figure 3. The five layers (including the application layer) are implemented. A physical representation of the demonstrator is given in Figure 14 below.




FDF/CE, Chat, Web browsing

(Linux PC)VoIP

(TOMA Terminal)

SN_Security(Linux PC)

TS_Router TS_TAD TS_MAC TS_QoSManager (Linux PC)

TS_Radio(Physical Radio)

SN_RouterSN_TechServer

DN_Server (data)DN_Mediation

(Linux PC)

TN_Router TN_QoSManager

(Linux PC)

Ethernet Switch

DN_Server (voice) (Linux PC)

LAN

SN_Security (Linux PC)



SN_Router SN_TechServer DN_Server (data) DN_Mediation (Linux PC)


(Linux PC)

EthernetSwitch

LAN




(Linux PC)

FDF/CE, Chat, Web browsing

(Linux PC)VoIP

(TOMA Terminal)

DN_Server (voice) (Linux PC)

IP BonePhone (Linux PC)

TS_RouterTS_TADTS_MAC

TS_QoSManager(Linux PC)

TS_Radio (Physical Radio)


(Linux PC)


SN_Router SN_TechServer DN_Server (data) DN_Mediation (Linux PC)

DN_Server (voice)(Linux PC)

FDF/CE, Chat, Web browsing (Linux PC)

VoIP (TOMA Terminal)

Ethernet Switch

LAN





(Linux PC)


SN_Router (data) SN_TechServer DN_Server DN_Mediation (Linux PC)

FDF/CE, Chat, Web browsing (Linux PC)

SN_Router (voice) VoIP client (CAFES)

(Linux PC)

Ethernet Switch

LAN





(Linux PC) IP BonePhone

(Linux PC)

IP BonePhone (Linux PC)

Smart-L2

APAR

Heli1

Heli2 Smart-L3

Smart-L1

Nexus Gateway Network Controller

(Linux PC)

VR-Forces (Windows PC)

Ethernet Switch

Ethernet Switch

Configuration Network

Ground Truth Network

Configuration PC (Linux PC)

Figure 14: LARA international demonstrator

The LARA radio network is either based on physical radios or on “slotted” Ethernet. In the latter case, an additional PC is used to generate top slot messages every 10ms to mimic the radio behaviour.

In the LARA international demonstrator, physical radios are derived from WiMAX prototypes. Modifications were necessary to deploy a fully meshed radio network, since WiMAX exclusively implements the point-to-multipoint scheme of IEEE 802.16 standard. The modifications mainly related to the radios’ working mode, the frame’s synchronisation and the Automatic Gain Control (AGC) as summarized in Table 2 below. As a result of these modifications, it shall be noted that the LARA physical radios are no longer WiMAX compatible.

Characteristics WiMAX radios LARA radios

Mode A WiMAX radio either works as a Base Station or a Subscriber Station.

LARA radios transmit like Base Stations and receive like Subscriber Stations.

Synchronization Subscriber Stations are all synchronized to the Base Station.

For each slot, receiving nodes need to be synchronized to the transmitting node; the transmitter’s synchronization is therefore conveyed in each frame.

Automatic Gain Control (AGC)

A Subscriber Station always listens to the same Base Station; the AGC is therefore calculated for the next slot only.

The AGC depends on the transmitting node and is therefore computed for each slot and applied instantaneously.

Table 2: Characteristics of the LARA radios




Transmission Stations in the LARA Radio NE are MANET nodes with multicast capability. They embed a routing protocol and a multicast forwarding daemon derived from INRIA’s MOLSR/MDFP protocol stack, an RSVP daemon derived from USC ISI’s open source daemon, and a dedicated LARA MAC layer that was specifically developed for the LARA demonstrator. Session flows are relayed internally in the LARA MAC layer while elastic data flows are forwarded by the IP stack. RSVP signalling is intercepted for processing by the local node. Reservation requests are passed to the LARA MAC layer for dynamic slot allocation.

The LARA security gateway is derived from the one developed in the ETNA Eurofinder. It implements the proposed amendment to RFC 2746 (refer to paragraph 4.2) so that latency characteristics of the black network are properly taken into account in the service network when triggering resource reservation. It also encrypts multicast traffic and is able to generate multicast RSVP signalling. IPSec discovery was modified to cope with radio silence constraints.

TESA nodes from TCF are deployed in the LARA international demonstrator to provide the data service and dissemination networks. TESA nodes interface with RSVP to trigger resource reservation for session flows and mark elastic data packets with an appropriate DiffServ code point derived from the class of service they belong to. TESA nodes also map dissemination groups to IP multicast groups.

In the LARA international demonstrator, TESA nodes disseminate real-time data flows generated by the FDF and CE application simulators. Figure 15 below gives an example of the tactical display that comes with those application simulators.

Figure 15: Example of an FDF/CE scenario




Telephony in the LARA international demonstrator is supported by two types of products: NGIN for the naval platforms based on a S5000 product from M2MSoft, and CAFES from TCNL for the land platform. SIP is the VoIP signalling for both products, but NGIN embeds a stateful SIP server and CAFES a stateless SIP server. Both products also interface with RSVP to trigger resource reservation upon call setup. Interoperability between the two products is provided.

4.6 SIMULATION

Due to various reasons, the LARA demonstrator was contractually limited to 6 nodes. However a typical naval deployment would very likely involve up to 20 nodes. Simulation was then a suitable solution to verify that the proposed LARA architecture is appropriate to deployments of that size.

The simulation model of a LARA node is based on OPNET with the wireless extension package. The simulation model covers all the architecture layers described in paragraph 3. The transmission layer model substitutes the typical ARP level of the standard MANET station provided in the OPNET library. On top of it, the standard IP level plays the role of the connectivity layer. The simulation model then forks over IP: one branch implements the communication services and dissemination layers supporting the FDF/CE application model; the other branch represents the transport level of the standard TCP/IP stack supporting the standard voice application. Figure 16 shows the complete stack of the LARA node designed for simulation.

Figure 16: LARA node simulation model




A typical scenario was defined to calibrate the simulation model with the demonstration results. Figure 17 shows the OPNET Project Editor view of this scenario, also referred to as the 6-node scenario.

Figure 17: 6-node scenario evolution

The basic idea for calibration is pretty straightforward. Delay and bandwidth statistics are collected on the demonstrator from different measurements, taking into account the type of flows, the number of hops, etc. Data collected from simulation is then compared with the gathered demonstrator statistics to properly tune the simulation model.

After the calibration phase, the number of nodes can be scaled up to a level that is more representative of a realistic deployment. Additionally, while the maximum number of hops is limited to 3 in the 6-node scenario, it is deemed interesting to assess the performances of a LARA-based deployment up to 5 hops. A 20-node scenario served as basis for the simulation. Figure 18 hereafter shows the OPNET Project Editor view of this 20-node scenario.




Figure 18: 20-node scenario in OPNET




5. CONCLUSION

The main objective of LARA was to answer the following question:

“Is an IP radio network able to support exchanges of real-time data needed for multi-platform situation awareness and common engagement?”

LARA actually proved that latency can indeed be bounded and jitter minimized, which is essential for multi-platform situation awareness and common engagement, but at the expense of a large amount of resources that need to be reserved in the network.

LARA also pointed out that quality of service in an IP network is not only a matter of bandwidth. In some cases, and in particular for real-time data flows, latency is probably a factor as important as and definitely more demanding than bandwidth, even though at the end of the day only bandwidth is reserved in the network. Over-reservation ratio may then be extremely high due to the additional slots that need to be reserved to cope with a short time slot spacing. A ratio above 10 was observed in the LARA demonstrator for some FDF topics.

Similarly, LARA brought to light the importance of the time slot size to guarantee low latency through a TDMA-based radio network. The minimum latency to be experienced will ultimately depend on this size. The shorter the time slot, the lower the latency that can be guaranteed.

LARA took a long step forward in terms of QoS management not only in the analysis phase but also practically in the demonstrator. In particular, a new class of service has been identified for those flows that need guarantee of bounded, low latency. Coupled with the OPWA mode of RSVP, it made possible the guarantee of maximum end-to-end latency. LARA did not oppose the IntServ and DiffServ approaches, but rather managed a combination of both for an optimized QoS management in the network. By propagating the reservation requests through the LARA security gateway, actual physical resources could be allocated in the radio network based on bandwidth and latency requirements expressed by the applications in the red enclaves.

The dynamic slot allocation mechanism proposed by LARA was an innovative concept to derive a radio slot configuration from the required bandwidth and the maximum afforded latency, to dynamically manage a distributed pool of available slots, to take into account conflicts in concurrent requests issued on different radio nodes, to efficiently re-use slots when nodes are at least 3 hops away, and to perform pre-emption. A patent was submitted on this mechanism.

Some technical challenges were overcome in LARA, namely the support of RSVP in an OLSR-based MANET network with multicast extensions, and the implementation of the LARA MAC layer above a physical radio modified for ad hoc networking.




The LARA architecture that came out of the project is a generic IP-based architecture that combines: • Data and voice traffic; • Real-time and elastic data; • Point-to-point and point-to-multipoint traffic.

Some of the LARA results may lead to normalisation actions, e.g.: • Towards NATO:

- the new ‘real-time’ class of service for sensitive real-time data;

• Towards IETF: - the RSVP tunnelling enhancement for OPWA support; - RSVP sequence numbers for multicast transport; - a dedicated LATENCY object in the RSVP RESV message;

• Towards INRIA: - RSVP coupling in multicast OLSR.




6. LIST OF ACRONYMS AND ABBREVIATIONS

AGC Automatic Gain Control

ARP Address Resolution Protocol

CAFES Common Audio Framework for Extended Sotas

CE Common Engagement

CoS Class of Service

CTP Common Tactical Picture

DDS Data Distribution System

DGA Délégation Générale pour l’Armement (French MoD)

DIFFSERV Differentiated Services

DN Dissemination Node

DSCP Differentiated Services Code Point

ETNA European Theatre Network Architecture

FDF Force Data Fusion

HCDR High Capacity Data Radio

IETF Internet Engineering Task Force

INRIA Institut National de Recherche en Informatique et en Automatique

INTSERV Integrated Services

IP Internet Protocol

LAN Local Area Network

LARA Layered Architecture for Real-time Applications

MAC Medium Access Control

MANET Mobile Ad hoc Network

MDFP Multicast Data Forwarding Protocol

MOLSR Multicast Optimized Link State Routing




MPLS Multi-Protocol Label Switching

NATO North Atlantic Treaty Organisation

NBD Network-Based Defence

NCO Network Centric Operations

NCW Network Centric Warfare

NE Network Element

NEC Network Enabled Capability

NGIN New Generation IP Network

OLSR Optimized Link State Routing

OP One Path

OPWA One Path With Advertising

OSI Open Systems Interconnection

OSPF Open Shortest Path First

PDU Packet Data Unit

QENI QoS-Enabled Network Infrastructure

QoS Quality of Service

RSVP Resource Reservation Protocol

RSVP-TE Resource Reservation Protocol – Traffic Engineering

SE Secure Enclave

SIP Session Initiation Protocol

SN Service Node

SOAP Simple Object Access Protocol

TCF Thales Communications France

TCNL Thales Communications Netherlands

TDMA Time Division Multiple Access

TESA Transformation Enterprise Service Architecture




TN Transit Node

TS Transmission Station

USC ISI University of Southern California Information Sciences Institute

VoIP Voice over IP

WP Work Package

XML Extensible Mark-up Language



lara - eda.europa.eueda.europa.eu/docs/documents/lara_executive_summary.pdf · lara layered...

Documents