Hi all,

I've been wondering about HSMM-Mesh and the point that it needs to be used only by amateurs.

The system's communication is not encrypted, and it is on the lower 6 channels of the WiFi band, running no more power typically than can be put out using a WRT54G in stock mode. It connects to the internet, runs IRC and more, all of which are pretty public.

I don't understand what makes this configuration unique for amateur radio use and exclusivity. DD-WRT also provides a mesh capability, but it has no such requirement. It even shares the frequency for AP use.

I'm starting to wonder if this net could be setup in non-urban 3rd world areas and not be subject to amateur radio regulations?

So, can anyone clarify why this is so "amateur radio" specific? 

Thanks, Don  VA7IQ / AE7UP

I am not a lawyer, but I have spent a lot of time carefully reading documentation and thinking over this topic. So with that, here is my carefully formulated answer:

The only time any device or person follows Part 97 rules is when they transmit or affix to and while under direct control (ie. RC aircraft) their FCC-Part 97-assigned call sign. Should you choose not to use your FCC Call Sign, then technically speaking, you are still operating under Part 15 rules.

In short, there is nothing that makes Broadband-Hamnet unique for amateur radio use only other than the fact that most users here will put their Amateur Radio Call Sign as their node name (the node name gets transmitted once every 5 minutes), and thus are expected to abide by Part 97 rules and regulations. Why is this? Anytime you identify using your FCC-assigned call sign, you are implying to the rest of the world that you and your equipment are following the rules and regulations as outlined in accordance to your license grant.

So what does this mean with respect to Broadband-Hamnet?
You and your equipment must abide by Part 97 rules and regulations as soon as you change the node name to contain your call sign. If you ever change your node name to anything else other than a call sign, then you are no longer operating under Part 97 rules and regulations, but instead fall back to the rules and regulations as specified by the type of certification of that particular equipment.

I hope this adequately and sufficiently answers your question.

This reply has been tailored to those who operate under Title 47 CFR 97. Please double-check the documentation from your governing radio agency/commission for the most up-to-date information concerning what is and is not permitted (amateur radio related or not).

Well to me the main reason BBHN is for ham use is because the developers are hams. There are a number of other non-ham Mesh projects out there that I'll list below. As also mentioned; everyone is using a callsign on the BBHN network thusly indicating any relayed traffic over the nodes is Part 97 ok/ham oriented. I.E. emails transported over BBHN may come out on VHF (Winlink) packet nodes, or VOIP traffic out IRLP nodes etc.

Village Telco - Mesh Potato http://villagetelco.org/mesh-potato/

Byzantium - wireless mesh networking for the Zombie apocalypse http://project-byzantium.org/

Serval Mesh - Emergency Preparedness MESH project http://www.servalproject.org/

SPAN - Smart Phone Ad-hoc Network https://groups.google.com/forum/#!forum/spandev

Commotion Wireless - an open-source communication tool that uses mobile phones, computers, and other wireless devices to create decentralized mesh networks. https://commotionwireless.net/

Hyperboria Sites - see the list of available services. http://hyperboria.net/

Meshnet - using CJDNS - Seattle or Santa Cruz https://projectmeshnet.org/

Commotion Wireless - https://commotionwireless.net/

Quick Mesh - http://qmp.cat/Home

I have a very new license, and have only been reading about HSMM, so my thoughts on this topic are very preliminary.

It seems to me that we should be thinking about part 97 versus part 15 operation, and that in particular we should have tools to rapidly switch between the two.

Part 97 operation offers greater flexibility in terms of power and frequency. You can make connections that might not otherwise be possible.

Part 15 operation offers greater flexibility in terms of the sort of traffic which can be handled. You can carry messages or permit unsupervised users.

The equipment, software, and skills needed to set up a network mostly overlap. IMHO when the desired connection can be established under part 15 rules, then it makes sense to do so. A part 15 connection could be connected to the open internet and used by non-HAM 'customers' without worrying about content.

A part 15 connection could be encrypted, whereas a part 97 connection cannot. (And while a HAM operation should not be encrypted, an _emergency response_ might need encryption, say for medical records.)

This is vaguely analogous to the rules about using the minimum power to effect the desired communication, or the requirements in the emergency operations rules permitting other rules to be broken only if no other communications method is available.

I've also been pondering the concept that if you use your call sign you _necessarily_ imply that you are operating under part 97. If you use your call sign with no qualification, then you are clearly saying 'this is a part 97 operation'. But what would happen if I used 'AF7TS/part15' to identify a node? This would be akin to someone who just upgraded appending /AE to their call sign. It removes any ambiguity caused by the use of a part 97 call, and part 15 doesn't have any particular call sign requirements.

The real question is how possible it would be to have a network that has some links operating part 97, and other links operating part 15, and automatically (and correctly) route traffic across such a network.

Thanks for considering my thoughts

73

Jon

AF7TS

I am going to go out on a limb here and suggest the notion simply using your callsign in any form in network identification attributes "automatically" puts your Part 15 compliant gear under Part 97 rules is ridiculous.  This is no more true than if you used your callsign on your home router.  It's just a string of characters used in networking parameters and nothing more.  Crossing the divide between Part 15 to Part 97 is not a matter of interpreting network device identification parameters, rather, it is strictly a question of straying from defined technical attributes including Power/EiRP limits, operating outside Part 15 frequency bands, use of certain modulation techniques, etc.  it's all right there in the FCC's Part 15 documentation.

Because of band and modulation overlap, it is technically possible for a Part 15 device to communicate with a Part 97 device.  It could be as simple as the Part 97 system is a Part 15 router with a beam antenna that causes it to exceed the EiRP limit.  It is otherwise just a couple pieces of network gear although the Part 97 guy needs a callsign in the system somehow.  Unfortunately the Part 97 operator would be violating 97.113 by communicating with the Part 15 device.  I don't know if the Part 15 operator would be violating anything.  The cure to this situation is for the Part 15 guy to simply be a ham and act as control operator and then yes he has to jump through some hoops to ensure things like certain encryption is off, etc. plus he then needs to put a callsign somewhere in the network id.

This brings us to these points

• A piece of wireless gear broadcasting a callsign may or may not be Part 97 (there is no way to know if the identifier is just a random string or something more),
• A piece of wireless gear operating under Part 97 shall broadcast a callsign.

A subtle, but important difference.

It is more complex than you suggest. It is true that these devices could be operated under either part 15 or part 97 rules. If you owned all the nodes in use and no other people are in the network, it is easy for you to set your own rules. The rub occurs when you have other people involved as they pass data through your mesh node.

If you load this firmware and connect to other BBHN mesh nodes, your traffic and the traffic of other hams will all pass to the next step in the mesh. You might think you are operating under part 15 but they are not and you can't enforce any restrictions on other nodes. The problem gets worse if anyone connects an Internet feed to the network or adds an access point to let cell phones be used over WiFi. The ham owning or deploying the mesh node needs take steps to avoid FCC violations.

All devices with BBHN firmware should be treated as if part 97 applies.

Caution: Please don't extend this topic into an encryption discussion. None of us write the rules and we can't change them regardless of what we say here.

Understood NG5V. Some of the Maryland folks have approached us in rural Virginia to locate a node on our hilltop location. Our hosts, and myself as trustee, likely won't allow anything that can be even remotely questionable and the current "technical possibility" of mixing the two regimes (15 and 97) is enough for them to say "no way."

However, the 3.4 GHz approach looks very promising as it seems there is a paperwork hurdle to cross before one can purchase a, I assume an export version, Bullet, etc. A built-in processing barrier filtering out non-hams goes a long way towards avoiding the potential problems and, much more importantly, convincing a bureaucracy to allow it.

I remain an optimistic student of this effort.

There exist several competing mesh networking schemes, all using different blends from a common pool of open source software.

You can absolutely set up a part 15 mesh network, with multiple users, by downloading router firmware from one of the other mesh networking projects.

I absolutely agree that as currently implemented all BBHN devices should be treated at part 97 devices.

I was simply pointing out the _utility_ of part 15 operation and suggesting being open to the _option_ of part 15 operation using the BBHN software base. Perhaps this is as simple as a community announced 'part 15' SSID to use in place of the default SSID.

I suspect that any sort of 'part 15' feature would have to prevent over the air connections to part 97 devices. Using a different SSID would automatically prevent these connections.

On the call sign issue: I tend to agree with kx4o, however I have followed internet discussions arguing the other side, including one which included a response from a low level FCC official, stating that if you use your call sign you are implying a part 97 operation. I don't think there will be a certain answer unless there is an enforcement action one way or the other. In other words, what _I_ think is reasonable is different from what others think is reasonable, and it hasn't been to court. IMHO using a part 97 call sign on a part 15 operation _should_ be okay, but that using "/part15" would be more likely to be accepted should there ever be an enforcement action, and a trivial extra 'burden'.

73 Jon AF7TS

There is a precedence of millions of linux computers, many used in commercial environments, with a wifi card and firmware that is not released by the manufacture. The FCC supports this -- see this reference:

https://www.eff.org/deeplinks/2016/08/fcc-settlement-requires-tp-link-support-3rd-party-firmware

These Linux devices include the OpenWRT and DD-WRT communities and any linux desktop/server with, e.g. many Qualcomm-Atheros wireless chipsets. While the manufacturer contributed to the open source driver, it is modified and released by the open source community.

See this reference on how linux deals with this: http://wiki.prplfoundation.org/wiki/Complying_with_FCC_rules_on_Wifi

Exerts here (in context that BBHN and AREDN are both based on OpenWRT):

Does this requirement apply to OpenWrt itself?

No, not directly. The FCC regulates devices which produce radio waves. The software, by itself, does not produce radio wave therefore software, open source or not, is not regulated by the FCC. That said, the mechanism for controlling transmission characteristics in order to comply with regulatory requirements could be implemented in software, and in the case of Linux is implemented in software. This mechanism would be considered part of the device for regulatory purposes.

So if it doesn't apply to OpenWrt itself, why is this an issue to OpenWrt?

The growth and quality of OpenWrt, like most open source software, is dependent on the ability of the community to innovate. As part of this, users need to guarantee their modifications work as anticipated. If routers software is locked down completely, there's no way for an individual to install their modified software on their own, personally-purchased router. This lead to a situation where the community can't participate and neutralizes many of the benefits of manufacturers using open source software. This is to say nothing of the fact that users wouldn't be able to use their own devices as they see fit.

Joe AE6XE