<div dir="ltr">When you connect to HamWAN you'll get a single address via DHCP. That works great for testing and most general use. We also have plenty of address space in case your site needs a larger subnet.<div><br></div><div>To advertise your own /24, we need a Letter of Authorization from the owner of the address space. For AMPR addresses, that comes from Brian Kantor. If you own the addresses and your name is on file with ARIN, you can write the LOA. Nigel usually handles submitting the LOAs to our transit providers.</div><div><br></div><div>Tom</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 7, 2016 at 3:43 PM, Ed Morin <span dir="ltr"><<a href="mailto:edmorin.jr@gmail.com" target="_blank">edmorin.jr@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yep, agreed.  I'm going to borrow the specified equipment for a portable HamWAN setup, but I think I will need link addresses to use.  We have a /24 allocation, but I don't think we need to route it for simple testing and/or NAT via an AP.  If you have the proper contact for that off the top of you head, let me know.  I believe I submitted an application already, so I'll dig in my e-mail for that as well...<div><br></div><div>My plan is to start surveying the stations as well as a few other points of interest (my home of course!).</div><div><br></div><div>As a side note, down the road, it might be possible to work with HamWAN to deploy a general-purpose cell site in Redmond somewhere; it will take some research as that's beyond my knowledge in terms of permissions process, etc.  I think a case could be made that it would support emcomm around Redmond including ARES.  At any rate, need data and I will certainly share what I find; it'll take a while although I'm sure some of the other ARES members would love to help as it's exciting stuff.  :-)</div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 7, 2016 at 2:28 PM, Tom Hayward <span dir="ltr"><<a href="mailto:tom@tomh.us" target="_blank">tom@tomh.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ed,<div><br></div><div>HamWAN has a relatively new offering we call our Open Peering Policy. This allows you to multi-home your /24 on our network. After the appropriate paperwork is filled out with our transit providers and the owner of the /24, you will be able to announce your /24 over HamWAN and subsequently HamWAN's Internet transit providers. This will allow HamWAN to be one piece of your autonomous network.</div><div><br></div><div>You are right that my recommendation would leave you with Haystack as a single point of failure. My point is you have to start somewhere. Some of your stations should also be able to see the HamWAN Capitol Park site, so you have an opportunity for redundancy there. And you're free to create as many independent links as you want, in due time.</div><div><br></div><div>If any of the sites you have access to have the coverage to serve a significant number of potential HamWAN users, we could deploy sectors there. We have also been experimenting with distribution over 900 MHz, which may work well in your area. HamWAN coverage to Redmond has been poor for a long time--if you can't see Haystack or Capitol Park, there's no other option. It would be great to fill some of that area with some new cell sites (our term for anywhere we deploy sectors).</div><div><br></div><div>Regarding deployment by ARES members: it takes practice! Get some portable HamWAN stations put together. You can see a photo of mine on the homepage of <a href="http://hamwan.org" target="_blank">hamwan.org</a>: <a href="http://hamwan.org/t/tiki-download_wiki_attachment.php?attId=147" target="_blank">http://hamwan.org/t/tiki-download_wiki_attachment.php?attId=147</a> It's simple, but allows me to go anywhere with a view of the mountains and set up a HamWAN client in a few minutes. I get a little better at it every time. It also gets you thinking about how you want to use it--this picture shows it connected directly to my laptop, but I've practiced setting up other configurations as well, like a local 2.4 GHz access point for sharing the HamWAN.</div><div><br></div><div>You've got a lot of great ideas. The next step is to get out there and build something!</div><span><font color="#888888"><div><br></div><div>Tom</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 7, 2016 at 12:52 AM, Ed Morin <span dir="ltr"><<a href="mailto:edmorin.jr@gmail.com" target="_blank">edmorin.jr@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>4. Ok, so your last questions are getting more to what really should drive the requirements and discussion.</div><div><br></div><div>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.</div><div><br></div><div>My assumptions (yep, more of 'em) for longer-term functionality based on various conversations, personal experience, etc. are:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.  ;-)</div><div><br></div><div>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!</div><div><br></div><div>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.</div><div><br></div><div>Does that help?</div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 6, 2016 at 11:32 PM, Tom Hayward <span dir="ltr"><<a href="mailto:tom@tomh.us" target="_blank">tom@tomh.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ed,<br>
<br>
It might be time to step back and talk about your goals. I thought we<br>
were talking about putting these stations on HamWAN, not creating a<br>
new independent network. I'm not opposed to helping you with this<br>
plan, but it certainly will be easier (and cheaper!) to lean on our<br>
existing infrastructure. I'd start by trying to get as many of the<br>
stations connected to Haystack as possible. I think it should work for<br>
all but 11.<br>
<br>
My experience with 2.4 GHz is that it's just really noisy. HamWAN<br>
settled on 5.9 GHz for a number of reasons:<br>
- ham-only, so relatively lower noise floor<br>
- equivalent size dishes will have significantly more gain on 5.9 GHz<br>
than 2.4 GHz. This gain happens to be about equal to the increased<br>
path loss, meaning you have net zero cost for moving up to the quieter<br>
band.<br>
- smaller Fresnel zone on 5.9 GHz allows mounting lower on towers and<br>
shooting through smaller gaps in trees (as long as there's a gap!)<br>
- down in the Part 15 section of the band, there's lots of spectrum<br>
for wide-channel, fast point-to-point links<br>
<br>
What criteria are guiding your triangle-topology design? What types of<br>
applications do you want to use this network for? What constraints<br>
have you been given (sounds like an in-house solution is preferred)?<br>
<span><font color="#888888"><br>
Tom<br>
</font></span><div><div><br>
On Sun, Mar 6, 2016 at 11:00 PM, Ed Morin <<a href="mailto:edmorin.jr@gmail.com" target="_blank">edmorin.jr@gmail.com</a>> wrote:<br>
> Hi Tom,<br>
><br>
> Well, you have been busy!  Thank you for looking into these things -- I know<br>
> it can take a while sifting through the possibilities.<br>
><br>
> My "stick in the ground" model that I've been presently mulling is a<br>
> "hub-and-spoke" sort of setup -- at least from a theoretical point of view<br>
> because it sure doesn't resemble one on paper!  (Owing to the geography of<br>
> course...)<br>
><br>
> Core triangle of 12, 13, and 17 for reasons stated earlier -- UNLESS one of<br>
> the other stations ends up having a "better" link<br>
> Station 14 would hang off 12 (and possibly have a HamWAN link as well as it<br>
> surprisingly has a possible shot at it)<br>
> Station 16 would likely hang off 13 (and/or possibly) -- station 11 would<br>
> have to hang off 16 (so having a redundant link to 16 would be worth<br>
> considering)<br>
> Station 18 is potentially a challenge, but might have a shot at 12 (and<br>
> maybe HamWAN as well as you point out)<br>
><br>
> Anyway, we need to get on the roofs and "see what we can see" to get a<br>
> better idea.<br>
><br>
> As an aid for this, I made a little "telescoping mast" out of some PVC pipe<br>
> that I can put my phone on and hoist up 15 feet or so using a rope (from<br>
> wherever I'm standing).  (It's a Windows phone, so it's expendable. :-)  I<br>
> use it to first take a short 360 video.  Once I have an idea of a<br>
> potentially promising direction, I use a timer for taking a<br>
> higher-resolution picture that I can study in more detail.  The other day I<br>
> was pleasantly surprised that I might very well have a good shot at station<br>
> 16 from our home where there is a relatively convenient mounting point.<br>
> (For testing convenience as it's a nice 3 km+ path.)  Anyway, it was nice<br>
> not having to drag out the extension ladder.  :-)   So, it may be helpful<br>
> for scoping things out at the stations; we'll see.  If any of you have ideas<br>
> for simple site surveying, I'd love to hear them.<br>
><br>
> I don't know how this is all going to play out, but several folks on the<br>
> ARES team are excited by the prospects and having some more hard data from a<br>
> survey will definitely kick up the energy level I'm sure.  :-)   We're still<br>
> kicking around ideas on what to do for inter-station linking; it can get<br>
> expen$ive in a hurry...  Has anybody here played with 2.4 GHz amps and<br>
> dishes?  They are relatively inexpensive and the choices for routers to use<br>
> are plentiful and inexpensive as well...  One of the ARES guys and I<br>
> achieved (more or less) a 1.5 km link using Linksys routers with dd-wrt and<br>
> only 70 mW into DIY helical antennas on flimsy tripods!  It wasn't<br>
> super-stable, but for only 70 mW, I thought it wasn't too bad...<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Sun, Mar 6, 2016 at 9:35 PM, Tom Hayward <<a href="mailto:tom@tomh.us" target="_blank">tom@tomh.us</a>> wrote:<br>
>><br>
>> On Sun, Mar 6, 2016 at 4:05 PM, Ed Morin <<a href="mailto:edmorin.jr@gmail.com" target="_blank">edmorin.jr@gmail.com</a>> wrote:<br>
>> > As for locations.  These are the fire station addresses and GPS<br>
>> > coordinates<br>
>> > that one of our other members put together:<br>
>> ><br>
>> > Station Address City Zip Lat/Long<br>
>> > 11 - HQ  8450 161ST AVE NE REDMOND 98052-3848 47.677913, -122.124938<br>
>> > 12 4211 148TH AVE NE  BELLEVUE 98007-3119 47.648426, -122.143646<br>
>> > 13 8701 208TH AVE NE REDMOND 98053 47.680206, -122.063499<br>
>> > 14 5021 264TH AVE NE REDMOND 98053-2718 47.651962, -121.987793<br>
>> > 16 6502 185TH AVE NE REDMOND 98052-5039 47.664105, -122.093651<br>
>> > 17 16917 NE 116TH ST REDMOND 98052-2246 47.703403, -122.114135<br>
>> > 18 22710 NE ALDERCREST DR REDMOND 98053-5845 47.692245, -122.03717<br>
>><br>
>> Ed,<br>
>><br>
>> I have not done RF models for each of these, but some quick plotting<br>
>> on the map shows line of sight from Haystack to stations 12, 13, 14,<br>
>> 16, 17, and 18. Station 11 is in a low spot and the only opportunity I<br>
>> see is a direct link to station 16.<br>
>><br>
>> > My thinking is to have a "core network" of links between stations 12,<br>
>> > 13,<br>
>> > and 17.  Of all the stations, 13 seemed to be the most promising.<br>
>> > Station<br>
>> > 12 is practically next door to Microsoft's main campus and the noise<br>
>> > level<br>
>> > is huge there, but it potentially has great shots to several other<br>
>> > stations<br>
>> > which makes it attractive to having in the core.  Station 17 has become<br>
>> > somewhat of a "hub" station for ARES -- at least we continue moving in<br>
>> > that<br>
>> > direction; trees could be an issue there.  One or two of the other<br>
>> > stations<br>
>> > might have coverage potential, but it's all showing even more spotty on<br>
>> > the<br>
>> > map than these others.  (Of course if we were able to access a node on<br>
>> > Cougar, everything changes for the better...)<br>
>><br>
>> Station 17 shows line of sight to station 12, 13 and 18, so could be<br>
>> somewhat useful as a hub, but not for all of the stations.<br>
>><br>
>> Keep in mind the coverage map on <a href="http://hamwan.org" rel="noreferrer" target="_blank">hamwan.org</a> is binary and only shows<br>
>> signals greater than -70 dBm. This is essentially 100% signal<br>
>> strength. "Spotty" might mean 5 Mbps speeds instead of 15 Mbps. Of<br>
>> course it could also mean zero signal, especially if there are local<br>
>> issues not accounted for in the model, like trees. It's worth doing<br>
>> calculations for specific sites in those "spotty" areas with a tool<br>
>> like <a href="http://ubnt.com/airlink" rel="noreferrer" target="_blank">ubnt.com/airlink</a> or Radio Mobile, and if it looks favorable, ask<br>
>> here on the mailing list for someone to come out and test. We've got a<br>
>> number of people here who love playing with our portable HamWAN rigs.<br>
>> :-)<br>
>><br>
>> Tom KD7LXL<br>
>> _______________________________________________<br>
>> PSDR mailing list<br>
>> <a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br>
>> <a href="http://mail.hamwan.net/mailman/listinfo/psdr" rel="noreferrer" target="_blank">http://mail.hamwan.net/mailman/listinfo/psdr</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> PSDR mailing list<br>
> <a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br>
> <a href="http://mail.hamwan.net/mailman/listinfo/psdr" rel="noreferrer" target="_blank">http://mail.hamwan.net/mailman/listinfo/psdr</a><br>
><br>
_______________________________________________<br>
PSDR mailing list<br>
<a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br>
<a href="http://mail.hamwan.net/mailman/listinfo/psdr" rel="noreferrer" target="_blank">http://mail.hamwan.net/mailman/listinfo/psdr</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
PSDR mailing list<br>
<a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br>
<a href="http://mail.hamwan.net/mailman/listinfo/psdr" rel="noreferrer" target="_blank">http://mail.hamwan.net/mailman/listinfo/psdr</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
PSDR mailing list<br>
<a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br>
<a href="http://mail.hamwan.net/mailman/listinfo/psdr" rel="noreferrer" target="_blank">http://mail.hamwan.net/mailman/listinfo/psdr</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
PSDR mailing list<br>
<a href="mailto:PSDR@hamwan.org">PSDR@hamwan.org</a><br>
<a href="http://mail.hamwan.net/mailman/listinfo/psdr" rel="noreferrer" target="_blank">http://mail.hamwan.net/mailman/listinfo/psdr</a><br>
<br></blockquote></div><br></div>