Subject: [NEXTEL-1] Re: Subject: Re: "Hot-Spot"

From: [email-masked]
Date: Wed, 30 Jul 2003 13:05:17 -0400

Paul Z. yesterday stimulated an interesting discussion between Todd  M. and myself
on a Ultra Wide Band (UWB) component production, application and the benefits of
UWB.  I'm  deferring to the group for some additional input.

-------- Original Message --------
   From: Todd Marshall <[email-masked]>
Subject: Re: Subject: Re: "Hot-Spot"
     To: [email-masked]

It seems to me someone could build a pretty remarkable device using Ultra Wide
Band (UWB) for layer 1, ATM (Asynchronous Transfer Mode) for layer 2 and TCP/IP
doing layer 3 only at the edges (i.e from PC to the Access Point). Put it in a
package of less than 30 square inches (3x3x3). Actually, the DoD has already done
one huge part of this
(http://www.harris.com/view_pressrelease.asp?act=lookup&pr_id=385).

Let these devices be nodes in a dynamically self configuring web (not mesh) where
each node maintains constant contact with 4 or more adjacent nodes in different
directions. UWB allows this at very low power on unlicensed spectrum when nodes
are close to each other. With proper loosening of the regulations, these "software
radios" could throttle their power and frequency spectra according to licensed
activity they see in their vicinity. Then they could power up into the unused
spectrum in those rural areas and drive the signals much farther.

Use TCP/IP to bring content to an edge node. Then drive an ATM  virtual
connection  (or several to carry various parallel streams at different rates)
across this web using a form of LON/LAT addressing (like trip planning software).
Lock down the connection; dialog the data; and depending on what you're doing;
release the connection (e.g. web browsing might drive a separate connection to
each URL visited and then release it. A phone conversation would maintain the
connection until hung up ... Push to Talk would just be another application ...
not a distinguishing service.).

I've run some numbers on the off the shelf chip sets to build this and compared to
ISP charges such devices would pay for themselves in a year or so. The result: no
ISPs; no carriers; greater bandwidth; great mobility; no last mile issues at all;
lifetime addressing; good rural coverage (if regs won't loosen, municipalities put
up towers to web connect with adjacent distant neighbors ... actually, except in
some western states you don't go more than 5 miles between houses or businesses
anyway).

You don't even need satelites or undersea cables to go global. With ATM doing the
hopping it is practical to have 100's or 1000's of nodes making up a connection.
IP can't do that. Thus, you can get over large bodies of water by going up the
coast and then taking a strait across to the other continent ... often less than
100 mile hop.

And with ATM carrying the baggage (as it does for the carriers anyway), all this
ridiculous IP stuff  like IPSEC, RSVP, DiffSrv, MPLS, IntServ, VoIP, etc. (stuff
just emulating ATM) goes away. Every connection becomes a simple, low cost,
secure, dynamic VPN.

Each user (node) on the web buys their own little box ... and that's all they pay
for ... ever again. In addition to these ubiquitous little boxes would be an
additional market for adapters. These would take this digital transmission at the
AP and reconstitute it in software to low powered standard RF so you could tune
your existing radios and TV's and have the content flow digitally. And that takes
out the broadcasters.

In the end we just have content providers and content consumers (i.e. just plain
ole conversations with no middle men).

Know anyone who wants to build it? I don't think the carriers do.

WithGLEE,
Todd Marshall
http://WithGLEE.com

[email-masked] wrote:

> Sure-
>
> There are many Engineers lurking on the list who are driven as paul describes.
> Paul and myself  are just 2 of them.
>
> Todd Marshall wrote:
>
>
>> "Paul J. Zawada" wrote:
>>
>> Subject: Re: "Hot-Spot"
>>
>> I was reading the NEXTEL-1 digest and this little dialog interested me. It
>> just sort of flew in out of the blue. Could we open a dialog?
>>
>> WithGLEE,
>> Todd Marshall
>> [email-masked]
>> http://WithGLEE.com
>>

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/61FxlB/TM
---------------------------------------------------------------------~->

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

---

From: Rick Parrish <[email-masked]>
Date: Wed, 30 Jul 2003 12:22:55 -0500

-------- Original Message --------

Howdy Todd!

Wazzup!

Sign me up. I'll take some of those chips ...

-rick

------------------------ 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/sO0ANB/LIdGAA/ySSFAA/61FxlB/TM
---------------------------------------------------------------------~->

---

From: Rick Parrish <[email-masked]>
Date: Wed, 30 Jul 2003 13:06:07 -0500

[email-masked] wrote:

If routing is lat/lon-based, would this magic 3" x 3" x 3" cube include
something like GPS to determine the cube's location?

non-sequiter: 3 X 3 eyes

In the case of a cube mounted in a moving vehicle - where nearby nodes
eventually fade while new nodes into view, how does ATM handle a
"roving" connection?

-rick

Yahoo! Groups Sponsor

ADVERTISEMENT

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

---

From: "tbm3518" <[email-masked]>
Date: Thu, 31 Jul 2003 03:10:55 -0000

--- In [email-masked], Rick Parrish <rfmobile@s...> wrote:
> Thinking out loud: Let's assume that when you're roaming, the
protocol is capable of reporting your position to your fixed node on a
regular basis. When a call setup request is received, your fixed node
responds with your current position. The call setup then routes to
that position. Even if you don't really have a fixed node, you could
use a surrogate ... kind of like an answering service.

---

From: Rick Parrish <[email-masked]>
Date: Thu, 31 Jul 2003 02:25:38 -0500

tbm3518 wrote:

I was imagining something like cellular - but with redundancy - the
"fixed" cubes in the area would  act like cell towers and the mobile
cube would act like a cell phone does now. I'm just wondering how ATM
copes with this arrangement. It's just a technical issue that plenty of
folks smarter than I will or already have solved.

Here's a politcal concern. Forget the carriers crying and moaning over
instant obsolesence for moment. Let's talk about Big Brother.

On the one hand, a routing mechanism based on physical location will
make private advocates scream bloody murder. For two end-points to
communicate, they have to know their physical location. You connect to
a web server and company "X" immediately knows your home address.
Compare this to some of the privacy discussions on the RFID groups over
the possibility of your sweater or automobile tires giving away your
identity. [ Side note: it's amazing how quickly people's behavior
changes when they realize that someone can show up at their doorstep. ]

On the other hand, laws like CALEA and the ECPA go out
the window.  For CALEA: suppose a federal judge issues a wire tap order
to monitor the communications of some crime syndicate. To whom does law
enforcement go to place the wiretap? My cube acts as an end-point for
my data but also as a router - as does every other such cube on the
planet. Data is routed in a dynamic, fault tolerant, and unpredictable
manner. My guess is law enforcement (remember Carnivore?) and the NSA
(remember Echelon?) would have to deploy their own "monitoring cubes"
in close physical proximity to the "mark" or person being monitored.

CALEA gave LE the universal wiretap. This system takes that away
(though a CALEA compliant module in the cube's protocol stack is very
conceivable).

I see the same problem for the ECPA. For this to work - my neighbor's
data has to be routed through my box. Laws like the ECPA exempt
carriers from prosecution for listening on the presumption that they
need to monitor the quality of their service. Remember the "baby
bells"? Everyone with a such a cube in their living room effectively
become "micro-bells". For me to consent to my neighbor's data traffic,
I wouldn't want the liability of something like the ECPA hanging over
my head.

-rick

Yahoo! Groups Sponsor

ADVERTISEMENT

---

From: "tbm3518" <[email-masked]>
Date: Thu, 31 Jul 2003 13:35:18 -0000

--- In [email-masked], Rick Parrish <rfmobile@s...> wrote:

Todd: 
<<< First, when I try to reply I don't get the message as I would
expect. So this time I've copied it in and put these brackets around
my reply. 

	 Msg # 	
From:  Rick Parrish <rfmobile@s...>
Date:  Thu Jul 31, 2003  2:25 am
Subject:  Re: [NEXTEL-1] Subject: Re: "Hot-Spot"

ADVERTISEMENT

I was imagining something like cellular - but with redundancy - the
"fixed" cubes in the area would  act like cell towers and the mobile
cube would act like a cell phone does now. I'm just wondering how ATM
copes with this arrangement. It's just a technical issue that plenty
of folks smarter than I will or already have solved.

Todd: 
<<< Correct. It's just a technical issue with a real smorgasborg of
alternative solutions. 

Todd: 
<<< My favorite subject. 

On the one hand, a routing mechanism based on physical location will
make private advocates scream bloody murder. For two end-points to
communicate, they have to know their physical location. You connect to
a web server and company "X" immediately knows your home address.
Compare this to some of the privacy discussions on the RFID groups
over the possibility of your sweater or automobile tires giving away
your identity. [ Side note: it's amazing how quickly people's behavior
changes when they realize that someone can show up at their doorstep. ]

Todd: 
<<< Use of LAT/LON for routing I expect will allow quicker and more
elegant algorithms for navigating the topology. With IP, large tables
must be maintained at the nodes which I think is unnecessary overhead. 

The protocol doesn't have to pinpoint the source or the sink
locations. It just has to locate a MIB that can receive from the
source on one end and a MIB that can send to the sink on the other. It
could use LAT/LON to locate that MIB. That MIB could be in a knowable,
yet secure physical location ... like your ISP is. 

On the other hand, laws like CALEA and the ECPA go out the window. 
For CALEA: suppose a federal judge issues a wire tap order to monitor
the communications of some crime syndicate. To whom does law
enforcement go to place the wiretap? My cube acts as an end-point for
my data but also as a router - as does every other such cube on the
planet. Data is routed in a dynamic, fault tolerant, and unpredictable
manner. My guess is law enforcement (remember Carnivore?) and the NSA
(remember Echelon?) would have to deploy their own "monitoring cubes"
in close physical proximity to the "mark" or person being monitored.

Todd: 
<<< You are correct. CALEA can't operate on that which they cannot see
or hear or control. If that's the show stopper, fine? It's kind of
like the populace submitting to a Federal rule that you can't have a
personal conversation unless you first dial a Federal number and leave
your phone off the hook so they can listen in if they want. Big
Brother wiretaps because he can. Now that he is used to it he may
refuse to allow communication when he can't listen in. I just grin
when I envision him trying to impose such nonsense when he has no
short hairs in his grasp. Frankly, I think such arrogance will be hard
to push down the throats of the people on my block. It was always easy
to cram down the carrier's throats ... their business was at stake.

Todd: 
<<< The only way Big Brother can impose things like CALEA is through
the regulatory clout they have. If the carrier does not provide the
feature, they pull their license. Big Brother has a problem here when
they have no license to pull. It's a new ballgame now for Big Brother.
It's not "one if by land, two if by sea" anymore. 

Todd: 
<<< ATM is different from IP when it comes to listening in. First, the
packets (cells) are smaller and have less identifying information.
Next, they aren't broadcast, they run in connections. To get the
necessary information, the call setup protocol must be tapped.   Also,
because it is dynamic, all rerouting must also be tapable and
successfully tapped. This is only practical at the end points.
Further, being connection oriented, it is trivial to cipher the stream
(much easier than IP which must keep some information in clear text).
Let them listen. I have a ciphering technique I would like the pros to
look at. It has to be breakable as all of them are, but I sure don't
know how I would break it ... even for short messages. Anyone want to
see the technique (http://withglee.com/CaseStudies/CS00009.htm ) and
show me how it is easily compromised? 

Todd: 
<<< /Todd 

-rick

  Message 9886 of 9889  |  Previous | Next  [ Up Thread ] 	Message Index 	
 
	 Msg # 	
Reply | Forward | View Source | Unwrap Lines 	

Copyright © 2003 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Copyright Policy - Guidelines -
Help - Ad Feedback

---

From: "Paul J. Zawada" <[email-masked]>
Date: Thu, 31 Jul 2003 10:54:31 -0500

This is interesting because my manager and I are starting discussions 
on what we should propose to work on during year two of the grant I'm 
working under.  (See http://www.ncassr.org/ and the related press 
release.)

>just emulating ATM) goes away. Every connection becomes a simple, low cost,

I'm not sure I agree with this....  The high-performance networking 
community has been down the ATM path once and has pretty much 
abandoned it.  ATM has issues with overhead, both in the "cell tax" 
you pay by adding the ATM header to each cell as well as the 
processing overhead required to do so.   You also have problems with 
optimizing the buffering in the ATM switches...  Overall ATM turned 
out to be a bad experience for many folks.

I'm interested in looking at options for Ad Hoc networks for Voice 
(PTT or otherwise), perhaps using IETF's MANET work and/or IPv6.

>your existing radios and TV's and have the content flow digitally. 

My application is a little less all-encompassing...  I'm looking at 
implementing this sort of thing for mobile workgroups (think 
battlefields or public safety incident response).

--zawada

-- 
Paul J. Zawada, PE       | Principal Network Research Engineer
[email-masked]          | National Center for Supercomputing Applications
+1 217 649 2233          | University of Illinois at Urbana-Champaign

---

From: Rick Parrish <[email-masked]>
Date: Thu, 31 Jul 2003 15:45:46 -0500

tbm3518 wrote:

Actually, Big Brother has one significant tool they can use to
influence the process of getting such a network off the ground. FCC
type acceptance - if you don't have that, you can't sell your product
in the US.

The cool thing about the type acceptance issue is that you could most
likely succeed in getting just the UWB module (the "air interface")
type accepted. Any additional components (like processor and protocol
software) would be able to inherit that type acceptance. I may be wrong
on this.

-rick

Yahoo! Groups Sponsor

ADVERTISEMENT

---

From: Todd Marshall <[email-masked]>
Date: Thu, 31 Jul 2003 16:26:58 -0500

> out to be a bad experience for many folks.

I am astonished by these kind of comments. I have seen zillions of 
dollars going into initiatives to try to give IP some QoS 
characteristics. All of them are emulating one or more elements of the 
ATM model. For example, they need IPSec because they cast packets to the 
wind in broadcasting rather than using easy to encrypt and more 
naturally secure connections. They invent MPLS to label the packets and 
tell new smart routers how to deal with them while the ATM model depends 
on labels; always has had such labels; and manages them in hardware. IP 
has TCP to try to reform the stream of packets arriving out of order or 
dropped while the ATM model assures data arrives in order. If there are 
drops, TCP/IP waits on its window while ATM knows immediately and has 
some pretty clever mechanisms for dealing with the rest of the stream. 
Further, with IP, the relatively disciplined TCP throttles back (as in 
"drops QoS") when confronted with a burst of totally undisciplined UDP 
... and most video goes UDP so it just squashes the voice. IntServ and 
DiffSrv are dedicated to marking the packets with priorities at the 
edges and interrogating them within the cloud to differentiate and 
integrate service while the ATM model does all of this at 
call/connection set up time and never thinks about it again. And IP has 
RSVP for signaling while such signaling is just an inherent part of the 
ATM model. And after IP nodes figure all this out, what do they do? They 
slice and dice the packets into ATM cells and go to the next node via ATM.

Are all of these arguments to be dispelled with a simple "I'm not sure I 
agree with this". What in the world is not to agree with?

The so called ATM cell tax is in the order of 15%. If we were really 
concerned with that, would XML have any following at all? And there is 
zero processing overhead associated with these labels. It's all done in 
hardware in less than a clock cycle. Contrast that with IP which must do 
it in software (it must open the packets to get to the MPLS labels). And 
what do some techniques do with those labels? They translate them (or 
copy them) directly into the ATM VPI/VCI fields.

When you look at things like VoIP you find that unless you can collect 
multiple calls into TDM trains or some other such technique, the ATM 
voice cells travel 1/2 full anyway ... especially with compression. 
Bigger IP packets would just travel even more empty. The cells and 
packets just can't wait around to fill before they need to be on their 
way to avoid anoying delay.

Re optimizing the buffering in the ATM switches: When I last looked, 
they had amazingly clever methods in the UTOPIA-II chip sets for doing 
this... Far more elegant than anything I have seen in IP traffic shaping 
for example. And if you look at the carrier's tendency to want to trunk 
things ... because that's how they did it with wires ... you see they 
themselves create these optimization and buffering problems. The ATM 
model doesn't want to be trunked. It wants to be spread out ... like in 
a web.

Further, the carriers ignored ATMs SVC capability and rather went with 
manual provisioning of PVCs. They took the easy way out with circuit 
emulation ... again, just emulating wires. Manual provisioning doesn't 
cut it in a dynamic enviornment. And when they do this trunking, as I 
said before, they run up against VC exhaustion. The ATM labels just 
don't have enough bits when you try to cram all the world's traffic down 
one pipe and try to keep it separate. So what do they do? They jam all 
the traffic together and then at each node they separate it all back out 
again to redistribute it. And then jam it all back together to move on 
to the next node. How can anyone say cell-tax with a straight face after 
all that?

Must we ditch this most elegant of designs available to us because of 
urban legends? If ATM turned out to be a bad experience, it has to be 
because it was invented before the hardware was ready to support it and 
because it was misapplied. Your comments are exactly as extensive as any 
contrast I have seen suggesting that ATM is in some way deficient to IP. 
This isn't rocket science. It's FUD.

With ATM spread out in a web, all those issues go away.

> (PTT or otherwise), perhaps using IETF's MANET work and/or IPv6.

I sure don't see the big deal here. Once a connection is established, 
PTT is automatic. By its nature, PTT is bursty (like the internet) and 
you model for that. Such a model may have the connection go into a 
dormant state with disuse and get new priority when the button is 
pressed. It's just another way of using the connection.

And take the example of  video conferencing:  you create a call which is 
a collection of connections. You have a highspeed connection for the 
video that isn't too concerned with jitter and dropped cells. You have a 
lower speed, but higher QoS connection for the voice because it suffers 
badly from jitter and cell drops. And you have a low speed low QoS 
connection for things like a mouse or a whiteboard. All this is 
controlled by a real low speed control connection which has perfect QoS 
(i.e. CBR). When you hang up the call, you close all the connections. 
Further, if  you bring on another party, you just add a connection for 
them ... maybe it's voice only. The flexibilty available lends itself to 
very natural solutions to a wide range of scenarios.

> battlefields or public safety incident response).

And here is where I think the model can really shine. Think of trying to 
deliver cell phone service to a rock concert. The more people who 
gather, the more concentrated the web and the greater its bandwidth. 
Most of those people are just talking to other people at the same 
concert and so their traffic never goes to a tower. With the low power 
consumption characteristic of UWB, you also don't have a huge battery 
drain which you would have if you tried to implement this using another 
wireless technology. The more packed the concert gets, the lower power 
the radios need to find adjacent nodes. Pretty soon they're jambed so 
tight you have BlueTooth. And with all that bandwidth, the music could 
be piped with great fidelity straight to anyone with a cell/radio.

You have the same issues with public safety. As traffic builds (all the 
cops and firemen come to the scene) your bandwidth naturally builds and 
your power needs naturally diminish. And since you're using software 
radios, there is no one listing in. All conversations are easily and 
naturally encrypted and decrypted by the radios.

How are things in Illinois? I'm from Peoria.

WithGLEE,
Todd Marshall
Spring, TX: USA
http://WithGLEE.com

> <http://rd.yahoo.com/M=259538.3625325.4914071.1261774/D=egroupweb/S=1707367802:HM/A=1695348/R=0/SIG=11u38u3s2/*http://hits.411web.com/cgi-bin/hit?page=1374-105951838331032> 
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service 
> <http://docs.yahoo.com/info/terms/>.