Digitally deployed: signal transformation in combat: 3/2 Stryker Brigade Combat Team in OIF

Paul Fischer

More than four years in the making, countless hours in development, engineering, procurement and fielding, two Combined Arms Training Center rotations, several rapid-fielding initiatives and the 3rd Brigade, 2nd Infantry Division Stryker Brigade Combat Team was ready for deployment.

Arguably the best-resourced, best-trained and most technically-proficient brigade in the history of the Army was prepared to prove the concept of "network-centric" warfare in the toughest test of all, combat.

Though the brigade was named for the much publicized Stryker Infantry Fighting Vehicle; able to rapidly and comfortably deliver Soldiers anywhere in the battlefield, the 'heart' of the SBCT is its integrated complement of command, control, computers, communications and intelligence systems. Digital enablers provide the combatant commander with full situational awareness of friendly forces and the benefit of rapid dissemination of relevant information horizontally and vertically. The phrase "See first, understand first, act first and finish decisively" highlights the power of digital systems at the disposal of the ground commander.

Exercised in the Mohave Desert of Fort Irwin, honed and validated in the forests of Fort Polk, the country of Iraq was the true litmus test where, as COL Michael Rounds, 3/2 SBCT commander states, "We meet the enemy at the time and place of our choosing."

The mission was to provide for a stable and secure Iraqi environment while capturing or killing noncompliant forces; a mission statement that the SBCT was designed to execute. This article addresses the capability of organic signal and C4I systems to support the SBCT in the accomplishment of this mission in the first 120 days of operational deployment.

Background

The SBCTs signal architecture is built on a Wide Area Network/ Local Area Network Internet Protocol backbone that is networked in what can be described as a "self-contained" structure. As with the Operational and Organizational document that identifies the brigade as a force-projection element capable of self-sustained operations so too is the signal architecture. The network is traditionally viewed as a lower and upper tactical Internet with Force XXI Battle Command Brigade and Below being lower Tactical/Internet and links between battalion and brigade and Army Battle Command Systems as upper T/I. The T/I and WAN is managed by a Network Operations Security Center at the Brigade Tactical Operations Center supported by three Secure Mobile Anti-Jam Reliable Tactical-Terminal assemblages, two subscriber nodes and a forward Networks Operation Center.

In its organic structure the brigade maintains over 713 FBCB2 systems, 735 Enhanced Postion Location and Reporting Systems, 1200 Single Channel and Air Radio Systems, 78 AN/PRC-150 (HF), 26 PSC-5c, 44 Near Term Digital Radios, 450 PRC-148 MBITR, 15 Relay/Retransmission vehicles, three Network Control System--EPLRS, three SMART-T satellite terminals, three Trojan Spirit systems, two Brigade Subscriber Nodes, and one Network Operations Center-Vehicle.

Figure 1 depicts a snapshot of the brigade's signal architecture. Two months prior to deployment from Fort Lewis 13 Blue Force Tracker systems were installed in Stryker CVs and CPs, a CA/Psychological Operations and an Air Calvary Squadron was attached which increased the BFT count to over 46 systems as well as adding additional CNR assets to the brigade.

[FIGURE 1 OMITTED]

Prior to and after the successes at the National Training Center and the Joint Readiness Training Center the brigade initiated several signal force modernization projects to improve upon brigade data transfer and relay/retransmission capabilities. One key effort was the Internal Ku Satellite System. The Ku system was conceptualized after the brigade's experience at NTC where battalions were having difficulty sustaining reliable and adequate bandwidth between battalions and the brigade through the NTDR. At the conclusion of JRTC and upon determining the projected battle space the brigade would operate within Iraq, IKSS was approved for implementation into the SBCT architecture. The brigade was fielded with 13 IKSS terminals, one per unit TOC, BDE TAC and two spares. The second major force modernization project was the creation of a three "stack" Frequency Modulation retransmission vehicle. Based on the analysis of prior field exercises a requirement existed to provide relay/retransmission vehicles the capability to retrans three separate FM nets. By enabling retrans teams to increase the number of nets retrans'ed there is reduced manpower and force protection requirements in addition to minimizing the risk to soldiers. This concept was validated at JRTC and Headquarters Department of the Army approved the brigade to deploy to Iraq with three net retransmission capabilities.

Operational timeline

3/2 SBCT was alerted for deployment in July 2003 with an Authorized Load Date of Sept. 15. During the preparation for deployment the brigade executed two Pre-Deployment Site Surveys visits to Kuwait and Iraq. Each PDSS addressed requirements and established primary points of contact for reception, staging and onward movement; the brigade S6 was a primary team member for each PDSS. The first Roll On/Roll Off ship departed Tacoma, Wash., Oct. 13, 2003, with the first elements of the Advanced Echelon arriving Udari, KU, Nov. 6, 2003, and the brigade main body closing Nov. 17, 2003. From Nov. 17-Dec. 3, 2003, the brigade received all deployed equipment from Arifjan, KU, established TOCs, executed a Digital Command and Control Rehearsal, conducted ranges and training requirements as directed by Coalition Forces Land Combatant Commander. During this RSO period the brigade received the IKSS system from PEO-C3T as well as received final refresher training for integration into the brigade's architecture. Dec. 4, 2003, the brigade crossed the border into Iraq with a mission to maintain a secure and stable environment under 4th Infantry Division. The brigade convoyed over 900 Km while maintaining voice and digital communications throughout the route into an Area of Responsibility of east Samarra headquartered at FOB Pacesetter (Duluiyah), Figure 2. Combat operations with 4ID began Dec. 10, 2003.

[FIGURE 2 OMITTED]

At the conclusion of operations with 4ID the brigade was directed to conduct a transfer of authority with 101st Infantry Division (Airborne) in AO North, headquartered out of Mosul, Iraq,(Figure 3). Jan. 3, 2004, lead elements of the brigade moved into AO North; and Feb. 1, 2004, the TOA with 101st was complete. Elements of I Corps, designated Task Force Olympia, was deployed as Multi-National Brigade North higher headquarters for 3/2 SBCT. The mission of fostering a secure and stable environment remained with an addition of facilitating the transfer of that mission to Iraqi military/security forces.

[FIGURE 3 OMITTED]

In conjunction with 101st, 501st Signal Battalion conducted a TOA with a National Guard signal battalion, which assumed the mission of providing MSE connectivity between MNB-N and CJTF-7. Because the signal battalion was headquartered in Baghdad, they incorporated a "mini-BATCON" in the BDE NOSC in lieu of a fully staffed element. Effective Feb. 15, 2004, the brigade's task organization and network architecture looked as below (Figures 4 and 5).

[FIGURES 4-5 OMITTED]

Systems

All of the signal equipment fielded to the SBCT was designed to facilitate network data or voice connectivity throughout the brigade, and in some cases externally. Although exercised at the CTCs the true measure of effectiveness was not fully realized until the brigade deployed. The assessment of signal in the SBCT is broken into five sections, systems, software and procedures. Each section addresses the equipment, interaction, integration and architecture. The following is presented by largest node to smallest system, not by effectiveness or utility.

Brigade Subscriber Node

The AN/TYC-25 Brigade Subscriber Node provides switching, routing, transmission and network management and security services within a single shelter. These components form the Stryker Brigade Combat Team communications network infrastructure. The BSN also supports direct connectivity to legacy Army communications (MSE and Tri-Service Tactical Communications System) systems.

The legacy interface is achieved through the CSP-5X Vantage Server (Figure 6). There are two BSNs fielded to the Signal company, one provides support the brigade main command post and the second supports the brigade support battalion. The operational concept is to have the BSNs located where a preponderance of data enters and exits the brigade network.

[FIGURE 6 OMITTED]

From the onset of fielding the BSN consistently provided reliable data and voice communications internally to the brigade. Only when integrated with MSE assets from higher did the BSN and more specifically the Vantage demonstrate problems with voice circuits externally of the brigade into MSE networks. Problems were noted prior to the NTC rotation (Certification Exercise I) and the Project Manager responded exceptionally well by fielding the brigade an upgraded version of the BSN originally destined for 172nd SBCT (SBCT-3) during the RSOI period. Vantage Software Version 4.3 was in use at this time. The NTC rotation was executed without significant problems in regard to BSN voice traffic because C2 with higher was predominately via CNR and there was not a substantial MSE network on the "backside" of the network. Still routing and call completion was an issue known primarily only to NOSC and contractor personnel. At the conclusion of the NTC rotation all equipment shipped directly to JRTC. The signal architecture for CERTEX at Fort Polk was virtually identical to that of NTC, thus other than the trouble tickets submitted for minor problems no significant problems occurred.

Vantage Software Version 4.4 was provided after JRTC CERTEX and was implemented for use in a limited in-garrison BSN/MSE Communications Exercise. No issues surfaced during this exercise. Due to an extremely tight timeline for deployment the BSNs were configured for load-out without any additional problems being noted or changes to software. The brigade was confident that the BSNs would perform well in deployment, though questions remained on whether the software had ever been truly tasked and if it would successfully perform in a mature theater level MSE network and traffic load.

Upon arrival into theater the brigade established the network at Camp Udari, KU, for RSO operations. 4th ID provided a communications package to the brigade to facilitate operations and maintain C2 with their headquarters in Tikrit, Iraq. The 4th ID provided a comms package of an Asynchronus Transfer Mode Small Extention Node and SMART-T for division C2. The brigade interfaced into this package via SMART-T (shot from Udari to Tikrit) through BSN 3 (Brigade Main) using Vantage Software Version 4.4 Call completion into the MSE network degraded to a 0 percent call completion rate (i.e. called party not found," all trunks busy tone, dead air or error tone). The BSN CECOM LAR and chief warrant officer developed several tactics, techniques and procedures to restore legacy voice routing:

--Have MSE Node delete and re-add the (AIL), or the DTG

--Reset the Vantage DTG from BSN

--Restart the Vantage Windows NT operating system

--Or Shutdown the Vantage after which legacy call processing resumes.

Though these TTPs were effective in restoring BSN to MSE call routing it typically reappeared within a few hours. Several trouble tickets were forwarded to the PM at Fort Monmouth and the BSN trouble ticket Internet site (BSN Quickplace).

The brigade completed RSO operations and relocated to FOB Pacesetter to execute combat operations. The BSN--MSE interface was through a 4th ID ATM-MSE network utilizing a SMART-T shot from the BSB BSN into Tikrit, a HCLOS shot from BSN 3 to a Node Center on FOB Pacesetter and a HCLOS/ SMART-T intranodal network. The links were established and issues with Forward Error Correction card settings and problems with a 4096 Kbs link using an EETGMD into the Vantage were immediately apparent. After a significant period of time working engineering issues with 4th ID technicians, the local node center, and by the brigade's Soldiers the links between MSE and the brigade were stabilized. The 4096 link was reduced down to 2048 Kbs.

Several recommendations were posted on the BSN/PEO website after this first ever "full mesh" of MSE and BSN networks. The most notable recommendation was to provide a 2nd Digital Transmission Group card to the BSN in order to dual home MSE network links. This second card would have provided greater redundancy for voice and data between each BSN rather than a network where a single transmission means provided the only link into and out of the brigade. This would capitalize upon the existing "triple" redundancy of the SBCT intranodal links by providing the capability of terminating two MSE links from higher into each BSN.

The problem with the Vantage remained and was so severe that times the brigade was totally cut off from voice communications both internally and externally of the network for up to four hours. Typically the mean time for Vantage stability was one hour or less, at times the only means of command and control from the brigade to higher/adjacent forces was through email. The severity and frequency of the call routing symptoms became so bad the brigade S6 requested an emergency release of Vantage Software Version 4.5.1 and VDTG Firmware release 2.9. The brigade was advised that all previous Vantage hard drives were suspect because of a difference in the fielded Vantage platform and the Lab Vantage platform that the software was configured.

The new baseline Vantage hard drives were received and installed. Call problems from BSN subscribers to MSE subscribers occurred less frequently and stability improved. Unfortunately because of the operational timeline and unit's movement north to Mosul, evaluation of the new software was cut short. The TTP of hard and soft restart/booting the Vantage and resetting the DTG continued.

Once established at Camp Freedom, Mosul; the brigade interfaced with 501st Signal Battalion and eventually 234th Signal Battalion (NG) via THSDN-MSE through BSN/CX-11230, and by BSN/ HCLOS (226 mode), using Vantage Software Version 4.5.1 and VDTG Firmware release 2.9. Call routing and completion from BSN subscribers to MSE subscribers was averaging 65-70 percent, lasting days instead of hours. The noticeable difference in this scenario was when calls from the BSN would not process, the MSE switch could still force dial through the network a majority of the time. Over a two-and-a-half month period of stability in Mosul the Vantage switch continued to not function with the reliability expected between the MSE and SBCT networks, resulting in the brigade establishing local MSE phone lines into command posts where MSE nodes were within wire range. This obviously provided some means of voice redundancy when calling external of the brigade to other prefixes or area codes; though calls being attempted into the brigade network was never an issue. Of particular note is intra-brigade Voice Over Internet Protocol call processing has operated without issue during Vantage/legacy voice routing problems.

In mid April the brigade was provided a new software and firmware upgrades to the Vantage. The software, version 4.5.2 and VDTG firmware cards (Ver. 2.10), were installed in sequence with BSN #4 (Brigade Support Battalion) first getting the upgrade followed by BSN #3 (Main TOC). The improvements to call routing and processing between MSE and the brigade were immediate. To date the Vantage has not required a soft or hard re-start, and call completion between MSE to brigade and intra-brigade are 95-100 percent.

Although the BSNs most significant problem was the Vantage performance, the data and intranodal voice capabilities have performed well throughout the deployment. The High Capacity Line-of-Sight radio system and upgrades to the General Dynamics-Foward Error Correction and CTM100 have proved to be extremely beneficial toward mission accomplishment and relative ease in establishing internodal connectivity. As with any initial concept and pre-product system there is room for improvement. Specifically the BSN would benefit from the addition of Promina multiplexer. The shelter is pre-wired for the installation of the Promina and would add exceptional flexibility and data termination without the reliance on external support. Consideration needs to be made to retrofit the fielded SBCTs with a Tactical Switch Node or Single Shelter Switch type internal architecture that takes advantage of updated commercial-off-the-shelf switches and routers with enhanced capabilities consummate with the tactical WAN improvements. Additionally, the BSN is fielded with a Brigade Remote Subscriber System that has never provided any utility to the network. The objective of facilitating expansion of voice and data links inter-brigade has never proven to be a requirement. Recommend that future BSNs are not fielded with Brigade Remote Subscriber System or other like enabler. Other considerations are noted below.

--The BSN needs a (call completion rate report), such as MSEs R1 through R6 reports, using the current WMI to inform the operator when call completion is below a certain percentage (Traffic Metering capability)

--The BSN's Vantage needs the flexibility to establish two legacy internodal links per system

--The CTM 100 LCD display needs a light source of some type

--Installing the Promina, would enable the brigade to negate dependence on legacy signal elements to provide services such as Non-secure Internet Protocol Router Network/Secure Internet Protocol Router Network and Defense Switched Network and provide a joint interface capability to the SBCT

--WMI is a good tool however some operator functions should be more flexible to reflect the actual working network configuration

--The router/Vantage/GDFEC cables need to be included in the ASL on hand for the unit

--The GD-FEC housing unit needs to be accessible from the top of the case so the card can be inspected for proper settings without removing the delicately designed card (these cables are potentially a single point of failure for data traffic to higher)

--Operators and mangers need additional training on Vantage/ PBX H.323 call handling (specifically regarding "digit manipulation" within the BSN voice routing protocols)

--HCLOS (226 Mode) works well interfacing MSE

--The data interface with MSE worked well once routing protocols and procedures were configured

--Consider integrating a Ku satellite system (Initial Ku Satellite System into the shelter--see below for space saving)

--Remove the BRSS from the BSN fielding concept

--De-install one HCLOS radio from the BSN and provide it in a transit case IOT provide more flexibility to the network and enhancing connectivity with adjacent units as a stand alone radio.

NOC-V

The Network Operations Center-Vehicle has proven to be one of the most valuable signal shelters on the battlefield for the SBCT. It has consistently provided the critical link both internally and externally for the brigade during NTC, JRTC and now in deployment. In its early stages the NOC-V was conceptualized as the primary communication planning and operations cell, integrated into the brigade Main TOC. This concept rapidly faded when the brigade moved toward a three CP structure of the Main TOC (TOC A), a Forward TOC (TOC B), and a BDE TAC. Initially the NOC-V and a SMART-T was a component of TOC B, and remains its primary mission, though the brigade further developed a "forced entry" communications platform; named the STRYKER Communications Package. The STRYKER Communications Package was used as a C2 enabler for the TAC. Under this new operational concept the NOC-V's true value was realized and the brigade's communication architecture bore a new life and flexibility.

The original O&O block diagram/architecture of the NOC-V is depicted on Figure 7 and was envisioned as a fixed node that extended the C4I of the brigade. The NOC-V in its original form was a potent C4I platform incorporating FBCB2, Tactical Internet Management System, NTDR, SINCGARS, 20 telephones, SIPRNET and BVTC capabilities. Even in its original form, the NOC-V provided the commander an exceptional tool for C2. Under the original concept the NOC-V was limited to supporting TOC A and the IP addressing scheme reflected this vision. But the brigade viewed the NOC-V as an extremely flexible communications enabler for the commander, capable of providing high bandwidth data, voice and imagery at any decisive point on the battle space in a very limited amount of time. Prior to CERTEX I at NTC the brigade was fielded a newer version of the NOCV that increased flexibility and increased the number of links that could be terminated (depicted on Figure 8). During the CERTEX II rotation at the Joint Readiness Training Center, the NOC-V was used to support maneuver battalions and the brigade TAC. With this capability realized and proven, the brigade commander had the flexibility to deploy his command CPs (TOC A, TOC B and TAC) based on the fight, placing an extremely robust and network capable node anywhere in the brigade's AO. During, the deployment to Iraq the NOC-V package was used to support the Forward TOC (TOC B) on initial movement north. Later the NOC-V was used to support the TAC on the brigade's first assault mission in Iraq and again on the movement to Mosul. The NOC-V provides the warfighter voice, data (NIPR and SIPR) and video communications and constant Situational Awareness between his battalion commanders and CPs anywhere on the battlefield.

[FIGURES 7-8 OMITTED]

Typically the NOC-V deploys with an associated SMART-T assemblage to provide intranodal links to the brigade Main CP or the BSB; but with the advent of the IKSS and subsequent installation of the system into the shelter, as well as a host of other minor modifications (Cisco 3620 router, FXO/FXS cards, dial peers) the NOC-V had two redundant brigade intranodal satellite links to facilitate command and control and a modified block diagram (Figure 9). The installation of the TOC B IKSS made the NOC-V a true standalone C2 multiplier for the brigade commander (Figure 10-12).

[FIGURES 9-12 OMITTED]

The NOC-V's flexibility is in its ability to operate multiple VLANs and the two subnets programmed in the routers and switches. The multiple subnets allow the NOC-V to have its management LAN separate from the TOC LAN. This way the NOC-V is part of the WAN network and not limited to supporting Forward TOC. The ability to place this vehicle anywhere in the brigade makes it the most valuable asset in the brigade's communication architecture.

During the rotations to NTC and JRTC as well as the deployment to Iraq the ability to interface directly with MSE was a significant limitation. The NOC-V is not the signal-planning cell for the brigade as originally thought and had achieved a larger operational role in combat operations than initially envisioned. The NOC-V has always been called to push forward in the battle space initially to establish communications in the brigade's AOR. So the ability to interface with MSE would have been the optimal solution. A VANTAGE switch installed in the shelter would give the network planners the flexibility to sequence assets into to the AOR as well as giving the brigade the ability to deploy any of its CPs into theater and still interface with a HICON via MSE. If implemented, the NOC-V must be retrofitted with an option for voice Long Locals as part of the upgrade.

The NOC-V needs another organic means to interface into the Brigade network and/or MSE other than SMART-T or IKSS. Specifically the NOC-V needs possess the ability to establish Line-of-Sight radio links. The BSN already has the HCLOS radio internal to its shelter and "baselining" the brigade with a common high capacity radio system in all primary signal nodes would facilitate a tertiary means of establishing connectivity. The HCLOS radio has the ability to push data rates up to 8.192M; this will increase the bandwidth between the two main TOCs (TOC A and TOC B), as well as into the BSN located at the brigade support battalion. With the ability to interface with AN/GRC-226 radio, the HCLOS radio would enable seamlessly interface with legacy MSE networks and the NOC-V.

The NOC-V provides sensitive but unclassifed data to the users via KG-175 (TACLANE). This was a much-needed upgrade, but the next step is to add an SBU router in the shelter. Currently, we have installed a 3620 router in the NOC-V. The router provides the ability to do DHCP as well as the ability to NAT when fewer addresses are available. The shelter also had a SBU port installed in the SEP panel. The connection is BNC; the issue with BNC is that we only use CAT 5 cable or fiber. So, putting a RJ-45 or a fiber connection on the SEP panel instead of BNC would provide seamless connectivity. The concept is already in the BSN and should be implemented during the next NOC-V upgrade.

As a component to upgrading the NOC-V at Fort Lewis a Global Broadcasting System was installed. Though during deployment the GBS was never used because of the power of the rest of the brigade's network to obtain the same information (Trojan Spirit, CNN, Armed Forces Network, web-based products) over other organic systems. The GBS is not doing anything for the brigade installed in the shelter. As a brigade, we need the capability, but in the dismounted configuration and not installed in the NOC-V. The GBS needs to be a component of the brigade Main TOC in addition to saving weight and room in the NOCV for other useful upgrades such as IKSS.

In the final set for the brigade at Mosul, the NOC-V has been largely static though provides a valuable mission as a spoke for Intial Ku Satellite System, a secondary C2 node for network changes involving the BSNs and a network management/ troubleshooting platform. Typically the NOC-V and its associated SMART-T can be configured for mission and prepared to support any operation within the brigade's battle space within one hour. As the operational concept of the SBCT evolves the NOC-V must continue to develop into the premier platform for the signaler and more importantly the warfighter on the ground.

Secure Mobile Anti-Jam Reliable Tactical-Terminal

Three SMART-T are fielded to the brigade and are closely associated with TOC A, TOC B and the BSB; and provide the brigade an intranodal backbone for data/voice traffic. The SMART-T is a Ku-band satellite system capable of Low and Medium Data Rate (LDR/MDR) links via the MILSTAR constellation, supporting data rates up to 1544Kbs (typically operating 512 and 1024Kbs). As mentioned the brigade has used the SMART-T and the NOC-V in a STRYKER Communications Package to support the brigade commander's TAC. To date the SMART-T has consistently provided reliable connectivity to the brigade. Once deployed the brigade experienced issues with the availability of satellite hops in theater, which effectively limited the brigade to only two of three terminals being in system at any one time. Due primarily to the saturation of SMART-T assets in Iraq (4th ID and 1st Armored Division) the brigade was limited to allocated hops and the subsequent data rates were limited to 512 and 1024Kbs.

During operations in Samarra the network structure for the SMART-T was 1024Kbs from TOC A to 4ID and 512Kbs from TOC B to TOC A. This architecture benefited the brigade by enabling employment of the SMART-T as both an intra-brigade and internodal (to 4th ID) communications system. Once the brigade moved to its final set in Mosul the SMART-T supported intranodal link between TOC A and the BSB at 1024Kbs and a 512Kbs link for the NOC-V.

Prior to deployment AAR comments from 4ID and 1AD indicated severe equipment reliability issues with the SMART-T primarily related to the Medium Power Transmitter and cooling fans on the transmitter "buck." To date the brigade has not experienced similar or any equipment issues, though the cooler weather during the initial deployment may have been a factor.

Of note was the employment of the SMART-T and the management of the MILSTAR "hops" during deployment. During CERTEX I and II, the brigade used all available signal assets to take full advantage of the flexibility of links within the brigade. Specifically the SMART-T was maneuvered to support a battalion during NTC, JRTC and during ground assault convoy operations from Samarra to Mosul. The brigade created a transit case based communications system (Trans Stack) that enabled the termination of a SMART-T link for data and voice, managed from the BSN or NOC-V. The Trans Stack consisted of a KIV-19, GD-FEC, CTM-100 and Cisco 3620 router; there were two develop by the brigade. This stack in conjunction with a SMART-T provided end users NIPR, SIPRNET and phone connectivity into the brigade network. This "mud box" voice/data system enabled the brigade to move one assemblage (SMART-T) anywhere on the battlefield to provide emergency or temporary connectivity a C2 node. But as with any satellite link the issue of bandwidth must be addressed.

Due to the proliferation of SMART-T assemblages in theater the brigade's requirements added strain on an already saturated MILSTAR network. This was evident with the limited number of links that were allocated to TOC A and TOC B, throughout the deployment, though requested numerous times, two links (1024 and 512Kbs) was all that was provided. Eventually the link structure was modified to three links at 512Kbs each.

The SMART-T has performed exceptionally well throughout deployment. Some physical improvements to the assemblage would enhance operational capability. Enabling an auto tracking memory function would improve satellite acquisition time. When shutting down the SMART-T and reinitializing the acquisition process, the SMART-T needs to possess the ability to "remember" the last know location of the MILSTAR satellite in relation to GPS/long/lat position. This would preclude a start-up, acquisition, and "lock" of the satellite lasting 20 minutes or more; the Trojan Spirit terminal has such a capability enabling restarts and acquisition of less than five minutes. Frequently the brigade's SMART-Ts were knocked off of the bird by other terminals that obtained a higher priority for links. After some investigating it was determined that management of the MILSTAR constellation and terminals enabled operators and MCPTI managers to configure images "on the fly" external of the Satellite Access Request process which resulted in certain links to lose priority. This procedural issue resides in the management TTPs of the theater and is not with the assemblage though consideration should be made for the level of reconfiguration that can be accomplished at the terminal level.

As mentioned the SMART-T is an exceptional workhorse for the intranodal links within the brigade (and in some cases to higher) though due to the saturation of terminals and limited segments available on the MILSTAR constellation recommend that the community revisit the implementation of a tri-band satellite system. The flexibility and utility of a tri-band satellite terminal would significantly enhance the capability of the brigade to establish connectivity both internally and externally of the network (Phoenix Tri-Band). Consideration should be made to incorporate both tri-band and SMART-T systems in the brigade. This capability in conjunction with the installation of a Promina in the BSN would provide a true multifunctional terminal that could adapt to virtually any theater level satellite footprint and facilitate joint connectivity.

Internal KU Satellite System

At the conclusion of CERTEX I at the NTC the brigade identified a data "gap" between the power of the automated systems and the limited digital transmission capabilities fielded to battalions compared with the relatively high bandwidth capable systems available to the brigade headquarters. The brigade possesses incredibly powerful intelligence collection assets, video, voice and SIPR/NIPR providing the brigade commander virtually limitless situational understanding and awareness but a data "bottle neck" exists from the brigade down to battalions. The digital data radio (NTDR) was incapable of transmitting the volume of digital traffic at an acceptable speed and with reliability to the battalions.

Days after CERTEX I the brigade S6 began working with Battle Command Battle Lab-Fort Gordon and the Program Executive Office-Command, Control and Computers, Tactical to develop a potential solution. Two weeks (July 31, 2003) after the conclusion of CERTEX II at JRTC a rudimentary concept of a TDMA Ku satellite system based on Linkway network secured with KG-175 TACLANEs was developed and presented to the brigade. After an Operational Needs Statement was approved and funding secured through Headquarters Department of the Army, procurement was initiated through Data Path Inc. Training of Signal Soldiers in the brigade was initiated on Sept. 8, 2003, at Fort Lewis with surrogate Ku systems. Much of the final material solution and technical architecture was still forming while the brigade was receiving training from PEO-C3T, BCBL(G) and Mitre. Once training was complete the surrogate systems were returned to the manufacturer and the brigade deployed to Kuwait with the understanding of receiving the IKSS in theater (the reason for this was the long lead times for certain satellite components). Associated BVTC and TACLANEs for each of the 13 systems deployed with the unit. The engineering, approval, procurement and training process was truly remarkable when considering a timeline of under 90 days from concept to employment in the field, a first for the signal community.

The 3/2 SBCT IKSS operates under a hub and spoke concept with two Master Reference Terminals that control 11 Traffic Terminals with over 7 Mbs aggregate data rate shared between all end stations; though TTs are limited to 800Kbs uplink. Each TT is comprised of a Linkway modem, Cisco 1760 VPN, KG-175, Cisco 3725 and UPS in a transit case with a 1.5 meter satellite dish. Set up time is typically 45 minutes or less. The MRT is essentially a TT with the addition of a second Linkway modem, ViaSat combiner and Sun system computer management terminal hosted from a 2.4 meter satellite dish. Only one MRT can control the Linkway network, thus the second MRT is traditionally identified as an AMRT (Alternate MRT). The employment concept and component integration is depicted left (Figures 13 and 14). Each IKSS terminal is fielded with one TACLANE for encryption of the Ku link into SIPRNET, tunneling of NIPR through a second TACLANE was achieved by harvesting an existing TACLANE that resided in each S1/S4 vehicle within the battalions. This leveraging of INE assets internally of battalions was not possible for attached units (i.e. Air CAV) that did not have organic TACLANEs. As a result "analog" units were resourced with two TACLANEs (one from the fielded IKSS and an additional TACLANE from one of the spare systems). Ostensibly this created a capability shortfall if the brigade ever had to employ with spare IKSS terminals.

[FIGURES 13-14 OMITTED]

Early in the development and training of the IKSS the brigade began the process of obtaining accreditation of the IKSS network for SIPR and NIPRNET traffic. The primary issue in regard to encryption was a KG-175 providing "bulk encryption" for a tactical network over a commercial circuit. After working with theater and Defense Information Systems Agency to validate the security protocol and acknowledgement of the TACLANE as a primary encryption standard, the brigade was approved to exercise the IKSS in theater.

Once fielded in Udari, KU, the importance of IKSS became immediately apparent in providing battalions wide band data links to the brigade C2 nodes. Each battalion received a set number of NIPR IP address (approximately six IPs per battalion) based on an IP pool provided by higher and a total of 16 SIPR IPs were dispersed throughout the IKSS network; additionally each TT facilitated four VOIP "red side" phones (hosted off of the BSN) and an "orderwire" line. Though the IKSS provided immense capability to the battalions the actual data that passed through "gateways" out of the brigade was predicated on what was being provided from higher. This issue along with Vantage inconsistency and problems with MSE call outs and link stability resulted in, initially, IKSS being questioned by brigade leadership whether it was operating as advertised. This perception was wholly based on the systems that facilitated inter-brigade network connectivity (MSE, Vantage) and not necessarily the IKSS. What must be understood is IKSS as a transmission medium and data path that is dependant on the network that is being "passed" to other customers in the network. Once the Vantage and MSE stability improved and the capability of the system fully realized; the brigade fully endorsed IKSS as the most valuable upper T/I asset for network access and the warfighter.

Early in deployment the brigade worked with PEO-C3T to devise a "sanctuary" IKSS node outside of the brigade's battle space. Given the mobility of the brigade and the changing mission sets placing a MRT in Camp Doha, KU, connected to a DKETS would provide SIPRNET on demand to TTs as well as a control/management location external of the brigade. After a significant period of time CFLCC approved the network accreditation to integrate the IKSS into the theater network. Soon after the brigade agreed to position a MRT with PEO-C3T and Data Path Inc. support staff at Camp Doha, subsequently connecting the IKSS into the DKETS. This network connection enabled the brigade receive SIPRNET connectivity external of MSE theater assets and significantly improved the speed and reliability for the brigade.

Overall the IKSS has been the biggest C2 force multiplier within the brigade and has demonstrated a capability that must be included in all follow-on SBCTs as well as signal transformation architectures. The brigade successfully demonstrated the feasibility, viability and flexibility of IKSS for any unit operating in a non-contiguous battle space. The use of commercial satellite networks lessens the impact upon military satellite networks and in some cases can provide a "cleaner" and more reliable footprint in an AO. Being the first unit to ever receive and use a Ku satellite system to the extent that the brigade did and the speed at which it was developed and deployed there were several recommended changes that the brigade has noted. Most of the changes have been addressed by PEO-C3T for inclusion into follow-on Ku solutions for 101st ID (A) and 3rd ID.

Specific to IKSS, all systems should be fielded with E100 model TACLANEs and potentially incorporation of Advanced Encryption Standard Cisco routers. Such a configuration may negate the need for a second TACLANE for "tunneling" NIPR (as in the current configuration). Using an AES router could potentially facilitate a NIPRNET path directly from router to router and a single TACLANE would tunnel the SIPRNET. Each IKSS terminal provides four 2-wire VOIP phones for voice services, though as the deployment has progressed it is evident that end users require additional phone capacity. Specifically future systems should provide for at least 10 VOIP phone ports per a system (operations and future expansion). All TTs should be fielded with a satellite phone (Iridium) in order to place calls to the satellite controller during registration of the satellite.

This empowers the operators to set up the satellite virtually anywhere in the world with the confidence of successfully registering on the satellite without external communications support. All TTs need to be fielded with an auto-acquire and auto tracking satellite dish. Though set up times are usually under 45 minutes, having such a capability would enable the operators to complete set up of the modem, routers and TACLANE while the dish acquires the satellite which would facilitate set-up times of under 20 minutes. In addition to an auto-track/acquire dish for fixed locations serious consideration should be made to incorporate this technology on the Stryker CV platforms.

The brigade conducted some analysis with PEO-C3T on the feasibility of placing an auto-track/ acquire dish on a Stryker, the size, weight and power requirements were beyond the thresholds of the vehicle. Potentially as improvements are made to mobile satellite systems, such problems may be overcome. The concept of a sanctuary IKSS should be expanded where all MRTs are placed in a safe haven where access to STEP capabilities could be ported into the network (SIPR, NIPR, Voice/DSN). This would allow for quick deployment of the brigade worldwide in virtually any size or composition without a reliance on externally provided "forced entry" communications systems for support. Finally in addition to integrating the IKSS into the NOC-V platform, engineering to install IKSS equipment into the BSN would parallel the logic of incorporating existing routers, TACLANEs and switches to fully leverage the power of both the BSN and the IKSS rather than two separate systems. This could be accomplished by transit case mounting one of the HCLOS radios in the BSN and replacing it with IKSS components.

NTDR

The Near Term Digital Radio was originally fielded to the SBCT to enable Army Battle Command System information to be passed from brigade to battalions. As referenced with the IKSS this concept while still valid, did not meet the requirements of the commander on the ground. Of the 44 NTDRs fielded approximately 10 have been in operation at any point and time during the deployment. Stryker CVs have used the NTDR during operations in order to maintain an ABCS link with a Command Post; but typically NTDRs have been used as a link for Combat Training Command Post to the Brigade Support Battalion within a 3 km footprint on a Forward Operating Base. All NTDRs have been operating on "wide band" mode.

Several units used the NTDR for connectivity from their TOCs to relay/retrans sites to CV Strykers. The longest LOS link obtained during deployment was 40 km from a battalion TOC to a relay/retrans site. The NTDR does provide minimal data processing to CVs and has been beneficial for ABCS Common Operational Picture development though that is the sole purpose for the NTDR, not passing large data files.

A TTP that the brigade developed during NTC/JRTC was in order to achieve "in net" status with the radios all of the antennas must be on an equal "plane" in a three-dimensional space. Essentially all the antennas should within a height tolerance of equal to +/- 2 meters and 10-20 km apart in order to achieve a good link (during NTC and JRTC the brigade consistently achieved 12 km links, the longest being a 45 km link). This was exceptionally hard to achieve in a deployed battle space that was 200 x 400 km and where a majority of forces were occupying cities or air bases. With such an AO the brigade used the NTDR in a reduced role and used it primarily as a short-range link for elements within range of a TOC. In fact it could be argued that the NTDR and the IKSS created a subset of the upper T/I with the NTDR filling a role as a "low level" or "degraded" upper T/I and the IKSS providing true upper T/I connectivity.

In regards to the equipment the antenna and mounting base needs to be re-engineered to be more durable in a field environment. Specifically the antenna base o-ring consistently failed resulting in the antenna becoming "off center" and not 90 degrees in orientation to the ground. Additionally the contact pins internal to the antenna frequently broke leading to intermittent data links.

Overall the performance (since its fielding) of the NTDR has been below expectations, especially in light of the data requirements of the brigade. The relatively low data rate (~28.8 Kbs), difficulty in obtaining a reliable link, large battle space and emphasis on other systems has resulted in the radio not being extensively used during deployment. Finally the NTDR is not longer a viable system for the warfighter to solely rely on for digital connectivity. The expectations of today's commanders and Soldiers demand a system that provides high data rates, consistent reliability and mission flexibility.

Serious consideration must be made whether to continue this program beyond the current fielding and replace it with a Beyond-Line-of-Sight high data system. If this program does continue the waveform should be replaced with the next generation Joint Tactical Radio SystemWideband Network Waveform in order to better facilitate higher data rates and longer ranges.

EPLRS/FBCB2

By far the most valuable system fielded to the brigade for the commander and Soldiers on the ground has been EPLRS/FBCB2. The SBCT is fielded with over 713 EPLRS/FBCB2 and possess 3 Network Control Station-EPLRS assemblages. Prior to deployment the brigade initiated a change to the address database to account for unit attachments in anticipation of receiving changes or additions to the task organization. The significance of these changes was the depth and speed at which the database was modified by engineers at the Program Manager and testing by the Consolidated Training Support Facility at Fort Hood. The database change added over 200 roles to the addressing list and encompassed the following:

--Military Police

--Special Operations (Ranger/ Special Forces)

--Lift and Attack Aviation

--Civil Affairs and PSYOP

--Wingmen (Platoon)

--1SGT

--Mission Data Replicator

--ABCS-Light (L) platforms

Prior to deployment and as a component to the new database the brigade fielded FBCB2 version 3.5.4.

Since deploying the brigade has consistently maintained over 500 FBCB2 systems in network spanning the entire battle space. During RSO activities at Udari, KU, the brigade conducted a Digital Command and Control Rehearsal to validate all organic C4ISR systems; the commander's intent was to ensure all FBCB2s were fully operational. All hard drives were loaded with 5-meter imagery of the CENTCOM AOR with 1-meter imagery for areas of interest.

The movement from Udari to Samarra was an 800 km movement where the brigade implemented a COA of bounding the NCS-Es and relay/retrans vehicles throughout the route in order to provide route coverage for convoys. Expected range of the EPLRS radio in southern Iraq was over 75 km and in execution varied between 35-100 km.

A constant challenge to maintaining SA was the positioning of NCS-Es and relay/retrans at Convoy Support Centers, which unfortunately were typically near built up and urban areas. This reduced the effective range of the EPLRS system to below 75 km, especially as convoys traversed the relative urban sprawl of Baghdad. Each convoy was tracked north of the Iraqi border until terrain masked the EPLRS signal and each radio went into TRACNET (an isolation of the EPLRS network where only radios in that network can provide SA and messaging services internal to the TRACNET group). Upon entering a NCS-E management area NCS-E operator reassumed control of the radios by "advance without a re-key" to bring them out of TRACNET and back into the existing EPLRS network. This COA was a carefully synchronized operation and required very experienced NCS-E operators to constantly manage the network to ensure stability and prevent total fragmentation.

A significant draw back to this COA was the inability of each NCS-E to be in direct line-of-sight communication with other NCS-Es in the network. Having a direct link between NCS-Es is necessary to efficiently manage the radios, maintain a control net between operators, and establish proper timing/network RSID divisions. A second issue was due to the total distance of the route a NCS-E could not initially be placed at Samarra. Regardless of these limitations the brigade was able to maintain SA and the EPLRS network was reasonably intact as the brigade closed from Baghdad into Samarra (150 km). Once closed, the EPLRS network needed to have several "advances" and re-keys in order to achieve a completely restored network.

Without two of the most experienced and knowledgeable NCS-E operators in the Army executing the network, re-establishing control of all of the EPLRS radios and the subsequent FBCB2 SA would have taken significantly longer than the two days it did.

During operations in Samarra FBCB2 proved to be the most valuable asset to the commander in obtaining and maintaining SA of elements as Strykers conducted operations in the city. The training and TTPs of the brigade to rapidly update the COP and message between platforms enabled commanders to visualize the battlefield and effectively manage forces and synchronize operations.

Because of their remote locations in the noncontiguous battlefield and COE of Iraq, security of key signal nodes was paramount to the command. The requirement to minimize combat power tasked with securing fixed sites and maximizing forces focused on NCF drove NCS-Es and relay/retrans vehicles to be placed in less than optimal locations and collocating with other C2 assets. The focus of the planning staff was to first provide FM coverage and second FBCB2/EPLRS connectivity. The result was an EPLRS network that required constant supervision and control by all operators. Though largely "invisible" to the Soldiers on the ground, the effort required to maintain connectivity was surprising and a constant concern of the BDE S6.

As a component to operations in Samarra the brigade operated with elements of 4th ID. Though 4th ID possessed EPLRS/FBCB2 their NCS-Es operated on different C2 needlines from the brigade. After coordinating with 31C Soldiers from 4th ID the brigade was able to "merge" the two EPLRS networks via a Gateway. This interface immediately proved the immense power of the FBCB2 network, though the networks could not message between themselves the SA that was provided ensured that boundaries, QRF, CFL and other control measures were effectively managed and employed.

Below are described the specific procedures implemented in order to merge 4ID and 3/2 EPLRS networks.

Procedures:

1. FBCB2 needlines are dynamically activated Permanent Virtual Circuits. They are High Data Rate Carrier Sense Multiple Access circuits. Neither source or destination RSID/MILID are entered in the database because they are dynamic and any radio can request activation of the Logical Channel Number assigned to the NL. The LCNs are pre-assigned by the FBCB2 database builders to correspond with the FBCB2 HDD and INC databases therefore cannot be altered. Every brigade that has FBCB2 uses a different LCN for the brigade wide SA NL.

2. LCNs are used by the Radio Set similar to a port on a computer and are only associated with the circuit in that it has been assigned to that circuit in the NL database. It is not necessary for all radios participating on the same PVC to use the same LCN.

3. It is possible for the NCS-E operator to "add HDR unit" (RSID/ MILID) with a different LCN into the FBCB2 NL entry.

4. The EPLRS Gateway Radio Set consists of two EPLRS RTs and a conduit cable between the two RTs. To establish a gateway NL, both radios must be assigned the same LCN. The NL can be activated by either the NCS-E or the Gateway RS operator (.A URO message IAW TM)

5. The Gateway RS operator must manually enter the correct host link parameters (-L URO message IAW TM) for gateway operations.

Required coordination between brigades:

1. Each brigade's EPLRS Planner must know the complete list of used LCNs for the "other" brigade. An LCN should be selected that is not already in use by either brigade and must be the same for both brigades because of item 2 above.

2. The RSID/MILID of the Gateway RS that will be loaded with the "other" brigade's COMSEC will need to be known by the "other" brigade.

In the following example 2nd BCT, 4 ID and 3 BDE, 2 ID will be used. The actual data will not be used and is for explanation purposes only.

3 BDE, 2 ID NCS-E database contains the following:

1. NLID 1801 is brigade-wide SA and is assigned LCN A0

2. LCNs 11, 12, 13 and A0 through BF (hex) are in use.

3. RSID/MILID of Gateway RSs are 197E/ 1G8WAYA2 and 197F/ 1G8WAYB2

2 BCT, 4 ID NCS-E database contains the following:

1. NLID 1811 is brigade-wide SA and is assigned LCN D9.

2. LCNs 2A-2D, 90-9F and D0-EF are in use.

(the two brigade wide SA NLs use different LCNs so a LCN not in use by either brigade must be selected for use by the Gateway RS in order to link the two radios together)

The unused LCN C0 is selected. RSID 197F will be loaded with 4 ID COMSEC. Now LCN C0 can be activated on both the Gateway radios (197E and 197F) creating a PVC between both brigades FBCB2 SA.

3 BDE, 2 ID NCS-E menu selections and database entries:

Edit

Library

Needline entry

Add HDR unit

Type 1801 and hit return

Enter source RSID 197E, source LCN C0, PRI 1 and IDX 001 and hit return.

2 BCT, 4 ID NCS-E menu selections and database entries:

Edit

Library

Needline entry

Add HDR unit

Type 1811 and hit return

Enter source RSID 197F, source LCN C0, PRI 1 and IDX 001 and hit return.

At the conclusion of combat operations in Samarra the brigade initiated movement north to Mosul. Leveraging some of the lessons learned from the first major movement, the brigade employed the brigade TAC, NOC-V, SMART-T and an NCS-E at Mosul prior to the follow-on movement of the main body. This ostensibly "book-ended" the convoy route with WAN access and EPLRS/FBCB2 coverage. Additionally this proved a theory that was discovered during JRTC where the EPLRS network was able to be managed and provide SA through the brigade's satellite terminals. Through this link the brigade was able to accurately and reliably track SP and closure of all assets from Samarra to Mosul, a distance of over 459 km, via EPLRS. Once established in Mosul the brigade emplaced relay/retrans and NCS-E teams at two locations on the battle space, one to support operations to the far west and one to support operations to the south.

This array provided complete coverage of the AO with EPLRS line of sight distances in excess of 100 km. The third NCS-E was maintained at the BDE TOC though not actively managing the network, it generated Integrated Key Encryption Key for EPLRS radios as well as acted as tertiary management terminal for network. The distance between the two active NCS-Es was on the outer limits of EPLRS range (over 110 km) and occasionally resulted in fragmentation of the network the SA and messaging of FBCB2 platforms. Once again the demands of force protection and economy of combat forces for security of signal nodes resulted in the NCS-E to the far west have issues maintaining a consistent and reliable control link to the southern NCS-E (a distance of over 110 km). This issue was not overly critical and did not negatively impact any combat operation though it did pose some issues with timeliness of message delivery and receipt.

Though EPLRS is an integral part of the FBCB2, the FBCB2 on its own is a true combat multiplier to the Soldier on the ground, while providing leadership a phenomenal view of the battlefield. In a Contemporary Operating Environment such as Iraq, the main threat is primarily IEDs, small arms fire, and RPGs. Combat operations consist of patrols, apprehending targets and small-scale offensive operations in remote locations. It is this environment where FBCB2 truly demonstrates an overwhelming advantage over traditional voice communications and Blue Force Tracking. The brigade uses FBCB2 to track convoy operations, whereas every convoy must have at least two FBCB2 systems operational, one at the front and rear of the convoy. This provides the battle captain a graphic depiction of convoy SP, progress and arrival as well as a means to rapidly alert crews to dangers ahead or changes in mission.

By manually posting a red icon on the screen, all elements within the AO are able to associate a threat and collaborate it with voice reporting or "free text" messaging. During targeting operations FBCB2 is used to post the latest graphics, imagery and updated threat situation "on the fly" (the bandwidth of EPLRS enables data transfer and SA update faster than BFT). Frequently during raid operations FBCB2 was used to update a COP, provide immediate Actionable Intelligence obtained from other sources that translated into a second or third operation within minutes of receiving information rather than initiating another planning session or meeting at a rally point. The density of EPLRS/ FBCB2 platforms in the brigade enabled multiple targets to be "exploited" simultaneously within minutes of receipt of AI that typically resulted in several additional targets to be detained.

Several lessons learned and TTPs have evolved from employing the largest active network and density of FBCB2 and EPLRS radios in the Army.

Specific to EPLRS:

(1) All relay/retrans or EGRU designated vehicles must QEAM mount EPLRS antennas whenever possible.

(2) As tactically feasible all available FBCB2 SA server designated platforms must be place in system to ensure proper SA and routing.

(3) NCS-Es whenever possible should be employed away from a TOC, the proliferation of EPLRS and other emitters in a SBCT TOC reduces the effectiveness of the management terminals.

(4) Planning staffs must have a complete understanding of the advantages and disadvantages of an EPLRS network and more importantly how to employ an EPLRS network within the constructs of a tactical environment.

(5) Increase the number of management platforms for EPLRS, though EPLRS Network Manager may be the future for SBCTs, it does not provide the power of a NCS-E to manipulate and configure the network. Consider incorporating both ENM and NCS-E in future SBCTs.

Specific to FBCB2:

FBCB2 is a winner and based on having the luxury of both BFT and FBCB2 operating in the brigade the general consensus is EPLRS/ FBCB2 is far superior. I would venture to say, if a BFT enabled unit was able to conduct operations in a EPLRS based environment, it would find EPLRS/FBCB2 significantly better at SA, messaging, speed and information assurance. The Army needs to take a close look at the requirement to continue any BFT fielding for future SBCTs. Lessons learned and TTPs:

(1) Though relatively intuitive, FBCB2 requires training; a common "windows"-based platform should replace the windows/UNIX feel of the software. Specifically, messaging should be similar to Outlook as an interface where addresses are quickly called up and identified and a sent/deleted message folder established. Incorporate a "you-have-mail" pop-up on the primary screen vice a FIPR block ID panel.

(2) Icon filters must be improved so platforms can be rapidly found within the database and immediately referenced on the map.

(3) The brigade rarely used the message formats on FBCB2, instead using the faster "free text" message option to send critical information. Scale down the number of message formats to their most basic functions (free text, spot report, MEDEVAC, etc.). Increase the free-text message size limitation from 876 bytes to one that can better accommodate larger messages.

(4) Increase the variety and type of icons in the database to incorporate all branches and specialties, having "infantry" icons only made filtering through them difficult to find a specific type of unit.

(5) Develop a database that is configurable on-the-fly capable of adding unique role names at the unit level rather than requiring a arduous engineering process through the PM and CTSF.

(6) Develop an easily configurable platform priority designation where only certain FBCB2 platforms can post and delete graphics, engineer graphics, etc. (i.e. only an engineer platform can delete a posted minefield on the FBCB2 network, vice any platform being able to change icons and database objects)

(7) Incorporate a "message received" confirmation into the messaging process. In an age of instant email the brigade has found that a "message sent is message received" mentality is prevalent. This has extended to FBCB2, where a message has been sent with the assumption that the addressee received it. Confirmation of receipt should be intuitive and easy to acknowledge.

(8) Develop a "flash" and "priority" message banner on the main GUI of the FBCB2 rather than a numerical designation on the FIPR ID panel. Finally,

(9) Improve the Fragmentary Order/OPORD message format to enable more flexibility for developing and reading orders on the FBCB2.

Two items of critical note is the implementation of a FBCB2 "digital-stand-to" and the flow of replacement FBCB2 parts in the brigade. Early in the deployment the brigade expanded a SOP of digital connectivity validation and confirmation to encompass FBCB2 network connectivity on a weekly basis. The purpose of this stand to was to ensure that all available FBCB2s in the network were capable of obtaining messaging and a COP.

Non-mission capable systems (i.e. down for parts, trouble tickets, prime mover issues, or other) were exempt from this stand to. Typically the stand to was executed early in the morning and in some cases was synchronized with the brigade-wide EPLRS OTAR. This was a command directed event, coordinated at the S6 level, orchestrated by the BDE S6/ NOSC and typically resulted in over 85 percent of the brigade FMC FBCB2s being consistently in net (550-595 systems).

During CERTEX I and II, the brigade experienced significant FBCB2 parts availability issues. This was traced to problems with the turn-in and evacuation of FBCB2 screens, CPUs, keyboards, PLGRs and on-hand quantities of cables and connectors. CTSF-Northwest (STRYKER) was clearly the most capable organization to assist the brigade in mitigating the parts shortage and equipment evacuation. With a robust receiving, packing, and evacuation team (positioned throughout the theater and in the states) and procedures as well as the technical expertise of PM FBCB2 contractors, CTSF-STRYKER was ideally suited to assume the mission of improving FBCB2 parts flow and maintenance tracking. Within a month of deploying CTSF-STRYKER assumed control of "pushing" FBCB2 parts, coordinating evacuation of components, and tracking all asset availability. FBCB2 ASL was transferred to CTSF-STRYKER and a team was placed near the Electronics Maintenance Shop for receipt of equipment at the BSB.

Operational Readiness of FBCB2 improved significantly once this procedure was in place. Still the availability of FBCB2 parts needs to improve and the production limitation of hard drives, screens, and keyboards should be lifted to address the proliferation of FBCB2 (and BFT) systems in the Army.

BFT

Prior to deployment the brigade was fielded 13 Blue Force Tracker systems. These were installed on each battalion commander's Stryker CV and one for each TOC. Additionally the aviation squadron, Civil Affairs and PSYOP units were enabled with 46 BFT systems. The CA and PSYOP units were provided a hybrid BFT/ FBCB2 that could switch between BFT and EPLRS/FBCB2 once the J3 cable and hard drive was swapped.

Although BFT has been very popular with "analog" units in providing SA, the brigade has not found BFT as beneficial as FBCB2 for SA or executing combat operations. Perhaps due to the density of EPLRS/FBCB2 in the brigade and TTPs established by the Soldiers to integrate and use the system as a means for communications (messaging) and SA on the move; BFT has gone largely unused. This is not meant to imply that there is no need for BFT. On numerous occasions BFT was used to determine positioning of "analog" units within an area of interest or during movement through adjacent battle spaces.

Finally, there have been numerous COAs presented on merging the BFT and EPLRS/FBCB2 networks at the lower T/I level. Concurrently there are numerous hurdles that must be overcome before such a network can exist, mainly the merging of an unclassified (BFT) network with a classified FBCB2 network. Though technically it's possible, the greatest draw back is the lack of messaging, which in the SBCT, is one of the primary methods for communicating with dispersed platforms.

Lastly, a new L-Band enhanced EPLRS/FBCB2 COA has been presented to the brigade though the same questions remain in regard to security, messaging and distribution of these radios in an EPLRS network. Careful consideration must be taken when attempting to integrate "new" systems into the SBCT architecture vice injecting them into an "analog" unit. The SBCT do not easily accept changes or additions to routing, IP addressing and databases of the existing network.

Relay/Retransmision Vehicle

As previously mentioned the relay/retransmission vehicle, with the addition of a third stack of FM radios, was one of the significant enhancements to the brigade's network. So-called relay/retrans because of the density of data radios in the brigade operating under the premise of relaying rather than retransmitting. The additional FM stack, in and of itself, enabled the R/R mission to require less force protection, provide an "economy of force" for retrans Soldiers, and increase the C2 capability of the brigade. As originally fielded there are 15 R/R vehicles, two per IN BN, three per CAV/FA BN and three in the Signal company. Each vehicle has FBCB2/EPLRS, 3 x AN/VRC-92F SINCGARS, NTDR and deep cycle batteries, AC/DC converters to convert the power generated by the towed 3KW generator. Finally each team is comprised of either two or three Soldiers as well as 6 COM-201 FM antennas.

The R/R vehicle serves two critical network functions. One R/R vehicle in each battalion is designated an EPLRS/FBCB2 SA server. The SA server enables FBCB2 messages to be routed to their destinations and ensures the accurate positioning of icons on the screen. This designation allows for an EPLRS "hop" to be "refreshed" if the number of EPLRS "hops" exceeds the limit of the radio system (typically four hops, where a hop is an EPLRS to EPLRS LOS link). This ensures that the EPLRS network can efficiently route needlines.

Without this SA server functionality of the R/R vehicle the FBCB2 network could fragment or be lost all together. Each RTNS1 FBCB2 "role name" is automatically designated a SA server, though if not available or NMC, another vehicle can "re-role" their FBCB2 to assume SA server functionality. A second network function of the vehicle (specifically the EPLRS) is the identification its radio as a Grid Reference Unit. An NCS-E can manually specify EPLRS radios as GRUs; the brigade's TTP is to always designate relay/retransmission vehicles as GRUs. By establishing GRUs across the battle space the EPLRS network can accurately determine position of any radio through triangulation of the reference points. A third network relay function is the NTDR, though as a matter of SOP the radio is powered up but as previously mentioned the brigade has not employed the NTDR substantially, thus this capability has gone largely unused in the R/R vehicle.

The value of the third stack of FM radios became immediately apparent when brigade conducted operations north of the Iraqi border. Positioned at key convoy support centers the brigade was able to retransmit BDE CMD, BDE convoy and a QRF net throughout the route with a solitary vehicle. This negated an increase of life support, force protection, and logistical requirements of an additional vehicle. The capability of maintaining a command, convoy and quick reactionary force net without having to deploy additional assets forward significantly reduced the forward footprint at four different CSC. Essentially the brigade accomplished the retrans mission using four vehicles versus eight, the benefits were clear.

Once combat operations in Samarra commenced the brigade employed nine R/R vehicles in support of operations throughout the sector. Seven vehicles were deployed in the immediate AO (45 x 50 km) and two additional systems were tasked in support of a detached infantry battalion 40 km south and west of the brigade that needed EPLRS and voice connectivity. Two of the nine vehicles were brigade (Signal company) R/R assets. The density of these assets was required for voice and digital connectivity down to squads and platoons operating in the urban terrain of downtown Samarra.

As the brigade transitioned from Samarra to Mosul a single brigade R/R vehicle was emplaced mid-route to provide voice retransmission for GAC operations (two brigade and one battalion net). Once the brigade was established in Mosul a second R/R site was occupied to the west for CNR and EPLRS connectivity. The final brigade CNR network was one R/R site 75 km west of Mosul and a second 45 km south; NCS-Es were co-located with each R/R vehicle. Each brigade R/R team retrans'ed BDE CMD, BDE O&I, and BDE Fires; as the AO developed several battalions emplaced their R/R vehicles with the brigade assets in order to consolidate force protection and logistics support. At one site three R/R vehicles are executing operations that would typically require five "standard" dual stack retrans vehicles.

In order for each relay/retrans vehicle to have adequate power to operate the radio systems (FBCB2/ EPLRS, 3rd 92 series radio, NTDR) each vehicle is outfitted with dual deep cycle marine type batteries as well as a 3KW generator for stand alone power generation interfaced with a DC charging unit. Using this system the relay/retrans is able to charge from the 3KW generator or directly from the vehicle's alternator. Of note was a potential issue with failure of the DC chargers in high heat environments. The charger was moved farther off of the mounting plate to allow for increased airflow. Another potential issue is the "under" loading of the 3KW system. Commercial, local and "stateside" generators were integrated with power adapters to facilitate load and remoting of radio systems.

Each relay/retrans vehicle was provided 6 COM 201 FM antennas, these antennas used in conjunction with the mast sections of an OE-254 or Quick Erect Antenna Mast significantly improved set-up and tear down time to under 30 minutes for full three-net operation. The COM 201 is a significant improvement to the existing OE-254 antenna. At less than 10 lbs the antenna is extremely lightweight and can be configured for free-standing (ground), mast-mounted or aerial hanging operations. The brigade possesses over 200 COM 201s and has outfitted every CP with these antennas with all elements reporting significant improvements on FM range and clarity. Serious consideration must be made by the signal community to phase the COM 201 antenna into the inventory as the replacement to the OE-254. Additionally the brigade tested another Atlantic Microwave product, a "Stacked" COM 228, capable of two FM nets from the same antenna mast.

Predominantly used at R/R sites, these systems enabled faster set-up and tear down time as well as reduced the physical footprint of the retrans site.

The R/R M1113 Highly Mobile Multi-Wheeled Vehicle tows a High Mobility Trailer carrying the 3KW generator and equipment. Experience has shown that the HMMWV is underpowered during cross-country and hill climbing operations when towing the trailer. The best HMMWV platform for this configuration would be the M1114, which provides greater lower end torque and horsepower. This configuration would ensure that R/R teams could tow the trailer up steep hilltops and through rugged terrain without significant power loss or requiring the trailer to be unhitched.

Follow-on SBCTs R/R vehicles should be replaced with Stryker Command Variants. The CV is the ideal platform because it provides more than adequate power, a redundant electrical system and external antenna ports for a retrans operation. The vehicle would solve the power problems, space constraints, eliminate trailer requirements and would embed a force protection capability that currently must be accomplished by infantry.

Overall the relay/retransmission vehicle in concept has proven its worth as a force multiplier for the brigade. The Stryker brigade retrans should be identified as a platform unique to transformation and acknowledged as a system of systems for follow on digitized units. Without it facilitating the EPLRS and NTDR network, providing retransmission of three FM nets and enhancing command and control, the brigade would be forced to employ a greater density of signal assets to accomplish same mission.

CNR (AN/PRC-148, AN/PRC-150, AN/PSC-5, AN/PRC-117F)

Combat Net Radio is the life-blood of any fighting force and the SBCT is no exception with over 1200 SINCGARs, 450 AN/PRC-148 MBITR, 78 AN/PRC-150, and 26 PSC-5c radios the brigade is arguably very well resourced. Throughout the deployment the brigade exercised every communications system available in order to accomplish the mission. Recommendations for improvements and additions are noted below.

AN/PRC-148 Multi-Band Inter-Intra Team Radio was fielded to the brigade as an enhancement to platoon, squad, and team operations. Originally fielded with 450 MBITRs the brigade quickly determined the flexibility and capability of the radio as a full spectrum communications device. Though the initial impression is the brigade has more than enough MBITRs to accomplish any mission; the non-contiguous and Civil Military Operation focus identified a shortfall in the distribution of the radios.

Each infantry battalion and the cavalry squadron were fielded approximately 95 radios each with the remaining balance being distributed among the BDE HHC, engineer and anti-tank companies. But because of the nature of operations, the field artillery and brigade support battalions conducted urban operations typically reserved for infantry units. In fact the FA BN was provided a battle space and mission virtually identical to the infantry and cavalry units organic to the brigade. With the addition of an engineer battalion and air cavalry squadron, it was obvious the brigade required additional MBITR assets. The brigade was approved by CJTF-7 to acquire an additional 250 radios for distribution to the engineer, air cavalry and field artillery battalions though production demands may preclude the brigade obtaining the radios prior to redeployment.

Future allocations of PRC-148 radios for SBCTs should be increased from 450 to 600 in order to facilitate the full spectrum capability of all combat units and attachments in a Stryker brigade.

Seventy-eight AN/PRC-150c Advanced High Frequency/Very High Frequency Tactical Radio Systems were fielded to the brigade. The distribution of these HF radios was predominantly in the cavalry, MICO and in each CV and TOC/ CPs. As a long-haul voice asset the brigade has used it with varying degrees of success. In Automatic Link Establishment mode the radio was extremely successful communicating in relatively small networks (battalion and below) though ALE was not practical as a command net for brigade wide communications.

When used as a digital transmission medium the HF radio was very reliable. By combining the HF radio with TacCHAT units were able to send data via serial mode at 9600 baud. Though not fast, the HF radio in this configuration provided data links to company and platoon out sites there were not within a typical MSE/IKSS SIPR footprint. The limiting factor with the HF radios was the availability of usable of frequencies for standard day/night operation. Though daytime frequencies were plentiful evening frequencies were a premium and unless on ALE mode, largely unusable. The brigade must obtain a reliable HF/ VHF propagation program for HF frequencies on a global terrain database.

The traditional workhorse for the Army, the AN/PSC-5 Spitfire, continues to be one of the most beneficial long haul voice and data assets for the brigade. With 26 Spitfires assigned to the brigade (a majority assigned to the cavalry and MICO) their utility was foremost in maintaining tactical voice communications with outlying units. Though used in limited form for data transmission the Spitfire was predominately used for voice traffic between BNs and the BDE in addition to communicating to higher. The most glaring issue was the lack of useable wide-band 25 KHz channels theater wide. Though the original SA and Information Exchange Requirements for Spitfire depicted channels for command, intelligence and fires, the brigade was only able to retain two 5 KHz (one ANDVT, one DAMA) channels for operations. Both channels were virtually unusable for clear-voice traffic and one channel did not possess a take off angle that facilitated using the SATCOM On-the-Move system installed on selected CVs (above 21 degrees). Neither channel was used for data transfer. An additional problem, though directly related to the radio, was the distribution of the radios in the brigade. Once again as with the PRC-148 the BSB, FA, engineer and attached units were not fielded a Spitfire radio. The brigade cross leveled PSC-5s internally to ensure all units possessed the capability to communicate via S/C TACSAT, though the availability of antennas and radios necessitated providing two units PRC-148s (for operation in SATCOM mode) and low gain antennas acquired from depot stockage. Future SBCT must be fielded this capability throughout the brigade in all battalions and separate companies.

The AN/PRC-117F Multi-Band Radio (Falcon II) was not fielded to the brigade but throughout deployment numerous agencies (OGA, Air Force, SF) elements possessed the radio. The brigade immediately recognized this radios flexibility and reliability in integrating with SATCOM, SINCGARS and HF (30-512 MHz) frequencies. The brigade requires such a radio for its multi-band capabilities and multi-use as a single communications platform for CNR operations.

Much like the PRC-148, the Falcon II should be developed as the communications platform of choice to replace the PSC-5 and HF platforms in follow on SBCTs and transformation efforts. An added benefit of the PRC-117F radio is the availability of the High Performance Waveform which provides an Microsoft Outlook based email waveform enabling files up to 3 Mbs to be easily transferred between another 117F. Had the brigade possessed such a radio the numerous company level FOBs in the AO could have possessed the ability to send and receive large data, imagery and presentation-based files. In an effort to address this requirement the brigade is pursuing the procurement of PRC-117F radios in addition to facilitating, in the short term, companies with a ViaSat PCMCIA data controller card for use with the PRC-150 radio and a laptop.

Other CNR enablers

Throughout the course of deployment the brigade is constantly searching out new and improved systems to enhance combat operations and signal communications. Below are some of the signal initiatives we have researched and implemented.

Television Equipment Associates provides tactical headsets, microphones and lower cords sets. Their equipment is extremely durable and an unsurpassed improvement of communications systems associated with CVC and MICH as well as dismounted radio systems. Recommended selections are Lash II throat mics, dual cord with integrated PTT for two radios, INVISO bone mics and Lite II headsets (noise cancellation and ambient reduction).

ABP PP 6224 Power converters are standalone power converters that facilitates dismounting of multiple connections. The brigade remotes complete FM (VAA), GPS, FBCB2, HF, PSC-5 and other 12 or 24-volt mil standard systems from shelters into hardstand environments.

Power spikes are minimized and equipment is protected by soft startup/shutdown characteristics. These power converters are the systems of choice for all C4ISR equipment dismounted and remoted in the brigade.

The INMARSAT Mini NERA sat-phone is a small-lightweight phone the brigade is using for COMSEC up/download to battalions through a STE. By successfully passing COMSEC via STE and INMARSAT soldiers and equipment are not placed at risk by traveling to a central location for COMSEC issue.

ABCS hardware/software

The Army Battle Command System in the brigade is comprised of Maneuver Control System, All Source Analysis System, Advanced Field Artillery Tactical Data System, Air and Missile Defense Workstation, Combat Service Support Control System and Digital Topographic Support System. "Light" versions of MCS and ASAS running a Windows 2000 platform are distributed as 36 MCS-L and 13 ASAS-L down to the battalion level and in some cases separate companies. Over all the "light" versions of MCS and ASAS have been the platforms of choice for their flexibility, size, common OS and capacity for peripheral attachment. The brigade deployed with the following software baseline under ABCS Version 6.3.4:

AFATDS: 6.3.1 8-12K_SP4

AMDWS: 2.0.6.3

ASAS-RWS: 6.3.2.5.1_P5

ASAS-L: 6.3.2.4_P10.5.4

DTSS: 8.0/8.0.5.0

FBCB2: 3.5.4

IMETS: 6.2.3 Bld 11_P4

Map Server: 1.2.0.0

MCS: 6.3.3.2_P2

CS-L: 6.3.3.2_P6

TIMS: 2.5.2.0

MDR: Exch/SQL/Win 2000

Though the brigade was guaranteed that additional software fielding would be suspended once in country, the proliferation of MCS-L, ASAS-L and AFATDS in theater forced upgrades to two specific platforms. AFATDS was upgraded to 6.3.2 under 6.3.4 to facilitate inter theater communications with AFATDS systems in the brigade. The second was an upgrade to ASAS-L from P10.5.4 to P10.5.5 as a means to share a common server database throughout theater.

This upgrade, though guaranteed to work by the PM did not meet expectations and is currently being re-engineered for theater-wide use. The failure of this patch has not precluded the ASAS-L from accomplishing its function at the brigade level. Finally an upgrade of FBCB2 from 3.5.4 to 3.5.5 was initiated by theater though the brigade declined this upgrade primarily due to a lack of value added of the patch and the premise of the software was to improve theater visibility of FBCB2 rather than improve the brigade internal. Upgrading FBCB2 software, while easy to implement for the relatively few platforms in theater synchronized with rotating units and Stay Behind Equipment, upgrading over 700 platforms in the brigade was not operationally feasible.

The utility of ABCS software has been minimal at best. With the proliferation of email and file servers in the brigade, the messaging and collaboration suites in ABCS have gone largely unused. In fact the primary function of much of the ABCS systems is to leverage the TOC server functionality and maintain SA. Most of the ABCS suites and hardware are being used as standard 'SECRET' laptop computers for access to email and SIPRNET. The brigade never used CSSCS, now defunct as a system. In general ABCS software provides the user an extreme amount of unnecessary functionality. As with FBCB2, Unit Task Reorganization is so complicated, it has never been attempted as a synchronized action. ABCS messaging is too inflexible in its inability to communicate with external unit messaging protocols.

The brigade has embraced email as the messaging of choice over anything inherent in ABCS. Though initially touted as a collaborative software package, and after a significant amount of training and "fanfare" the collaborative nature of ABCS has never been realized. Instead the brigade has found MercChat and Microsoft Net meeting as far better alternatives for collaboration and file sharing. ABCS has no inherent Information Assurance functionality or plan and password control is non-existent.

Some systems use the generic administrator account with no password; others do not allow users to configure passwords (this is a larger issue than just ABCS, it encompasses FBCB2 and BFT as well). Security patches and IAVA updates cannot be done in a timely manner due to PM directives for what and when they can be loaded on their systems. As a result a majority of these systems remain vulnerable in the interim.

The brigade S6 has attempted for years to rectify this with the PM, and has resorted to updating the Antivirus signatures. While there is a list of IA software associated with ABCS, none of the software has been configured to function, nor is there an ABCS master IA resource server to activate remote perimeter protection.

Though there are numerous issues with ABCS systems, certain individual systems can be highlighted.

AFATDS continues to be a success for the brigade in providing situational awareness as well as in indirect, counter-mortar and radar acquisition modes/roles. Interfacing with AN/TPQ-36 and 37 radars the AFATDS provided a power tool to the commander to accurately track frequent mortar attacks in the city of Mosul. During operations in Samarra the brigade used the rapid acquisition interleaved with AFATDS fire mission execution and clearance of fires to rapidly conduct indirect fire missions as well as Harassment & Interdiction fires.

ASAS as a system has never had the intuitive red picture and spot report corroboration that was touted throughout the brigade's training and deployment. Frequently assumed to be a training issue, deployment has shown that the software is the primary problem.

There is no true "active" database from which deconfliction of spot reports, enemy link diagrams and nested threat matrixes can be accessed. ASAS-L has primarily been used as tool for analyzing information, not collaboration, facilitating a decision or recommendation to the commander.

DTSS and the map server has been a significant enhancement to the brigade. It is probably the most used ABCS component to providing usable products and information to ground forces. Throughout the deployment DTSS has provided imagery, map data and city sector information for urban operations. Frequently the imagery accessed and modified by DTSS has been loaded on a MDL and provided to unit FBCB2s with specific responsibilities within city/town locales. While the brigade received attachments and unique missions the DTSS team provided maps, route/ convoy information and graphical building numbering schemes that enhanced logistics, communications and operational planning and execution.

One issue with the DTSS is its designation as a "non-standard" TOC platform. This designation has created some issues with maintenance and service. Because the DTSS platform and components are associated with MANTECH Corp, the contractors assigned to the brigade were frequently unable to work on the shelter or its systems. The DTSS must be re-aligned under a common service contract in order to better facilitate software/hardware sustainment and maintenance (PM TOCS/Platforms).

MCS, MCS-Heavy, originally designed as both a server and user workstation, is moving more and more into a server only role, with the MCS-Light picking up the "workstation" portion of the functions. The MCS has a critical role as server, and so it was based on the Solarix (Unix) operating system.

However, its ease of use is greatly surpassed by that of the MCS Light, as soldiers are often already familiar with MS Windows [TM]and MS Office [TM] At the BDE Main, a second workstation is used as a cross check on live feed and an additional display, and in past has been used as a repository for the data transfer of overlays. Some units still use the MCS WS for messaging, since it's a central system that is almost always up. In rare cases the Send Plan capability is still used. A plan can be sent directly to another MCS Heavy or ABCS Unix based system with notification, such as AFATDS. Again, only in rare cases, as the preferred SOP is to place MCS-Light .xml files on the (non-ABCS) BDE web page for download.

As mentioned earlier, MCS-Light is used in more staff sections across the brigade than in the past, and it is valued for its flexibility. Brigade purchased extra laptops to accommodate the additional requests and attachment of "non-digital" units. It is used for most all workstation tasks: maps and overlays, messaging, live feed, presentations, orders and more. It has been added to the MICO, BDE S-4, S2 sections, and to units augmenting the BDE such as Civil Affairs, ALO and the Air CAV liaison.

Due to the compatibility with C2PC (though the brigade doesn't maintain C2PC organically) and other map/graphical software extensions several sections have added software to the "Light" platform, for example Falcon View. The addition of software on some of these systems can cause unpredictable software conflicts, though the significant ones have been resolved. Note that part of the reason for the addition is that the two systems are not able to pass overlay data readily, which has caused extra work for battle captains and planners. There are also interoperability issues with DTSS overlays, and to a lesser extent with C2PC overlays.

MCS Light, while providing an easier interface to plan creation and upload, is not being used to post plans to the MCS web page as a single compressed file. Documents and overlays are passed as individual files, posted to the BDE web page.

Prior to deployment the brigade was fielded a Message Data Replicator. The MDR was provided as a means to exchange friendly unit data between ABCS and GCCS-A/J. Its usage has been limited, in part due to its newness and late date of introduction. The bottom up brigade internal feed has been more important to the higher headquarters than the top down theater feed to the brigade. While theater level is interested in the whole picture, the brigade needs to focus on individual COE/MOOTW operations, which are often isolated from other units. Only in one case where visibility of BFT (only) equipped units has been required has the top down feed been requested.

Overall the MDR has performed well and was exactly what the brigade required to interface with CJTF-7 vice the more complex and "top heavy" Digital Bridge that was initially proposed as the element designed to link SBCT and an "analog" higher headquarters.

Tactical Internet Manager, aka ISYSCON (V)4; was fielded to the brigade as the network management tool for battalion and brigade signalers to maintain and manage the tactical network. To date the functionality and usability of TIMs has been essentially useless to Signal officers and Soldiers. The original concept was to provide a single management platform for monitoring, tracking, configuring and troubleshooting the tactical internet. Currently, TIMs is only being used as a SA platform for signal sections, not as a management platform. As far back as April 2003 the brigade identified the shortfalls of TIMs to project managers with recommendations to improve upon it.

Recommendations encompassed:

(1) Improving the planning function on TIMs to include improved LOS profiling, map overlays,

(2) incorporate existing radio systems in the brigade to the planning tools,

(3) develop easily configurable router scripts,

(4) include a network mapping program that is intuitive and comprehensive that does not require a significant amount of training to master (What's Up Gold, though good, is not ideal for management),

(5) the Unit Task Organization and Unit Task Reorganization function is difficult to execute and configure and never has been used. To date none of these recommendation have ever been accepted or implemented. As a direct result, virtually no one in the brigade uses TIMs, choosing to use other commercially available network management systems. It is important to note that the brigade has tried to integrate TIMs and incorporate it as recommended by the developers; but time and time again the brigade has found it lacks functionality and flexibility.

The brigade network is inflexible and static enough without a management terminal that perpetuates it. TIMs is viewed as a system that was forced upon the brigade as a management enabler that had to be used in its current form. Network managers in the brigade feel that TIMs need to be completely redesigned or discarded as a program. Transformation and the migration to COTs network solutions should be managed by an industry accepted management solution rather than a GOTs developed "stovepipe" terminal.

Finally, ABCS and the software suite should be reassessed for its utility. It must be understood that ABCS (or a like system) needs to address the needs of the commander and not be enabled with functions and capabilities that are "nice to have" and largely not necessary. Anything that does not immediately improve the ability for the commander to make decisions or execute battle command faster or with additional clarity is not necessary (FBCB2 is a prime example of providing value added). Software that requires in-depth training or configuration for an added benefit usually results in the software not being used to the fullest extent. The general consensus is if management systems work in the civilian sector and is widely accepted then it is probably adequate for military use (i.e. Windows, Outlook, etc.). The military community should not continually attempt to re-invent the "wheel" in regards to digital systems.

Network General

SBCT networks need to be completely stand-alone. Each SBCT needs its own permanently assigned Autonomous System Number and IP addressing, not associated with any other organization. This would have greatly enhanced the brigade's ability to join the network in theater. The theater routing protocol (EIGRP) was not inherent to the brigade's internal OSPF-based protocol. Because of limitations of the lower T/I routing equipment and INCs (which requires smaller routing tables and updates) the brigade was forced to quickly, without testing, come up with filters and access-lists to limit the amount of routing updates allowed to reach the lower T/I. Initially upon deployment the theater was operating EIGRP protocol for all routers. The brigade built filters and ACLs to accommodate the theater network. Problems occurred when the theater changed routing protocol in conjunction with a change of theater signal assets. When this change occurred the SBCT network became a part of the large theater (WAN) OSPF Area '0' which resulted in a loss of lower T/I feeds to battalion TOCs. The primary cause was the limitations of the Internet Network Control cards to process the entire theater's IP routing tables. This configuration did not allow filtering due to limitations of OSPF. The significant lesson learned is that all SBCT external network connections should be via Border Gateway Protocol. Had this been the case, changes in the theater network would not have adversely effected the brigade's routing. An added benefit to incorporating BGP gateways is network managers would only require proficiency on one internal and one external routing protocol.

Additionally, STEP site connections also require BGP, which would allow the brigade to quickly connect to the DISA networks in a less mature theater.

The SBCT needs a Microsoft Exchange Server, associated domain controllers and web server to effectively communicate with Non-ABCS units. NAV server, SUS server for SIPR and NIPR could alleviate the workload from 74Bs and Signal officers at battalion level.

Given theater load and stateside problems with servers Army Knowledge Online and AKO-S proved reliable only when network conditions were perfect. Local servers would limit inter-theater traffic, as well as allowing the unit to effect IAVA and anti-virus updates in an efficient manner. SIPR email traffic was over 75 percent from brigade to brigade. Using AKO-S email adds what should be, internal traffic to already congested inter-theater communications links.

Each SBCT needs a permanently registered domain on SIPR, for quick connection anywhere in the world. The DNS servers and mail servers addresses need to be registered prior to deployment. The current structure of brigades falling under division and corps domains are not realistic and in many cases (bde3.id2.c1.army.smil.mil) could result in DNS and exchange server addressing changes occurring to frequently to be practical. Division and corps are not likely to deploy with SBCTs. A separate unit that falls directly underneath a different higher command can register as a subordinate of that organization. However, as in our case, changing higher commands multiple times leaves the network admin without a good solution. In fact the normal naming of our unit under the control of 4ID would be bde3.id4.c3.army.smil.mil. The issue there is 4ID already has a 3rd Brigade. Not to mention the fact III Corps was not deployed. The brigade then fell under the control of 101st ABN Div and MND North within months. This would have forced the brigade to change domain names (as well as all associated systems) four times from deployment to the current date. Another possible option was to register directly under CJTF-7. Realizing that c5.army.smil.mil would be replaced with the change over to III Corps, the solution from the brigade, was to register the domain sbct1.army.smil.mil directly. This solution disregards the hierarchical design of DNS, but provided the most logical solution.

Procedures: Contractors/Support

CTSF-STRYKER deployed a 31-person team (Team Blue) in support of 3/2 SBCT's deployment to Iraq and continues that support as it conducts combat and CMO operations in its AOR. CTSF-STRYKER has literally been a part of the brigade's training, sustainment and maintenance of its C4I systems through numerous local training events, CERTEX I and II at NTC and JRTC, culminating with deployment to Iraq. The composition of CTSF-STRYKER personnel encompass the full range of equipment in the brigade and representation from a majority of project managers; not just C4I equipment. Team Blue deployed with the brigade and was immediately integrated as a component of the Arrowhead Team. The contractors worked, lived, conducted convoys and battlefield circulation throughout the brigade's AO from Udari to Samarra and eventually in Mosul. Without the support of the CTSF-STRYKER team the brigade's systems would have some significant logistical challenges (evacuation of systems) as well as engineering challenges with attached units. Though the perceived size of the C4I contractor support may seem large, they are in fact a huge combat multiplier for the brigade. Team Blue deployed as a completely self-supportive entity with multiple vehicles, hard drive replicators, tentage, power generation and all classes of supply and repair save for POL. CTSF-STRYKER possesses a duplicate set of communications to mirror the brigades automation systems as well a internet reach assets.

CTSF-STRYKER operates from a brigade help desk that is manned by Brigade S6 personnel and 74Bs from the signal company. Trouble tickets called in or emailed, logged from battalions by the help desk and triaged by the Soldiers and CTSF personnel. If the problem cannot be rectified on the phone the contractors coordinate with the S6 and S3 to move with a convoy to resolve the problem at the battalion. Travel is accomplished in a fleet of up-armored HMMWVs maintained by the contractors, Strykers or in extreme cases via helicopter.

Upon closing upon Mosul the CTSF-STRYKER team consolidated from 31 to 21 contractors. This was in response to the reduced reliance by the brigade on the contractors in addition to a steady decline of trouble tickets throughout the deployment. The revised composition of the team included two field engineers, two PM TOC personnel, two FBCB2 engineers, PM TRCS, CECOM, PM Platforms, AFATDS, ASAS and CSSCS engineers; these personnel were split between the brigade TOC and the BSB. This established a split base operation where help desk operations were executed from the brigade TOC and logistics and part evacuation was accomplished at the logistics hub in Mosul.

Early in the pre-deployment of the brigade Team Blue was directed to support C4ISR ASL for the brigade ant thus does all the shipping, packing and repair for those items. They are triaged by skilled FSRs and use a GD repairman with parts pallet positioned at the BSB to materially aid this process. This support falls in line with a small logistic footprint forward concept of the brigade whereas CTSF possess a large number of support links (material and software) throughout the AO as well as CTSF-Fort Hood in the United States. The CTSF-STRYKER team provides greater logistic C4ISR support structure that is solely focused on the brigade as well as the expertise of engineers and technicians. More than 1,500 trouble tickets were opened and successfully closed in Udari prior to moving into Iraq and the total number in Iraq more than six months was 600. The daily averages of open trouble tickets in the brigade typically are under 20 and are almost exclusively open because of parts availability.

As transformation progresses and Soldiers begin to receive digital training from AIT throughout their careers the reliance on support from contractors will diminish (much like MSE), until then, support from C4I CTSF-STRYKER will continue to be a reality. Team Blue's support to the brigade has been phenomenal and a significant combat multiplier during the initial phases of deployment. Even today contractor support has streamlined at all echelons of triage, troubleshooting, evacuation, receipt and reach logistical support. The contractor support concept as devised by CTSF-STRYKER is a clear model for all other SBCTs in training or deployment.

COMSEC

Though the brigade is arguably the best trained and resourced combat force in the history of the Army, COMSEC operations in deployment was not adequately addressed in any train up to deployment. For garrison operations there was only one Soldier (74C40) assigned to run the COMSEC account. The SBC6T COMSEC account is responsible for more than 800 lines of COMSEC key ranging from FOUO to Top Secret. Accounts of this size normally have one each: Warrant Officer, one each: Skill Level 4 NCO, and two each Skill Level 10 Soldiers assigned full time. There were several Soldiers identified on paper as being alternate COMSEC custodians but they were otherwise performing their primary duties based off the MTOE. Mathematically, the bodies were simply not available to effectively operate/ deploy the account. Several DART submissions addressed this personnel shortfall though to date the MTOE has yet to be adjusted to reflect the enormity of COMSEC responsibilities for one Soldier.

The deployability of the LCMS based account was also another issue that raised concerns. Lessons learned from previously deployed units proved that the LCMS system did not perform properly in a tactical environment. Consequently, the decision was made not to deploy the LCMS. This decision resulted in the requirement to leave the only fully trained COMSEC custodian (74C40) at Fort Lewis with the actual account. A plan was devised to conduct a split-based operation with alternate COMSEC custodians executing a select portion of the deployed account (SMART-T with one alternate, CNR with another, etc.).

Each alternate would manage a specific set of keys. The plan was to deploy the brigade with an adequate supply of key material until COMSEC support could be established in theater. All future key, unique to the brigade would be DCS'd or electronically transferred from the Fort Lewis account to the forward based account.

Upon arrival into theater, it quickly became evident that the multiple alternate custodian concept was not going to work. Different methodologies and a lack of deployed COMSEC procedures made the operation and accountability of the forward based account a management challenge for all concerned. There was not a central figurehead on the ground that was maintaining centralized control of COMSEC key loading, issuing, ordering or destruction.

Within two weeks of deployment a collective decision was made to appoint a sole individual as the alternate COMSEC custodian. The management and operation of the account would be the responsibility of that sole individual. Unfortunately the responsibility of COMSEC custodian was passed to the BDE S6 251A (CW2) and was a net loss to the brigade's information operations but a gain for the brigade COMSEC operations. The operation of the account improved significantly once the change was implemented.

A subsequent challenge that arose was the distribution of key material to the battalions within the SBCT. The AOR for the SBCT is spread over distances that require convoy operations to get to and from the BDE TOC (where the COMSEC Vault is located). A TTP was established which would require the local elements to convoy to the BDE TOC for COMSEC issue. This was followed by establishing set dates for COMSEC issue in order to provide the local elements ample time to coordinate and assemble their convoys. An alternate method for issuing key material was the process of electronically transferring the key via STU-III or STE. Thus far, the code has not been broken in order to successfully transfer key material through the existing network structure within the SBCT. The brigade is working to purchase nine each INMARSAT phones in order to by-bass the existing network architecture and transfer the data directly from STE to STE via INMARSAT. This method has been very successful for electronically transferring key material from the rear-based account to the forward-based account in theater; recommend that all SBCTs be issued INMARSAT phones down to the battalion level for issuing COMSEC during deployment.

The SBCT COMSEC account has been self-sustaining with little or no assistance from external accounts or higher headquarters. The majority of the required KEYMAT has been either DCS'd, hand-carried, or otherwise electronically transferred from the rear-based account. Prior to assuming occupation of FOB Freedom (Mosul) from the 101st Airborne Division, it was understood that MND-N would be the higher headquarters for the SBCT. MND-N arrived without a COMSEC account, COMSEC custodian or Frequency Manager. The responsibility for providing key for all units within MND-N AOR, to include MND-N Headquarters as well, fell on the shoulders of the brigade. The successful operation of the COMSEC account has been maintained but if the unit base continues to grow as trends are indicating, it is imperative that MND-N establish an account in order to strain on the SBCT.

It is recommended that all future SBCTs have a higher headquarters identified prior to deployment and that proper coordination takes place to identify shortcomings prior to execution.

Overall, the operation of the COMSEC account continues to evolve and improve as lessons are learned. Considering that this is the first time that the SBCT has deployed its COMSEC account on a real-world or training mission the execution of COMSEC operations has been very successful.

Conclusion

The communications and network architecture evolves as the brigade continues to conduct combat operations in Iraq. Attachments, detachments and changes in mission sets drive the continuous assessment of the communications network. Much like any other signal organization the primary signal mission remains the same "Support combatant commander's scheme of maneuver and intent."

Though the brigade has been immensely successful in employing and sustaining a digital network it has not been easy. Vigilance is a essential in the Network Operations Security Center to ensure that the brigade can effectively pass ABCS, FBCB2, relevant information, video, voice, data, SIPRNET and NIPRNET at all times. With so many individual networks, some meshed together, others "stove piped" making changes in the architecture typically results in secondary and tertiary cascading effects much of which cannot be anticipated. The brigade is writing the book on transformation, the S6s and the Signal Company are writing the future of Objective Force communications. Digitization and the nature of the systems fielded to the brigade have resulted in a "self discovery" of sorts with what does and does not work and what need improvement. Though conceptually sound and seamless in its genesis, the brigade architecture is nowhere near the modular, scalable and integrated system it was designed to be.

The SBCT signal concept works. At times systems seem to have been "forced" upon the brigade for use and integration when other simpler solutions would have obtained the same result. The O&O of the brigade has been realized but in combat the question generated was, "Is the rest of the Army ready for transformation?" From a signal standpoint the answenot quite." The community understands this as evident of the numerous ABCS, BFT and transformation initiatives that were rapidly fielded into Afghanistan and Iraq for "analog" units. The density of these systems in theater assisted in the brigade's integration with other units, though the IP based WAN architecture of the brigade remains the difficult component to integration.

Finally, the most important component to facilitating the brigade's communications are the Soldiers. The Signal company and the brigade S6 foster a unique operational and command relationship. Structured where the Signal company commander is the NOSC OIC and assists the brigade S6 in operational planning, and the S6 directs plans and operations; the relationship between the two officers is paramount to success. More often than not the organizational division of the Signal company (and its Soldiers) and the brigade S6 is nonexistent which enhances the teamwork and mission accomplish. Ownership of the brigade communications plan from the brigade down to the individual operators is the lynchpin to operational success.

Overall the brigade's communications architecture is working and working better than anyone had ever truly expected. As stated at the beginning of this assessment, the brigade was built on the Stryker Infantry Carrier Vehicle, and is enjoying unparalleled success as the premier fighting vehicle in Iraq. But the digital heartbeat, the C2 enabler is all Signal transformation, transformation that is ... digitally deployed.

DEFINITION

TRACNET--Isolation of the EPLRS network where only radios in that network can provide SA and messaging services internal to that group.

ACRONYM QUICKSCAN

ABCS--Army Battle Command Systems

ABN--Airborne

AD--Armored Division

ADVON--Advanced Echelon

AES--Advanced Encryption Standard

AFATDS--Advanced Field Artillery Tactical Data System

AI--Actionable intelligence

AI--areas of interest

AIL--Allowable Input Link

AKO-S--Army Knowledge Online-SIPRNET

ALD--Authorized Load Date

ALE--Auto Link Establishment

AMDWS--Air and Missile Defense Workstation

ANDVT--Advanced Narrowband Digital Voice Terminal

AO--Area of Operation

ASAS--All Source Analysis System

ASAS-L--All Source Analysis System-Light

ASN--Autonomous System Number

ATM-SEN--Asynchronous Transfer Mode Small Extension Node

BCBL(G)--CCommand Battle Lab-Fort Gordon

BCC--Brigade Coordination Cell

BCT--Brigade Combat Team

BFT--Blue Force Tracker

BGP--Border Gateway Protocol

BLOS--Beyond-Line-of-Sight

BRSS--Brigade Remote Subscriber System

BSB--brigade support battalion

BSN--Brigade Subscriber Nodes

C2--command and control

C4I--Command, Control, Computers, Communications and Intelligence

CA--Civil Affairs

CECOM LAR--Communications Electronics Command Logistics Assistance Representative

CERTEX I--Certification Exercise I

CFLCC--Coalition Forces Land Combatant Commander

CJTF-7--Coalition Joint Task Force-7

CMO--Civil Military Operations

CNR--Combat Net Radio

COA--Course of Action

COE--Contemporary Operating Environment

COMMEX--Communications Exercise

COMSEC--Communications Security

COP--Common Operational Picture

COTS--commercial-off-the-shelf

CP--command post

CSC--Convoy Support Centers

CSMA--Carrier Sense Multiple Access

CSSCS--Combat Service Support Control System

CTC--Combined Arms Training Center

CTCP--Combat Training Command Post

CTSF--Consolidated Training Support Facility

CV--Command Variant

CVC--Combat Vehicle Crew

DAMA--Demand

DC2R--Digital Command and Control Rehearsal

DC--Direct Current

DISA--Defense Information Systems Agency

DKETS--Deployable Ku Band Earth Terminal

DNS--Delta Network System

DTG--Digital Transmission Group

DTSS--Digital Topographic Support System

EETGMO--Extended Range Enhanced Trunk Group Modular Oderwire

EIGRP--Enhanced Internet Gatway Routing Protocol

ENM--EPLRS Network Management

EPLRS--Enhanced Position Location and reporting System

FBCB2--Force XXI Battle Command Brigade and Below

FEC--Forward Error Correction

FIPR--Flash Immediate Priority Routine

FM--frequency modulation

FMC--FBCB2 network connectivity

FOB--Forward Operating Base

FRAGO--Fragmentary Order

FXO--Field Exchange Officer

FXS--Field Exchange Service

GAC--ground assault convoy

GBS--Global Broadcasting System

GD-FEC--General Dynamics-Foward Error Correction

GRU--Grid Reference Unit

GUI--Graphical User Interface

HC-LOS--High Capacity Line-of-Sight

HDR--High Data Rate

H&I--Harassment & Interdiction

HMMWV--Highly Mobile Multi-Wheeled Vehicle

HMT--High Mobility Trailer

HPW--High Performance Waveform

HQ DA--Headquarters Department of the Army

IA--Information Assurance

IAVA--Information Assurance and Vulnerability Assessment

ICV--Infantry Carrier Vehicle

IER--Information Exchange Requirements

IKEK--Integrated Key Encryption Key

IKSS--Initial Ku Satellite System

INC--Internet Network Control

INE--In Line Encryptor

INMARSAT--International Maritime Satellite

JRTC--Joint Readiness Training Center

JTRS--Joint Tactical Radio System

KEYMAT--Key Material

LAN--Local Area Network

LCMS--Local COMSEC Management System

LCN--Logical Channel Number

MCPT-I--MILSTAR Communications Planning Terminal-Integrated

MDL--Mission Data Loader

MDR--Message Data Replicator

MBITR--Multi-Band Inter-Intra Team Radio

MCS--Manuever Control System

MICH--Modular Integrated Communications Helemet

MICO--Military Intelligence Company

MILID--Military ID

MILSTAR--Military Strategic and Tactical Relay

MNB-N--Multi-National Brigade North

MND--Multinational Division

MPT--Medium Power Transmitter

MRT--Master Reference Terminals

MSE--Mobile Subscriber Equipment

MTOE--Modified Table of Equipment

NAV--Network Allocation Vector

NCF--Non-Compliant Forces

NCS--E-Network Control Station-EPLRS

NL--Needline

NMC--Non Mission Capable

NOC--Network Operations Center

NOC-V--Network Operations Center-Vehicle

NOSC--Network Operations Security Center

NTC--National Training Center

NTDR--Near Term Digital Radios

O&O--Operational and Organizational

OIC--officer in charge

ONS--Operational Needs Statement

OPORD--Operations Order

OR--Operational Readiness

OS--Operating System

OSPF--Open Shortest Path First

OTAR--Over the Air Re-key

PC MCIA--PC Card

PEO-C3T--Program Executive Office-Command, Control and Computers, Tactical

PDSS--Pre Deployment Site Surveys

PM--project managers

POL--Petroleum Oil Lubricants

PSYOPS--Psychological Operations

PVC--Permanent Virtual Circuits

QEAM--Quick Erect Antenna Mast

QRF--Quick Reaation Force

R/R--relay/retransmission

RO/RO--Roll On/Roll Off

RSID--Radio Set ID

RSO--reception, staging and onward movement

SA--Situational Awareness

SAR--Satellite Access Request

SATCOM--satellite communications

SBCT--Stryker Brigade Combat Team

SBE--stay behind equipment

SBU--Sensitive But Unclassified

SEP--Signal Entry Panel

SINCGARS--Single Channel and Air Radio Systems

SMART-T--Secure Mobile Anti-Jam Reliable Tactical-Terminal

SOP--Standard Operating Procedure

SOTM--SATCOM On-the-Move

SSS--Single Shelter Switch

STE--Secure Telephone Equipment

STEP--Strategic Tactical Entry Point

STU-III--Secure Telephone Unit III

SU--Situational Understanding

t/I--tactical Internet

TAC--Tactical

TEA--Television Equipment Associates

TDMA--Time Division Multiple Access

TFO--Task Force Olympia

TIM--Tactical Internet Manager

TIMS--Tactical Internet Manager System

TOA--Transfer of Authority

TOC--Tactical Operations Center

TRI-TAC--Tri-Service Communications System

TSN--Tactical Switch Node

TT--Traffic Terminals

TTP--tactics, techniques and procedures

UTO--Unit Task Organization

UTR--Unit Task Reorganization

VDTG--Virtual Digital Transmission Group

VOIP--Voice Over Internet Protocol

WAN--Wide Area Network

WMI--Windows Management Instrumentaion

WNW--Wideband Network Waveform

MAJ Fischer is executive officer of the 29th Signal Battalion stationed in Balad, Iraq. He served with the 3rd Brigade, 2nd Infantry Division (SBCT), brigade Signal officer on deployment in Iraq. Prior duty assignments were as the deputy chief, Team Signal--Fort Lewis, in support of the Brigade Coordination Cell where he assisted in the development of 3/2 SBCT signal systems and architecture. MAJ Fischer's other assignments include Squadron S6, 2/11 ACR and the Signal Observer/Controller for the Mechanized Trainers (Scorpions) at the National Training Center. He graduated from Santa Clara University, Calif., in 1990 as a Signal officer.

COPYRIGHT 2004 U.S. Army Signal Center
COPYRIGHT 2004 Gale Group