Modern warfare comes knocking: Side-enablers and GNSS disruption

January 25, 2025 · Posted in Command, Command PE · Comment 

Quickly now, raise your hand if these headlines sound familiar:

These and other similar titles underline a crucial military transformation during our lifetimes. Modern warfare is not “WW2 but with better weapons”, and the comforts of post-Cold War COIN & intervention / regime-change ops are no longer to be taken for granted. The GPS navigation systems guiding modern platforms and weapons will likely be disrupted (in fact count yourself lucky if the satellite constellation above you survives), and the BLOS comms that forces rely upon for everything from cell-phone connectivity to drone control may or may not be available, theater-wide or locally.

So, how to represent these threats and vulnerabilities, and the opportunities arising from them, in Command?

Side Enablers

What we came up with is the concept and framework of “Side Enablers” (aka “theater access options”): Capabilities that act as force multipliers, enabling options for action – or taking them off the table if they become unavailable.

The most common such enabler is access to satellite-based navigation, particularly with regards to weapon guidance (and more recently, autonomous operation of drones). GPS is of course the most commonly referred example, but GLONASS (Russia), BeiDou (China) and NavIC (India) are also other options.

Such enablers are now available for configuration in Command when editing the properties of Sides in the Scenario Editor:

Clicking the “Enablers” button brings up the available enablers for the selected side:

Checking or unchecking each checkbox enables or disables this capability for the selected side.

Apart from the top Side-level, these enabler items are also configurable on a local basis. The idea here is that in many cases the ability (or lack thereof) to use a certain functionality may be restricted geographically; Starlink’s “no Ukraine” geofencing for its LEO-BLOS comms service is a recent example, but another common case may be the localized jamming/spoofing of GPS on a town or frontline of interest. The reverse may also be true: A given service may be generally unavailable theater-wide but available on a specific area (local beacons for both PNT/GNSS and comms are rapidly proliferating; you can now fit some of them even on artillery shells).

The way we model area-specific availability is through the area & reference-points manager:

By selecting a zone and clicking on the new “Enablers” button, we get access to the same menu of enabler options as on the side level. Embedding this ability on zones also allows taking advantage of all the nice properties already present in them, such as anchoring them on units, contacts or reference points.

Given that the (non)availability of these services can be highly dependent on events happening during the sim execution (or player decisions), it makes sense that the enablers themselves are configurable also through Lua scripting. Here is an example of fetching the enablers for a given zone and modifying them:

local s = VP_GetSide({name='side-A'})
print(s)
local z = s.standardzones
local myz = s:getstandardzone(z[1].guid)
print(myz.enablers)
myz.enablers = {GNSS_GLONASS = true, GNSS_GPS = false}
print(myz.enablers)

GNSS disruption

So, what do all these enablers actually buy/deny you “in the field”?

The first concrete implementation of the enablers framework is, to no-one’s surprise, GNSS disruption. This is a large topic of discussion in western defence circles as an acknowledged vulnerability, given that so many different weapon systems since Desert Storm have come to rely on GPS navigation for guidance – and this trend has been also subsequently replicated in Russia, China & India (to our knowledge, the pan-European Galileo system has not yet been adopted as a guidance component on any fielded weapon system).

GNSS disruption (in the form or jamming, spoofing or complete denial of service) is a huge and highly technical subject, but in the context of terminal weapons guidance its effects are fairly simple: It significantly increases the CEP figure of anti-surface weapons, thus significantly degrading their accuracy. Such weapons typically rely on an internal inertial navigation system (INS) which acts as the primary navigation reference, with the GNSS providing a regular correction to the INS’s inevitable drift. If GNSS is denied, the weapon has to rely entirely on its INS for terminal guidance.

When a weapon is denied a GNSS update, a “NOGNSS” warning is shown next to the weapon icon on the map, to indicate that this weapon is suffering from such degradation:

When the weapon’s impact is evaluated, the INS drift due to GNSS denial is taken into account and may significantly raise the final CEP value used in the impact evaluation. This is presented in the message log, as in this example:

> 8/4/2017 10:08:14 – Weapon: GBU-39/B SDB #993 has been without a GNSS update for 6 min 49 sec. Weapon has INS: 1990s+ tactical weapon INS. Max drift: 105m. Actual drift (CEP increase): 79m

Notice in this example the significant difference between max and actual drift: The max drift represents the maximum deviation from the DMPI if one assumes that all drift perturbations will cumulatively swing the weapon away from the aimpoint. A more (statistically) likely case is that the actual deviation will be somewhere between zero and max; in this case 79 meters.

There is a popular misconception on public discourse, that GNSS disruption can instantly turn a weapon useless. This is a gross exaggeration. The actual effect of such degradation on a weapon’s impact accuracy, and to its overall effectiveness, will strongly depend on the inherent accuracy of the weapon’s INS system, the time the weapon spends in a degraded state (INS drifts with time, not distance covered), the weapon’s warhead type and yield, as well as the type and physical dimensions of the aimed target.

Some recent examples illustrating this:

  • According to persistent reports, ground-launched SDB (GLSDB) bombs have been ineffective in the Ukraine theater due to extensive GPS jamming/spoofing. This makes sense for a weapon like SDB, whose penetrator-explosive warhead is highly dependent on high accuracy (a near-miss does not produce any proximity damage; it’s direct-hit or bust); combined with an increased flight time (ie. more time to be exposed to GNSS disruption, depending on the reach of enemy EM activity) this creates ample opportunity to disrupt the weapon sufficiently to make it a clean miss.
  • On the same theater, GMLRS guided rockets have reportedly been highly successful despite facing the very same jamming activity against them. Why? The warheads of these rockets are area weapons (they disperse bomblets) so a near miss usually is as good as a spot-on direct hit. Additionally, their small flight time reduces the opportunity for significant jamming and thus diversion. (Reportedly air-launched SDBs, the very same type as ground-launched by GLSDB, have also been a popular weapon. Why? Presumably the shorter flight time compared to the ground-launched variant makes for a sharply reduced window of GNSS-jamming vulnerability.)
  • High-velocity weapons in general have an inherent advantage in such conditions because of the time-based drift on INS systems. This is an additional reason that high-speed systems (incl. hypersonics) are a popular avenue for research and development.

Note #1: The current GNSS disruption model applies only to weapons that use INS+GNSS for terminal guidance (JDAM being the prime example), and NOT to weapons that combine INS+GNSS for mid-course guidance with homing sensors for terminal guidance (e.g. most modern cruise missiles). There are a number of reasons for this, incl. the complexity of representing “actual” vs “perceived” weapon position (cue the “missile knows where it is” memes…), as well as the fact that such systems use terminal homing precisely in order to compensate for mid-course guidance errors and thus are less susceptible to GNSS disruption.

Note #2: Currently there is no distinct field in the database to mark the INS performance level of each individual weapon. For this reason a simple “deduction” algorithm is used, based on the weapon properties:

  • If the weapon is a guided gun round (e.g. Excalibur) or rocket (e.g. GMLRS), assume it uses MEMS-based INS (Assumed drift: 5nm / hr).
  • Otherwise, if the weapon’s maximum range is under 162NM, assume it uses a “1990s+ tactical weapon”-grade INS (Assumed drift: 0.5 nm / hr)
  • Otherwise for longer-range weapons, assume it uses a “1990s+ high-grade” INS (AIRS etc.)(Assumed drift: 0.05 nm / hr)

The 162NM (300km) threshold is based on the MCTR regime rules, which treat missile weapons with a >300km range as “strategic”.

Both the Side-Enablers framework and the GNSS disruption feature are now available on the new CMO public beta released on the MG forums. Have a look through them and give us your feedback!

Tags: no tags