Reconnaissance-fire complexes for Warsaw Pact forces

[TarkError]

This concept isn't well known in usual Cold War gone hot research sources for wargames, but it's worth throwing out there to forecast game implementation feasibility either through explicit depictions or abstraction at the developers' discretion.

Within the context of an FPC-type game, a reconnaissance-fire complex is an organization formed at the Soviet divisional level, consisting of a commander, dedicated reconnaissance elements, an artillery reconnaissance direction post, and the firing subunits--with the purpose of finding and engaging fleeting and time-sensitive targets that would not be typically seen by artillery OPs supporting maneuver units up front.

Below are a couple of excerpts:

Larry A. Brisky, "The Reconnaissance Destruction Complex: A Soviet Operational Response to Airland Battle," The Journal of Soviet Military Studies 3, no. 2 (1990): 297-298.

rdc_big.png (115.37 KiB) Viewed 984 times

Department of the Army, Heavy Opposing Force (OPFOR) Tactical Handbook, TRADOC Pamphlet 350-16 (Fort Monroe, VA: Training and Doctrine Command, 1994), 7-8. While the document is talking about a generic OPFOR and published after the Cold War, this pamphlet's information is actually slightly edited from late 1980s revisions of U.S/British army threat manuals on the Soviets, thus remaining valid for our purposes.

RFC.png (42.74 KiB) Viewed 984 times

Lester W. Grau. Soviet Non-Linear Combat: The Challenge of the 90s. (Fort Leavenworth, KS: Soviet Army Studies Office, U.S. Army Combined Arms Center, 1990): 19-21. While Grau talks about the reconnaissance-fire group as an interim reconnaissance-fire complex, he might not been aware at the time of the video below, which was filmed eight years before he wrote the report.

grau_ROG.png (206.8 KiB) Viewed 984 times

There is also a training video on YouTube from 1982 introducing the audience (likely artillery reconnaissance students) the role of an artillery reconnaissance direction post within a reconnaissance-fire complex, indicating that the concept was more than just unfeasible theory in military journals:

https://www.youtube.com/watch?v=UiIh1c6f1OI

The video is in Russian language, but I've amateur-translated parts of it below, focusing on the scenario starting on 28:53:

https://docs.google.com/document/d/1xXR ... sp=sharing

[IronMikeGolf]

ROGs were definitely a contributor to our IDF (Indirect Fire) model upgrade. At this point, we don't want to have truly separate (by nation/faction) models for this. Studying military thought (which the Soviets and now Russians were and are no slouches at) I see a lot of convergence in methods and approaches to military problems and while equipment/munitions and organization do have some remarkable differences, the functions of those have a lot of overlap.

I do believe you can implement this with the current game engine. There's no need for trying to replicate the flow of targeting data. Currently, you can think of that as data being on a targeting buss and is available to all firing units. The main thing to look at is how to get the response time (time from mission request to rounds impacting on target) to match what you expect for the ROG controlled fires.

In the SS model, this is determined largely by the number of "hops" from the requesting unit to the firing unit. This is starting at the observing unit, going up the chain of command to the node where doing the same hopping up from the firing unit arrives at the same node. In most organizations, this will be the HiHQ of the scenario.

To get faster response time, you reorganize your Order of battle and put the observing units subordinate further up the chain. So, for the fastest response time, I'd make all the OPs (including the arty battalion OPs) directly subordinate to the ROG HQs. And I'd make the ROG firing batteries directly subordinate as to the ROG HQs as well. That gives you 2 hops from observer to firing battery. This will likely give you the shortest "mission request distance" while avoiding problems with command range. But, something to try out is subordinating the OP to the firing battery or vice versa. That's one hop, but I suspect there will be a command range issue and an associated delay that is bigger than saving one hop.

So, shortening the mission request distance is the first thing. You'd want the ROG's firing batteries under FSCC control (unless you want them silent for a time period). Once you plug a firing unit into the FSCC, missions will start routing to the unit. So, to screen out that and thus further avoid delays, you set firing batteries to Direct Support and I'd do that for the various ROG OPs.

As to OPs, you have one (with good sensors) per ROG Battalion. But I'd probably press elements of Division or Regiment level recon into service if you need addition coverage. I don't know where we are currently on sound/radar target acquisition unit on map for generating counterfire targets.

Feel free to DM me if you decide to play with this and need help with the Scenario editor.

[WildCatNL]

Another option would be to set the ROG artillery in direct support of a single observer, or a group of observers. That would also reduce the communication delay from observer to ROG battery. The downside is that the ROG is no longer responding to requests from other sources than the observers.

Wrt counter-battery detection: in Southern Storm, that's abstracted (and assumed to be performed by higher-up assets outside the OOB). On-map counter-battery radar (or weapons tracking radar) would be seen as emitting when active, but does not add to the detection of hostile artillery positions.

William

[TarkError]

Thanks for the responses guys, I'll plan on experimenting once my new computer system (and a bigger monitor!) is up and running

[JacquesDeLalaing]

In the SS model, this is determined largely by the number of "hops" from the requesting unit to the firing unit. This is starting at the observing unit, going up the chain of command to the node where doing the same hopping up from the firing unit arrives at the same node. In most organizations, this will be the HiHQ of the scenario.

To get faster response time, you reorganize your Order of battle and put the observing units subordinate further up the chain. So, for the fastest response time, I'd make all the OPs (including the arty battalion OPs) directly subordinate to the ROG HQs. And I'd make the ROG firing batteries directly subordinate as to the ROG HQs as well. That gives you 2 hops from observer to firing battery. This will likely give you the shortest "mission request distance" while avoiding problems with command range. But, something to try out is subordinating the OP to the firing battery or vice versa. That's one hop, but I suspect there will be a command range issue and an associated delay that is bigger than saving one hop.

That's interesting but I can't seem to make it work.
I have subordinated a mortar battery directly to a recon HQ and set it to "Provide Direct Support to: Same Formation or lower" and made sure it was well within the recon HQ's command range. And yet there is no increase in reaction time. It is still 8 minutes (which is exactly the "on call delay" value from the Soviet faction Excel sheet), the same as it was before when I had 2 hops up.

The mortars had the same reaction speed, nevermind if the OOb looked like this:

Supreme HQ
-- Recon HQ
-----mortars
-----spotters

Or like this:

Supreme HQ
--Recon HQ
----spotters
--Rifle Btn HQ
----mortars


What am I doing wrong? Afaik the range of dedicated recon units to their HQ doesn't matter (green point)?

Is the hops system actually in the game or does it use the standard values displayed in the faction-Excel-sheets, regardless of OOB structure?

Just to make sure: When I say reaction speed, I refer to the time that a battery receives the order to the time when it starts firing.

[IronMikeGolf]

Let me run some tests and talk with William.

[JacquesDeLalaing]

Thanks. Much appreciated!

[WildCatNL]

Just to make sure: When I say reaction speed, I refer to the time that a battery receives the order to the time when it starts firing.

The communication is as follows:
1. spotter spots a threat, calls for fire support
2. request travels up the chain if necessary
3. request gets assigned to fire support unit
4. fire support unit receives order and starts preparations
5. fire support unit starts fire mission

What you should compare is the time from the spotter calling for fire support to the fire support unit firing the first round on the requested target. The benefit of fewer hops is in step #2, not in in steps #4-#5. Step #4-#5 should take the same amount of time regardless where the order came from.

In the example, the time from fire support request to rounds falling is 16mins, 8 of which are due to the request going up to the group's HQ and being assigned to the mortar unit, another 8 for the mortar unit to halt, dismount, prepare and shoot.

fse_timing_example.marked.png (1.23 MiB) Viewed 825 times

The example is from 'A Final Push', using 2/172 MRR as a formation, disabling all artillery other than MTR/2/172 (setting it 'NOT under FSCC control'), and setting MTR/2/172 in direct support of its own group.

William

[JacquesDeLalaing]

Thank you for your answer!
So there is a delay for "receiving the call" (variable based on OOB structure)
and a delay for "processsing/preparing the mission" (more or less fixed depending on faction and probably soft factors/unit status)

That's really cool and makes perfect sense.

But then I have to ask: Where do you get that second table (B. LIST OF PROCESSED FIRE SUPPORT REQUESTS) in your Fire Support Window / Fire Support Control Center tab from? I don't have that in my game? Even after my artillery units have fired many on call support requests, I only ever get table A. Therefore it was really intransparent and hard for me to get a feeling for the delay of "receiving the call".

My FSCC tab always looks like that:
(also note I have some requests without an actual spotter...? I suppose these are all counter battery or ground search radar contacts?)

[JacquesDeLalaing]

Just to make sure: When I say reaction speed, I refer to the time that a battery receives the order to the time when it starts firing.

Can you confirm whether table B is restricted to some sort of developer build? Or should it be present in my game also?
EDIT: My multiplayer opponent confirms that he doesn't get to see that table in his game either.

[WildCatNL]

Can you confirm whether table B is restricted to some sort of developer build? Or should it be present in my game also?

My mistake, and my apologies. That table is debug info, only available to developers.

William

[Tcao]

Another option would be to set the ROG artillery in direct support of a single observer, or a group of observers. That would also reduce the communication delay from observer to ROG battery. The downside is that the ROG is no longer responding to requests from other sources than the observers.

Wrt counter-battery detection: in Southern Storm, that's abstracted (and assumed to be performed by higher-up assets outside the OOB). On-map counter-battery radar (or weapons tracking radar) would be seen as emitting when active, but does not add to the detection of hostile artillery positions.

William

I think this is the better option to simulate the ROG arty. It's interesting to read Lester W. Grau believes ROG provided a decentralized support to the tactical commander. The application and ROG's structure tells it is the opposite. It is the traditional soviet way of the solution, assign a dedicate formation for a particular mission.