Download Firefox: WindowsMac OS X
logo       
Google Custom Search
    AddThis Social Bookmark Button
-->

Re: New implementation option for DS: msg#00007

Subject: Re: New implementation option for DS
On Thu, 16 Sep 2004, manisha s wrote:

> As we are know that IEEE 802.11 standard does not specify the physical
> medium to implement the DS. instead it just mentions services that have
> to be offered by the DS. Is it possible to use cellular technology(like
> GSM,GPRS,etc) as distribution system medium to connect APs?Is it valid
> idea?  What one should do to implement/change for this?

Regulatory problems: do the tariffs in your national jurisdiction allow
arbitrary internet access over cell phones?  Commercial problems: does your
service provider allow it, or do they insist that you do IP transport (and
pay big bucks for it) through their own subsidiary using a protocol that
works only on their network?

I'm no expert in cellular protocols, but as I understand it, each packet 
has a header so the tower knows which cell phone it came from, much like 
the MAC address in the 802.x family.  All that's necessary is to allocate 
a bit in the header that says "this is a data packet" (versus voice).  And 
of course to get firmware upgrades into all the towers and cell phones, 
over the kicking and screaming lawyers of the service providers.

802.x serves as a good model for such a design -- for example, you would 
need the equivalent of ARP -- but 802.11 in particular has a lot of baggage 
which in my opinion is mandated at the wrong protocol level.  WEP for 
example: encryption should be at the third layer (e.g. OpenVPN or PoPToP) 
or the fourth layer (SSH, HTTPS); it's totally bogus to put it at the 
second layer.  Packet handoffs between APs are anally retentive: if the 
mobile station switches APs and a packet is trapped, the former AP should 
either drop it, or upon hearing traffic for the station's MAC address from 
another source, it should put the trapped packet back on the LAN.  The 
third and fourth protocol layers are designed to deal with these issues and 
they should be used.

I think the companies (NCR, Aironet, Proxim) who pioneered the field wanted 
to make wireless match wired Ethernet in reliability of packet delivery, 
perhaps knowing that certain operating systems reacted badly to flaky 
transport.  The fix should have been to clean up the IP protocol stack in 
the (non open source) offending operating systems, not to burden 802.11 
with duplicating capabilities implemented elsewhere.

In summary, forget 802.11 over cell phones; use the existing cellular
protocol to the max, and beyond that, go with the lowest common
denominator.

> if suppose somehow we have implemented this idea, then how we communicate
> with Ethernet ? will the portal take care of the communication between
> such heterogeneous media?

Assuming second layer bridging were implemented, the third layer payload
would be IP packets, and any kernel knows how to accept an IP packet on one
interface and send it out another one.  Transport at the third layer should
be totally transparent, except it would go slow, like on a dialup
connection.  Actually the packet's protocol could be anything: IPv4, IPv6,
IGMP, ESP, etc., but it would appear to the tower's kernel as a third layer
object, to be routed (or dropped) exactly the same as if it came in over a
second wired NIC interface.

In your design, keep the layers strictly separate, and your life will be a 
whole lot easier.

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90095-1555
Email: jimc-w59uUeO1EWWFhjwBz98joA@xxxxxxxxxxxxxxxx    
http://www.math.ucla.edu/~jimc (q.v. for PGP key)


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php


<Prev in Thread] Current Thread [Next in Thread>