Subject: [NEXTEL-1] Area agencies seek $6 million in grants for radio system

From: [email-masked]
Date: Sun, 05 Oct 2003 04:58:24 -0400

Area agencies seek $6 million in grants for radio system

BY JACOB LOPEZ, Staff Writer
Sep 19, 2003

Yuma area public safety and public service agencies hope to get up to $6 million
in state and federal grants for a new radio system that one Yuma city official
says would allow them to communicate between each other more effectively and less
expensively.
Area fire and police departments, the Yuma County Sheriff's Office, Arizona Public
Service Co. and the U.S. Border Patrol are among the agencies that could benefit
from the high-speed Project 25 Digital 800/700 MHz Trunked Radio System.

With this new system, said Greg Wilkinson, assistant director for information
technology services in Yuma, there would be one provider, Motorola, for all the
agencies. As a result, cost and maintenance would be reduced, he said.

Another advantage is all the agencies would be able to communicate with each other
with the push of a button, Wilkinson said. He added they could talk with their own
agency and still be able to listen to other agencies at the same time.

They would also be able to communicate on their own private frequency when needed.

He said with the current system, there is an interim solution for some radios
where operators can switch frequencies to talk to other agencies. But Wilkinson
said the operators can only listen to one agency at a time, and only certain
operators in the field have this limited option in their vehicles.

Wilkinson said Phoenix and Mesa have integrated this new radio service into their
communications system and it is successful.

He said the city will pursue the grants through state and federal sources over the
next six months. If the funding comes through, the system could be in place in one
to two years, he said.

The system would include four radio transmitters strategically located throughout
the region, Wilkinson said. Radios would be placed in each agency's vehicles and
home bases.

He said servers would be placed at the buildings, containing data bases that would
microwave voice information to radio towers and then transmit it to the users in
the field.
Wilkinson said the region served by the system would take in all of Yuma and
stretch south to San Luis, Ariz., west into California and as far east as Roll.

Wilkinson said the agencies would share the cost of the radio service and
maintenance would be reduced as well.

He said he talked with representatives from 70 agencies in the area about this new
communications system, and he hopes the agencies will adopt it. Half of the
agencies have said yes to thesystem, Wilkinson said, while the other half said
they needed to discuss the plan with their superiors.

The more agencies in favor of the new communications system the better, Wilkinson
said, because they would give the city a better chance of receiving the grant
money.
"With today's technological system, everyone can communicate with everyone else
and it's cost-effective," Wilkinson said. "It's a win-win situation all the way
around.”
http://yumasun.com/artman/publish/articles/story_7292.shtml

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
Printer at MyInks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/61FxlB/TM
---------------------------------------------------------------------~->

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

---

From: Todd Marshall <[email-masked]>
Date: Sun, 05 Oct 2003 17:50:51 -0500

UWB/ATM Micro Web Configuration:
================================
Yuma, AZ
================================
Node cost: $200
Appropriation ($M): $    6.000
Area: 27.2 sq. mi
Population:    77515
Appropriation per person: $77
Total potential nodes:    30000
Link distance: 175ft
1 out of 2.6 people become nodes
================================
If all people were nodes:
--------------------------------
Link distance: 110ft
Node cost (after subsidy): $123

[email-masked] wrote:

> around."
> Yahoo! Groups Sponsor
> <http://rd.yahoo.com/M=259395.3614674.4902533.1261774/D=egroupweb/S=1707367802:HM/A=1524963/R=0/SIG=12o885gmo/*http://hits.411web.com/cgi-bin/autoredir?camp=556&lineid=3614674&prop=egroupweb&pos=HM> 
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service 
> <http://docs.yahoo.com/info/terms/>.

---

From: Todd Marshall <[email-masked]>
Date: Mon, 06 Oct 2003 09:09:51 -0500

Hi Paul,

Below are some links that allude to what I am describing as the UWB/ATM 
Microweb.

It looks like I may have tobe the one who writes the white paper.

All the concepts I've found links to get my general idea. But they fail 
to get the essence of what I believe to be the proper implementation.

In very simple terms, the concept is this:

At layer 1 we have UWB "underlaying" existing bands without disturbing 
licensed users. Each transciever is a node (as small and probably 
cheaper than a cell phone). It automatically seeks to socialize with 
immediately adjacent nodes and forms links ...  and those nodes and 
links form a web. For the most part these are very quiet as they only 
need to chirp once in a while in a stay alive fashion. The more dense 
the nodes (e.g. at a rock concert or public calamity) the shorter the 
links. The shorter the links, the lower the power needed to reach the 
nearest nodes. Thus, with congestion, the overall noise goes down and 
the bandwidth available goes up (just the opposite of what we experience 
with classical techniques).

At layers 2-4 we have an ATM like protocol. Here, the data is sent over 
the links as very small cells (probably 35 bytes)  with a small 
(probably 32 byte) payload. If a cell can move through a node in a 
microsecond, that makes  256Mbps linkage. If we're dealing with 
compressed digitized voice, we may only require 8Kbps meaning a node 
could potentially be relaying 32 million voice calls. By keeping the 
cells small we avoid the latency problems which  IP suffers. The 
challenge is to collect these cells into virtual connections (a 
challenge ATM techniques serve naturally). These virtual connections 
will make up a virtual call. A virtual call is a collection of 
connections between two end  points (i.e. nodes).

The concept proposes ATM like switching. This means that at call setup, 
the path across the web is negotiated and locked down for the QoS 
requested by the connection. Each cell passes through the same 
progression of nodes (unlike IP which must discover its route with every 
packet). So as each cell reaches a node, 1 microsecond later, it's on to 
the next node, until it reaches its destination.

Each node will naturally know is latitude/longitude (using GPS like 
techniques). Users will authenticate themselves as an endpoint at the 
node they are using (note anyone can potentially use any node ... this 
is different than your cell phone). Computer techniques will maintain 
dictionaries of participants and the lat/lon of their nodes in real 
time. The protocol for this will be "ET - call home" like. As the party 
moves about, his node dynamically sets up a connection to his home 
telling where he is (actually there is an optimization that makes this 
simpler). When people want to reach him, they call his home and get his 
current node identity and location. The protocol then uses "trip 
planning" like techniques to navigate across the web to set up the 
connection.

Once an end to end connection is established, it's just mechanical 
toggling of cells across the nodes. With 500 ft links we would have over 
32,000 hops to go across the country. However, with each hop only taking 
a microsecond, we could potentially deliver that 256Mbps coast to coast 
with a latency of 31 milliseconds.

How does this all come about?

I think it begins as a novelty. You create the radios and sell them like 
toy walkie talkies (and potentially as cheap). Buy two and two people 
can talk 500'. Buy three and three people can talk 1000'. Buy 4 ... you 
see the progression. Pretty soon everyone in your neighborhood has one 
and can talk to everyone else. Pretty soon, all neighborhoods in the 
city have them and anyone can reach anyone else in the city. Pretty soon 
all cities have them and anyone can reach anyone in the country. Pretty 
soon all countries have them and anyone can reach anyone in the world.

And it can all happen spontaneously. No one owns it. No one collects a toll.

Putting this all in perspective, the money being spent on P25 would buy 
the needed nodes. That's what my "endless posting of these numbers" 
illustrates.
/Todd

Some links ... mostly untechnical in nature.

The next bout: 3G versus BWA
Discusses Broadband Wireless Access encroachment on classical  cell 
phone initiatives like 3G. Shows that there is a movement away from 
carrier controlled licensed spectrum and into protocol controled 
unlicensed spectrum.
http://www.3gnewsroom.com/3g_news/sep_03/news_3793.shtml

Open Spectrum: The New Wireless Paradigm
A ways to implement open spectrum technologies is to “underlay” 
unlicensed technologies in existing bands, without disturbing licensed 
uses. This approach, epitomized by the ultra-wideband technology the FCC 
authorized earlier this year, effectively manufactures new capacity by 
increasing spectrum efficiency.
http://werbach.com/docs/new_wireless_paradigm.htm

Peter Cochrane's Uncommon Sense: Mobile guesses
A multitude of small digital radio units costing $50 screwed to the side 
of every house and office building connected to a PC, hundreds of cars 
and trucks carrying a similar capability, and every laptop, PC and PDA, 
all wireless-enabled, will see the emergence of a new form of mobile 
network.
http://www.silicon.com/opinion/500018-500001/1/6057.html

The 100 Mile-Per-Gallon Carburetor: How Ultra Wide Band May (or May Not) 
Change the World
The first commercial UWB radios will probably be use for wireless 
computer networks (GE is working on that) and portable phones. UWB 
computer networks being developed now will initially operate at 40 to 60 
megabits-per-second, or four to six times as fast as the most common 
networking technologies now in use. Researchers think that UWB networks 
may eventually run at speeds up to a gigabit-per-second, and therefore, 
should be able handle all the phone, television, and Internet traffic 
for any home or business. And since UWB radios don't interfere with each 
other, every home and business in the neighborhood can have its own 
gigabit.
http://www.pbs.org/cringely/pulpit/pulpit20020124.html

TRINITY for Media-rich Wireless Applications PRODUCT BRIEF
ExteremeSpectrum and others are building UWB chips
http://www.xtremespectrum.com/PDF/xsi_trinity_brief.pdf

Boeing gathers "networked battlefield" partners
FCS aims to link troops in the field with surveillance satellites, 
aircraft, artillery, warships and their commanders with wireless 
Internet-like connections, making military operations more efficient.
http://www.forbes.com/technology/newswire/2003/09/19/rtr1086949.html

Paul Timmins wrote:

>Do you have any links to useful whitepapers, documents, technical
>writeups, or equipment manufacturers for UWB/ATM Micro Web? I guess you
>could say your endless posting of these numbers has got me curious what
>the technology is capable of, and I figure if you post these, you must
>know some good links so I can get more information about it.
>Thanks!
>-Paul
>
>
>On Sun, 2003-10-05 at 18:50, Todd Marshall wrote:
>  
>
>>>Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>>>      
>>>
>>                        Yahoo! Groups Sponsor
>>                                          ADVERTISEMENT
>>                                             click here
>>
>>Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>>    
>>

---

From: Paul Timmins <[email-masked]>
Date: Mon, 06 Oct 2003 10:53:54 -0400

Is there somewhere I can buy some of this equipment, or plans to
construct it?
Can the operation be restricted to specific bands with part 15
limitations, operate within spec for that band under part 15, and still
work with the kind of numbers you quote?
How many people could be in one spot before the noise floor has risen so
high you can no longer use the band?
How would a device determine an end to end route? Would the contact have
to be made within one hop's range and then stretched apart, or would
there be some sort of rendezvous server?
What kind of modulations would be used, and what's the maximum
signalling rate if I were limited to using the 900, 2.4, and 5.8Ghz part
15 bands for legal or political reasons?
What is the potential for interference to licensed users if subscriber
density dictates usage of the highest power the node is capable of?
What protection is there from rogue nodes?
Can a terrorist or angered individual create a node that will draw
public safety (or other types of traffic) toward it, then throw it away
while routing housekeeping packets and other types of traffic so as to
interfere?
Would the implementation include something to enforce data integrity?
How does the network deal with me marking my bulk traffic as "High
Priority" (IOW, can I set my own precedence over other arguably more
important users?)
How would you approach a city government about placing hardened UWB/ATM
Microweb nodes on streetlights or other city structures, without
replacing their trunked radio system, say if you wanted to offer
commercial service with it?
Would this demand any wired infrastructure?
How much CPU and memory would each node require?
How would a corporation provide for billing if the management was done
by a private enterprise? 
Is there a centralized infrastructure for authorizing a node before it
accesses the network?
Could I sell it as a replacement for inter-location PRI circuits between
company branches?
How many hops would a packet have to take before it reached a 250ms time
in flight?
Would routing changes cause jitter in packet flow?
Would it be difficult to rate limit data traffic based off of a tiered
service model?
I see the name "ATM" in there. Does this mean that large data frames
would have to be broken up into cells, and if so, how would this affect
my overall throughput?
Does it have a viable business model outside of walkie talkies?
Would there be inefficiencies if I wanted to do a one to many
application, (i.e. "Calling all cars, please be on the lookout for a
white boneville with plate number xxxx, please consider armed and
dangerous")?
Would I waste bandwidth by using an application like telnet over it,
where it sends a packet containing a one byte payload?
How does geographic routing work when the mobile node is incapable of
receiving GPS or Loran signals, like on the shop floor of an industrial
plant? Would it conflict with Patent #5,400,338?
Does the geographic routing conflict with US Patents #4,939,726, and
#5,115,433?
-Paul

On Mon, 2003-10-06 at 10:09, Todd Marshall wrote:
> Hi Paul,
> 
> Below are some links that allude to what I am describing as the
> UWB/ATM Microweb.
> 
> It looks like I may have to be the one who writes the white paper. 
> 
> All the concepts I've found links to get my general idea. But they
> fail to get the essence of what I believe to be the proper
> implementation.
> 
> the bandwidth available goes up (just the opposite of what we
> experience with classical techniques).
> 
> At layers 2-4 we have an ATM like protocol. Here, the data is sent
> over the links as very small cells (probably 35 bytes)  with a small
> The concept proposes ATM like switching. This means that at call
> setup, the path across the web is negotiated and locked down for the
> QoS requested by the connection. Each cell passes through the same
> progression of nodes (unlike IP which must discover its route with
> every packet). So as each cell reaches a node, 1 microsecond later,
> it's on to the next node, until it reaches its destination. 
> 
> time. The protocol for this will be "ET - call home" like. As the
> party moves about, his node dynamically sets up a connection to his
> home telling where he is (actually there is an optimization that makes
> this simpler). When people want to reach him, they call his home and
> get his current node identity and location. The protocol then uses
> "trip planning" like techniques to navigate across the web to set up
> the connection.
> 
> toggling of cells across the nodes. With 500 ft links we would have
> over 32,000 hops to go across the country. However, with each hop only
> taking a microsecond, we could potentially deliver that 256Mbps coast
> to coast with a latency of 31 milliseconds.
> 
> I think it begins as a novelty. You create the radios and sell them
> like toy walkie talkies (and potentially as cheap). Buy two and two
> people can talk 500'. Buy three and three people can talk 1000'. Buy 4
> ... you see the progression. Pretty soon everyone in your neighborhood
> has one and can talk to everyone else. Pretty soon, all neighborhoods
> in the city have them and anyone can reach anyone else in the city.
> Pretty soon all cities have them and anyone can reach anyone in the
> country. Pretty soon all countries have them and anyone can reach
> anyone in the world.
> 
> Putting this all in perspective, the money being spent on P25 would
> buy the needed nodes. That's what my "endless posting of these
> numbers" illustrates.
> /Todd
> 
> 
> uses. This approach, epitomized by the ultra-wideband technology the
> FCC authorized earlier this year, effectively manufactures new
> capacity by increasing spectrum efficiency.
> A multitude of small digital radio units costing $50 screwed to the
> side of every house and office building connected to a PC, hundreds of
> cars and trucks carrying a similar capability, and every laptop, PC
> and PDA, all wireless-enabled, will see the emergence of a new form of
> mobile network.
> The 100 Mile-Per-Gallon Carburetor: How Ultra Wide Band May (or May
> Not) Change the World
> computer networks being developed now will initially operate at 40 to
> 60 megabits-per-second, or four to six times as fast as the most
> common networking technologies now in use. Researchers think that UWB
> networks may eventually run at speeds up to a gigabit-per-second, and
> therefore, should be able handle all the phone, television, and
> Internet traffic for any home or business. And since UWB radios don't
> interfere with each other, every home and business in the neighborhood
> can have its own gigabit. 
-- 
Paul Timmins <[email-masked]>

---

From: Todd Marshall <[email-masked]>
Date: Mon, 06 Oct 2003 11:51:14 -0500

>Is there somewhere I can buy some of this equipment, or plans to
Not yet that I know of. But I can assure you there's a military skunk 
works out there that already has it operating. This is not rocket science.

>work with the kind of numbers you quote?
I don't know. One way is to shape the pulse so it contains no frequency 
component in the specific band. Another is to filter the output so it 
doesn't transmit in a specific band. Both are problematic. From what 
I've read, the best way is to just go real low power and lurk with the 
legal noise.

>high you can no longer use the band?
As people congregate, the energy in the pulses is reduced. The power 
need goes down by the square of the distance. So the more congestion 
(i.e. shorter the links) you have, the smaller the contribution to the 
noise floor.

>How would a device determine an end to end route? 
>
Conceptually, in a fashion similar to the way trip planning software 
routes your trip. Only it would be much simpler since all streets 
between nodes would be as-the-crow-flies.

>Would the contact have
There would be no rendezvous server. You would have a fixed home node 
which you would advertise to your callers. This fixed home node would 
know about your current mobile position. Nodes would socialize with each 
other and set up links and adjust power such that they transmit with 
just enough power to reach their adjacent links with reliable BER. It's 
likely the protocol would have intermediate home nodes at the first 
fixed node with capability for it (being fixed they could have more 
memory and more power ... to do computing and data storage.). Rather 
than reporting all the way home, you would report this fixed node 
position home and then report your moving position to it. In a way, that 
would be your rendezvous server ... dynamically chosen and replaced.

>15 bands for legal or political reasons?
Modulations are not used. The transmission is just a pulse in the 
time-domain which in the frequency domain is a level containing all 
frequencies. As I said earlier, the pulse may need to be shaped to stay 
legal. Hopefully, it could just lurk in the noise floor.

>density dictates usage of the highest power the node is capable of?
Power would never exceed "legal" limits. If a link could not be 
established without exceeding the limit, the node would not be usable.

>What protection is there from rogue nodes?
What kind of attack are the rogue nodes presenting? As in normal 
conversation, it takes two. When one talks over the other, the offendee 
may disengage and go find someone else to talk to.

>while routing housekeeping packets and other types of traffic so as to
There is nothing special here with regards to public safety or any other 
user. As a person can call 911 with their cell phone, they could call 
911 here. The word routing only applies during call setup. After that, 
you have the route and you just switch the cells along that established 
route. Each connection will have a requested and granted QoS. The 
traffic would be regulated at the edges so violation would be 
disciplined at the first hop. This is very different from current IP 
strategies which have no way of throttling and shaping traffic at the edges.

>Would the implementation include something to enforce data integrity?
Yes. That would be handled at layers above layer 2. Problems would be 
mitigatged by maintaining a low bit rate reverse channel to report 
errors quickly (unlike TCP which takes a real long time to even know it 
is having a problem).

>Priority" (IOW, can I set my own precedence over other arguably more
When you request a connection within a call you specify the QoS you 
want. Once granted you are guaranteed that QoS. If that guarantee can 
not be granted, you must seek less QoS. This is all part of the call 
setup process. Once all the nodes in the path are on board, they manage 
their cell queues to deliver the granted QoS end to end.

>commercial service with it?
I really think it would come from the other direction. The use would 
become pervasive before the city governments bought into it. Kind of 
like now when we find police and firemen using their own cell phones 
when they're out of reach of their trunked system or its capacity is 
exceeded. In time there would be no need for the trunked system. This 
ubiquitous UWB/ATM Microweb would deliver more robust connectivity at no 
cost (beyond the cost of the node)

>Would this demand any wired infrastructure?
In the near west (e.g. Wyoming, Nevada, etc), it is likely nodes would 
be too sparse. Thus, it is likely that municipalities in those areas 
would employ directional antennas, fiber, or whatever other layer 1 is 
appropriate. The UWB/ATM would use that connectivity to emulate its 
native wireless protocol. Those bridge endpoints would be a super node 
with super capacity.

>How much CPU and memory would each node require?
Less than your current cell phone. Transwitch 
(http://www.transwitch.com/index_flash.jsp)  has interesting hardware 
that illustrates what is already being done in the implementation of ATM 
in Utopia II chipsets. My proposal would not use ATM. It would just use 
ATM-like cell transfer. ATM has cells traveling even when there is no 
traffic. My proposal would only have cells traveling when there is payload.

>How would a corporation provide for billing if the management was done
What are you billing for? Once one buys a node they pay nothing else.

>Is there a centralized infrastructure for authorizing a node before it
No. But there would have to be some licensing and inspection of hardware 
for compliance, just as we have now with all forms of radio.

>Could I sell it as a replacement for inter-location PRI circuits between
I think a lot of such concepts just become obsolete. The web would have 
enormous bandwidth and it would be very low cost (like zero) so the 
reason for setting up PRI circuits kind of goes away. Picture yourself 
at your PC and wanting to send an MPEG file to someone else. You just 
send it like an email. The protocol would be more transparent than IP is 
now ... and it would work. Further, say you wanted a 
audio/video/whiteboard conference. You make the call; add an audio 
connection; add a video connection; and add a whiteboard connection. You 
talk. You exchange visuals. You write on your whiteboard. When you're 
done, you hang up the call and its connections get hung up. All on demand.

>How many hops would a packet have to take before it reached a 250ms time
If a hop takes a microsecond, you could make 250,000 hops in 250 ms. At 
500' per hop that's about 25,000 miles.

>Would routing changes cause jitter in packet flow?
This is a huge issue. First, there would be no routing change unless 
there was a break in the connection. I propose that the connection is a 
function of the QoS demanded. It will take some experimentation. With a 
very long distance connection, the probability of a break becomes large. 
It is impractical to setup a complete new connection in such an event. 
Thus, nodes must be able to fix their own breaks in real time. This 
could mean that they maintain several  conceptual links which they can 
instantly press into service should they lose the link carrying the 
traffic. This is the largest challenge to a suitable protocol. However, 
because of the huge amount of bandwidth available to us and its low 
cost, maintenance of multiple simultaneous links will likey be 
practical. It then just becomes a case of reading another link if the 
one you're using goes dead ... the cells being duplicated and flowing in 
parallel. You don't have the problems that VoIP has. Its latencey is 
unpredictable as each packet finding its own route and can arrive out of 
order. ATM-like cells will flow in order and with predictable precision 
because the proposal is truly connection oriented.

>Would it be difficult to rate limit data traffic based off of a tiered
No. It would be very simple. The reason is that this is a totally 
"connection oriented" protocol. That means you have intimate control at 
the edges and all along the line. Once you're granted the QoS you 
request, it is deterministic. All the nodes set up their queues 
accordingly. And they always know their committments so they can reject 
a request for a link or connection. In such an event, the protocol just 
searches elsewhere. This is something a web can do that a trunked design 
cannot. Further, a violation of the "service level agreement" at the 
source is immediately disciplined at the first node. It doesn't enter 
the cloud and cause problems where mitigation is more difficult.

>would have to be broken up into cells, and if so, how would this affect
Yes. That's exactly why it can work. For example, if you have 8Kbps 
compressed voice and anything over 1/8 second delay is annoying, that 
means you can't hang around waiting for large data frames to fill. If 
the web itself had no latency, you could only wait for 125 bytes before 
you used up your 1/8 second. That's why I propose 32 byte cells with a 3 
byte header. You then only wait 1/32  of a second before you are on your 
way. That leaves 3/32 of a second of latency for the trip (93,000 hops). 
Now there are lots of reasons you won't get these numbers in practice 
but there are also lots of ways to mitigate issues that come up.

>Does it have a viable business model outside of walkie talkies?
This concept has an "enormous value proposition" and a really "weak 
business model". The only way to make money with it is by making and 
selling the nodes. And it can't work if someone tries to take a 
proprietary approach. Ubiquity is the key to it working ... no cell 
tower farms. The protocol must be developed completely in the open so 
attackers and defenders can joust continuously until the model is solid. 
Further, as new requirements and capabilities present themselves, the 
nodes need to be able to upgrade their software. You can't use the 
Microsoft model to do this. You have to use the OSS model. Further, all 
nodes must have a lowest common denominator bios. It must be 
uncorruptable and be able to bootstrap itself up to a currently safe 
software configuration from any cold start ... now and into the future.

>white boneville with plate number xxxx, please consider armed and
This would be handled in different ways by different players. In one 
case you could use the multi-level distribution model (video on demand). 
In other cases you might would use the leaf model (virtual classroom). 
The calling all cars model would likely be chain model where every 
interested car has linked itself into the chain. These are all software 
issues with their own strengths and weaknesses and behaviors.

>where it sends a packet containing a one byte payload?
No. Actually you would waste less than current IP. A 1 byte payload 
would waste 34 bytes of transmission capacity. With current IP we waste 
much more than that. Further, you could come up with a better telnet 
protocol since you have intimate, full duplex control of the connection.

>plant? 
If the node is able to link, it "is" a GPS-like signal itself. If 4 
other nodes have lat/lon information about themselves and it is 
"genetically diverse" then the node knows where it is with GPS accuracy. 
In the web there will be fixed and mobile nodes. Fixed nodes can have 
their location certified. The protocol could take this certfied location 
information into account to give a factor of merit to the mobile 
location. Again, there are interesting issues here. The purpose of the 
lat/lon is principally for addressing the node. As for the shop floor 
... it's likely every machine has some kind of processor and would thus 
be a potential node. Connectivity would be very good in such a plant.

>Would it conflict with Patent #5,400,338?
>
A quick scan of it looks like it may. That patent isn't very novel.

>Does the geographic routing conflict with US Patents #4,939,726, 
>
This one talks about absolute coordinates ... my method's coordinates 
are dynamic.

>and
Again ... absolute.

Patents today, especially with software, are problematic. People are 
getting patents for things that are not novel.

Really really good questions.

Thanks...
/Todd

---

From: Paul Timmins <[email-masked]>
Date: Mon, 06 Oct 2003 14:37:54 -0400

> (i.e. shorter the links) you have, the smaller the contribution to the 

But there will be a point where connection housekeeping, RF noise from
non UWB devices (Hi Nextel!), and other signals on the band would raise
the noise floor too much, especially in a disaster where everyone's
talking at the same time. You can only adjust a transmitter's output
power so low before it doesn't have enough of an RF impetus to make it
through the finals and still be intelligible to a receiver standing next
to you.  

> between nodes would be as-the-crow-flies.

So my subscriber unit would have to perform routing calculations and
hard-define a strict (or even a loose) route? How could it perform this
operation without knowing the signal quality of the devices in between?
And how big would the packet have to grow to support this strict route
across an installed base of thousands of nodes with mediocre line of
sight, like cellular phones or HTs?

> would be your rendezvous server ... dynamically chosen and replaced.

Perhaps the business model here would be to supply a home node, but
you've gotta have some sort of rendezvous server, or have a lot more
intelligence (and routing memory and CPU to calculate routing tables) in
the network to properly route an end-to-end transmission.
I like the idea of caching the location, but that doesn't do us much
good when the endpoint is in motion. The closest thing I've seen to this
thus far can't stay locked on a mobile traveling more than 60MPH.

> legal. Hopefully, it could just lurk in the noise floor.

So this is basically legal, low power spark gap? eek.
What would my limitations be if I restricted the pulse to only be 100Mhz
wide? Would it still work okay?

> established without exceeding the limit, the node would not be usable.

Fair enough..

> may disengage and go find someone else to talk to.

Malfunctions, intentional or accidental misrouting, modifications of
data as it passes through, monitoring of traffic passing through it
(eavesdropping), selective intentional dropping of certain calls without
confirming the drop to either end, intentional corruption, not to
mention simply standing up and locking the transmitter on at full legal
power.
All of these could happen because of equipment malfunctions, loss of
power, or inappropriate power levels being supplied to equipment, or
even as my i88s learned last week, dropping it in water while in-call
takes its toll on the proper functioning of the gear without making it
stop working entirely.

> strategies which have no way of throttling and shaping traffic at the edges.

So I design a node that allows initial call routing and signalling, and
permits transit of data to all called numbers except 911. My node is
well trusted and is a good peer until all shit goes down and you try to
get help. Now what? Your call is going through me, and I'm synthesizing
a proper call to 911, except you're talking to me instead of a real 911
operator.
Or in the walkie talkie metaphor, when I want to blow up the building, I
make sure I have a really well connected node on top of a nearby
building so I'm the preferred best node out of the area (I can reach for
miles on 1 hop). When police walkie talkies show up, I'm the preferred
best path back to dispatch, and the "hop along a billion phones" model
isn't even considered.
Now I start to allow the signalling to open a circuit to dispatch,
without actually relaying the cells in question. You're screwed. Who are
you gonna call to shut down the rogue node? There's not really any
accountability in this network.

> their cell queues to deliver the granted QoS end to end.

I want my cell phone to have a higher QoS than the Police. How does my
neighbor's node know that's not something it should not allow?

> cost (beyond the cost of the node)

But the FRS radios are cheaper. And they'd probably get farther on just
one HT, because theoretically they can use more power. Why would anyone
buy my overengineered subscriber unit that's not guaranteed to work
because -they- are the infrastructure I'm bootstrapping with?
Isn't there money to be made in deploying fixed units so I can say at
least that your walkie talkie will work anywhere in Detroit, to anywhere
in Detroit? Engineers like neat gadgets, but consumers want guarantees
that they're not buying an expensive plastic doorstop.
But if I were to deploy these fixed units, I'd want to be able to charge 
for their use so I can afford to maintain them, so the technology would 
demand some sort of payment, billing, and settlement system for corporations 
who are capable of deploying infrastructure but want to see a return from their 
investment. Not all the nodes would have to be mine, but you have to bootstrap the new technology.
It's one thing to define a standard, but another entirely to get people
to use it. Case in point, does your IP provider support multicast, or
IPv6?

> native wireless protocol. Those bridge endpoints would be a super node 

Initially, until you reach critical mass, wouldn't the need for these
bridges exist in quite a few places, if not even just to link big cities
together?

> traffic. My proposal would only have cells traveling when there is payload.

While my phone has GPS in it, and is capable of running java
applications, I don't know that it's capable of computing a routing
table, doing power adjustment with up to several hundred adjacent nodes,
and making complex routing decisions, either on behalf of myself or
other nodes using me as a transient relay. I could see the argument that
my iPAQ has enough CPU power, but not my cellular telephone.

> What are you billing for? Once one buys a node they pay nothing else.

I want to provide a connectivity service via the infrastructure that
costs money, but the incredible decentralization of this model precludes
my doing so, even if I deploy the nodes myself, because I can't
guarantee that only my customer's traffic traverses them, and noone
would perceive any benefit from my service if I allowed just anyone to
traverse my wireless infrastructure I engineered and deployed.

> for compliance, just as we have now with all forms of radio.

Of course, but this prevents me from subsidizing the unit and making it
affordable to a consumer during the bootstrap period.

> done, you hang up the call and its connections get hung up. All on demand.

People thought ISDN would make POTS obsolete too. We have GSM and CDMA,
but my friend still has an AMPS phone. We have trunked radio and P25,
but my hometown still uses a single channel VHF system and arms their
volunteer firefighters with Motorola Minitors.
Nothing just becomes obsolete. I contracted for a company once that
still uses DDS lines running DECNet LAT over them to this very day.
They'd put them over some of their frame relay, but noone knows of a
good way to simulate the DDS circuit over their Frame connection, and
noone knows the system well enough to configure it any other way.
There needs to be a graceful strategy to gradually cut over to the
network. We can't have a flag day. Once I get the execs and their phone
systems working over the infrastructure, I can start to point out how
reliable it was during the last disaster and start to sell them new
UWB/Micro ATM cell phones. But I gotta start somehow, and that's by
migrating circuit based connectivity gracefully. Noone said I had to do
it with a circuit based mentality, but even if I dynamically opened the
channels over the micro web, I'd need to have a way to know that some
dude in a traffic jam jabbering to his wife about the laundry doesn't
take precedence over the executive level conference call that is about
to happen across the simulated circuit.

> 500' per hop that's about 25,000 miles.

If you have to make routing decisions or queue packets due to
congestion, this changes things quite a bit.

> because the proposal is truly connection oriented.

Without some centralized way to keep track of these alternate routes,
how do transient nodes make agreements on routing?
Wow, there's a bunch of routes, with tons of backups. I'll establish a
call in that direction.
*call is now in progress*
blam, 45 nodes in the path just shut off their phones. The movie
started.
Since the protocol doesn't know how to avoid a movie theater, would
there be a way to give the fixed node up on the streetlight preference
as a backup route?

> the cloud and cause problems where mitigation is more difficult.

Alright.

> but there are also lots of ways to mitigate issues that come up.

But say I want to transfer a huge CSV of my entire plant inventory to my
sales guy who needs to know this information while he's at a customer's
site in a meeting, rather than 1500 byte frames, This several megabyte
file now has to be broken up into little bitty pieces, wasting network
bandwidth with packet overhead that wouldn't have existed in a
traditional wireless data network.
Besides, it's my understanding that packet sizes in VoIP are due to the
compression buffer filling up, rather than waiting for a fixed packet
size to come through on the IP layer. Because if that was true, it'd be
possible for me to tweak my IP frames down to a 29 byte payload and
achieve similar RTT.

> Microsoft model to do this. You have to use the OSS model

Do you have evidence the OSS model has ever worked for hardware
engineering?
And how to you make something forward compatible, for my neighbor who
will -never- upgrade his subscriber code, because it works fine, and
it's not broken, but it's chopping my new features in half every time I
try to use them?

> Further, all 

Define a safe software configuration? What if someone finds a flaw in
this immutable, uncorruptable configuration, and exploits it?
How do you force a user to upgrade their software in such an anarchy, or
how do you safely deactivate someone else's malfunctioning node? Noone
would have the authority to do so in your model.

> issues with their own strengths and weaknesses and behaviors.

But would it be inefficient? Could I subscribe to a multicast stream
like I can in the IP world?

> protocol since you have intimate, full duplex control of the connection.

But replacing the protocol does nothing for the installed base of
clients out there who now are going to do circuit based tunneling of a
PPP session with my virtual ISP because there are no provisions to
cleanly handle internet protocol packets, forcing my hand to use
something more inefficient so I don't break end to end connectivity by
trying to play address translation games.

> be a potential node. Connectivity would be very good in such a plant.

Connectivity may be good, but routing will be funky. I don't want my
drill press to be an RF transmitter. I want it to be a drill press.
Likewise with my cardboard baler and the forklift. I can't replace my
drill press because the UWB transmitter in it failed because of nasty
power rippling from the motor in the same packaging, among other things.
If there was a demand for this level of integration, Symbol, et al,
would have done it already. But no, walk on the plant floor and look up
near the ceiling, and there's your wireless nodes, still with no GPS
reception. :-)

> A quick scan of it looks like it may. That patent isn't very novel.

But all the same valid. Something you need to consider in your
engineering.

> This one talks about absolute coordinates ... my method's coordinates 

"In the web there will be fixed and mobile nodes. Fixed nodes can have 
their location certified."

> Again ... absolute.

"In the web there will be fixed and mobile nodes. Fixed nodes can have 
their location certified."

> getting patents for things that are not novel.

They might have been during the original grant period. Perhaps they need
to have a way to remove a patent when it's become obvious to anyone in
the industry that based on the current location of the industry, this
patent is now a sticking point for innovation, because it's really
obvious now, so it's time for it to expire.

> Really really good questions.

Thanks. I'm itching to get something going as a data network that
doesn't have the inefficiencies of thousands of wired points (Hi,
802.11b!), but in the industry these days, you have to be skeptical and
ask lots of questions.
-Paul

---

From: Todd Marshall <[email-masked]>
Date: Mon, 06 Oct 2003 19:09:46 -0500

Paul Timmins wrote:

>talking at the same time. 
>
I don't think I agree with you. The UWB scheme employes channels in 
time. The nodes know precisely when to talk and when to listen. They 
know to talk soft enough to not desturb more distant nodes and loud 
enough to get over noise and reach the near nodes. And because the more 
distant nodes are linked to the nearer nodes, it is possible to assure 
that the more distant nodes don't have time slots colliding with nodes 
that can hear them or that they can hear. With nanosecond pulses there 
are 10^9 time slots for bits. Again, in real life you won't get the 
theoretical maximum, but that maximum is a few orders of magitude over 
what is needed.

>You can only adjust a transmitter's output
So that would set the minimum. Do you know what that is? I know they're 
talking about using UWB techniques within computers themselves so that 
level must be very low indeed.

>sight, like cellular phones or HTs?
No. Your subscriber would just need to know which direction to go from 
where it is to where the destination is and set a link in that 
direction. This would cascade along always moving toward the destination 
using direction vectors. No node would know the whole route nor need it 
know it. The protocol relies on the nodes socializing (i.e. keeping in 
contact with nodes immediately around it). So when they get a request 
for a connection, they already know the best candidate node for 
requesting the next hop.

>the network to properly route an end-to-end transmission.
I don't see the home node having anything to do with the business model. 
It could be a node in your own home. For someone to call you, you would 
give them the lat/lon and perhaps unique ID (e.g. a GUID) of this home 
(fixed location) node. They would drive a connection to that node (which 
would always be there just like the telephone on your wall) and it would 
then give them the lat/lon and ID where you can be reached. You then 
drive a connection to there. Almost no CPU is required to setup up the 
link. It's just real simple triginometry. Each node just tries to get 
closer to the destination and that's all it needs to do with the route. 
Once the link is established the communication on the link is totally 
automatic and requires no CPU at all (other than the specialized ATM 
like processor that maintains the queue linked lists and moves the bytes 
from the input port to the queue and from the queue to the output port). 
There are no routing tables at all. The reason IP needs routing tables 
is because it doesn't know direction and location ... the tables have to 
describe the topology. With lat/lon direction, this isn't the case.

>So this is basically legal, low power spark gap? eek.
Right ... kind of like your car makes. Do you say eek when you run your car?

>wide? Would it still work okay?
You talk about the width in nanoseconds (time domain) not Mhz (frequency 
domain). If you want 100Mhz in the frequency domain around some center 
frequency, then you don't have a pulse ... you have a sinewave in an 
envelope. I don't propose this although most UWB strategies (e.g. WiFi ) 
I believe use that technique. Its also the technique being proposed for 
MBOA  and that really bothers me. It's just plain wrong.

>Malfunctions, 
The node breaks the connection and makes a connection around the 
malfunctioning node(s).

>intentional or accidental misrouting, 
>
Once we see the first cut at the protocol, let the jousting begin. Let 
the attackers show how they would attack. Let the defenders show how 
they would mitigate. Let the protocol improve. We have better tools for 
coming up with a hard robust solution in this medium than we do in the 
connectionless IP medium. Frankly, I think identification of bad actors 
would be easy and the protocol would just ostracise them.

>modifications of
>data as it passes through, 
>
This is difficult (and really kind of fruitless). The data is in a 
connection. It's moving very fast. It has check bits in the header. And 
a sabateur would have no idea who he is sabataging. I think these issues 
are not show stoppers.

>monitoring of traffic passing through it
>(eavesdropping), 
>
It's a trivial exercise to cipher the payload ... much easier than using 
IPSec for example. Being connection oriented makes a huge difference 
when you want a simpler solution. IP solutions for QoS are difficult 
because they are fundamentally connectionless.

>selective intentional dropping of certain calls without
>confirming the drop to either end, 
>
Can't be done. The control channel knows immediately when there is a 
break and causes nodes to find other paths. No one can control even the 
tiniest fraction of nodes along a path.

>intentional corruption, not to
This can be done today with cell phones, police radios, or anything but 
fiber and wire. But it is not an issue because the attacker is easily 
identified.

>takes its toll on the proper functioning of the gear without making it
I agree ... and I said one of the greatest challenges is having self 
healing connection links so the whole connection does not have to be 
reestablished. It is my single biggest concern with my proposal. 
However, all that can happen right now in our IP enviornment. But it 
doesn't happen that often (if at all).

>get help. Now what? 
What all shit goes down? I can take classical radio solutions down just 
by toppling a tower or killing its power. With the UWB/ATM Microweb 
there is no tower and no single power sources. All shit doesn't go down. 
Take out a node or a cluster of nodes ... I just go around the break. I 
only get hurt if I am part of the cluster ... just like somebody putting 
a bullet in my police radio.

>Your call is going through me, and I'm synthesizing
You're going to be like the Maytag repairman listing for random 911 
calls. The probability of my call going through you is tiny. And the 
probability of your knowing it is a 911 call is tiny. But if you want to 
set up such an attack, lets disect it and see how many ways there are to 
mitigate it. I'm sure there are very many ways of mitigating such an attack.

>miles on 1 hop). 
This is a fundamental misunderstanding. The protocol always seeks out 
the nearest nodes. It knows nothing about how the node is connected. A 
node on the top of a building will probably get less use than one at 
ground level because most of the mobile nodes will be on pedestrians.

>When police walkie talkies show up, I'm the preferred
But if you're acting badly, there are many other paths nearly as well 
preferred. I think you would have one heck of time being the most 
preferred node and maintaining that position. A chain a firemen walking 
down a subway tunnel would be such an instance. But if one breaks the 
chain, the protocol just goes past the break to the guy behind him 
(we're probably talkin 10' links or less).

>without actually relaying the cells in question. You're screwed. 
>
But only for a few microseconds. I can detect what you're doing. 
Remember we have an end to end full duplex connection here and you have 
to simulate the handshake of both ends which could incorporate some 
secret methods that you couldn't emulate.

>Who are
>you gonna call to shut down the rogue node? 
>
I'm not going to call anyone. The protocol will just go around it after 
it identifies it.

>There's not really any
Exactly. That's really how it can be more robust than a method with 
accountability. With methods employing strong accountability, all you 
have to do is become the accountant.

>neighbor's node know that's not something it should not allow?
Frankly, I think this method gives so much bandwidth, especially in 
times of congestion, that you and the police could have optimum QoS and 
there would be capacity to burn. Actually I would favor a protocol that 
doesn't favor the police. As soon as I have a protocol that favors any 
group in particular, I open myself to attack by someone impersonating a 
member of that group.

>because -they- are the infrastructure I'm bootstrapping with?
Your arguments are getting a little hard to follow. These UWB/ATM nodes 
are really simpler than even FRS radios and thus will likely be cheaper. 
Once people have these, FRS dies just like all other communications 
modes. This UWB/ATM Microweb would outperform the FRS except where they 
weren't ubiquitous. Otherwise, with the UWB/ATM being as well behaved 
among FRS as it is among common FM and TV, there is no issue. To break 
the system you would have to somehow get all nodes to power down. How 
would you propose to go about doing that.

>in Detroit? 
There could be. There's money to be made selling bottled water. But I 
get my water for free.

>Engineers like neat gadgets, but consumers want guarantees
Consumers are flocking to cell phones right now and receiving a level of 
service and guarantees orders of magnitude below what my proposal 
delivers. If you want a gold plated doorstop and that makes you more 
comfortable, have it. But for the system to work, the lowest common 
denominator has to be effective and gold plating it doesn't make it more 
effective.

>investment. 
Fine. But your fixed units will be competing against fixed units that 
require no service and thus make no monthly recurring charges. I don't 
think you will compete for long. Your business model would be 
artificial. But then again, people are buying the bottled water (and 
lottery tickets) so have at it.

>Not all the nodes would have to be mine, but you have to bootstrap the new technology.
My proposal would make IP go away too. You don't need IP when you have a 
better connection oriented web to put your traffic on. However, if you 
insist on IP, have it. Conceptually it would look like two routers ... 
yours and the recipients. In between would be UWB/ATM Microweb looking 
like a single strand of fiber. Just like your IP enters the cloud today 
and travels by ATM, the IP would enter the UWB/ATM Microweb and travel 
on ATM-like cells.

>bridges exist in quite a few places, if not even just to link big cities
Yes. That's why I say you introduce it as a novelty. It will reach 
critical mass much quicker than analog and PCS phones did because it 
will require no infrastructure. You buy a node and you've increased the 
mass. I really think you'll find the rural people will be able to employ 
directional antennas and get adequate distance using this proposal just 
as we see them doing with WiFi. It is in everyone's individual interest 
to get connectivity and some will have to work harder to get it than 
others. But eventually they will all get it. And as I said, 
municipalities may choose to set up links between themselves to make 
that happen faster ... but I doubt they could hold their first few 
meetings toward reaching such a decision by the time the users had met 
their own needs.

>my iPAQ has enough CPU power, but not my cellular telephone.
But it doesn't have to compute a routing table. And your cell phone is 
already doing power adjustment (phones far from the tower are stronger 
than those near so all signal hit the tower at about the same strength). 
This proposal doesn't require power adjustment with several hundred 
adjacent nodes ... only with a handfull of the closest nodes. Believe 
me, we're not talking about much computing power here at all. Less I am 
sure than your current cell phone (even if it doesn't play games). Less 
than my MP3 play that I bought at WalMart for less than $80.

>traverse my wireless infrastructure I engineered and deployed.
And thus you would not be a UWB/ATM Microweb user. Now I suppose you 
could come up with your own protocol that would allow only your nodes to 
talk to each other and ignore others. But then you would also have to 
provide your own ubiquity. I just don't know why you would want to do 
that. But I don't know why people buy bottled water either.

>affordable to a consumer during the bootstrap period.
Well, we'll see if that is necessary. Right now you can get WiFi for 
free almost as easily as you can get it for a fee. You could charge for 
a glass of water served with a meal, but most other restaurants won't so 
you'll either lose customers or drop the practice. My models show a 
price of $200 for the nodes and the P25 funding virtually buying 
everyone who wants to be a node the hardware and yielding 100' to 500' 
links. I really think when everyone starts making them, they'll cost 
less than $50. I can buy a WiFi card now for $19. The bootstrap period 
will be a fleeting instant at these rates.

>volunteer firefighters with Motorola Minitors.
I really think this proposal will drive away "all" the reasons those 
conditions exist. The value proposition is just too huge.

>still uses DDS lines running DECNet LAT over them to this very day.
Fine ... let them use them. But things do become obsolete. Go to a 
rummage sale and buy an "ice box". Then try to find someone to deliver 
blocks of ice to you.

>network. We can't have a flag day. 
>
The graceful strategy will be just that. Initially the nodes will be 
used mostly for voice. Then they will be used for point-to-point data. 
Then they will be used for frame relay emulation. Then they will be just 
used.

>Once I get the execs and their phone
>migrating circuit based connectivity gracefully. 
>
Fine. Once this technique is proven and attacked and defended until it's 
rock solid, the problem will be making nodes fast enough to meet demand. 
During that time, be as graceful as you want.

>Noone said I had to do
Remember ... this isn't like IP where you're just whistling in the wind. 
You ask for specific QoS when you request your connection. If you get 
the connection, that QoS is guaranteed. And you have a much better 
chance of getting exactly what you want with all this bandwidth and 
connectivity afforded by the web architecture. Remember when we used to 
pay more money to call long distance and now the cost is the same as a 
local call on our cell phones? Well, this proposal is even better than 
that. You pay nothing and get splendid bandwidth.

>congestion, this changes things quite a bit.
Right ... but you don't. All routing decisions are made at call setup 
(just as IP MPLS mechanisms will try to do). And they're not routing 
decisions ... they're just connecting in the direction I want to go. 
After the links are established, it's stricly electronics ... no 
computer involved.

>how do transient nodes make agreements on routing?
Transient nodes are constantly negotiating for new connections and 
casting off old ones. The protocol will need to anticipate these in 
mobile situations so it just becomes a simple switch to the new 
connection once it's established and then the old connection is dropped. 
In mobiles this will happen less than you might think. With lat/lon 
capability, we know our relative position to adjacent nodes. We'll seek 
links where that relative position doesn't change. This means if we're 
in a car, well use nodes in cars going our way rather than cars coming 
in the other direction. We'll avoid nodes in houses along the way.

>there be a way to give the fixed node up on the streetlight preference
The protocol would favor fixed nodes over mobile ones and would favor 
nodes with low relative motion over nodes with high relative motion. 
Remember, we're working in microseconds here and dealing with dynamics 
happening is seconds.

>traditional wireless data network.
Wrong wrong wrong wrong wrong. I said I'm proposing a 32 byte payload 
and a 3 byte header. That's 10% overhead. That's less than I have right 
now with IP. Are you griping about IP? And I'm delivering 10 or more 
times the bandwidth of WiFi. Does that mitigate that overhead a little 
bit? Breaking a stream into 32 byte pieces is no hassle. Remember, that 
IP packet isn't going out in parallel ... it's being delivered in 1 byte 
packets that eventually make up the IP packet. And further, its flying 
through the cloud in 53 byte (48 byte payload) ATM cells right now.

>possible for me to tweak my IP frames down to a 29 byte payload and
Perhaps ... but then you have the 6 byte IP header. Weren't you 
complaining about overhead? Run the numbers, 8Kbps compressed voice is 
1Kbyte per second or 125 bytes per 1/8 second (acceptable voice 
latency). The only way VoIP can make beat it is to combine a bunch of 
voice calls and trunk them. Those packets need to move just as fast as 
the ATM cells so the only way a bigger payload can be used is to carry 
simultaneous calls. That means you have to collect those calls into the 
node and lay them out in the payload. At each node you then have to take 
the payload apart (some of the calls will go in different directions) 
and then repackage for the next hop. You do this for every hop. Plus you 
have to again decide how to route the packet. It's really really silly 
how they do it.

>Do you have evidence the OSS model has ever worked for hardware
No. But I really think the issues are 95% software ... not hardware. 
Remember, we have a trivial transmitter and a trivial receiver. We have 
computers telling one when to pop and the other when to listen.

>Define a safe software configuration? 
>
The PC bios.

>What if someone finds a flaw in
We swap out the prom.

>how do you safely deactivate someone else's malfunctioning node?
>
You don't force them. The protocol upgrades itself. A real issue is, 
what do you do when the node can't accept a new upgrade (i.e. can handle 
links for the brand new 3-D TV with smell protocol). In that case, we 
have the same problem we had when color TV was introduced.

> Noone
I hope I've answered it.

>like I can in the IP world?
Yes. Think about how IP delivers those packets to all the subscribers. 
Then just substitute the word cell for the word packet. I really expect 
there will be less and less of that. The reason we watch most broadcasts 
simultaneously is because that's the time they're broadcast. A better 
model is to watch it when we want to. On the other hand, interactive 
classrooms are a case where we have a true need for a broadcast.

>trying to play address translation games.
You're losing me ... on purpose I think. You keep throwing out problems 
that don't exist in the new environment.

>drill press to be an RF transmitter. I want it to be a drill press.
Maybe so. But a whole lot of drill presses out there are computer 
controlled. Some have direct connections via IP to the program that 
tells them what to do. These are candidates for nodes as well.

>near the ceiling, and there's your wireless nodes, still with no GPS
If I have wireless nodes on the ceiling, they know their lat/lon. They 
know it because they triangulate distance related to time with other 
nodes which know theirs. If they have reception, they have GPS capability.

>But all the same valid. Something you need to consider in your
which means ....  ?

>obvious now, so it's time for it to expire.
I don't know. For sure, this isn't a new issue nor one unique to this 
proposal.

>802.11b!), but in the industry these days, you have to be skeptical and
As I think I said, for this to succeed it cannot be proprietary. It has 
to be created and challenged in the open ... in the beginning and 
continuously. That's why the business model is so weak. I'm just hoping 
the value proposition is huge enough to overcome the business model and 
some of the technical questions and details. Frankly, I think it is.

Again ... thanks for your comments and questions Paul.

/Todd