[Mep-dev] Re: Mep-dev digest, Vol 1 #57 - 4 msgs
Glenn Currie
glenn.kd5mfw@gmail.com
Tue, 2 Dec 2008 23:45:57 -0600
The Austin HSMM Special Interest group has been working with Wi-Fi devices
for ham radio use since 2002.
In the central Texas area, we have a network of 2m / 440 packet and voice ham
stations in area hospitals. This is the ARCHES project:
<http://www.your-website-in-24-hours.com/travishams/tcares.org/index.php?option=com_content&task=blogcategory&id=14&Itemid=26>
When any significant number of the area hospital packet stations are
activated, the
available bandwidth is quickly overloaded. In 2002 I proposed we
move the traffic in the dense
urban Austin area traffic to microwave using Wi-Fi gear running under
part-97 rules. This
would leave the 2m and 440 frequencies for the folks form small outlying towns
to get into "resource central" in Austin. If we clog the system with
our local traffic
in the City of Austin, the guys out of town are also out of luck.
The ARCHES system
will eventually be expanded to 40 or more packet stations.
This month we should have The Office of Emergency Management for Austin and
Travis County linked to the Local Red Cross chapter office. Both
locations support
large well stocked radio shacks. For our digital work with Winlink
2000 related packet
work, we make use of computer servers at both of these key locations. Soon we
will have the servers connected with our broadband mesh nodes. We have done
site surveys to link Brakenrige Hospital, the area trauma center as
well as the State
of Texas EOC.
Linking these high value sites should help reduce the huge burden of explaining
what we are trying to do. Some groups will "jump on the bandwagon" because "the
most important sites" are using the system. We can't easily explain what we are
doing to most hams, much less hospital administrators. Since we control all the
infrastructure and it is battery backed, it is not unreasonable to
mention it could
be useful for homeland security. Use of the Internet by all agencies is now
"normal" communications and can have problems. So the ARES mission needs
to include broadband capability or risk being considered irrelevant.
"We hams are the radio experts except for some of the most popular types of
radios ever made, that are cheap and can be configured out of the box for
Part-97 use", will be a hard sell as it makes no sense - and that is
pretty much
where where we are with broad band capability at the moment. I am
greatly encouraged by
the work discussed in this group. Hams can "show'em how it is done", if we
apply ourselves.
>From the get go, the ARPANET was required to be able to route around
failed links.
Whatever did not go up in the mushroom cloud should reroute traffic and continue
to work. In Austin there are several backbone links into the
Internet. It is entirely
possible that one carrier might be down due to terrorist "backhoe" attacks that
cuts fiber optic cables. (Happens all to often, and the guys are
contractors burying
sewer pipes, not terrorist. They just snag a particularly tough "tree
root" and manage
to jerk it out of the ground, only to find it is a communications cable.)
Supplying dial tone from the Red Cross to the area trauma center 2.2 miles away
is entirely possible using our mesh nodes and Asterisk PBX software and related
hardware in a PC. It wold be a limited number of lines, but we are
doing emergency
communications, not trying to become a telco. Training is minimal. Users just
dial a telephone number as usual. This is just one potential use of
the mesh system.
Also in our area we have hurricanes. About every 10 to 12 years Texas
gets one or
more devastating hurricanes. It is not a mater of if, but when there
will be massive
communications failures. The mesh node system we are building can be deployed
quickly using portable stations. "Throw Box" nodes (packaged battery
and all in a plastic
ammo box) can be deployed in minutes. They can be used to "bread
crumb" your way
into a building to your portable station in the parking lot of a the
building. If the power
switch is thrown as the Throw Boxes are unloaded and carried into the
building, they
will have already formed a working network before you can get them
into the building.
If you plug a link with Internet access on it to the WAN port on a
WRT54G mesh node,
all nodes it can see will have Internet access in 5 seconds.
We will soon release our 3rd version of custom firmware for the WRT54G wireless
router. We have had excellent results with this versatile hardware.
One of the key features supported by our firmware is Optimum Link
State Routing (OLSR).
OLSR allows WRT54 based mesh nodes to automatically link in 5 seconds
after coming
into RF range. From a cold start of a WRT54G we a linked and passing
data in 35 seconds.
(see www.olsr.org)
Installing these systems to augment the existing ARCHES hospital sites
gives us sites for
a base network. All the hospitals are on major roads in the area and
thus well placed for
store and forward data mule communications. Our focus has been on
ARES activities
as all the served agencies like the Red Cross all make extensive use
of the Internet.
Establishing an Internet link to the home office of the Red Cross is
the first order of
business when arriving on a disaster site. All damage assessment and
requests for
supplies are all handled via the database at the Red Cross home office near
Washington DC.
Being ARES activities are currently our main focus, we have done
extensive portable
and mobile testing of our mesh nodes. We can make 10 mile links
across the thousands
of Access Points in Austin, at will with the unamplified output of the
WRT54G (about 35mw).
FROM GOOD SITES.
Recently the Roadrunner Microwave Group has joined us in our HSMM
efforts. They have
a great deal of experience in long (for microwave) links.
Perhaps this basic self-configuring, self-healing network could be
helpful in this groups
efforts. You guys are the only other ham group I am aware of that is
discussing DTNs
and store and forward techniques.
I have been trying to keep up with all the DTN, sensor network, pocket
networks etc.
with papers published to the Internet. Our field work shows that the
spread spectrum
used in Wi-Fi devices is amazingly immune / tolerant of noise. Our
longest unamplified
link with 35mw gear has been 15.67 miles using 24dB ganin BBQ grill dishes.
We have also shown that by changing the crystal in the RF section of
the WRT54G,
we can move all the Wi-Fi channels more into the ham band. Even
operating in the
shared ISM band we are invisible to standard 802.11 equipment as we
are out of spec,
both in center frequency and spread spectrum timing. Only two like
modified radios
will talk to each other. The crystals used for the mods cost us 54
cents each. We
call this a "fixed slide band" modification
I am currently working on a variable crystal modification that will
allow us to slide up
and down the band dynamically. This we call a "dynamic slide band
modification".
With this modification we will be able to slide up and down the band
under firmware
control, using the algorithm of our choice. We can make big jumps in frequency
and the OLSR firmware will relink us in 5 seconds, or we can slew the
crystal frequency
at a rate that allows us to maintain data flow during the slide.
We did this work to get around the hysteria regarding sending patent data from a
hospital to the city or state EOC.
This modification works because of the highly cost optimized design of
the WRT54G
wireless router where all RF timing is derived from a single crystal.
A similar mod
might work on other wireless routers, but we have limited resources
for development
and testing.
We have done extensive solar power testing and a Linksys WRT54GL attached to
a nominal 60 watt solar array and a 55 amp hour array will run
indefinitely in Texas.
Our mobile and portable work includes file transfers between moving
vehicles as well
as moving vehicles to a fixed station. All the key developers are interested in
astronomy and we provide Internet access to about 800 amateur astronomers from
the Prude Guest Ranch near Fort Davis and the McDonald Observatory in
west Texas,
using a 802.11a backbone to support 802.11b/g access for the
astronomers. Lots of
good experience has been gained making this system work the last few years.
On the long ride home from the Texas Star Party, we have passed files
and live IP video between vehicles for hours
to gain a feel for the TCP time outs when vehicles loose link then
relink going over hills
and around bends.
Transverters would be of interest. www.fab-corp.com is already
selling a transverter
to move 2.4 GHz Wi-Fi radios into a government band.
<http://www.fab-corp.com/home.php?cat=297>
With a transverter to another band and turning on good software
encryption makes for
a good high bandwidth radio for non Part-97 users.
The bulk of our intellectual property is Linux related code and is
portable even if the
Linksys WRT54GL goes out of production. A laptop running Linux with a
Wi-Fi card
makes a great mesh node. The WRT54G is just a super optimized low power node
with no moving parts that costs about $50.00 quantity 1 retail.
So yes, some of us are using Wi-Fi equipment. It has been a
particularly over ambitious
effort to get a working, self configuring network developed. Now we
have to make best
speed through the bureaucracy needed to obtain sites and that is in progress.
Inexpensive transverters would be most welcome. The Roadrunner Microwave guys
are testing Bi-Direction Amplifiers to extend range and discussing
transverter designs.
We need to develop some easy to use ham related applications. As much of a
achievement as getting the base network going, most ask "how about
some content".
We are working on a lightweight VoIP application as well as portable
servers with no
moving parts for field use.
I told the guys that we needed to get the basics working and by the
time we got that
done, the "smart guys" would have some store and forward and data mule
applications
for us to use on our network.
We stuck with IPv4 but the latest firmware has mods moving us towards
IPv6. IPv6 addresses
some of the problems we encounter with portable and mobile stations.
No need to invent
a non standard wheel. Our served agencies use IPv4 and will some day
be forced to
move to IPv6. Our systems are installed in the hospitals as a
physically separate network
from the network already in the building. Sticking with standard
IPv4 and eventually IPv6,
makes it easy to link in our served agencies.
We could, with the permission of the building IT director, link our
system to the building network easily. We have found it useful to refer to
our outdoor shielded CAT-5 type cable serving the mesh nodes as "feed
line" so it
gets run along with the other radio coax from the roof. Call it CAT-5
cable in one
meeting with the hospital IT folks and they can freak out! Best to
side step the issue
and call it feed line.
The hospital nodes are being linked as best we can by nodes on private
amateur radio
towers. These links form pocket networks. Due to security concerns,
we are not
allowed to get an Internet link from the hospital networks at this
time. So we provide
Internet access via a portable link or a link to a ham node in the
area of the hospital.
We have scouted out a number of parking garages in the area that can serve as
temporary portable sites to link pocket networks in our areas, as needed, for a
specific event.
We have been keeping a low profile because for most people, including most hams,
if you do not have a network in place with web page servers and other
content and
applications like VoIP in place, they ask "what is your network it good for?"
The work we have done for our local project might be useful in some of
your network
plans. I will be watching this group carefully for store and forward
and data mule
applications.
Our mesh network is called ARES-NET. It is designed to benefit ham
radio in service
to the community. Although the users call sign is saved in flash
memory during the
configuration phase of a node, and is transmitted in clear text every
10 minutes automatically,
no one hams call sign is used in the network projects name. It is a
group project and to have a single hams call as part of the the
projects name, is considered inappropriate by the developers.
We have a developers only, non advertised Yahoo site that contains the
information
related to the project for the last few years. We are are careful to
only have developers
as part of the group. They must contribute in some way, not just be
asking questions
all the time.
I have met a number of the hams on this list. I am sure you do not remember me,
but I know there are some of the heavy hitters in the ham community
here and they
can make things happen. Your help, interest and advice are most welcome.
I moderate the Austin HSMM SIG development group and would be happy to add some
of you to the Yahoo group if you feel it would be useful. We have
done some good
work, but is it just a part of an overall system. There are about 6
key developers and
we do our work in our spare time, and we are a bit pooped, just
getting the basics working.
We could use your help with the other big chunks of a comprehensive system.
-Glenn
kd5mfw@arrl.net
On Tue, Dec 2, 2008 at 2:00 PM, <mep-dev-request@uppermeadow.com> wrote:
> Send Mep-dev mailing list submissions to
> mep-dev@uppermeadow.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.uppermeadow.com/mailman/listinfo/mep-dev
> or, via email, send a message with subject or body 'help' to
> mep-dev-request@uppermeadow.com
>
> You can reach the person managing the list at
> mep-dev-admin@uppermeadow.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Mep-dev digest..."
>
>
> Today's Topics:
>
> 1. RE: A Simple "What If?" (Bob McGwier)
> 2. MEP as an IP Network (Timothy J. Salo)
> 3. Re: MEP as an IP Network (Timothy J. Salo)
> 4. Re: MEP as an IP Network (Paul Williamson)
>
> --__--__--
>
> Message: 1
> From: "Bob McGwier" <rwmcgwier@gmail.com>
> To: "'Michelle'" <w5nyv@yahoo.com>,
> "'mep'" <mep-dev@uppermeadow.com>
> Subject: RE: [Mep-dev] A Simple "What If?"
> Date: Tue, 2 Dec 2008 00:26:06 -0500
> Organization: N4HY
>
> This is a multipart message in MIME format.
>
> ------=_NextPart_000_00FD_01C95414.93A17180
> Content-Type: text/plain;
> charset="us-ascii"
> Content-Transfer-Encoding: 7bit
>
> They shouldn't be afraid of these bandwidths or these frequencies. This is
> easily within range of several RF IC's that will deliver IQ data to an SDR
> and even if we need to do IQ imbalance correction (we will) this is easily
> done. The tricky part is getting the oscillators. There are competing
> interests here: high stability, good precision, and cheap. Those are
> competing against each other for the dollars.
>
>
>
> Bob
>
>
>
>
>
> ARRL SDR Working Group Chair
>
> Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
>
> NJQRP, QRP ARCI, QCWA, FRC.
>
> "And yes I said, yes I will Yes", Molly Bloom
>
>
>
> From: mep-dev-admin@uppermeadow.com [mailto:mep-dev-admin@uppermeadow.com]
> On Behalf Of Michelle
> Sent: Monday, December 01, 2008 9:38 AM
> To: mep
> Subject: Re: [Mep-dev] A Simple "What If?"
>
>
>
> Well, let's try it and find out.
>
>
>
> At the very worst, it's a prototype along the way and we learn a lot. At the
> very best, it's a cheap, available, standards-based systems component of a
> MEP implementation. Sounds like a win-win to me.
>
>
>
> Anyone on the list already working with WiFI gear? I'm expecting
> transverters from the San Bernardino Microwave Society "real soon now". They
> are expected to be about $100, and they seemed unafraid of the 10MHz
> bandwidth requirement and the dual-band intent.
>
>
> -Michelle W5NYV
>
>
>
>
> ------=_NextPart_000_00FD_01C95414.93A17180
> Content-Type: text/html;
> charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> <html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
> xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
> xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
> xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
> xmlns=3D"http://www.w3.org/TR/REC-html40">
>
> <head>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Dus-ascii">
> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
> <style>
> <!--
> /* Font Definitions */
> @font-face
> {font-family:Calibri;
> panose-1:2 15 5 2 2 2 4 3 2 4;}
> @font-face
> {font-family:Tahoma;
> panose-1:2 11 6 4 3 5 4 4 2 4;}
> /* Style Definitions */
> p.MsoNormal, li.MsoNormal, div.MsoNormal
> {margin:0in;
> margin-bottom:.0001pt;
> font-size:12.0pt;
> font-family:"Times New Roman","serif";}
> a:link, span.MsoHyperlink
> {mso-style-priority:99;
> color:blue;
> text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> {mso-style-priority:99;
> color:purple;
> text-decoration:underline;}
> span.EmailStyle17
> {mso-style-type:personal-reply;
> font-family:"Calibri","sans-serif";
> color:#1F497D;}
> .MsoChpDefault
> {mso-style-type:export-only;
> font-size:10.0pt;}
> @page Section1
> {size:8.5in 11.0in;
> margin:1.0in 1.0in 1.0in 1.0in;}
> div.Section1
> {page:Section1;}
> -->
> </style>
> <!--[if gte mso 9]><xml>
> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
> </xml><![endif]--><!--[if gte mso 9]><xml>
> <o:shapelayout v:ext=3D"edit">
> <o:idmap v:ext=3D"edit" data=3D"1" />
> </o:shapelayout></xml><![endif]-->
> </head>
>
> <body lang=3DEN-US link=3Dblue vlink=3Dpurple>
>
> <div class=3DSection1>
>
> <p class=3DMsoNormal><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
> color:#1F497D'>They shouldn’t be afraid of these bandwidths or =
> these
> frequencies. This is easily within range of several RF IC’s =
> that will deliver
> IQ data to an SDR and even if we need to do IQ imbalance correction (we =
> will)
> this is easily done. The tricky part is getting the =
> oscillators. There are
> competing interests here: high stability, good precision, =
> and cheap. Those
> are competing against each other for the dollars.<o:p></o:p></span></p>
>
> <p class=3DMsoNormal><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
> color:#1F497D'><o:p> </o:p></span></p>
>
> <p class=3DMsoNormal><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
> color:#1F497D'>Bob<o:p></o:p></span></p>
>
> <p class=3DMsoNormal><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
> color:#1F497D'><o:p> </o:p></span></p>
>
> <p class=3DMsoNormal><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
> color:#1F497D'><o:p> </o:p></span></p>
>
> <div>
>
> <p class=3DMsoNormal><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
> color:#1F497D'>ARRL SDR Working Group Chair<o:p></o:p></span></p>
>
> <p class=3DMsoNormal><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
> color:#1F497D'>Member: ARRL, AMSAT, AMSAT-DL, TAPR, =
> Packrats,<o:p></o:p></span></p>
>
> <p class=3DMsoNormal><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
> color:#1F497D'>NJQRP, QRP ARCI, QCWA, FRC.<o:p></o:p></span></p>
>
> <p class=3DMsoNormal><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
> color:#1F497D'>"And yes I said, yes I will Yes", Molly =
> Bloom<o:p></o:p></span></p>
>
> </div>
>
> <p class=3DMsoNormal><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
> color:#1F497D'><o:p> </o:p></span></p>
>
> <div>
>
> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
> 0in 0in 0in'>
>
> <p class=3DMsoNormal><b><span =
> style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
> </b><span
> style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
> mep-dev-admin@uppermeadow.com [mailto:mep-dev-admin@uppermeadow.com] =
> <b>On
> Behalf Of </b>Michelle<br>
> <b>Sent:</b> Monday, December 01, 2008 9:38 AM<br>
> <b>To:</b> mep<br>
> <b>Subject:</b> Re: [Mep-dev] A Simple "What =
> If?"<o:p></o:p></span></p>
>
> </div>
>
> </div>
>
> <p class=3DMsoNormal><o:p> </o:p></p>
>
> <div>
>
> <div>
>
> <p class=3DMsoNormal>Well, let's try it and find out.<o:p></o:p></p>
>
> </div>
>
> <div>
>
> <p class=3DMsoNormal> <o:p></o:p></p>
>
> </div>
>
> <div>
>
> <p class=3DMsoNormal>At the very worst, it's a prototype along the =
> way and
> we learn a lot. At the very best, it's a cheap, available,
> standards-based systems component of a MEP implementation. Sounds =
> like a
> win-win to me. <o:p></o:p></p>
>
> </div>
>
> <div>
>
> <p class=3DMsoNormal> <o:p></o:p></p>
>
> </div>
>
> <div>
>
> <p class=3DMsoNormal>Anyone on the list already working with WiFI gear? =
> I'm
> expecting transverters from the San Bernardino Microwave Society
> "real soon now". They are expected to be about $100, and they =
> seemed
> unafraid of the 10MHz bandwidth requirement and the dual-band =
> intent.<br>
> <o:p></o:p></p>
>
> </div>
>
> <p class=3DMsoNormal>-Michelle W5NYV<o:p></o:p></p>
>
> <div>
>
> <div>
>
> <div>
>
> <p class=3DMsoNormal><span =
> style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p> </=
> o:p></span></p>
>
> </div>
>
> </div>
>
> </div>
>
> </div>
>
> </div>
>
> </body>
>
> </html>
>
> ------=_NextPart_000_00FD_01C95414.93A17180--
>
>
> --__--__--
>
> Message: 2
> Date: Tue, 02 Dec 2008 12:53:02 -0600
> From: "Timothy J. Salo" <salo@saloits.com>
> To: mep <mep-dev@uppermeadow.com>
> Subject: [Mep-dev] MEP as an IP Network
>
> Michelle wrote:
>> I strongly agree with the goal of making MEP a fully functional
>> IP network. That is the baseline assumption, and should be explored,
>> challenged, and talked about until we are more than fully convinced it's
>> the right thing to do, where "it" is well-defined. This leads directly
>> to identifying the requirements for fully supporting IP.
>
> I'm sort of working on it. My AMSAT 2008 paper is a start.
> An MEP interface specification that describes how the MEP
> interfaces with its users will be a fundamental document.
>
> My objective is that the MEP be indistinguishable from other
> IP networks. It should connect to both devices (e.g., a
> personal computer) and networks (e.g., a home network or
> even the Internet).
>
> Doing this well requires more than simply forwarding IP
> packets. For example, RFC 1812, the original "Requirements
> for IP Version 4 Routers" is 175 pages long. Plus, it is
> incomplete and probably wrong in places. One significant
> implication of this is that we should think about whether
> the remote/ground stations ought to (or must) run a traditional
> operating system, such as Linux (or an embedded Linux variant).
> This would enable the MEP to leverage a large body of existing
> software.
>
>> What are the repercussions of amateur radio communicating over a
>> fully functional IP network? What possibly unexpected requirements do we
>> incur upon ourselves by doing so? Are authentication and security and
>> identification controversial issues, or are they now so embedded in the
>> communications ecosystem that to remove these functions would be
>> negative?
>
> I'm probably sure what the questions are, but...
>
> The one unique requirement I can think of is the need to
> identify the transmitting station. AX.25 decided to use
> call signs for both station identification and routing.
> As a result, AX.25 doesn't interoperate with anything else.
> I believe that the MEP ought to route on IP addresses and
> add text-based station identification somehow.
>
> For regulatory station identification purposes, one could
> simply put the station identification in an IP option.
> This is transparent to IP networks (well, except for ISPs
> that discard packets with options, because IP options all
> but break commercial routers). This "station identification"
> should be a text string that is transparent to the MEP. It
> might contain a call sign. It might contain other information.
> But, to the MEP it is simply an opaque text string. And, the
> MEP should know how to translate between these station
> identification text strings and IP addresses, as described
> below.
>
>> Is the transport protocol truly unaffected by the type of
>> traffic, which is a hallmark axiom of layered protocols? In other words,
>> is there anything in particular about amateur radio that would cause a
>> change in the requirements for IP?
>
> The notion of a universal protocol that transports everything
> has been around for a while. In the 1990s it was ATM, which was
> supposed to carry voice, private lines, video, and data. IP has
> pretty much taken over as the universal protocol. Perhaps,
> the biggest challenge for the MEP and the ACP is to handle
> the short packets used by voice gracefully. But, I think this
> is an FEC issue, not an IP issue.
>
>> Searching, rooms, filters, friends lists,
>> modeling, quality of service, and other fun things that are enabled by a
>> rich set of metadata certainly start to sound a lot like "accounting".
>
> I don't know what "searching, rooms, filters, friends lists"
> are, but they all sound like applications that might use the MEP,
> rather than functionality that should be provided by the MEP
> (which, I claim, ought to be an IP network). I think about all
> these applications need from the MEP is a way to translate
> between text station identifiers and IP addresses, and a way
> to know the station identifiers of the active stations. I
> think that hosts should be able to use the DNS to perform
> this translation. The MEP remote/ground station ought to
> provide a DNS resolver.
>
>> Do you (all) think that the the lack of pressure to make the service pay
>> for itself (as opposed to possibly trying to make the hardware come in
>> at cost) might make any difference to the design choices of the
>> protocols and the link?
>
> Probably not if we start with an IP network as a model.
>
>> Most of the examples that I am familiar with spend a lot of time on
>> accounting. Most of the satellite models and most cellular models have
>> to keep track of users and how long and how much they use the link, in
>> order to charge for it and make money.
>
> See above.
>
>> My first inclination is that the deletion of all the accounting
>> overhead would do two things - it would require some redesign of the
>> link, and it would possibly increase performance due to a lessening of
>> complexity.
>
> I doubt it, but would be happy to have someone explain how I
> am confused.
>
>> The level of accountability (authentication and security) needs to be
>> explored and discussed. How concerned should we be with harmful or
>> unauthorized use?
>
> At the RF level, you are probably out of luck. You can't prevent
> people from transmitting. A rich set of strong authentication
> and security capabilities are available with the Internet protocols.
> We should use them, rather than invent new ones.
>
>> A model to consider is D-Star, which
>> has repeater registration by call sign. This is a user-entry ID. So, to
>> me, it is the equivalent of stating your call sign on the air and
>> remains a voluntary, honor-system act.
>
> As I understand it, this is a very weak system. We ought to
> use cryptograpically based systems when we want to authenticate
> parties.
>
> -tjs
>
>
> --__--__--
>
> Message: 3
> Date: Tue, 02 Dec 2008 13:09:56 -0600
> From: "Timothy J. Salo" <salo@saloits.com>
> To: mep <mep-dev@uppermeadow.com>
> Subject: Re: [Mep-dev] MEP as an IP Network
>
> Timothy J. Salo wrote:
>> I'm probably sure what the questions are, but...
> ^^^^
> not sure
>
> -tjs
>
>
> --__--__--
>
> Message: 4
> Date: Tue, 2 Dec 2008 11:59:17 -0800
> From: "Paul Williamson" <paul@mustbeart.com>
> To: "Timothy J. Salo" <salo@saloits.com>
> Subject: Re: [Mep-dev] MEP as an IP Network
> Cc: mep-dev@uppermeadow.com
>
> On Tue, Dec 2, 2008 at 10:53 AM, Timothy J. Salo <salo@saloits.com> wrote
>> For regulatory station identification purposes, one could
>> simply put the station identification in an IP option.
>
> That would identify the originator of the packet, not the transmitter,
> so it doesn't solve the regulatory station ID requirement. Assuming of
> course that you don't want to rewrite every packet at every node.
>
> I don't think anything fancy is required here, legally. Just put the
> callsign into a UDP packet addressed to nowhere and transmit that as
> required (every ten minutes when the transmitter is active).
>
>> A rich set of strong authentication
>> and security capabilities are available with the Internet protocols.
>> We should use them, rather than invent new ones.
>
> We have to be careful to pick ones that never encrypt the payload, in
> order to be legal in the United States. Even then, we will probably be
> illegal in most other places if we use any cryptography, even for
> authentication.
>
>
> --__--__--
>
> _______________________________________________
> Mep-dev mailing list
> Mep-dev@uppermeadow.com
> http://lists.uppermeadow.com/mailman/listinfo/mep-dev
>
>
> End of Mep-dev Digest
>