Navy NETWARS Interoperability Efforts

1
Navy NETWARS Interoperability Efforts

• SPAWAR SAN DIEGO (SSC SD)
• NETWORK CENTRIC WARFARE ANALYSIS BRANCH
• Chris Alspaugh, Tom Hepner, Cam Tran Ph.D.,
  Wonita Youm, Albert Legaspi Ph.D.
• GEORGIA INSTITUTE OF TECHNOLOGY
• Steve Ferenci, Richard Fujimoto Ph.D., and Myung
  Choi Ph.D.

2
Outline

• Background
• NETWARS
• NSS-NETWARS Integration
• Concluding Remarks

3
Background

• Who We Are
• SSC-SD 2822 (Network Centric Warfare Analysis
  Branch)
• Represent Navy Modeling and Simulation Management
  Office (NAVMSMO), OPNAV N61-M, and N61F, for
  Joint C4ISR Communication MS assessment domain
• Supporting Communication MS for 10 years
• Lead Navy NETWARS developers
• What We Do
• Perform C4ISR communication system performance
  analyses
• Modeling and Simulation (MS) is our most
  commonly used assessment method

4
Communications System MS Applications

• Capacity Planning/Scalability
• Where are my network bottlenecks?
• How will my network support future growth?
• Technology Impact
• How will my new application impact existing
  systems?
• Impact of NBC attacks on network performance?
• Acquisition
• Why is this new router better for my network?
• Prototype development and assessment
• Before it is deployed, what are the deficiencies
  in my new TDMA protocol?

5
Communications System MS Applications
(continued)

• Operational Decision Aids/Doctrine Development
• JTF OPTASK COMMS development guidance.
• Co-simulation
• Link to C2 and ISR simulators for complete C4ISR
  assessments.

6
SSCSD MS Capabilities and Resources

• Simulation Tools
• Naval Simulation System (NSS)
• NETWARS/OPNET
• QualNet
• Existing Communications Model Library
• COTS and GOTS protocols, devices and systems
• OPNAV N61M C4ISR standard models
• Scenario and Traffic Data models
• Navy Defense Reference Model (DRM)
• Operational scenarios validated by Office of
  Naval Intelligence
• Probe and Information Exchange Requirement (IER)
  data.
• Import real probe traffic data into modeled
  networks

7
Outline

• Background
• NETWARS
• NSS-NETWARS Integration
• Concluding Remarks

8
Why NETWARS?

• Joint Chief of Staff C4ISR Network-communication
  Modeling and Simulation initiative
• 1998 Military Communications Electronics Board
  All services endorsed NETWARS for C4ISR
  network-communication MS
• Model Development is based on standards
• MOEs/MOPs were developed from CINC requirements
• Commercial Off The Shelf (COTS) Simulation Engine
  produced by OPNET Technologies

9
NETWARS Architecture
Device Model Library
Scenario Builder
Simulation Domain
Execute Discrete-Event Simulation

• Set Device Parameters (Configure Models)
• Create OPFACS
• Build Organizations
• Define Comm Requirements
• Perform Collaborative Planning
• Build Scenario

Analysis Tools
Create Comm Models
Capacity Planner
Analyze link utilization and demand priorities
10
Joint Model Interoperability

• Services in 1998 MCEB endorsed support JCS J6I
  NETWARS Program to benefit from model reuse and
  interoperability
• NETWARS Architectures and Standards Working Group
• Model Develop and IERs
• Common COTS simulation, databases and interfaces
• High Level Architecture
• Navy Standard Models Development Guide

11
Hierarchical Model Development
Deployment Models (e.g. STENNIS BG)
Organization Models (e.g. USS Lake Champlain)
OPFAC Models (e.g. ISNS)
Device Models (e.g. CISCO 7500 router)
Function and Process models (e.g. Ethernet)
12
OPFACs of NIPRNET and ADNS Organization

• 4 Network Operations Centers worldwide
• Templates PRNOC SIPRNET NIPRNET
• Template modification for UARNOC, IORNOC, ECRNOC

13
Modeling Classes
14
Modeling Standards Scope
Scope of this modeling standard is based on a
given level of resolution and fidelity.
                 
 
15
Resolution of Models

• Resolution is defined as the degree of detail and
  precision used in the representation of real
  world aspects in a model or simulation
• High resolution assumes physical entities of each
  of the 7 OSI layers are represented down to the
  lowest possible physical device. Since
  resolution can be defined down to the smallest
  particle in the universe (such as an electron or
  even smaller), highest resolution models here
  will be defined down to a communication device
  that is considered to be a product of a formal
  C4ISR communication-related ACAT 1, 2 or 3
  program.

16
Fidelity of Models

• Fidelity will be based on measures of performance
  and effectiveness requirements derived from the
  JCS modeling and simulation metrics. These
  MOPs/MOEs were derived from the operational
  community and are not based on a particular
  modeling environment.

17
Attributes

• Static or Dynamic
• Common Attributes (e.g. name of entity, position,
  state)
• Administrative
• Device Interface
• Messages
• Optional

18
Minimum Attributes

• Each model class has an associated required set
  of attributes that describes the functionality
  and performance of a communications device.
• Each of the attributes from this required set is
  a necessary feature for the model to exhibit an
  appropriate device behavior.
• Appropriate behavior of a device model is based
  on the MOPs.
• For example, transmit rate is in the set of
  required attributes for a radio since transmit
  rate is vital in deriving link throughput in a
  simulation.

19
Attribute Types

• String
• Text string value
• Real
• Double precision floating point number
• Integer
• Long integer number
• Boolean
• True/False, 1/0, Enabled/Disabled, On/Off
• Enumerated
• Datatype that can be assigned only a finite set
  of values
• Complex
• Datatype that consists of aggregate of multiple
  attribute types in a single structure

20
Device Interface Attributes
 
21
Navy OPNET Models
Systems and Networks

• CVN
• LHD
• DDG
• CG

• TCA Ships
• ISNS U/C (various versions)
• JSIPS-N
• FLBCST

• ADNS
• EC5G LOE Lab
• FORCENET LOE Platforms
• GiG

• ADMS
• NCTAMS
• NNOC

• Computers (Client/Server)
• Custom Workstations/Servers (PTW, IPL, etc).
• Routers (Cisco, Fore, etc.)
• Hubs (10baseT)
• Switches (100BaseT, 1000BaseT, etc.)
• Wired Links

• Link 11
• Link 16
• C2P
• EHF TIP
• Tactical Voice (KY68, STU-III, MMT, DNVT)
• Switched Voice (PBXs)
• TD1271 (DAMA)

• SATCOM Devices
• WSC 3/6/8 Radios
• USC 38
• TACINTEL
• IINMARSAT B Radio
• TACLANE
• KG 84/194

• Multiplexers (FCC100s, Timeplex Link 2/100s)
• Patch Panels
• BFEM Server
• Custom Workstations/Servers (PTW, IPL, etc).
• TCDL

Devices
Protocols and Processes

• Application Models (FTP, Rlogin, Email, etc)
• IP (v4, v6, QoS)
• ATM
• AAL
• Token Ring

• Frame Relay
• Ethernet (10 Mbps, 100 Mbps, etc.)
• TCP
• UDP
• JRE (JREAP A)

• STANAG 5066
• DSRMA
• Dynamic TDMA
• MANET Protocols (AODV, OLSR, etc.)
• DAMA

• Routing Protocols (RIP, OSPF, BGP, etc.)
• 802.11
• Wireless Channels (propagation models)
• SATCOM orbits
• Mobility

22
Recent MS Studies

• South West and North East Asia (SWA, NEA)
  amphibious readiness group (ARG) assessment for
  NETWARS QDR
• NCTAMS FMX network congestion analysis
• EC5G LOE Scalability Study
• Wireless MANET Subnet Relay prototype modeling.
• Unified Worldwide Ship-to-Shore Navy Network
• EIGRP and OSPF routing study (see paper
  04S-SIW-089)
• Time Critical Strike (TCS)
• Assessment of various C4ISR system families to
  support TCS

23
Recent MS Studies (continued)

• Battleforce Composite Networking (BCN)
• Examined JDN data transfers through JPN networks
  using IP QoS
• Deployable Autonomous Distributed System (DADS)
• Prototype modeling effort for distributed sensor
  networks
• End-to-end test bed for PMW 179
• TTIC lab model construction to augment hardware
  simulations

24
Time Critical Strike (TCS) Study

• Lead analysts for the TCS and BFC2 MCPs
• ASN (RDA) CHENG
• Objective was to assess alternate TCS threads
  through different C4ISR system families.
• End-to-end latency performance focus
• Operational Metrics (Time-On-Target)
• Modeled systems/threads
• Operational
• JSOW, E2C, F/A 18, CVN, UAV
• Technical Communications
• ISNS, SATCOM, TCDL, Link-16, JSIPS-N

25
Time Critical Strike
FUTURE UPGRADES
26
TCS Sample Study Results
Thread 3
Thread 1
Thread 2
27
Battleforce Composite Networking Study
Figure taken from Cliff Warner (SSCSD) BCN Briefs

• Integration of Tactical Data Links and ADNS using
  IP QoS technology and Composite Routing
  techniques -- Office of Naval Research (ONR)
• Direction from SPAWAR PMW 159
• Modeled systems/protocols under this effort
• IP QoS, C2P, JRE, Link 16, ADNS, EHF TIP
• Other models reused from library

28
Todays Architecture
Background
JCTN
Cooperative Engagement Capability (CEC)
Engagement
DDS
C Band Antenna
Sensors
Link 22 Terminal
HF Antenna
Link 22
KG
JDN
Common Tactical Picture
Link 11
Link 11 Terminal
HF Antenna
KG
Link 16
Displays
JTIDS/MIDS
L band Antenna
S-TADIL
Satellite Terminal
Satellite Antenna
KG
Weapons Control
JPN
SHF Satcom
Satellite Antenna
KG
ADNS ROUTER
Mux
Common Operational Picture
Imagery
Challenge Athena
Satellite Antenna
KG
Voice And VTC
Intel
Low Speed SATCOM
Satellite Antenna
Targeting
KG
CAP
Low Speed SATCOM
Satellite Antenna
KG
CAP
Integrated Network Manager
Figure taken from Cliff Warner (SSCSD) BCN Briefs
29
BCN Architecture
Technical Approach
Cooperative Engagement Capability (CEC)
Engagement
DDS
C Band Antenna
Sensors
Link 22 Terminal
HF Antenna
Link 22
Common Tactical Picture
Link 11
Link 11 Terminal
HF Antenna
KG
Link 16
Displays
JTIDS/MIDS
L band Antenna
NBN Composite Network
S-TADIL
Satellite Terminal
Satellite Antenna
KG
Weapons Control
Satellite Antenna
MDR Milstar
IP data with QoS
Dynamic Bandwidth Management
IBGWN
LOS Antenna
KG
SHF Satcom
Satellite Antenna
KG
ADNS ROUTER
Common Operational Picture
Imagery
Challenge Athena
Satellite Antenna
KG
IP Voice And IP VTC
Intel
Low Speed SATCOM
Satellite Antenna
Targeting
KG
CAP
Low Speed SATCOM
Satellite Antenna
KG
CAP
Integrated Network Manager
Figure taken from Cliff Warner (SSCSD) BCN Briefs
30
BCN Sample Study Results
31
Outline

• Background
• NETWARS
• NSS-NETWARS Integration
• Concluding Remarks

32
NSS-NETWARS Integration Overview
33
NSS-NETWARS Integration Architecture
34
Overall Functionality

• Functionality provided by the middleware
• Allow messages from NSS to be injected into
  NETWARS simulation
• Allow message transmission information from
  NETWARS to be sent to NSS
• NSS needs to be notified at what time messages
  arrive
• Provide a mapping between NSS entities and
  NETWARS entities
• Provide time management between NSS and NETWARS

35
DRTI Process Model

• Incorporated into OEs of the NETWARS entity that
  represents an NSS entity.
• Functionality
• Create NSS messages and schedule mobility events
• Report information from NETWARS to the DRTI
  Cosimulation

36
DRTI Cosimulation

• Implement OPNETs External Simulation Access
  (ESA) to provide communication between NETWARS
  entities using the DRTI Process Model and DRTI
  Object Management
• Facilitate info passing to and from DRTI Process
  Model
• Info to create events in NETWARS and
  notifications of when messages arrive to be
  delivered to NSS
• Manage the advancement in simulation time to
  ensure events arriving from NSS do not appear in
  NETWARS simulation past

37
DRTI Object Management

• Manage mapping between NSS entities and NETWARS
  entities
• Each entity in NSS publishes an object, and this
  layer discovers all objects published by NSS and
  maps each NSS entity to a NETWARS entity
• Facilitate the routing of messages from DRTI to
  the appropriate NETWARS entity

38
Federation Object Model Object Class Structure
39
Federation Object Model Communications
Interactions
40
General Problems and Solutions

• Mapping entities in NSS to entities in NETWARS is
  relatively straight forward.
• The names of the NETWARS entities were
  constrained to match the names of the NSS
  entities.
• NSS can dynamically create objects and start
  sending updates at any point during the
  simulation run, but there is no mechanism for
  dynamically creating entities in NETWARS.
• All NETWARS entities must be created before
  execution begins. When NETWARS receives the first
  update it will position the entity in the correct
  location and begin interacting with it. Until
  then the object can remain in a far off
  location where it wont interfere with the
  execution of the simulation.

41
General Problems and Solutions (continued)

• Model Fidelity High fidelity models in NETWARS
  have a large impact on federation performance.
• Navy NETWARS Link-16 models frequency hopping,
  equates to an event every 13 micro-seconds
  simulation time. Value of this level of fidelity
  is questionable for this project.
• Time Management Overheads Small lookahead
  values can significantly improve performance.
• Ongoing effort Show how using NETWARS
  communication models affects the outcome of the
  simulation.
• Do higher fidelity models impact MOEs or scenario
  outcomes?
• Is the price in performance worth the extra
  fidelity?

42
Outline

• Background
• NETWARS
• NSS-NETWARS Integration
• Concluding Remarks

43
Concluding Remarks

• Participate in NETWARS Architecture Standards
  WIPT to advance joint communications model and
  infrastructure development and assessment
• Conduct parallel and follow-up investigations
  into the integration of NETWARS with other
  simulators using HLA to leverage the strengths of
  each and promote software reuse

44
Backup
45
(No Transcript)
46
(No Transcript)
47
(No Transcript)
48
(No Transcript)