FSR Support

I think most people realize that the services we provide can greatly influence who will live and die.  If our systems are working correctly, we enable to commander to exercise his forces to kill bad guys and break their stuff.  If our systems don’t work, then we may well miss a radar acquisition showing an incoming round or keep a MEDIVAC call from reaching the helicopter.  Bottom line, our stuff must work.

An important part of making sure our stuff works is knowing how to fix it when it doesn’t.  This goes back to training that we talked about recently.  Since I became a warrant officer in 2006, I have always personally had the mindset that there is nothing I won’t do to make sure that the warfighter can talk.  This is especially true when we are deployed and in combat.  My thinking has always been that I will gladly send myself or one of my guys forward to fix a problem if it comes down to that but only after the guy on the ground has exhausted everything that they are able to do to fix it themselves.  I will not put myself, another Soldier, or a FSR on a convoy or aircraft unless the guy on the ground has tried everything that they can think of, that I can think of, and that my local FSR can think of remotely.

My other theory has always been that my FSRs will never work on a system on their own.  In the field, that means that they work with the local operator to fix the problem.  When deployed, if they are on a convoy or aircraft then one of my NETOPS Soldiers is with them as well.  This ensures that I always know what they are doing to my systems, and also helps to teach that operator so that hopefully they can fix the problem themselves the next time it occurs.

FSR Support at NTC

Nearly three years ago when NTC began to conduct decisive action rotations, we changed the way that we allowed FSRs to support the unit out in the box.  During the first part of the rotation, FSRs are more or less free to move around the box to support the unit as needed.  Once the actual force on force portion of the exercise began though, the rules change.  FSRs are no longer allowed to freely move around the box from unit to unit.  Instead, they begin to work on a “call-forward” basis.  Unless the unit submits a trouble ticket for a particular FSR, they won’t head out to the box.  Additionally, once an FSR is dispatched, they are only able to move themselves from the base out to the Brigade Main or to the BSA.  From there, the unit is responsible for coming to get them, and moving the FSR as part of a tactical convoy to the actual location, and then return them to the Main/BSA.

While many people voiced significant concerns with this setup (and many of them were valid), I personally fully support this idea.  For a while now, we have worked off of FOBS and made the assumption that FSR support would be readily available.  This was generally true because the FSR was located on the same FOB, or the FOB itself was only a short distance out so getting an FSR out there was not a significant challenge.  What many people fail to appreciate with decisive action though is that we are striving to simulate an area where we don’t have an established presence.  Active fighting is taking place and while there will likely be FSRs around, they will not likely not be forward located and moving with units as they actively defend or attack an international boarder.

For the unit commanders, this has two effects.  First, it helps bring to light just how dependent his unit may/may not be on FSR support and should help with the training discussion.  Secondly, it will force them to make a tactical decision on what is more important to them, having whatever system working or dispatching combat power to move the FSR across the battlefield.  We have had cases where instead of moving an FSR, the Net Tech decides to move himself as part of a one or two vehicle convoy to the unit with basically no support only to have themselves killed when they are attacked by the enemy then the commander gets to experience life without a critical person.

Hard Lessons Learned

Duty, Honor, RespectOn this day in 2008, my NCOs and I were troubleshooting a HCLOS link to a remote battalion headquarters located on a FOB known as Ghaz 1.  They didn’t have a JNN or CPN, but only a data package with this HCLOS link being their only connection to the rest of the network.  It had been down for 24+ hours and the S6 had spent hours on the radio with me and my guys trying to figure it out.  Finally, the decision was made to send my General Dynamics contractor along with my spectrum manager (an old 25Q himself) out there to figure out what the problem was.  We were out of ideas so they basically took an entire new system (the HCLOS was dismounted from the shelter) with them to trade parts if they needed to.

The convoy there happened without incident and when they got there, they quickly identified the problem as being a simple configuration problem (something that we had repeatedly checked with the S6 over the radio more times than we could count, and yet they still managed to screw it up.).  To say I was pissed off would be a true understatement considering the amount of time I had wasted personally, and then having to put my guys on the road needlessly.  Later that evening my NCO and FSR rejoined the unit’s convoy to come back to Camp Victory.  The existed the FOB and within 200 meters, their convoy was attacked by two armor-piercing grenades.  Both rounds impacted their vehicle.  The first one entered through the TC’s door who is truly the luckiest person I have ever met.  The slug went across his IBA and sliced through it but left him unhurt impacting into the radio mount which exploded severely injuring the gunner and driver and giving relatively minor injuries to my NCO who was in the rear seat.  The second round impacted the ground under the truck and ricocheted back into the vehicle right under my FSR’s seat.  He was critically injured and died within minutes of returning to the FOB.

We received word back at the Brigade TOC almost immediately although a fair bit of time would pass before we found out his death.  To the best of my knowledge, his death was the first person that General Dynamics WIN-T had lost in combat.  This was also the first death that 2/1 ID had experienced (although not the last unfortunately) during its 2008/2009 deployment.  I had the unfortunate duty of contacting the supervisors there on site (a good friend of mine) and informing him of the death.

Final Thoughts

So why am I writing this?  A few reasons.  First to point out the fact that occasionally needs to be reinforced, that even though we are signal, we are not safe on the battle field.  More importantly to once again express the importance of training our Soldiers.  My FSR and NCO were on the road because a S6 failed to do their job, failed to follow pretty straight forward instructions, and instead decided to take the easy way and let someone else fix their problem.  Take the time to train your Soldiers.  Force them to figure things out themselves in the field so that when deployed they can do it without problem.  Take the time for you and NETOPS to do every single bit of troubleshooting remotely that you possibly can.  The first answer should not be that Chief or someone from NETOPS, or an FSR to jump on the road; that should be the last answer.  We as Soldiers and technical experts have the responsibility to ultimately fix the problem but how we do that can be a hugely important decision.

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>