24.03.2013 Views

Practical Sustainment Concepts for the Non-Linear Battlespace

Practical Sustainment Concepts for the Non-Linear Battlespace

Practical Sustainment Concepts for the Non-Linear Battlespace

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!