All great questions Tom! First off, my answers are not necessarily any sort of "gospel" in the matter. I can answer some of what you are asking, but some of these answers are based on "stick in the ground start from somewhere" thinking that will almost certainly evolve over time.
1. Having built an ISP network covering much of the NW back in the '90's, one of our core principles was to not wholly depend upon ANY networks beyond our own control. I would not necessarily say an "in-house only solution," but rather an "in-house design" that includes redundancy to HamWAN's infrastructure. It's fine to link to Haystack, but what if Haystack fails and we don't have other good HamWAN link options?? At this point, I do not see a 100% HamWAN solution; more likely a :"HamWAN+" solution. That is to say, I fully expect to have *some* non-HamWAN redundancy component (eventually). "Cheaper" isn't the sole driver, but it is certainly a strong consideration. Getting linked to HamWAN is our first priority. Redundancy routing is desired, but must come later.
2. Your suggestion of connecting as many stations as possible to Haystack is very much worth a serious look. One of my assumptions thus far has been that only a few stations would have a decent HamWAN signal and that shorter inter-station paths might perform better. That is strictly assumption which needs to be replaced with hard data. How redundancy routing via non-HamWAN networks also needs to be factored in (eventually).
3. I totally see, and agree with, your logic -- from a technical point of view -- about 2.4 vs 5.9 GHz. It very much makes sense and squares with what I have read and studied. Not sure about the total cost being lower, but that will depend on what we find during surveys and testing along the way.
4. Ok, so your last questions are getting more to what really should drive the requirements and discussion.
First off, my experience with building networks is to try and create a flexible foundation, but evolve and grow them as time and resources permit. "Phase I" will be quite simple -- just getting some HamWAN connectivity to even a few stations would be huge. I can also envision capabilities I'd like to see far beyond that.
My assumptions (yep, more of 'em) for longer-term functionality based on various conversations, personal experience, etc. are:
1. INITIALLY, having at least one PC at each station that is able to transfer documents, spreadsheets, pictures, video and maybe even providing VoIP and video-conferencing capability. Eventually, I want to grow this to providing an Access-Point that multiple ARES members at the station could use simultaneously. *IF* we went part-15 for inter-station links, then non-hams (e.g. other incident staff) could use it as well and the hams in the group would manage the HamWAN gateway transition to part-97 governed network infrastructure. Now, that's not necessarily a requirement per se, but an interesting consideration. It is also a HUGE architecture driver as the network evolves. It's not an "out of the shoot" assumption or requirement, but I could certainly see it come up for discussion.
2. The fire stations, being geographically dispersed, would potentially make great core sites for linking portable networks using private address space at shelters, mobile command posts, etc. I think having infrastructure that is totally tied to the stations would be very limiting and potentially frustrating. That means that the stations themselves might potentially have some sort of "sector-based" infrastructure for handling these local-area connections. It would be nice to have a network where each station (or several anyway) could run "standalone" on a HamWAN link, but also have redundancy to other stations and/or ISP. That is, they can use the highest performing link(s) and have the "other" for fail over. (I am assuming ONE non-HamWAN ISP link somewhere in the network is probably sufficient.) All of this bullet item is way beyond Phase I though.
3. The above needs to be deployable and maneagable by several ARES team members. People can be a failure point as well, so having features and capabilities needs to be weighed against technical and administrative complexity. It will be interesting to see how far we can push it.
4. In terms of other driving factors, getting stuff mounted on a fire station is not easy. Having something "less obtrusive" bodes better. As much as seeing towers bristling with antennas and dishes supporting redundant links and other capabilities is a beautiful thing and a very pleasant thought, sadly, most who are on the critical path for success don't feel the same. That means "as low as possible, as unobtrusive as possible, as small as possible, as simple as possible, as cheap as possible, etc." You get the idea. And even *that* list is in conflict with itself! (Smaller isn't always cheaper, etc.) Some of those "battles" can be fought, but from a pragmatic point of view, I'd rather pick them based on functionality and effectiveness for fulfilling the needs than my own fleeting fantasies. ;-)
Part of what needs to be understood here is that we've been flogging the 1200 baud packet stuff for YEARS. A number of folks don't (yet) understand how having a multi-MEGAbit network will "change everything." All of a sudden, when the paradigm is radically shifted, how we think about ARES' function and what can be provided to the city radically changes. Not everybody "gets" that (yet). But, they will be blown away when they do!
So, in a way it's hard to totally articulate a detailed requirement because as one begins to understand how radically different things *could* be, the requirements will change. From my own experience, I know that having control over redundancy and infrastructure is a Good Thing. Not out of any mistrust or disrespect, but out of best practice. Having a flexible architecture/design that can both accommodate evolving requirements and adapt to potentially rapidly changing conditions during a disaster is also a Good Thing.
Does that help?