Re: [ipwave] Hidden terminal problem

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 19 April 2019 12:08 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CD4120145; Fri, 19 Apr 2019 05:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNN01xm_h04f; Fri, 19 Apr 2019 05:08:38 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA4C12009C; Fri, 19 Apr 2019 05:08:37 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x3JC8SQN081326; Fri, 19 Apr 2019 14:08:28 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A8ED3206640; Fri, 19 Apr 2019 14:08:28 +0200 (CEST)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 91E222030DD; Fri, 19 Apr 2019 14:08:28 +0200 (CEST)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x3JC8ScS017337; Fri, 19 Apr 2019 14:08:28 +0200
To: Abdussalam Baryun <abdussalambaryun@gmail.com>
Cc: Charlie Perkins <charles.perkins@earthlink.net>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org" <draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>, "its@ietf.org" <its@ietf.org>, "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
References: <155169869045.5118.3508360720339540639@ietfa.amsl.com> <MN2PR11MB356570FDBC5798F155DDEE25D82C0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMugd_Xce5cWLtVB4DbR1ZEaFbdfiRpXre9oq61ukRC+n+3cZw@mail.gmail.com> <D8D5F0B7.2F2BB8%sgundave@cisco.com> <D8D5F510.2F2BC8%sgundave@cisco.com> <3e716b4b-8236-0488-309c-7cd3a54db7b5@gmail.com> <D8D7B1E7.2F2CA2%sgundave@cisco.com> <CAD8vqFfSGKhw_ou3VB98C8r1gq=4WD8+f8C5P53C46k-0V+XuA@mail.gmail.com> <66e7c810-45a5-5244-59dc-4b764b6fb346@gmail.com> <1a6599ee-88f9-42d9-a208-918ba6711612@gmail.com> <11645738-6f95-82e5-48f1-ebc3ce54423e@gmail.com> <6aaea808-6013-cd73-c894-c29fd8c98ac8@gmail.com> <72f60b2f-0a3a-8d60-f6de-09c058913c33@earthlink.net> <62a65ef0-43f2-648e-fe68-50f484d09ef1@gmail.com> <fe190caa-fa94-f398-6cf9-01a8f23e2e4f@earthlink.net> <CADnDZ89GYk=hRpxohaAgRvNTc30KDacX82OFyS5cbQugu043ew@mail.gmail.com> <c53b8f0c-0ab7-bf30-ccc9-f02a764949f3@gmail.com> <CADnDZ8_6sEARtP0YMY1vPSQDK928Bbe1=VuLoAND6FEJWcdjCQ@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <33f2f81c-c2be-007a-bfb7-5c5f9788c2a3@gmail.com>
Date: Fri, 19 Apr 2019 14:08:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CADnDZ8_6sEARtP0YMY1vPSQDK928Bbe1=VuLoAND6FEJWcdjCQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/UpJBqGKl0AVftJjuMMGB-w-AJB0>
Subject: Re: [ipwave] Hidden terminal problem
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2019 12:08:40 -0000


Le 19/04/2019 à 12:26, Abdussalam Baryun a écrit :
> 
> 
> On Thu, Apr 18, 2019 at 10:21 AM Alexandre Petrescu 
> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote:
> 
> 
> 
>     Le 18/04/2019 à 04:43, Abdussalam Baryun a écrit :
>      >
>      >
>      > On Tue, Apr 16, 2019 at 5:50 PM Charlie Perkins
>      > <charles.perkins@earthlink.net
>     <mailto:charles.perkins@earthlink.net>
>     <mailto:charles.perkins@earthlink.net
>     <mailto:charles.perkins@earthlink.net>>>
>      > wrote:
>      >
>      >     Hello Alex,
>      >
>      >     Consider the following three nodes with radio links as shown:
>      >
>      >     A----------B----------C
>      >
>      >     Suppose that A and B are at 80% of their signal range, and
>     also that B
>      >     and C are at 80% of their signal range.
>      >
>      >     So A and C are not in range.  So A is 'hidden' from C, and C is
>      >     'hidden'
>      >     from A.
>      >
>      >     That's the hidden terminal problem.  It's not specific to OCB
>     or WiFi,
>      >     and it is not a hypothetical problem.  It's just physics.
>     It's not at
>      >     all difficult to understand, but it is very important to
>     understand.
>      >
>      >
>      > Yes but it has been reduced its effects of collisions by CSMA/CA,
>     and by
>      > using control frames,
> 
>     Is OCB using CSMA/CA?
> 
> 
> Yes,

I did not know that.  I thought CSMA, CDMA, WCDMA and OFDM are 
alternatives.  Something like this: Ethernet uses CSMA, CDMA phones use 
CDMA, WCDMA phones use WCDMA, and 802.11a uses OFDM.

So I learn OCB uses CSMA/CA and OFDM.

>     Is the OFDM that I see in OCB packet dumps an alternative to CSMA/CA?
> 
> 
> one in PHY layer and the other protocol in MAC layer,

Ok.

Just to let you know that my packet analyser wireshark talks only about 
OFDM at PHY layer, but it says nothing about CSMA/CA at the MAC layer; 
(the RadioTap Header (presumably PHY) displays Channel flags set to 
0x4140, meaning ÓFDM, 5GHz, half rate 10MHz; the LLC header and the 
802.11 QoS Data header (presumably MAC) dont say 'CSMA/CA' - but maybe 
it is there but I dont know it).

>     Is OFDM solving the hidden terminal problem?
> 
> 
> Yes when using MIMO and multi directional antennas, but some only think 
> in Omni-directional antenna use cases, and they think only in SISO use 
> cases.

In my deployments I typically put MIMO antennas in the IP-RSU (multiple 
groups of MIMO antennas) and MIMO antennas (one group) on top of the 
car; for V2V I put just one antenna (no MIMO) in front bumper and one in 
rear bumper, but it can grow to more if bigger car.

Before putting these MIMO things we had many reliability problems.

What is SISO?

>     In OCB there are no control frames; so the absence of the control
>     frames
>     can not help with the hidden terminal problem - on the contrary, it may
>     worsen it.
> 
> 
> In all cases of IEEE802.11 and application there are management messages 
> and control messages and data messages, so Do you say there is no 
> Control messages and no Management messages in OCB use cases,

Yes, I say so.  Most devices I listened to have no control messages at 
all in 802.11 in OCB mode.  I dont receive them.  Some few old RSUs 
beacon 'Probe Request' with en empty ESSID.  'Empty' means that the 
programmer writes something like s/he thinks like empty: some write 
'empty', italians write 'assente' (for 'absent') and so on.  So there 
can be an empty ESSID in these old RSUs, to respect the standard.

> I disagree,

I dont know why you disagree, but I dont disagree with you.

> IMHO, it is ok to configure OCB with RTS/CTS and poll technique to solve 
> some applications services needed.

I dont know what is OCB with RTS/CTS and poll technique.  IS there a way 
I can try that in practice?  Maybe an 'iw' command?

Which applications/services may benefit from OCB with RTS/CTS and poll 
technique?

Alex

> 
> 
> AB
> 
> 
>      >
>      >     One question below...
>      >
>      >     On 4/16/2019 3:18 AM, Alexandre Petrescu wrote:
>      >      >
>      >      > ...
>      >
>      >      >
>      >      > I do not know how the hidden terminal problem works.  I
>     feel like
>      >     if I
>      >      > start looking into it I will grow additional white hairs. 
>     I feel
>      >     like I
>      >      > better avoid  it.
>      >
>      >
>      > usually it is the IEEE problem to solve not this WG problem. I
>     believe
>      > they solved it.
> 
>     IT's good to know if it were that way.
> 
>      >      >
>      >      > I think other people have some experience with the hidden
>     terminal
>      >      > problem in non-OCB WiFi and 802.15.4.  I am listening to them.
>      >
>      >
>      > usually MIMO technology has change many issues, but 802.15.4 is big
>      > different MAC than 802.11,
> 
>     I agree.
> 
>      >
>      >      >
>      >      > I think nobody has any experience with the hidden terminal
>     problem in
>      >      > OCB settings.  I have some doubts, but still I think it is
>     almost
>      >     nobody.
>      >      >
>      >      >
>      >     I find this very surprising!  What do others think?
>      >
>      >
>      > I think usually this hidden terminal is old problem now
>     IEEE802.11 has
>      > been updated, solving many old problems including that. It is
>     called now
>      > hidden station in IEEE802.11 new docs. In old sunets and
>     terminals they
>      > have no intelligence but now the stations are smart especially
>     when it
>      > is a Car not a sensor, because a Car has big storage and power
>      > capabilities that can help to increase intelligence and decision
>     making.
> 
>     I think both points are worth mentioning: (1) 802.11 new docs
>     (presumably year 2016) do have solutions for hidden station problem and
>     (2) car may have more computing capability than a small temperature
>     sensor and hence may use it to alleviate the hidden station problem.
> 
>     I think there is much that can be put together about this.
> 
>     Pascal described an A-B-C-D problem.
>     Charles described an A-B-C hidden terminal problem.
>     I described a hidden car problem.
>     You mention the IEEE hidden station problem and the IEEE 802.11 new
>     solutions to it.
> 
>     It makes for a beautiful section "Hidden-icity Problems" (sorry I dont
>     know a good term about Hidden).
> 
>     Alex
>