Yasser A. Lotfy | 1 Sep 2003 17:24
Picon

Re: The Problem of Alien Node

Hi,
That is exactly my point. Ad-hoc nodes may not always have a MANET_PREFIX IP address due to possibilities of
nodes roaming with a static IP, and the chances of ad-hoc network getting partitioned or merged.

Therefore, it is not possible for ad-hoc nodes to rely merely on MANET_PREFIX IP address to distinguish
local nodes (LAA). The gateway also will asume nodes that don't have MANET_PREFIX IP address are
external, and will forward packets outside the ad-hoc. While in fact some nodes that don't have
MANET_PREFIX IP address are local nodes, with global static IP (I call it alien nodes).

Therefore, I believe, there should be a registration mechanism for all alien nodes at the gateway.

Any comments? any reason why not?

yasser
----------------------------------------------
I'm sorry but the point that you are trying to get across is not very 
clear, and your terminology is quite confusing...
perhaps it would become clearer if we knew what your references 
were...[047-01] and [048-01].

when building a scenario that incorportes both terrestrial and ad hoc nodes, it is best to use address in
MANET_PREFIX to identify ad hoc nodes.  this way the gateway knows which address are in manet and which are
in terrestrial network.  These address spaces should be mutually exclusive, or you are going to run into
the problems that you describe(atleast thats what I think you are talking about).

alternately, if you decide that the two address spaces can intermingle, then you need to run complex
registration/deregistration protocols at the gateway to inform the gateway which addresses(nodes)
are in the manet.(some hybrid form of MIP).

-manish
(Continue reading)

jhchauhan | 1 Sep 2003 23:43
Favicon

Value for CTSTimeout

Hello,

The IEEE 802.11 PHY and MAC Specifications state that "After transmitting an 
RTS frame, the STA shall wait for a CTSTimeout interval, starting at the 
PHYTXEND.confirm." If the station does not receive a CTS frame within this 
time period, it considers that the transmission of RTS has failed and starts 
retransmitting the RTS.

I am looking for a typical value for the CTSTimeout interval. It would be 
helpful if someone can inform me about it or tell me a mathematical equation 
in terms of aSIFSTime or aSlotTime or some other parameter. 
Any suggestions are appreciated.

Regards,
Jasmina

Jasmina Chauhan
Graduate Assistant
Wichita State University
Kansas.

Voice : 316-682-6133 (Res)
HyunWook Cha | 1 Sep 2003 05:10
Picon
Picon

RE: The Problem of Alien Node

Hi, Manish.

> -----Original Message-----
> From: manet-admin <at> ietf.org [mailto:manet-admin <at> ietf.org] On 
> Behalf Of Manish Karir
> Sent: Saturday, August 30, 2003 2:03 AM
> To: manet <at> ietf.org
> Subject: Re: [manet] The Problem of Alien Node
> 
> 
> 
> 
> 
> I'm sorry but the point that you are trying to get across is not very 
> clear, and your terminology is quite confusing...
> perhaps it would become clearer if we knew what your references 
> were...[047-01] and [048-01].
> 
> when building a scenario that incorportes both terrestrial and ad hoc 
> nodes, it is best to use address in MANET_PREFIX to identify ad hoc 
> nodes.  this way the gateway knows which address are in manet 
> and which 
> are in terrestrial network.  These address spaces should be mutually 
> exclusive, or you are going to run into the problems that you 
> describe(atleast thats what I think you are talking about).
> 

Basically, I agree.
But, some application which is not specific to MANET and not being using
for only MANET can not give MANET_PREFIX address of the peer manet node
(Continue reading)

ogier | 2 Sep 2003 08:15

Re: Comments on draft-jelger


Hi Christophe,

Regarding your new draft, I am not sure that "prefix continuity"
is necessary. That is, I am not sure that the set of nodes having 
the same prefix needs to be contiguous.  Please consider the 
following, and let me know if I am missing something.

It is only necessary for each node to have a route to the
gateway(s) it is affiliated with, and for each gateway to have 
a route to each node that is affiliated with it.
One might argue that if the set of nodes with a given prefix 
is contiguous, then it is easier to flood a message to all 
nodes having that prefix, but I think it is sufficient for a 
gateway to be able to perform the following types of flooding:

(a) Flooding to all nodes in the manet.
(b) Flooding to all nodes in the manet that are within K hops
    of the gateway (where K is such that any node affiliated with 
    the gateway is required to be within K hops of that gateway).

Thus, I am not sure it is necessary to go through the trouble to
ensure "prefix continuity".
A node can simply select the nearest gateway (which can be determined
from the information provided by a proactive routing protocol),
and use the prefix advertised by that gateway.  The node can keep 
that prefix until it no longer has a route to that gateway, or becomes 
more than K hops from that gateway, or finds another gateway that is 
much closer.

(Continue reading)

jian wu | 2 Sep 2003 11:17
Picon
Favicon

manet qos

Dear all

I am currenly studying QoS in manets. I wonder how to reserve resources 
(bandwidth) in an 802.11-type network. While in TDMA or CDMA MAC, you can 
reserve time slots for flows, but for a 2 Mbps 802.11 link, how do you 
reserve 200 Kbps for a flow? Any suggestions would be appreciated.

Regards

J.

_________________________________________________________________
Sign-up for a FREE BT Broadband connection today! 
http://www.msn.co.uk/specials/btbroadband
S.Sivavakeesar | 2 Sep 2003 16:43
Picon

Hidden Terminal Problem

Dear All : 

Can somebody tell me whether the IEEE 802.11 DCF can completely avoid 
'Hidden-Terminal' problem with the use of RTS-CTS, physical carrier-sensing 
and NAV in multihop MANET ? Does it depends on distance between  nodes and 
RTS & CTS duration ? Even if there is a chance for hidden terminal problem 
in multihop ad hoc networks, does IEEE 802.11 DCF mode operation in single 
hop environment completely avoid hidden-terminal problem. 

Cheers 

SIVA
Vishal Sisodia | 2 Sep 2003 17:14
Picon
Favicon

Hi everbody..

Hi,

I am working for telecomm company in India, and I have
lot of exp. in telecomm field,I want to do research in
manet field, can anybody tell me how I can proceed...

I have studied some papers in manet field already but
not getting any direction.

I am also interested for applying in US universities
for MS or PhD.

I will be very thankful to you all.

Best,
Vishal Sisodia
Hughes Software Systems
Gurgaon,India
voice: 09811808307

________________________________________________________________________
Yahoo! India Promos: Win TVs, Bikes, DVD players & more!
Go to http://in.promos.yahoo.com
Zhenqiang(Frank) Ye | 2 Sep 2003 18:41

Re: Value for CTSTimeout

Hi Jasmina,
  If the RTS-CTS handshake is successful, the RTS sender should recieve
a CTS frame after it sends out its RTS and waits for SIFS +
tranmission time of a CTS. Otherwise, it means the RTS fails. By the
way, you need to include some propagation delay. In ns-2 802.11 code,
the RTS timeout value is set to be:
 propagation dalay (of RTS) + SIFS +Tx(CTS) + propagation delay (of CTS).

On Mon, 1 Sep 2003, jhchauhan wrote:

> Hello,
>
> The IEEE 802.11 PHY and MAC Specifications state that "After transmitting an
> RTS frame, the STA shall wait for a CTSTimeout interval, starting at the
> PHYTXEND.confirm." If the station does not receive a CTS frame within this
> time period, it considers that the transmission of RTS has failed and starts
> retransmitting the RTS.
>
> I am looking for a typical value for the CTSTimeout interval. It would be
> helpful if someone can inform me about it or tell me a mathematical equation
> in terms of aSIFSTime or aSlotTime or some other parameter.
> Any suggestions are appreciated.
>
> Regards,
> Jasmina
>
> Jasmina Chauhan
> Graduate Assistant
> Wichita State University
> Kansas.
(Continue reading)

Zhenqiang(Frank) Ye | 2 Sep 2003 18:58

Re: Hidden Terminal Problem

IEEE 802.11 DCF can not completely avoid "hidden terminal problem".  If
all the mobile nodes are within the sensing range of each other (not
necessarily within one hop), hidden terminal problem will not occur.

On Tue, 2 Sep 2003 S.Sivavakeesar <at> connectfree.co.uk wrote:

> Dear All :
>
> Can somebody tell me whether the IEEE 802.11 DCF can completely avoid
> 'Hidden-Terminal' problem with the use of RTS-CTS, physical carrier-sensing
> and NAV in multihop MANET ? Does it depends on distance between  nodes and
> RTS & CTS duration ? Even if there is a chance for hidden terminal problem
> in multihop ad hoc networks, does IEEE 802.11 DCF mode operation in single
> hop environment completely avoid hidden-terminal problem.
>
>
> Cheers
>
> SIVA
>
> _______________________________________________
> manet mailing list
> manet <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
>

--

-- 

****************************************
Zhenqiang(Frank) Ye
(Continue reading)

ogier | 2 Sep 2003 22:27

Re: Comments on draft-jelger


Christophe,

Thanks for your response. Please see my futher comments below.

> Hi Richard and thanks for your comments,
> 
> Please check below within your text for my comments. In general, your points 
> make sense and we already considered most of them but we decided to insist on

> prefix continuity. There are of course pros and cons in any solution. We 
> decided to favor prefix continuity because the hop-by-hop propagation method 
> that we use naturaly leads to prefix continuity. I think there is no "best 
> method", because topological changes are unpredictable and it is difficult to

> simulate and compare different solutions. Well it would be nice to gather 
> comments and ideas from other MANET members, so more comments are very 
> welcome !
> 
> Regards,
> Christophe
> 
> Quoting ogier <at> erg.sri.com:
> 
> > 
> > Hi Christophe,
> > 
> > Regarding your new draft, I am not sure that "prefix continuity"
> > is necessary. That is, I am not sure that the set of nodes having 
> > the same prefix needs to be contiguous.  Please consider the 
(Continue reading)


Gmane