Positive ComputerWorld Article on Ham Radio

http://www.computerworld.com/s/article/9139771/Want_to_bone_up_on_wireless_tech_Try_ham_radio :

Want to bone up on wireless tech? Try ham radio

Abundant spectrum resources and an engaged research community are drawing wireless experimenters back into a hobby that many had forgotten.

Securing HSMM systems without violating FCC rules

There's a common thread to conversations about implementing HSMM (aka souped-up WIFI): If you cannot use encryption to secure links (because encryption is almost completely prohibited to amateur radio), how do you secure them from access by non-hams?

Let's start with a review of the FCC rule.  §97.113 (Prohibited transmissions) prohibits, in part:

messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein;

 It seems to me that this prohibition rests on two things: (a) the purpose of the encoding and (b) the obscuring of the meaning.

Let's take an example of communications that everyone agrees do not violate this section: the CRC codes in AX.25 messages.

In a packet radio message, the contents of the message include a CRC (cyclic redundancy code) at the end of the message, which is used to verify that the message was received undamaged. Is the purpose to obscure the meaning of the message? Not at all.  The bulk of the message is in plain text, and the CRC merely allows any receiver (intended or otherwise) to verify that the contents of the message.  Does it in fact obscure the message? No, because the CRC can be computed via known algorithms.

Now, lets consider what would happen if we added public key encryption into the mix.  In public key encryption, there are two encryption keys used.  One is private and one is public. Let's say the public key is registered with the ARRL, who makes it available to everyone, amateur or not.  Thus, it is commonly known how to find the public key for any ham.

Messages encrypted with your private key can be decoded by everyone (who has looked up your public key), and if they decrypt successfully with your public key it can be safely assumed that you and only you encrypted them.  This allows you to "sign" messages.  Similarly, any message encrypted using your public key can only be decrypted using your private key.  Thus, anyone can encrypt messages for you and have them be readable only by you.

Let's apply this to the CRC.  What if the sender of the message (who is clearly identified in the packet) encrypts the CRC using their private key?

Anyone (intended receiver or not) can decrypt the CRC using the sender's public key (which they found on the ARRL website).  And if the decrypted CRC is correct for the packet, we know two things: we know that the message was received without errors, and we know that the sender specified in the header did, in fact, send the message (i.e., it was not spoofed).

OK, how does this work with the law?

Is the purpose to obscure the meaning of the message? Not at all.  Consider:

• The actual message -- the rest of the packet -- is not encoded.
• The CRC is just as readable as it was before; you decode it using the sender's public key, and then you match it to the message to validate the contents.  Even the meaning of the CRC is not obscured; it is readable by all who posses common knowledge.
• What is the purpose of the encoding? The base CRC encodes the data to ensure that there is no error in it.  The "enhanced" CRC is encoded to ensure that the sender is properly identified.

So, will you agree with me that you can use a public key encryption to "sign" messages to authenticate the sender?

(If not, stop now.)

If that's possible, then, of course, there is going to be something analogous with HSMM.  It will be possible to authenticate the sender even while the message is in cleartext, and the receiving system can decide if the sender is authorized to use the system.  If not, the message can be ignored. Again, if the ARRL (or some other recognized body) keeps the list of call signs and public keys, then "open" systems will merely need to look-up an unknown call sign to add its public key to a cache and then allow all hams in and keep all non-hams (who, we assume, do not have a valid call sign with an entry in the ARRL database) out.

Did I miss something? Tell me in the comments!

Emergency Communications and amateurs ...

I don't get it -- why do people on eham and qrz keep battling about whether emergency communcations is good or bad?  Well, apart from "because they can" ...

It seems to me that amateur radio operators have one real strong benefit to offer: If something breaks, amateurs can generally fix it.  If the antennas all get blown off the roof of the police department, who there knows how to repair them?  Who there could improvise one?  Who there could even guess what a quarter wave-length is for 480 mhz?

Exactly.  It's only the people who do this as a hobby and have been through the process of setting up a station who can solve these kind of problems.  And in a disaster, it's going to be those people who get communications equipment working again on short notice.

Do amateurs only have value in operating a communications network? Perhaps in being able to help others out getting their networks working again is a valuable skill?  Or maybe both...

More AT&T Woes, this time in San Francisco

I just returned from Oracle Open World (OOW) in San Francisco, and my iPhone was just struggling to work there.  I had to turn off 3G services to get a reliable connection, and even then there were times that it just wasn't working.

I hate to hammer on the point, but it really seems like the network's maximum capacity is dangerously close to its average usage; a small uptick in usage and things go downhill fast.  Clearly, AT&T should have a sense of the calendar of events in San Francisco -- OOW happens just about the same time every year and they must have noticed the spike in usage last year.

I'd hate to see what happens there if (when?) a major and destructive earthquake hits and everyone starts twittering "OMG I just saw a building collapse in SF"...

How to lure more young people into ham radio

Give them free 2m radios when they get their license!

Of course, that would be a bit expensive, although I suppose if the ARRL did this en masse it could find something inexpensive or get one of those cheap chinese HTs FCC certified...

Still, it's a thought! Your average 16 year-old who might be interested in amateur radio probably isn't going to have the $100 or so to get a decent HT, which is kind of a buzz-kill for the hobby.

Web Services & Packet Radio ... But! But! But!

When discussing web services and packet radio, I hear a lot of buts ...

• But XML is too inefficient to go over 1200 baud links!
  
  XML in its native state is very inefficient; but that inefficiency also gives rise to incredible compressibility; you can shrink XML in ratios of somewhere around 8:1 .
  
  
• But we've tried (HTTP, TCP/IP, etc.) over packet radio and it's just too slow to bear.
  
  All of these are probably in support of interactive user sessions, which web services is not (usually).  Web services are computer to computer communications, and usually do not have a direct impact on the UI.
  
  
• XML is very bandwidth inefficient
  
  I don't think there's a bandwidth shortage.  As far as I can tell, most packet nodes sit idle almost the entire time; that means lots of wasted bandwidth.
  
  
• HSMM (i.e., wifi with higher power levels or better antennas) is much better for this sort of thing.
  
  It's much better for running a traditional TCP/IP network, for sure.  But web services do not require  TCP/IP or HTTP -- those are just one of many ways to deliver web services.  And while HSMM delivers high speed, it is also a very small niche compared to 2m packet and doesn't have the ability to easily blanket a community with a signal.
  

 To be fair, when I raised the question, it was very narrow (has anyone tried this?) without a lot of explanation of why.  I'll try to answer why in another post soon.

Compressing XML for over the air usage

In the quest for packet based web services, one big problem -- at least a performance problem -- stands out: XML, which is used in SOAP messaging, is horribly verbose.

In his paper, Compressing XML with Multiplexed Hierarchical PPM Models, James Cheney examines the various means of compressing XML files. And while he pushes hard to get the very best possible compression by using XML-aware techniques, even the widely used gzip is able to achieve about an 8 to 1 compression, which is really good. Plus, gzip compression is used in HTTP, so it has a defacto use in transport compression. The best compression he found as more like 12 to 1 compression, but apparently a bit of a time hog.

Gzip also is built into Java, making it easy to build support there, and there are freely available gzip libraries for .Net and PHP, covering about 99% of all web site development.

??? Listening

I must be the only one who has a problem with "Callsign listening" as the protocol for announcing oneself on a repeater -- I usually miss the first part (during the "huh, someone's on the repeater" moment). I guess when you already know everyone by sound and call sign, it works great, but for newbie me, I spend time wondering "who was that?"

And if I have my radio scanning around a few repeaters, I'm guaranteed to only hear the last few letters of their call...

Why are there no web services over packet radio

Approaching the world of ham radio from the perspective of a long time computer software -- and enterprise integration -- point of view, it struck me today: why are there no web services support in amateur packet radio.

Web services are a fancy name for the ability to make a subroutine call across a network (or even on the same computer). They are based in eXtensible Markup Language (XML), which means that the call can pass in and return data of any arbitrary complexity. They are quickly becoming the standard for integration applications across a network, especially in situation where the applications don't normally know about each other.

There are some things about web services that make them a natural for amateur packet networks:

• They are fundamentally half-duplex, like our radio connections: You send in a call (which could be split across packets because of size), and then wait for a response.
• They could allow for a very nice, local front end to traditional applications like bulletin boards, which got killed by not only better connectivity of the internet but, I suspect, nicer web user interfaces.
• They allow for arbitrary experimentation with packet -- no having to come up with a separate KJ4NGS-xx for every application.

It's the last point that seems strongest to me -- the ability to quickly experiment with new services on the packet net.

There's a lot issues to be solved to make this work, but it seems to me to be something that is fundamentally at the heart of what amateur packet should do.

Random ideas for improving ham radio

Here's some ideas that occurred to me ... they may be new to me but not new to everyone else, so if these have been kicked around the lot a few times, forgive me...

1. Creating a standard for having a small data channel along with analog FM. Like DStar, only open standard and inexpensive to implement. Something like broadcast FM's Radio Data System, only not so bandwidth hogging. If nothing else, it could do some of the tricks DStar does (unsquelch only when someone is calling you, automatic call sign transmission, etc). There is no reason to toss FM-voice away just to get a digital sub-carrier.
2. With #1, repeaters could log usage (maybe this is a bad thing?), but with a public web site, then you could get a sense of when people are on.
   
3. Repeaters with Antenna Diversity to allow for better reception of weak stations. Would be especially good for ecomm work where field units might be 5W HTs while the repeater is 50W or more.
4. Using packet radio to advertise when you are available on a repeater. If I broadcast a "listening message" and someone shows up 5 minutes later, my listening message is lost.
5. "Packet pager" -- sort of like an HT crossed with a blackberry. Ability to send and receive text messages from a small handheld device using packet (APRS?).

All of these have a critical mass problem (except #3), so they're nice in theory, at least...