Hurricane Sandy: 10/30/2012 (Photo credit: ccho)
Guest Post by: Rakesh Bharania
Rakesh Bharania is an engineer with Cisco Tactical Operations (http://t.co/bYsKdQG). The opinions in this article do not represent Cisco)
My team and I recently returned from a deployment in the aftermath of Hurricane Sandy where we worked to support public safety and disaster relief NGOs in the states of New York and New Jersey. This storm, regardless of what you want to call it (“Superstorm” seemed to be a popular moniker in the media, since the storm technically wasn’t a hurricane when it made landfall) seemed to usher in a whole new wave of technology in disaster response, and I think it’s worth trying to capture a few observations while the memories are still fresh and the after-action-reports are yet to be written. So, a standard disclaimer applies: this is really my own opinion, and not those of my teammates, or my employer.
But let’s rewind a little bit: the real coming-out party for disaster networks, crowdsourced information and so on (“Disaster ICT”) was the January 2010 Haiti earthquake. Since the need was so urgent, and more importantly, there was nobody to say “no,” many new applications and technology architectures got their trial by fire in Haiti – it really was a real-life test lab for crowdsourcing, crisismapping, and hastily formed networks to a scale thereto unseen. But I think the experience of Haiti also had set up unreasonable expectations in the nascent disaster technology community: since so many people came to Disaster ICT as part of the Haiti response, the implicit assumption in many of their minds was that any future disaster was going to look like Haiti. But subsequent disasters in the United States and around the world has proved what I thought initially: Haiti was always the exception, rather than the rule regarding how disasters were responded to.
So given that you couldn’t just “cowboy it” like you did in Haiti, what was interesting and different about technology during the Hurricane Sandy response?
1. Empowerment. From the Occupy Sandy movement to Burners Without Borders to any number of tech NGOs on the ground, communications technology and specifically social media allowed groups to coordinate among themselves, engage those in need, and solicit donors in a near-realtime basis. We’d seen some of this before, of course, but the scale of this was quite impressive. The downside is that some of these organizations were relatively inexperienced with the deployment and support of emergency technology and unfortunately became more of a hindrance than a help to the overall response effort.
2. Significant deployment of Ka-Band VSATs. For the first time, I started to see a number of satellite deployments that were based on the Ka-band, as opposed to the more widely deployed Ku-band. The advantage of the Ka systems is that their bandwidths are higher (I saw systems that were able to get 10-15 MBps download speed) … but the open question we had was how stable were these systems going to be when it rained? Ka-band satellite data services are more suscepti ble to “rain fade”, which is attenuation that occurs due to rain or snow. Remember that a significant Nor’easter hit the same area Sandy did about a week after the latter storm rolled through. Disaster responders will no doubt be discussing the merits of the higher bandwidth Ka-band compared to the lower bandwidth but more reliable Ku-band in the coming months.
3. The rise of 4G LTE. Yes, there were outages of the cellular telephone network and we saw crews from Verizon and other wireless carriers working feverishly to restore service to areas that had been knocked out. But while we were working in Coney Island, we noticed that while the area had had no power since the storm struck, there was a very strong Verizon LTE network that was operational, and we would get up to 20 Mbps download, 7 Mbps upload speeds on average. That was more than enough for us to move public safety agencies to – and the VSATs we had just deployed were rapidly decommissioned in favor of LTE-based solutions that were cheaper, had less latency, and provided more bandwidth. While I can’t say our subjective experience was the same across the disaster area, I think we proved a valuable new tool in our disaster toolbox and will be happy to take it out again in future emergencies where it makes sense.
Rakesh deploying the VSAT in Coney Island.
4. Video really does change everything. I know that the social media experts are looking at how Instagram was the breakout sensation of the Sandy response, and maybe in the crowdsourced community, that remains true. (I’ll spare you a discussion about how Instagram’s “creative manipulations” actually make it less useful for emergencies for another time). However, we had one example of where a public safety problem was emerging and leadership at the emergency operations center had no understanding of the reality on the ground and therefore the right resources were not being assigned. We put cameras on the problem, shared the video via WebEx and once the commanders could actually see the problem, things were fixed within fifteen minutes. I think the future for video in emergency response, especially with the availability of higher bandwidth links looks very very good.
5. Tech For All: During Hurricane Katrina, I could see the evolution of technology underway (and this was in an age before smartphones!) where tech started off as something for headquarters-level leadership. The second phase of this evolution was getting tech into the hands of responders in the field. I would argue that we are largely in the middle of this phase of the transition. The last phase, emerging and where we saw a lot of progress during Sandy, was in getting tech into the hands of the survivors of the disaster so that they could communicate with friends and loved ones, apply for disaster assistance, etc.
Wait, I’m kinda lying about the linear progression of this sequence. Yes, we have technology largely at the headquarters/EOC level. And we are working on the second part – getting tech into the hands of the responders. But the truth is that the last part – technology in the hands of the disaster public, already exists. The growth of mobile technology, smartphones and tablets and the whole Bring Your Own Device (BYOD) has largely empowered those communities that have access to those technologies. This is something I didn’t see in 2005 – the “consumerization” of technology has empowered disaster survivors in a really meaningful way. We as the emergency response community do not have to figure out how to get endpoints into the hands of disaster survivors – BYOD has taken care of that for us. What we need to sometimes solve for is how to get them connectivity – a different problem. It’s really Bring Your Own Device to the Disaster (BYODD). We still have to be mindful that this isn’t universal, and that communities with poorer access to technology and technology literacy might still need a hand … but Sandy hit a very tech-savvy population for the most part, with modern communications and technology readily available.
Yes, there were a number of challenges on the ground. These, in no particular order, were the ones I saw. None of them are insurmountable, and in many cases they’re to be expected considering this whole area is relatively new and certainly evolving at a ridiculous rate. We’ll get there, but it’d be nice if the community would have some further discussions around the following…
1. Sustainability. It’s one thing to deploy the latest tech toys in an emergency, but once you turn up the service (and sometimes that’s hard enough), relatively few organizations had any plans for supporting moves/adds/changes and were poorly equipped in gear and knowledge to sustain and support the things they’d deployed. Expert techs may be deployed for a limited amount of time – and then they go home …. what happens if something breaks at that point? Sometimes it is better to not deploy technology in the first place, than it is to deploy tech that can’t be supported or sustained over the duration.
2. Stop using FEMA’s name in vain! Several tech NGOs came to us looking for support on various projects, and a few would invariably name-drop “so-and-so at FEMA wants to see this happen…” If that’s true, show me the contract! Show me the accountability! As a tech company, we want to help, but we need to prioritize where we help. It’s basic triage. This kind of noise only makes our decision-making harder. And it creates the impression that FEMA itself is clueless (left hand doesn’t know what the right hand is doing) – which isn’t actually warranted by the situation. Don’t degrade your customer’s name and goodwill in order to enhance your own.
3. Coordinate On The Ground. If you are deploying a technology project, the coordinator for that project really needs to be on the ground and have “ground truth” about the need and the deployment. I saw several projects running astray because the primary coordinator was remote, and often there was a gap between what that person was telling us vs what the members of the project were telling us on the ground.
4. Wearing Different Hats is OK, But Be Clear About Which Hat You’re Wearing. There are only a few groups that do “disaster tech”, and it is not uncommon for them to collaborate with each other on larger efforts, or to act in concert with a governmental or other body. But it is vitally important to be clear which project or organization you’re affiliated with on a given project. If a group comes to me and asks for equipment and I give them equipment, I need to be clear that when two days later they’re asking for the same stuff again that it’s for a different project or a different context. Or worse yet, if work with two different groups on what appears to be the same project, but the groups themselves are approaching us independently of one another…
The response to Sandy shows that Internet communications is increasingly important for responder-to-responder, responder-to-public, and public-to-public communications. The rate of technology change is increasing, with the average mobile device (smartphone or tablet) being replaced about once every 16 months or so. So it’s important to plan for technology response using an all-hazards, all-methods approach that accommodates the fact that the technology, device, communications method, or application may change from day to day, or incident to incident. Technology in the Sandy response was largely successful, and learning from our experiences there will help set us all up for future success on the next disaster (and there is always a next one!)
I want to end this note with two points: firstly, “communications” are always about the message and never about the medium that message travels in. It is too easy for us as technologists to become enamored of our own technology, and miss opportunities to do it better, faster or cheaper. Remember that communicators, in and of themselves, have never saved a single life or restored a single community to health. Responders on the ground, working one-on-one with the survivors do that. And unless our fancy toys and blinking lights facilitates meaningful action on the ground, it’s just noise. Any “disaster tech” that doesn’t influence the reality on the ground is just trivia. Think about a brilliant, beautiful crisismap that is put together by lots of volunteers and is used by exactly nobody on the ground, for example.
My last point is this: even though we are technology first responders, and our chosen method of responding to the crisis is digital, we can never allow ourselves to forget that these are human emergencies that we are engaged in, not technological ones. We must lead with the basic human traits of compassion and empathy with regards to our fellow responders and the communities we are all trying to serve. Sometimes a hug delivered at the right moment is worth more than all the routers and switches in your truck.
Thanks to Rakesh for allowing me to share this with my readers!
idisaster 2.0 