26 lines
5.1 KiB
ReStructuredText
26 lines
5.1 KiB
ReStructuredText
===============================
|
|
AREDN |trade| Services Overview
|
|
===============================
|
|
|
|
As mentioned in the AREDN |trade| overview, the purpose of an amateur radio emergency data network is to provide typical Internet or intranet programs to people who need to communicate across a wide area during an emergency or community event. An AREDN |trade| network provides the transport mechanism for the types of programs people typically use today to communicate with each other in the normal course of their business and social interactions. This may include keyboard-to-keyboard chat, email messages with images and attachments, file transfer, collaborative document sharing, :abbr:`VoIP (Voice over IP)` phone service, video conferencing, :abbr:`GPS (Global Positioning System)` tracking, surveillance camera streaming, computer aided dispatch, deployed resource management, weather station reporting, sensor monitoring and control, repeater linking, and many other services.
|
|
|
|
The purpose for this section of the AREDN |trade| documentation is to identify examples of services that might be useful for communication across a mesh network. None of these programs are directly supported by the AREDN |trade| development team. Almost any program that can operate on a peer-to-peer TCP/IP network is a candidate for AREDN |trade| networking, but you should carefully select and test your services to ensure they will work within the following guidelines.
|
|
|
|
- An important consideration for selecting programs is to understand the impact each service will have on the performance and reliability of the network during the times when digital communication is required. As a best practice, choose programs which require the least amount of computing and network resources in order to operate successfully.
|
|
|
|
.. note:: The consideration above is especially important if you are deploying a service which regularly queries other nodes across the network. For example, if you deploy a network management system which polls metrics from remote mesh nodes, you need to carefully consider how many metrics you poll and how often you request them. Realize that polling dozens of metrics from each node every few seconds is likely to degrade mesh performance. Be sure to let node owners know what you are planning to do and get their permission/agreement for your polling schedule.
|
|
|
|
- It is equally important to choose data services that meet the criteria defined in FCC Part 97 regulations for amateur radio services. Try to avoid programs that use encryption or proprietary compression algorithms, which may be interpreted as "encoding messages for the purpose of obscuring their meaning" (FCC Part 97.113-a-4).
|
|
|
|
- As a general rule services should be run on separate LAN-connected computers rather than on the AREDN |trade| nodes themselves. Node devices have very limited resources which should be conserved for node operation rather than for running extra programs. Try to select external computers that have low power requirements, since many AREDN |trade| deployments are off-grid and without any external network access. Many operators use `Raspberry Pi <https://en.wikipedia.org/wiki/Raspberry_Pi>`_ computers which are small, easy to transport, and require minimal DC power for operation.
|
|
|
|
When choosing programs to use as AREDN |trade| services you will probably find that there is more than one way to accomplish your goals. It is crucial to clearly understand the types of communication that meet the requirements of your mission, and then you will be able to select the best programs for the job. Always try to use a program that will cause the least performance impact to your network.
|
|
|
|
Most TCP/IP programs are designed to use the `Client-Server <https://en.wikipedia.org/wiki/Client%E2%80%93server_model>`_ model, where one or more client programs communicate through a central server or servers distributed hierarchically. These types of programs can operate on a mesh network as long as the server is reachable or readily accessible by the nodes that need to use them.
|
|
|
|
As a general rule for mesh networks, simpler is better. The more complicated and automated you make your service design, the more network and computing resources will be required to operate the system. It is always best to conserve mesh networking resources wherever possible.
|
|
|
|
Several programs have been designed to take advantage of multiple paths between nodes and multiple peer servers coexisting on a mesh network. There are fewer of these mesh-friendly programs, but they will be identified as they appear in the following sections.
|
|
|
|
The remaining parts of this guide will focus on examples of services that could be offered on your AREDN |trade| network. Programs are grouped by type, and where possible the network impact of each program will be described in order for you to understand the resources that may be required to use the program as a service on the mesh. Remember that the mentioned programs are merely suggestions or examples of typical Internet-style TCP/IP applications which could be deployed on you network to meet the specific communication requirements of your mission.
|