The earthquake in Haiti was undoubtedly a tremendous human tragedy, and for communicators, it represented an enormous challenge to conduct operations on a truly combined basis. Operation Unified Response (OUR) provided a unique opportunity for data sharing between the Department of Defense, State Department, Haitian government, multinational military forces, civilian doctors from a multitude of nations, and non-governmental organizations (NGOs). All of these organizations required real-time, full mesh, two-way, mission-critical communications within a country whose communications infrastructure had just been decimated. This situation was exacerbated by the fact that the initial center of gravity for this operation was the USNS Comfort (T-AH 20), which was at anchor off the coast of Haiti, with very limited communications capabilities. This operation validated some of our preconceptions about multilateral communications and taught us some new lessons.
The immediate need upon arrival of USNS Comfort was to conduct medical triage for critically injured Haitians. During the first 10 days on station, a helicopter loaded with patients landed on Comfort at an average of every eight minutes. While the air traffic control tower and pilots are accustomed to talking to each other via radio, there remained the issue of tasking. An Air Tasking Order (ATO) was drafted nightly, but the reality was that as many as six mobile triage sites were set up daily to support 22 field hospitals. These triage sites were little more than an open area suitable to land a helicopter with a team consisting of a trauma doctor, expeditionary communications team and field security team.
The doctors on the ground, mostly from NGOs, were responsible for providing feedback to the operations center aboard Comfort which provided tasking to the helicopters via the tower. Although there were many NGOs taking part in OUR, Comfort primarily worked with nine of them providing medical support services.
The medical regulating control officer,a senior chief corpsman aboard Comfort, would direct the helicopter to the appropriate shore or sea-based hospital depending upon the medical needs of the patient and the availability of care at the hospital. This tasking included everything from medical evacuations (medevacs) and American citizen (AMCIT) evacuations to redeployment of triage teams, and distinguished visitors movements. This highly dynamic operational environment required timely and accurate communications with civilian and multinational military forces and NGOs, as well as a historical record of the operations.
Forget landlines; Haiti has none to speak of. Like many developing nations, Haiti's cellular infrastructure is far superior to its landline infrastructure. However, during the first week of OUR, the severely degraded cellular network was unable to meet the demand placed on it by the Haitians and the thousands of relief workers trying to coordinate a relief response. Landline phone calls routinely took 30 minutes or more to place, and more often than not, cellular-placed calls were dropped after a few minutes due to the heavy load on the cellular network.
Short message service (SMS) texts were the primary command and control (C2) channel in the first few days of the operation. SMS texts are short in length, provide a legal record (log), require very little bandwidth, and enable guaranteed delivery. These are the minimum standards required for any mission-critical C2 platform. More importantly, SMS uses open standards and requires no specialized equipment or software; anyone with a cell phone or Web browser can use it. Due to its positive attributes, SMS continued to be a primary C2 channel throughout the operation. From a strategic communications perspective, the networks used for SMS are viewed as communal so there was no perception that the United States or the Defense Department was attempting to “take over relief operations.”
Also, there were many challenges in attempting to use traditional military radio communications because of the lack of radios, batteries and chargers to meet the requirements of 22 field hospitals and the many NGOs, and because there was a concern among multinational partners and NGOs that the U.S. military would take control of the relief mission, military radio communications were used almost exclusively for flight and navigational safety.
Just as in most military operations, e-mail was a critical C2 application during OUR. One of the lessons learned, however, is that the Navy’s e-mail solutions were not as easy to access compared with commercial applications, such as Gmail or Hotmail, due to the rapid pace of mobilization, lack of infrastructure and high overhead involved with military communications.
The rapid mobilization (and subsequent turnover) of reservists, NGOs and other government organizations (OGOs) meant that even aboard ship, information technology departments had a hard time keeping up with the administrative overhead of creating and deleting accounts.
Administrative overhead includes: verifying that required information assurance training has been completed and that unauthorized group accounts are not created.
Truth-be-told, a lot of retroactive IA training occurred, and group accounts were created. Communications professionals understand acceptable risk and mission first. More difficult challenges occurred for Navy Marine Corps Intranet users and for those boots on ground.
Personnel with NMCI accounts encountered long delays in receiving e-mail forwarded to the ship. However, a more serious issue involved ground forces using Broadband Global Area Network (BGAN) or Very Small Aperture Terminal (VSAT) portable super high frequency (SHF) terminals. The problems were twofold: an insufficient number of Common Access Card readers and bandwidth availability.
The insufficient number of CAC readers meant that NMCI e-mail could not be accessed because secure access could only be obtained via log in with a CAC. Even if there had been a sufficient number of card readers, Outlook Web Access was prohibitively bandwidth intensive.
BlackBerry users were successful in sending and receiving e-mail once the cellular infrastructure returned to full capability, certainly, a critical means of communication for those fortunate enough to have them.
Chat While SMS worked well in the early days, as Internet service providers restored capability and BGAN and VSATs became more prevalent, chat and Web services became more widespread. SMS works well enough, but cell phones are not ergonomically designed for intensive continuous use nor are their screens large enough for optimized viewing for long periods of time. Additionally, SMS is not well suited for group collaboration.
U.S. Army Forces Command (FORSCOM) set up a Web-based chat that was available to anyone requesting an account. While having users that are not vetted is less than ideal for military operations, this Web-based chat allowed humanitarian assistance/disaster relief (HA/DR) operations to move more smoothly because it permitted access to a communications channel without the need to wait for IT personnel for connection.
In this case, the back-end software was Adobe AIR, but many products could have been as successful. The critical attributes of the tools that enabled success were: Web-based; open-standards using Jabber/XMPP; low bandwidth requirements; a log for an audit trail record; and open access enabled collaboration without the need for IT personnel intervention.
The Web-based nature of this chat version made it operating system agnostic. Users, regardless of whether they were using a Windows, Mac or Linux/Unix platform, could access the chat capability as long as they had a Web browser. Many cell phones have Jabber/XMPP clients so that was another connection option.
Using a nonproprietary open standard is a critical, but often overlooked, requirement. Incorporating an open standard frees users to choose their operating system and client. In other words, a change in vendors requires no additional overhead to remain compatible with the existing system. Allowing users to choose their own client actually reduces required bandwidth.
By allowing users to use the clients already installed on the platform of their choice, there is no need to re-download the Java-based client every time a connection is made, greatly reducing the connection time and bandwidth requirements for each client connection.
For several reasons, logging communications during these events became crucial. When communicating medical
information, it is essential that information is not misheard, garbled or otherwise misrepresented. By using chat over a TCP/IP connection, delivery is guaranteed and a historical record can be automatically created. Unlike voice, chat over TCP/IP auto-negotiates the next speaker/client so there is no concern that one party will “step on” the other.
Wikis Web services used included chat, wikis/portals and social media. Wikis and portals became the primary source for collaboration among the various groups. Wikis and portals are interactive Web pages that allow users to collaborate and post and share documents.
Read and post access can be controlled or uncontrolled on a page-by-page basis. As an example of role-based controls, Combined Task Group (CTG) 41.8 used a wiki that would allow anyone on Comfort to view information, but only watch floor personnel could edit information. Commander Task Force (CTF) 41 also used a wiki to post information and share documents.
A key to wiki success is the ease of use for authorized users to edit the information. For many wikis, editing content is as simple as clicking an “edit” button and typing using controls very similar to a word processor. In comparison with commercial wiki/portal capabilities, documents on Collaboration at Sea (CAS), a Navy-provided portal that rides the SIPRNET, are difficult to edit and maintain.
The wiki quickly became a hub for the most up-to-date medevac status, CONOPs, and other watchstander essential information. Four different wikis were used: media wiki (CTF 41); OS X wiki server (CTF 48.1); Google Groups (U.S. Southern Command); and Microsoft Sharepoint (Commander, U.S. Fourth Fleet).
The following characteristics helped make some wikis more useful than others: low bandwidth required, including for cell phone users; open standards; easy to use editing tools; searchable content; and online help. The Google Groups wiki became unusable due to both the number and size of the images that were used to “dress up” the site. But the Google Groups wiki functionality could have easily been fixed if the site were set up to limit the size of file attachments. Microsoft SharePoint proved unusable due to its high bandwidth requirements.
Individuals, commands, government agencies and NGOs used Twitter and Facebook extensively. While the use of Facebook and Twitter were resounding strategic communications successes, there were also some problems. The DoD has started using social media as a communications medium, and there are lessons to be learned from the OUR mission.
One such example involved a volunteer nurse embarked on Comfort. Having never been in an operational environment, the nurse posted an update on her Facebook page that was ill-informed and mischaracterized the conditions of treatment aboard Comfort. Her post quickly found its way to high levels of government, and quite a bit of effort was spent in the following days correcting the misinformation. While certainly not done out of malice, this unfortunate incident highlighted one of the operational dangers of social media.
Communications personnel aboard Comfort were greatly concerned about Facebook use due to limited bandwidth. While the bandwidth available was usually sufficient to support Comfort’s traditional mission, Comfort had more than 1,200 personnel aboard, including NGOs, volunteer doctors, Comfort’s medical staff, and a CTG staff.
The fears proved mostly unfounded, however. Users were briefed on acceptable Facebook usage and the network congestion that would result from excessive Internet use. While Facebook and Twitter usage had to be limited to nonpeak traffic hours, user awareness went a long way to reducing abuse and negatively affecting mission bandwidth.
The DoD is expanding its use of Web-based technologies, including wikis, chat and social media, but these technologies become truly powerful when they are combined into hybrid communications systems. Each of the aforementioned tools has their own strengths and weaknesses, but leveraging their strengths mitigates many of their weaknesses as communications tools.
To some extent, these tools attempt to shore up some of their own weaknesses. Twitter allows SMS messages to be used for updates (“tweets”) to individual accounts. Tweets can be submitted without a Web browser or specialized client. However, the number of cell phones that can be associated with a single account is limited. This limitation makes this capability less than ideal for a group or command account. How can this be solved? By using a hybrid system!
The Jabber/XMPP chat room option is fast, low bandwidth, and can be joined by virtually limitless users for collaboration. A weakness of chat, however, is that once a message scrolls off your screen, it may be lost unless you are logging all messages locally.
What if information that is posted in a chat room needs to be more permanently available? A hybrid system could be used so that information updated on one system (chat) could update information on another system (Twitter). A simple example would be to write an intelligent software agent that could look for key words or conditions and then use those entries to automatically update a Twitter or Facebook account.
For example, an important comment on chat might be that a medevac helicopter is down for maintenance. Certainly the helicopter maintenance officer would report that in chat, but if you weren’t logged onto chat, you might never know.
A tweet on a Twitter account is more permanent. Imagine that when the maintenance officer types this update into chat he precedes the update with “Tweet:”; this signals the software agent to automatically tweet everything after the colon. Now you have instantaneous updates for chat users and for users who are not in chat. Similarly, a software agent can scan for updates to a wiki and submit a tweet, chat message or SMS to notify all interested
Disaster relief efforts in Haiti provided a unique opportunity for data sharing among many disparate users. This unprecedented sharing of information validated some of our preconceptions about communications and taught us some new lessons.
In the most succinct form, here are the winners and losers:
• Vendor agnostic open-standard products;
• Jabber/XMPP chat;
• Social media;
• Low bandwidth applications; and
• Cell phone applications.
• Traditional military radio communications;
• Proprietary solutions;
• Bandwidth intensive applications;
• Bloated PowerPoint presentations;
• Large graphics files; and
• PKI-enabled e-mail.
I stopped at one of the larger field hospitals run by the U.S. Army that also included several NGOs. As I toured the hospital, I asked the colonel in charge about the hospital’s communications capability. She beamed and showed me a makeshift system supported by a BGAN terminal with eight computers on a network. In the makeshift command post, the following applications were on the screen: two Gmail accounts used by watchstanders, one FORSCOM Web-based chat, one Web browser with Web-based chat, one Google Groups account, three Facebook
accounts, one Twitter account and one Skype account. That hybrid of capabilities is a lesson learned and model for ad hoc communication and collaboration supporting future HA/DR operations.
Lt. Cmdr. Breuer is serving as the N6 on the COMDESRON 40 staff located at Naval Station