Practical Sustainment Concepts for the Non-Linear Battlespace
Practical Sustainment Concepts for the Non-Linear Battlespace
Practical Sustainment Concepts for the Non-Linear Battlespace
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
The Hierarchy of Nodes<br />
A few observations can be made to facilitate <strong>the</strong> planning of sustainment to combat<br />
operations. First of all, <strong>the</strong> level of service in various nodes is inherently progressive.<br />
The smallest of nodes can literally be a 5/20 drill, 3 which is essentially <strong>the</strong> first step in<br />
securing ground <strong>for</strong> <strong>the</strong> conduct of a task. Of course, nodes can vary in size all <strong>the</strong> way<br />
up to <strong>the</strong> very significant infrastructure seen today in KAF, where 13,000 people live and<br />
work. During OP ATHENA Roto 4, <strong>the</strong> order OP ZERIN ZMARAY (Ref B) defined <strong>the</strong><br />
level of support in a given node as a function of <strong>the</strong> disposition of units on a piece of<br />
ground. The order called nodes Tactical Infrastructures (TI) and defined a hierarchy as<br />
summarized in Table 3. Arguably, <strong>the</strong>se concepts could potentially apply to any nonlinear<br />
<strong>the</strong>atre environment.<br />
Generally speaking, support is provided from superior nodes to inferior ones. For<br />
example, a supply detachment in a PB will likely receive support from an adjacent FOB<br />
or camp, as opposed to receiving from a SP or leaguer. One could say that a certain<br />
dependency exists between nodes of equal or greater levels of support. There are<br />
none<strong>the</strong>less limits; OP ZERIN ZMARAY also showed that only nodes of a certain level<br />
of support could be used as dependencies. Column “Dependencies” of Table 3 shows<br />
that TI under that of PB do not have <strong>the</strong> capability to stock materials in sufficient<br />
quantities in order to replenish o<strong>the</strong>r nodes without additional assistance. <strong>Non</strong>e<strong>the</strong>less,<br />
one can use this general rule of superior node dependency in order to design<br />
sustainment architectures, and an example of this is shown in Figure 7.<br />
Figure 7: The rule of superior node dependency. The arrows denote dependency on superior nodes.<br />
There are exceptions to <strong>the</strong> rule of superior node dependency, as it would be<br />
feasible to see <strong>the</strong> reduction or even dissolution of an inferior node in order to boost a<br />
node in support of a priority operation. Also, if specialized or high value service exists in<br />
ano<strong>the</strong>r location, such as a mobile repair team (MRT) <strong>for</strong> a certain type of vehicle, <strong>the</strong>n<br />
that service can be re-tasked from an inferior node. <strong>Non</strong>e<strong>the</strong>less, superior node<br />
dependency can be considered a general rule of thumb <strong>for</strong> sustainment planning.<br />
We can make an analogy of <strong>the</strong> sustainment network to <strong>the</strong> Internet. The nodes are<br />
equivalent to <strong>the</strong> hierarchy of ports, switches, routers, hubs and servers in order of<br />
increasing capability to transfer in<strong>for</strong>mation. Links are comparable to trunks, wires, or<br />
wireless connections that bring a given service to <strong>the</strong> users on <strong>the</strong> nodes. When an<br />
Internet user submits a request, it is processed through <strong>the</strong> switch. If <strong>the</strong> in<strong>for</strong>mation<br />
requested is available within <strong>the</strong> switch’s internal network, <strong>the</strong>n <strong>the</strong> in<strong>for</strong>mation is<br />
rendered. O<strong>the</strong>rwise, <strong>the</strong> request is pushed to <strong>the</strong> router, to hubs and servers until such<br />
time as <strong>the</strong> in<strong>for</strong>mation is located and pushed back through <strong>the</strong> architecture to <strong>the</strong> user.<br />
Similarly, when an infantry soldier submits a support request (e.g., a repair request), it is<br />
processed initially by <strong>the</strong> CSS det in his PB. If <strong>the</strong> support is within <strong>the</strong> control of <strong>the</strong><br />
CSS det, <strong>the</strong>n <strong>the</strong> request is approved, and <strong>the</strong> service is rendered (i.e. vehicle is<br />
repaired). O<strong>the</strong>rwise, <strong>the</strong> request is fur<strong>the</strong>r dispatched between FOBs, camps and SB<br />
until <strong>the</strong> resource is located and pushed back through <strong>the</strong> network to <strong>the</strong> user. There is<br />
Canadian Army Journal Vol. 11.2 Summer 2008 53