Using Simulation to Evaluate
Traffic Engineering Management
Services in Maritime Networks

David Kidston and Thomas Kunz

October 25^th, 2006

Presentation Overview

A Definition of Maritime Networks

Motivation

The Maritime Model

The Management Services

Results

Conclusions and Future Work

Slide 3

Motivation

Since maritime units operate in a low bandwidth environment with varying communications capabilities the efficient use of bandwidth and effective exchange of information is essential

While different applications are converged onto a single network they do not all have the same value. Traffic engineering (TE) can be used to ensure that critical information is delivered before less urgent traffic.

In order to evaluate potential TE services in maritime networks, modeling provides a low cost alternative to implementation.

Maritime Model - Topology

Small Network

The connectivity of the small network model showing all the wireless links is shown

Based on the description of a single naval task group on patrol

Large Network

A straightforward extension of the small network, except with two naval task groups

The second task group has two high speed satellite links instead of one

Maritime Model – Mobility Model

Intra-task force mobility

Based on the Nomadic Community model where the individual nodes of each task group move randomly within 3 nm of their base position

Links fail when they exceed 18 nm.

Inter-task force mobility

The two task groups begin 18 nm away from each other (at the closest point) and at a random arrival angle.

The first task group then approaches the other steadily at a relative speed of 30 knots (nm/hour) on a set heading evenly distributed from this trajectory angle of -45° to +45°

Maritime Model – Traffic Model

The nominal load model was made to match as closely as possible the background traffic seen during a maritime exercise (“in” is towards the maritime node)

The high load model is based on the assumption of increased traffic at times of increased activity.

Management Services

Traffic Monitoring Service (TMS)

Designed to measure the incoming and outgoing traffic of a node and distribute this information in summary form to all other nodes (at a varying level of detail)

Traffic Prioritisation Service (TPS)

Provides a mechanism to rank traffic by importance and prioritise resource allocation accordingly using DiffServ

Adaptive Routing Service (ARS)

Provides load balancing and matches application traffic classes to network resources, determining what types of traffic must/should travel over a certain type of bearer

Results (TMS)

Based on the topology, mobility and background traffic described the TMS was simulated in OPNET

The effect of increased load is readily apparent in maritime networks, with the TMS delay almost doubling from nominal to high background traffic

Enhanced and detailed modes have a long delay which may be acceptable if the information is not being used interactively

Unlikely to be sufficient for problem solving purposes

Results (TPS)

Use of the DiffServ weights shown gave a significant improvement in the TMS delay.

Improvement of approximately 20% at saturation and
approximately 33% at high load were seen.

This confirms that DiffServ-style QoS can make a significant improvement to prioritized flows in the Maritime environment.

Further studies in OPNET could be completed to determine the impact of alternative WFQ weightings.

Results (ARS)

Without TPS or ARS, the delay of two voice calls from the NOC were both 1.4 +/- 0.3 seconds at high load, far less than an generally accepted maximum of 500 ms.

In order to improve utilization of the network, an MPLS overlay was introduced to allow traffic travelling to Ship 4 to take different routes depending on the application type and priority.

In this case high priority voice traffic was to travel via Ship 3 while all other traffic will travel over the default route via Ship 1.

With the combination of TPS and ARS, the impact on the delay of voice packets is significant.

The high-priority voice call which is taking the alternate lightly loaded route via Ship 3 has a delay of 0.19 +/- 0.03 seconds while the lower priority voice call which uses the default route has a delay of 0.43 +/- 0.10 seconds.

Conclusions and Future Work

Management services were shown to provide concrete improvements

TMS – Monitoring service with variable overhead and delay

TPS – Prioritisation service gives 20-33% improvement

ARS – Adaptive routing provides load balancing

Simulation provides low cost alternative to real-time deployment and testing

Results are only as good as the model

Currently using maritime model to investigate guaranteed reservation service


	A Definition of Maritime Networks
	Motivation
	The Maritime Model
	The Management Services
	Results
	Conclusions and Future Work


	Since maritime units operate in a low bandwidth environment with varying communications capabilities the efficient use of bandwidth and effective exchange of information is essential
	While different applications are converged onto a single network they do not all have the same value. Traffic engineering (TE) can be used to ensure that critical information is delivered before less urgent traffic.
	In order to evaluate potential TE services in maritime networks, modeling provides a low cost alternative to implementation.


	Small Network
		The connectivity of the small network model showing all the wireless links is shown
		Based on the description of a single naval task group on patrol
	Large Network
		A straightforward extension of the small network, except with two naval task groups
		The second task group has two high speed satellite links instead of one


	Intra-task force mobility
		Based on the Nomadic Community model where the individual nodes of each task group move randomly within 3 nm of their base position
		Links fail when they exceed 18 nm.
	Inter-task force mobility
		The two task groups begin 18 nm away from each other (at the closest point) and at a random arrival angle.
		The first task group then approaches the other steadily at a relative speed of 30 knots (nm/hour) on a set heading evenly distributed from this trajectory angle of -45° to +45°


	The nominal load model was made to match as closely as possible the background traffic seen during a maritime exercise (“in” is towards the maritime node)
	The high load model is based on the assumption of increased traffic at times of increased activity.


	Traffic Monitoring Service (TMS)
		Designed to measure the incoming and outgoing traffic of a node and distribute this information in summary form to all other nodes (at a varying level of detail)
	Traffic Prioritisation Service (TPS)
		Provides a mechanism to rank traffic by importance and prioritise resource allocation accordingly using DiffServ
	Adaptive Routing Service (ARS)
		Provides load balancing and matches application traffic classes to network resources, determining what types of traffic must/should travel over a certain type of bearer


	Based on the topology, mobility and background traffic described the TMS was simulated in OPNET
	The effect of increased load is readily apparent in maritime networks, with the TMS delay almost doubling from nominal to high background traffic
	Enhanced and detailed modes have a long delay which may be acceptable if the information is not being used interactively
	Unlikely to be sufficient for problem solving purposes


	Use of the DiffServ weights shown gave a significant improvement in the TMS delay.
		Improvement of approximately 20% at saturation and approximately 33% at high load were seen.
	This confirms that DiffServ-style QoS can make a significant improvement to prioritized flows in the Maritime environment.
	Further studies in OPNET could be completed to determine the impact of alternative WFQ weightings.


	Without TPS or ARS, the delay of two voice calls from the NOC were both 1.4 +/- 0.3 seconds at high load, far less than an generally accepted maximum of 500 ms.
	In order to improve utilization of the network, an MPLS overlay was introduced to allow traffic travelling to Ship 4 to take different routes depending on the application type and priority.
		In this case high priority voice traffic was to travel via Ship 3 while all other traffic will travel over the default route via Ship 1.
	With the combination of TPS and ARS, the impact on the delay of voice packets is significant.
		The high-priority voice call which is taking the alternate lightly loaded route via Ship 3 has a delay of 0.19 +/- 0.03 seconds while the lower priority voice call which uses the default route has a delay of 0.43 +/- 0.10 seconds.


	Management services were shown to provide concrete improvements
		TMS – Monitoring service with variable overhead and delay
		TPS – Prioritisation service gives 20-33% improvement
		ARS – Adaptive routing provides load balancing
	Simulation provides low cost alternative to real-time deployment and testing
		Results are only as good as the model
	Currently using maritime model to investigate guaranteed reservation service