MVMA Meeting, please attend!

From:  Bill Curtice, WA8APB

To:  The Miami Valley Mesh Alliance

  • I’m writing to encourage members to attend the MVMA meeting this Saturday, 10 November 2016, at 9:30 AM at the BARC Clubhouse.  Several important issues will be addressed. These Include:
    • MVMA Purpose and Direction
    • MVMA Organizational Structure, Charter, and Division of Responsibilities
    • MVMA Leadership Changes
    • AREDN Mesh Technical Challenges
    • MVMA Network Purpose and Focus
    • MVMA Hardware Inventory and Funding Status

We are now at a turning point.  Clearly, we need to better define MVMA Leadership Responsibilities, Technical Direction, Goals, and Objectives.  I raised some of these points at the October MVMA meeting. I sensed significant diversity in what people want from the MVMA, and what people expect the MVMA to do.  

    • Attend our meeting on Saturday morning.

I look forward to seeing  you at the meeting!! Additional details follow.

Bill Curtice WA8APB


BACKGROUND:  Following is background information… presented from my perspective.  Those who have lived this history are welcome to offer corrections or different points of view.  Please respond to the survey (link above).

  • Mesh…. has been a learning process  The MVMA was originally chartered as a Special Interest Group under the Greene County ARES organization.  It was envisioned that MVMA members would become skilled in mesh networking, and serve as a resource to ARES District 3 clubs and individuals as they built their own mesh networks. Over last four years, many in MVMA have worked hard to promote mesh, and to build mesh network infrastructure.  Some have watched from the sidelines. The good news is, that as of August, we had over a dozen node sites, supported by over three dozen individual transceivers. The bad news, is that growth in our activities and in our infrastructure has created technical and leadership challenges that must be addressed if MVMA is to move forward.
  • Technical Challenges: Growth of our network infrastructure has enabled us to better understand our mesh performance limitations.  While there is no imminent technical threat to our operations, it is clear that the failure of the routing protocol used by AREDN, to correctly manage traffic across the mesh, impacts our operations.  Both Chuck Gelm (NC8Q) and Moe Riggins (AB8XA) deserve MVMA hero badges for the work they have done to study, define, and document these issues, and to find a “work-around” solution that meets our immediate needs.  However, I believe the work-around solution forces a tradeoff of network performance (link speed and capacity) vs. network resiliency and survivability for EmComm applications. These tradeoffs need to be carefully considered by a steering committee representing both EmComm and Technical communities.  Additional detail regarding my perception of this issue may be found at the end of this letter.
  • MVMA Network Purpose:  The above trade-off leads me to ask …. what is the primary purpose of the MVMA Network Infrastructure… be it a pure mesh or anything else?  Does MVMA build and support a backbone network and primary net access points primarily for:
    • Learning and experimentation?
    • Creating high-speed data communications between and among participating players?
    • Emergency Communications Support to Served Agencies?  (If so… we have a lot of work to do to make each primary node mains-power independent.)
    • Tech demonstration to youth?
    • Some other purpose?

What takes first priority?

  • MVMA Hardware Inventory and Financial Tracking:  We have records of expenditures of both individual contributions to MVMA, and the DARA grant received a few years ago.  A complete hardware inventory and financial report will be available at Saturday’s meeting.

  • Organization and Leadership:  Since its inception, I have served as the default leader of the MVMA.  John Joseph, N8JJ, has served as our treasurer, and keeper of the bank account.  Tim Procuniar, N8NQH handled recruiting, and configuration and test of hardware prior to installation.  We have no formal charter. That worked fine, as long as MVMA activities were limited in scope, and as long as I had abundant time to give.  Over the last couple years, my situation changed. As the scope and time demands of the MVMA expanded, my available time decreased, owing to other responsibilities which I place ahead of my support of the MVMA. I believe MVMA now needs:
    • A clearly defined organizational structure
    • A division of responsibilities across the membership
    • A New leader

I will not continue as a “solo act” leading the MVMA.  I will continue to support the club as an active member, will continue to maintain my own mesh station, and will support MVMA activities.  I recommend the MVMA adopt a traditional organizational structure, with a President, Vice President, Secretary, Treasurer, Steering Committee, and sub committees as needed.   I will not serve as president. A list of the “service opportunities” available is shown below; please consider where you might contribute.

  • MVMA Organization Responsibilities….   From my view, the following responsibilities within MVMA need to be addressed, assuming MVMA direction and purpose remain unchanged..
    • The usual complement of elected office holders
      • President
      • Vice President
      • Secretary
      • Treasurer (John Joseph)
      • Steering Committee (5 Members)
    • Committee and Staff Assignments
      • MVMA Charter Committee
        • Draft
        • Review
        • Member Approval
    • Meeting Pre-Planning
      • Agenda
      • Announcements and Meeting Notifications
      • Meeting Location Reservations
      • Invitations to Speakers
      • Demonstration coordination
    • Outreach to Clubs, Organizations, and Individuals
      • Mailing List Management
      • Soliciting Clubs to Invite MVMA Presentations and Demos
      • Presentation Graphics: Update and Management
      • Web Site Content Management
      • Web Master (Stan Leeds) 
      • New Member Recruiting and Support (Elmer)
      • Create propagation plots for prospective members
      • Loaner Kit Management
    • Demo Deployments – Show and Tell
      • Maker Faire  (Chuck Gelm)
      • TechFest
    • Hamvention Support  and Participation
      • AREDN Coordination
      • Inside Exhibits Coordination
      • Demonstration Systems Planning
      • Install, Use, Removal of Hardware
      • Scheduling of Booth Support
    • MVMA Network Design, Integration, Optimization
      • Network  design and performance optimization
      • Accommodating holes, deficiencies
      • Integration of peripheral players
      • Hardware selection and planning
      • Tunnel Management
      • Site Hardening
        • Lightning Protection
        • Solar Power
    • MVMA Network Administration
      • Day to Day Network Performance Monitoring  (Moe Riggins)
      • Network Security
    • Secure Community Support and Operating Sites
      • Build Relationships
        • EMAs and County EOCs
        • DARA, Other Area Clubs, ARES, RACES
        • GDAHA, KHN, Premier
        • Red Cross 
        • Industry
        • Government – City, County, Fire, Police
      • Solicitations for Funding
        • Applications for Grants
        • Member Outreach
      • Evaluate what is offered
      • Work politics to secure what’s needed
      • Coordinate Site use – what’s installed
      • Manage Install 
      • Define long-term support plan
    • MVMA Installation Crew
      • Hardware pre-configuration and pre-test
      • Hardware install
      • Climbing Crew
    • MVMA Operating Site Maintenance and Repair
    • MVMA Equipment Purchase, Storage, Check-Out, and Inventory Control
    • Book Keeping – Purchases and Ledger(John Joseph)
    • Tactical Deployments
      • Go-Kits and Recommended Deployment Configurations 
      • Exercises and Demonstrations
      • Public Service Events
    • Net Operations – Network Real-time Use
      • Network applications evaluations
      • Standards for Net Apps
      • Standards for net clients (cameras, servers, etc.)
      • Available bandwidth management
    • Net Control Station for weekly ARES Mesh Discussion Net
  • OLSR Failure:  I am concerned about the failure of Optimized Link State Routing Protocol (OLSR) to effectively route traffic on AREDN Mesh Networks.  These comments refer to the most recent release of AREDN firmware, which incorporates the most recent release of OLSR.
    • As I understand it, there are three routing protocol issues impacting us:
      • First, is that the routing protocol (OLSR) used is not capable of selecting the best (or fastest) route through the mesh.  Instead, it selects routes based on the least number of radio transmissions, which loosely relates to the least number of node hops.  Often, performance of the selected shortest route, with the least number of hops, is far worse than other routing options requiring more hops.  

    • Second, is that OLSR provides no manual route management capability, needed to trim or disable links that are too weak to support  traffic. Weak links serve only to add a significant processing burden for nodes at each end, and in so doing, significantly degrade the ability of those nodes to passing traffic from other valid links.  


    • Third, is that AREDN code developers are fast approaching a wall on processor speed and memory size for older Ubiquiti hardware (Bullet, AirGrid, etc.).  It may be difficult for them to significantly improve the OLSR function, within constraints of the old hardware. This implies that given OLSR/AREDN does improve the performance of OLSR….. older hardware will not be supported, and we will be forced to purge our system of the Bullets, AirGrids, AirRouters, etc  In time… as we abandon 2.4 GHz and migrate to 3.4 and 5.8 GHz hardware, we may wish to do that anyway.
    • At this point, there appears to be no near-term OLSR-based solution in sight; we have what we have.  However, Chuck and Moe demonstrated that the performance of the 2.4 GHz Omni nodes can be significantly improved if:
      • They are prevented from communicating with distant nodes, by assigning different  SSID identifiers to nodes in different areas. In essence, RF links to each 2.4 Omni will be limited to a few select other nodes, or if:
      • Strong 2.4 nodes which serve no particular user, are shut down.

The upside of doing this… is that it fixes the performance problem.  The down side… is that the network no longer functions as a true RF-based mesh; some mesh performance characteristics, important to EmComm, will continue to exist only to the extent that we replace both primary and secondary network links with 3.4 or 5.8 backbone connections.  Even then, OLSR will not assure best path selection. If all mesh links were perfect (100% LQ), this would not be an issue; routing by the least number of hops would be acceptable. In the Midwest, and I suspect in many other parts of the country, mesh networks will automatically create links of varying quality.  Even the marginal links may be useful to someone, and may be the only links surviving a disaster. The ability of OLSR to route smartly… selecting the best quality route paths…. is crucial.

As a practical matter, our physical access to many MVMA sites is limited, to where we can install hardware for only one or two backbone links (and in some cases, none).  Given segregation of the RF mesh, and lacking multiple, redundant backbone paths, the resiliency and survivability of the mesh network is reduced. It is a tradeoff; performance vs. resiliency.  Right now… we appear headed for performance.

OLSR performance is primarily an issue for mesh systems on 2.4 GHz; however, even when we move into use of 3.4 GHz with faster equipment, the problem may follow us until AREDN and their supporting OLSR developers create some new magic.  I see this as a global challenge for AREDN; if they do not fix OLSR, I see little future for mesh. The more mesh networks are segregated using SSID changes, channel jumps, height reductions and power reductions, and the more backbone links are manually configured and hardwired …. the more our mesh networks begin to look like ordinary 801.11 commercial wireless communications networks.  The virtues of a “mesh” evaporate. I expect AREDN users globally will discover that they can build high-speed, multi-media, digital, RF based, fixed configuration 802.11 networks …. independent of AREDN mesh … by using and manually configuring stock WiFi Access Point hardware, running stock software (AirOS). AREDN deserves our encouragement, support, and participation on this issue.

Bill Curtice WA8APB