JFORCES Communications and Information Processing Module


This paper describes both the current and suggested JFORCES communications routing and information planning modules. Note that this document describes the simulated communications that occur during scenario execution, not the actual communications between the JFORCES model and other models, workstations, test articles or live feeds.


While it touches on the communications propagation, this is not the focus of this paper. But the routing description supersedes prior JFORCES routing descriptions, including the communications description delivered with the original delivery in 1992.


Sections:


Overview

The JFORCES communications module represents the simulated communications between assets associated with sensor reporting, status maintenance, command and control and so forth. As shown in Figure 1, the communications module is one of the primary modules for situation representation incorporated into JFORCES. It's first use is to determine the appropriate information available to commanders throughout the scenario based upon a realistic assessment of the force's communications capabilities, procedures, processes, threat activities, environment, terrain, deployment and so forth. The information passed to the commander is both restricted in amount and delayed in time based on the architecture's ability to transmit information and process it once received. This module access's data in the object state and environment databases to determine the states of the communicating assets and their subsystems, threat activities and capabilities, weather, daytime, solar activity, terrain, nuclear events, and so forth. The activities modules (e.g. C2, engagement, sensor) use the results of these calculations in order to determine the success of getting information to commander(s) and sending commands to engagement assets. Information on successes and failures is then logged for post-run analysis.


Figure 1: The Scenario Communications Module in the JFORCES Architecture



The model focuses on two distinct levels of communications, and this is where some confusion arises. The model currently includes both:

  1. The evaluation of the success in transmitting a communication between two assets and the

  2. The evaluation of successfully propagating a message through a network from a source (e.g. A sensor or commander) to a destination (e.g. A command site or an engagement unit). These networks can be multi-tiered with elaborate networking and redundancy. In each case the success of the message transiting the entire network is logged for architectural evaluation. Metrics collected include link and route probabilities of correct message reception (PCMR), overall architectural latency for any selected type of message, and actual message delivery times for sensor messages based upon a simply user-specified distribution (hopefully based upon prior runs of the organic architectural evaluation module).


It is proposed to expand this module in the following two ways:

  1. First, it is proposed to use the current evaluation model that models the performance of distinct communications routes throughout the architecture using directives (or rules) specific to the type of information being passed for actual communications from (or to) specific assets. It is not recommended that this replace the current communications model, or even become a new default, because the overhead associated with this resolution would be prohibitive given today's PCs executing large (e.g. Theater-level) scenarios. However, the design will allow for later expansion to replace the current model when either better computers evolve or smaller scenarios are run.

  2. Second, it is proposed that the communications model expand from it's current role of measuring communications success and latency by expanding to model information processes and dissemination. This expansion would admittedly overlap with current information processing incorporated in JFORCES,, including the tracker/fusion modules and the ballistic missile typing algorithm. But many information process flows are not strictly sensor-data related, and this becomes more obvious as we start to evaluate information flow at the command center as represented in the COSMIC project. This expansion would permit modeling processes occurring at any data center, be it at an intel or warfighting center.

Communications Propagation models (Current)

Before commenting on the networking models, some mention should be made of the communications propagation evaluation. This is the code that determines whether a message is successfully transmitted between two entities. It provides evaluation metrics to the communications networking module. The networking model defines series of assets that need to communicate in order to pass a message from a source to a destination. It then calls the propagation module for each pair of communicating assets to determine whether the communication succeeds. The results are returned to the networking model, which can (optionally) reroute any failed messages accordingly.


The propagation module can be thought of as the “nuts and bolts” component of the communications model. As shown in Figure 2, this is where the details of “how” the message is passed is defined. These data specifies the communications suites used to actually transmit the messages and and their characteristics.


Figure 2: The Communications Data Definitions



Based on its legacy, JFORCES incorporates three different communications propagation code sets. These are selected by the analyst during mission planning, although the user will need to make certain that the selected propagation code is linked to the local JFORCES executable. These three propagation code sets are:


  1. The AFS&A STRACCAM model. This model, which includes algorithms and data derived by the more complex WESCOM model, but in a quicker running package, was a recognized superior communications model for mission-level communications when selected for inclusion in 1987. It does detailed RF and laser communications between two points. When this module is selected the organic JFORCES telephone model is used for land line communications.

  2. The GTE GNET communications model developed in support of AFRL initiatives in the late 1980s. This model also covers RF and Laser communications. It overlaps STRACCAM's functionality and it's selection over STRACCAM is probably a personal selection. For information on GNET please refer to the delivery documentation, which can be downloaded here. Please contact AFS&A for information on the STRACCAM model.

  3. Finally, an organic communications propagation model is incorporated into JFORCES. It was originally called the “perfect comm” model, but this is misleading, so it's now referred to as the JFORCES core comm model. While this is a very simple model compared to the STRACCAM or GNET options, it does the following:


This simple model was originally developed because the it was feared the more detailed models require too much processing time. It turned out that the detailed models did not require too much time, but it quickly became obvious that very few engineers had the expertise and knowledge to correctly define a communications suite as required by the detailed model. And if the communications suites are not correctly defined communications fail (as you'd hope). And when the communications fail the assets are very ineffective in the scenario. Since this was usually more an indication of the inappropriate data than an actual architectural shortfall it has often been decided to use the simple core model.


So, in the end, the JFORCES core model is recommended unless the focus of the study is on communications propagation capabilities.


As proven in the ADISC2 acceptance tests, these modules can model a wide variety of communications suites and capabilities, including the following (which were all validated and verified during the acceptance test):

  1. SATCOM

  2. AUTOVOM

  3. HF Radio, including point to point

  4. GWEN

  5. Meteor Burst

  6. Commercial switched telephone

  7. point to point telephone

  8. RADIL (digital info link)

  9. UHF & VHF Voice Data

  10. VLF & LF Ground Wave

  11. Integrated Communications Networks

  12. Digital processor LANs & WANs



Figure 3: JFORCES Message Generation and Transmission



Figure 3 provides an overview of the detail of the communications module in terms of both the propagation modeling and the marshaling of information into operationally realistic messages both in context and format. Because the focus of this paper is the networking and information processing model this diagram will not be described in detail, but is presented here as a reference to the message marshaling that occurs within JFORCES and supports real-time simulation/live communications with sensors, trackers, workstations, C2 systems and so forth.


Point-to-point comm (Current)

From it's inception JFORCES has incorporated a routing model that overlaid the propagation code. The basic idea is that all assets needed to maintain communications with their control assets. An attempt is made to connect directly from the asset to the control asset by looping through all communications suites on each. A threshold PCMR is compared to any possible communications. If no adequate direct connection is found then assets capable of receiving data from the controller are evaluated for connection to the controlled asset. If successful this will result in a two-link route from the controller to the controlled asset. If unsuccessful then all friendly platforms capable of talking to all of the first-level relays (those capable of talking directly to the controller) are evaluated for communications to the controlled asset, thereby creating a 3-link comm route. And so forth. The original programmer documentation describes this in more detail and can be downloaded here. To reduce computation the original module restricted the route to 3 links. Subsequently this limit was raised to 10 links to handle some nasty jamming cases. Clearly, this method leads to a computationally intense solution with the potential that n10 links will be evaluated in the unfiltered case, where n is the number of friendly assets in the scenario. To reduce computations JFORCES:generates a matrix of platforms (and associated communications suites) capable of intercommunicating is created during initialization. But specific asset and subsystem states are evaluated at the time of computation. Other approximations used to cut down processing include:

  1. The PCMR is only evaluated periodically (by default every 15 minutes) and is assumed constant between updates instead of being recalculated for every transmission.

  2. When the PCMR is updated the original route is first tested and accepted if the current PCMR is above the threshold. The whole rerouting algorithm is only re-executed if the original route fails to achieve the threshold requirement. This means that, while there might be a delay establishing the original routing, it's only executed for a few selected assets during the comm route updates.


This model has proven very serviceable and it is recommended that it is maintained. But over time the following limitations have been observed and are the basis for the recommended changes:

  1. The original communications concept was built around tactical air defense command and control. So the basis was everybody had to maintain communications with their commanders. This is true both for information input (information from sensors to the command center) and to engagement assets. While this is a good first-order for tactical engagements, it does not adequately address the real information flow and processing in today's information age. The more capable information flow model embedded in Figure 4 requires a more flexible communications network.

  2. This model has also been used for other (not controller-to-asset) connections. In particular, it is used in the air defense C2 module for command center cross talk. But currently anything outside the controller-to-asset communications must be specified by code. While this is addressed by the current adaptive network evaluation module (described later), there's no provision for employing this model in generic asset-to-asset communications related to specific messages.

  3. The biggest restriction to this model is it assumes that all assets can be used to relay messages between the controller and asset if technically capable. It does not honor the restricted specification of dedicated networks in the interest of not overloading different nets. This might have been a reasonable approach when considering air defense against nuclear threats (the original JFORCES purpose), but is not generally appropriate. This limitation is the biggest single reason the adaptive networking model described below was developed.

The user can bypass of these limitations by fully defining all comm routes during scenario configuration. But this has two problems. First, the resulting network would not be very flexible (although backup routes can also be defined during mission planning). Second, defining these is very tedious and is unreasonable in an automated age. But this is mentioned because it is a valid approach when a limited number of narrowly defined communication routes wish to be modeled in specific scenarios.


Figure 4: JFORCES Information Flow




Star Architecture Comm (Current)

This is a very simple network approach that permits a user to define a star communications network. This is defined is as a set of single-link routes to a set of destinations. The interface, described in detail in the Mission Planner User's Manual, lets the user pick a center asset for the network, the communications suite for reception and transmission, and based upon this selection offers the user a list of all assets with the appropriate comm suite and he can pick a number of them to define the network. This is not adaptive, but can be useful in setting up a communications network across various echelon levels in tactical ground fighting.


Adaptive comm networking architecture evaluation (Current)

This is a new addition to the JFORCES communications network that evaluates an architecture's ability to maintain communications from a set of sources to a set of destinations by using a set of communications directives employing selected sets of candidate relays. Key concepts are:

  1. The employed assets are broken down into sets, referred to as nets, that can be defined at any of these levels:

Moreover, these collections of assets (or types) can be combined within a single net. So the user can specify that specific satellites or any aircraft of certain types can be used for any step of a comm route. Additionally, the user can specify that the message can be relayed multiple times within the net before proceeding to the next step if required to complete the route.


  1. Directives are instructions for passing the message through these nets. The directives are defined by the type of information passed. Logically directives state something like:

  1. For any ISR message originating from an asset in Net Space ISR try to pass the information through the following nets:

  2. Comm Sats, then

  3. Fixed Ground Sat Station net OR Mobile Ground Sat Station

  4. Proceed to the Intel net via land line OR use Comm Sat network (again) if a land line is unavailable

  5. Downlink to a Fixed Ground Sat Station If not already at a Intel center

  6. Connect via Land Line to the Intel Net If not already at a Intel center

In addition, multiple directive sets can also be defined to permit additional communications redundancy. Also, nets can be combined for specific directive steps. Since nets and directives are entirely user-defined, this system permits almost tremendous communications architecture specificity with relatively limited user inputs. To read more about this module go to www.jforces.com, go to the programmer's area, and click on the “Adaptive Networking Module”.


The limitation to this module is that it collects data on the architecture's performance, but does not track individual messages. As described below, it is recommended that this be upgraded to be used both for the transmission and tracking of individual messages. But, as also mentioned below, this is not a easy change to make generically (that is, to implement without frequent code changes).


For reference, the user can specify the comm nets, directives, and test specifics in the Mission Planner under “Scenario Defn->Communications->Define Comm Arch for Testing”.

Other Architecture Evaluation Metrics (Current)

Primary Bandwidth Utilization statistics

Additional metrics are collected by JFORCES. These metrics have been added over time to support specific studies and usually measure bandwidth utilization. This differs from the communications link and route data collection, which focus on the following attributes:

  1. Transmission utilization per asset

  2. Communications failures (or denials) between specific assets

  3. Communications delays.


These additional metrics focus on measuring the overall communications utilization at the bandwidth level throughout the scenario. When the user specifies that this information should be computed and logged the system will count the system utilization as messages are passed through the specified network during runtime. Moreover, the system will record not only the scenario driven message traffic, but also “background” messages; that is messages that we know occur but are not tied to any discretely modeled JFORCES activity.


For reference, the user needs to specify both the bands in which to collect this data and the background messages in the Mission Planner under “Scenario Defn->Communications”. Both the “Define Bands” and “Define Default Loadings” options must be specified. Once the bands are defined the metrics are collected for scenario messages based on the characteristics of the communications suite used.


Bandwidth Utilization Statistics Collection Update

Recently, there's been an additional collection option to augment the collection algorithm described above. This addition permits the user to specify the network that the communications suite uses instead of just looking for frequency overlap. This change was made to model wire-based (e.g. LAN & WAN) communications and TDM type of radio communications. Only information on communications using suites with defined networks in database prototyping. Any transmitting sensors also need to have defined communications priorities, message sizes and so forth. Currently only scenario-based ISR communications non-scenario loading are addressed.


An associated additional upgrade to this system permits the specification of the types, networks and priorities of background messages. Because this approach is still in evolution there's no GUI. But non-scenario loading can be specified in the nonscenario_network_loading database table.


Recommendations

This begins a section of recommended changes to satisfy the needs of the COSMIC evaluation and other similar near-term communications evaluations. Up to this point this paper has described the JFORCES communications module as it exists. From this point on these are recommended updates and are offered as suggestions. As such this is a living document. It is expected that this document will serve only as a preliminary requirements document and will change as metrics and processes change.


The recommendations are focused on:


  1. Providing more detail into the transition of specific messages to usable information.

  2. Populating and supporting information pools (which can include shared data) to be used for determining courses of action.


Adapting the adaptive comm networking architecture to specific communications

Invoking specific directives

The adaptive communications network based on nets and directives was described above. The system is very flexible, but was created to primarily to measure architecture-wide metrics, not for use in individual inter-asset communications. However, it was designed to model individual communications in the future, so the actual implementation should be straightforward after a few key questions are addressed. These are:

  1. When should any particular directive be used?

  2. Should this module be selected for all communications traffic, or only for selected communications?

  3. If this routing method is to be defined in addition to other communications methods, how should the implementation and results be segregated?


Recommendations on each of these questions is addressed below.


When Should Any Particular Directive be Used?

Currently, there is nowhere in JFORCES code that would enable the user to specify which of several communication directives can be used. This is because the core communications routing does not limit the intermediaries, but instead just looks for a routing scheme that satisfies the user-specified success criteria. So a method of determining which directive to use needs to be developed. Some options are:


  1. The first directive that addresses the specified source and destination will be used. Linked lists of directive options originating from any asset can be created during initialization to minimize runtime processing. The weakness is that if there are two communications channels between these assets (say, for example, when a satellite reports to a single center both ISR reports and orbit maintenance), the system would not know which of the directives to use.

  2. Hard-coded communications labels could be placed throughout JFORCES where ever communications originate. This is not a good solution because 1) it requires the users remember and use these labels, 2) It's very inflexible, 3) All originating nets most have the same name (although we could use a combination of originating asset name and directive type to tailor the directives). For all of these reasons this is not an attractive option.

As already said, this is a preliminary discussion of communications approaches, so new options might appear later. But currently my recommendation is to develop the first approach (just look for the first directive that matches the source and destination). This approach will even (sort of) work for complex cases with different communications going between common points by creating two assets with a different name at the same location. For example, the user could create both an “ISR Center” and a “Satellite Maintenance Center” at the same location to address the case mentioned above. But experience has indicated that this method is error-prone, tedious for the user, and losses might not be handled right if the center is attacked. Still, perhaps this is an uncommon enough situation to be workable.


I also recommend that the current communications routing routine (as described here), be maintained to accomplish communications between two assets where no directive is found. But this would only be used if no directive is found; if a directive is defined but no successful communications are possible using the defined directive then the communication would fail and the core communications routing algorithm would not be used.


Should this module be selected for all communications traffic, or only for selected communications?

In the perfect world this would be open to debate, but realistically if directives are required for all communications we'll never get a working scenario. And by always having the current core routing capability as a backup users would be able to have the ability to quickly define working scenarios. This is especially important since not all JFORCES scenario are focused on communications issues. But employing directives whenever defined (as described in the previous paragraph) will give us the ability to render communications architectures in detail without losing JFORCES current flexibility.


So, I recommend maintaining the current communications routing procedures alongside the adaptive technology despite the problems cited the the next paragraph.


If this routing method is to be defined in addition to other communications methods, how should the implementation and results be segregated?

This is a large concern. Subproblems include:

  1. Currently the way that the core communications routing algorithm makes a call to the algorithm and which runs an analysis and determines whether the communication succeeds,and, if successful, the delay in getting the message to the destination. The calling routine then records the success (if the communications are ISR related and data is being collected on individual detection reports) and schedules the reception of the message by the intended destination. Advantages of this approach include: a) it's fast, b) the communications results are recorded immediately within the sensor detection report record. This streamlines data analysis of the data type that generally produces the largest amount of raw data for analysis. And this is important, data analysis can be time consuming in any case and could be extremely slow if provisions like this aren't made.

  2. The way that this change would force the communications to work would require that the message be tracked as an individual object throughout the system. At any point during it's delivery we would need to know it's location, attributes (e.g. Type, priority, current disposition). This is a significant upgrade but required if we're going to expand into detailed information correlation, fusion and warfare.

  3. The biggest modeling concern with maintaining two communications methods is that the overload resulting from the entire traffic load would not be correctly computed. It is proposed that we alleviate this concern by expanding the non-scenario message traffic module (described here) to provide not only loading based on non-scenario events but also loads the newly modeled processing centers with messages actually serviced by the traditional JFORCES comm routing module.

Specific recommendations to address these issues will be postponed until there's time for general discussion.


Message Tracking

In order to reliably measure the benefits of combined improved communications and alternate information processing schemes like COSMIC, it's essential to determine which sites (and workstations) have what information at any given time. This means that the current resolution, which basically just models data as available to all C2 processes after the calculated delay, needs to be increased to determine when any commander has information to any particular piece of data. As importantly, the types and confidence of information available at a given point, needs to be tracked to determine what options are reasonably available to a commander.


On the other hand, it's unreasonable to maintain information on every message throughout the scenario execution. While this could be done (at the expense of large amounts of RAM), the real problem occurs when command algorithms use the information to determine activities. The messages received must be processed to easily understood information before these algorithms are executed, much like the raw radar reports are combined into tracks before air defense assets are committed in the real world. This system of simplifying the incoming data in imitation of real world activities therefore is not only efficient but satisfyingly realistic. So the question is not whether to do it, but how to do it.


My recommendations are:


  1. While the message is still transiting the system, it must be maintained as a unique message. It would not only be tracked as an individual message, but it's processing and dissemination at any relay point (or the final destination) would be evaluated against the processing capability of that site. Each site would contain a simple ?processing” model which would pass the message on only after a delay based on: 1) The number of messages currently at the site, 2) the type of site, 3) The message priority. For this first level I propose using a table look-up for this delay based on these inputs, but this could be upgraded to a detailed data queuing model at need. Also, for this initial cut I propose ignoring the type of message to reduce complexity.

  2. Once it gets to a command center and passes local inprocessing (or, more specifically, is delivered to an information pool, as described next) it will be aggregated into a higher level.

  3. The definition of the higher level is problematic. My current proposal is:

The problem with this is that it relies on a total artificial construct (the shadow entity that records incoming data) removing the JFORCES processing from anything that would be seen in the field. BUT, this has to be counterbalanced by the fact the JFORCES is being used in an analysis mode in this program, and the correlation of actual threat versus perceived information is a critical part of the analysis.


Perhaps a bigger problem is that this proposal throws away reports that don't correlate with actual threats. This eliminates the “fog of war” from erroneous reports that really happens. I'd like to discuss this before proceeding. Perhaps we can make phantom entities that correspond to these false detections, but since this pool can grow without limit this approach could overwhelm the computer. Before leaving this topic it should be mentioned that this concern does NOT apply to decoys; decoys are treated as actual objects (and hence drone threats) in JFORCES, so information on tracking and prosecuting them would be maintained.


Information Pools

The real value of the communications systems like COSMIC is the sharing of information between multiple systems that already exist. Today, JFORCES assumes that if information gets to a command center it's automatically available to all decision-making processes. This assumption by JFORCES basically presumes that a system like COSMIC already exists. So the data fusion benefit of COSMIC is not represented. The two approaches to changing JFORCES to represent this change are:


  1. (Recommended) Add an in-processing delay to each site. This delay would represent not only receiving and cataloging the information within the standard application, but also the ability to disseminate the information throughout the center. Frankly, this glosses over a lot of issues, including:

  1. Alternately, we could create a system of discrete information pools within command centers. Each of these information pools could include separate “threat shadow databases” as described in the previous section on message passing. Information could be passed between these pools after reasonable delays. Moreover, command functions would have to be mapped to the information pools so that the information for each type of command decision would be based only on the information available at the time of the decision within the appropriate pool. This is possible, but I question it's application to a mission-level model like JFORCES. I