Overview
Many AREDN networks exist around the world and are built on the excellent firmware that the AREDN development team has created over the years. The Palo Alto AREDN network differs in a few ways from a traditional AREDN installation. In this section, we consider at the disaster scenarios that drive our thinking and the design objectives that follow from them.
Scenario thinking
The Palo Alto AREDN network is more than the physical equipment that conveys bits from point to point. It is a combination of that equipment, network-based services that suit the scenarios we train for, and the teams that both use and support the network. Our starting point is to agree on the scenarios. Our thinking has emerged from significant prior research related to emergency preparedness and recovery efforts and, particularly, where communications have helped or failed to help. Attempting to prepare for all emergency situations dilutes our focus, so we are selective. of the scenarios where efforts in improved communications are most highly leveraged.
Summary (details found here):
- Communications volunteers are more highly leveraged in big incidents than in small ones.
- Big incidents require specific training. In our case, earthquakes are a clear and present danger. We should build and train for earthquake scenarios.
- The shaking in an earthquake is a problem in itself, but studies show that the overall impact is driven by a cascade of failures that cripple lifeline systems including communication, isolating the impacted area.
- Surviving loss of lifeline systems depends on having local resources to meet local needs.
Design objectives
Given the above scenario, the Palo Alto AREDN network is built around the design objectives of power resilience, operational resilience, personnel resilience, minimal complexity, standards-based protocols, commercial off-the-shelf equipment, sound software design practices, security, user friendliness, and cost effectiveness. More detail on design objectives can be found here.
Constraints
FCC Part 97 and the assumptions most people make about wireless networking form a web of constraints around AREDN network design.
- AREDN traffic can't be encrypted.
- The design of cloud-based network apps (Facebook, Instagram, etc.) as well as the design of special apps like Veoci are based on assumptions about network behavior that may cease to be true in a disaster, rendering these apps unusable.
More details on constraints are found here.
Fixed infrastructure vs. meshing
AREDN as conceived by its originators is an ad-hoc mesh. This means that AREDN nodes can come and go, but the ability to reach from anywhere on the AREDN network to anywhere should not be impacted. The dynamic capabilities of a mesh are well-suited for what goes on in an emergency. Nodes can come and go as equipment and power for them come and go. Getting traffic from one place to another should not be the concern of the users -- the network should take care of that, transparently.
A significant feature of ad-hoc meshes is that they don't require fixed infrastructure. But what if a modest amount of fixed infrastructure can be provided? Is there potential benefit? In the Palo Alto AREDN network, we make use of both meshing and infrastructure. Let's examine the way the infrastructure is laid out.
At the level closest to end users, called the Access tier, the network can be dynamic. The access tier includes individual hams operating nodes from their rooftops and the City providing strategically-placed hotspots as well as ad-hoc stations set up at emergency evacuation sites. In Palo Alto, it is likely that an access site will be surrounded by trees. Trees block the propagation of 5 GHz radio signals.
To overcome this limitation, the Palo Alto AREDN network relies on a Mid tier that operates from high points. Mid tier nodes relay traffic between the access tier and the Palo Alto AREDN Backbone. The backbone is a fixed-infrastructure, redundantly-connected set of wireless nodes that tie major points of the city together with high bandwidth point-to-point connections. Backbone nodes have redundant power (using combinations of solar, battery, generator and mains power). Backbone nodes are in secure locations. The Palo Alto backbone has redundant connectivity to the Bay Area Mesh.
Part 97 vs. non-Part 97 traffic
To handle both peacetime connectivity to the internet and emergency connectivity to the Bay area's AREDN services, we could create duplicate wireless links from the backbone to the mid tier to the access tier, routing AREDN traffic through one and generic internet traffic through the other. This is inefficient and expensive to maintain. Instead, we have chosen to design and operate all of the links from backbone to the mid tier, and some links from the mid tier to the access tier under U-NII rules. We then are able to tunnel AREDN traffic over the U-NII links. Note that the reverse is not possible. If we chose to design and operate the links under Part 97 rules, we would be prohibited from tunneling generic internet traffic over the Part 97 links because the generic traffic is encrypted. The downside of choosing U-NII is, as previously discussed, a substantial loss of permissible transmit power to overcome signal losses over long distances and through foliage. This raises the cost of the network as compared to an AREDN-only network.
U-NII extends to the access tier nodes that the City builds out as part of its AREDN infrastructure. These nodes have both U-NII and AREDN available by virtue of a local AREDN node that tunnels over U-NII and also provides local access. A special WiFi radio operating under Part 15 rules (same rule as what you operate under for your home for WiFi) will serve two distinct SSIDs: one for AREDN and one for non-AREDN. We call the non-AREDN one OESNet.
- The AREDN SSID lets users connect to the AREDN network and all its resources. This supports the concept of having local resources to meet local needs. It also has the benefit of enabling amateur radio operators to access the public internet (when it is available) without switching to OESNet. This is legal because the traffic travels over a Part 15 network from phone or laptop to the AREDN node which immediately shunts the internet traffic to the U-NII network. The internet traffic never transits a Part 97 wireless link and consequently causes no violation of Part 97 rules.
But what about meshing? We've said that the access tier is where AREDN meshing can come into play, and it still does. However, because the U-NII network does not extend along with the AREDN mesh, meshed nodes will not have access to the public internet because that traffic would be carried over a Part 97 wireless link.
The AREDN SSID is only directly usable by amateur radio operators. While a ham could help someone by accessing an AREDN resource on their behalf, or letting that person access the resource under direct supervision of the ham (acting as a control operator), giving non-hams direct and unsupervised access to AREDN is in violation of Part 97. - OESNet acts as a wireless internet service provider (WISP) and provides internet access in peacetime, just as using WiFi at Starbucks would. But when connectivity to the broader internet is limited or out, and unless special steps are taken (more foreshadowing), OESNet may not be very useful. This will be a problem for Palo Alto ESVs who are trained to use Veoci. Veoci's cloud servers could be on the other side of a large-scale network failure, making their servers inaccessible when disaster strikes. A recent real-world test from Palo Alto to Veoci's app servers (not their web server) revealed that the termination point is AWS in San Francisco, sixteen hops away from AT&T's fiber network in Palo Alto.
Current topology
The Palo Alto AREDN network is continually evolving to provide broader availability for access nodes to reach the mid tier. We are also expanding network-provided services, improving our backbone bandwidth, and increasing resilience of the backbone through additional points of interconnect to the broader AREDN network
- Our key backbone nodes are at Fire Station 8 in the Palo Alto foothills and City Hall. From there, we interconnect with the broader Bay Area via links to San Bruno Mountain and Hurricane Electric in Fremont, with a link to Black Mountain in the planning stages (summer, 2025).
- We operate mid-tier nodes at Channing House, the Municipal Services Center (MSC), Mitchell Community Center, Cubberley Community Center and (soon) the Public Services Building.