Re: [ipwave] [EXTERNAL] Re: I-D Action: draft-ietf-ipwave-vehicular-networking-15.txt

["Templin (US), Fred L" <[e-mail]>]

Alex, beginning in Y2K I led a research project at the UC Berkeley campus for
Unmanned Air Systems (UAS) comms where we had omni-directional wireless
antennas for IEEE 802.11 mounted on remote-control Yamaha RMAX helicopters
("UAM vehicles") that flew from just above ground level up to about 100ft
altitude.  The helicopters communicated with wheeled robots on the ground
("terrestrial vehicles") as well as handheld devices carried by researchers
("pedestrians") and ground domain base stations ("roadside units").  We
had a paper about it at the 2002 IEEE Aerospace conference:

https://ieeexplore.ieee.org/document/1036114

From this experience, you are correct in saying that the airframe of the UAM
can attenuate a signal if not in an optimal orientation, but this is a problem
that we solved early on with a simple physical antenna mounting arrangement.
So, this is something that has been known about for 20 years at least (and
probably a lot longer than that) and we proved that there are solutions.

Coincidentally, this program is also where the technology that eventually
became known as OMNI got its start.

Thanks - Fred


> -----Original Message-----
> From: its [mailto:[e-mail]] On Behalf Of Alexandre Petrescu
> Sent: Tuesday, July 07, 2020 1:24 AM
> To: [e-mail]
> Subject: [EXTERNAL] Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-15.txt
> 
> This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
> know that the content is safe.
> 
> 
> Le 06/07/2020 à 18:59, Templin (US), Fred L a écrit :
> > Paul, thanks. Also consider that a flying car that is only a few
> > meters off the ground
> >
> > may require V2V coordination with terrestrial vehicles at ground
> > level, and using the
> >
> > same sorts of wireless data links currently under consideration in
> > the terrestrial
> >
> > domain (cellular, DSRC, CV2X, Elon Musk, etc.). So, I think V2V
> > means any vehicle
> >
> > to any vehicle, whether or not at ground-level.
> 
> For communications between flying taxi and ground, I wanted to talk
> about a PHY level aspect.
> 
> To let know that I am looking at how flying taxis could be made to
> communicate to the ground.  One of the first steps I am confronting is
> the antenna placement - it should be on the belly of the taxi
> (underneath), and not as the current practice of situating an antenna
> on the roof of an automobile.  This induces some new design constraints
> to the frame and cockpit, but it should be workable.
> 
> My antenna provider who specializes in ITS antennas for automobiles and
> similar IoT and Urban, told me they have not yet received such request
> for such antennas.  They suspect the traditional 5.9GHz antennas would
> work, but just need to be placed elsewhere in this car, sorry, flying car.
> 
> Why is this PHY aspect important for IP networking?
> 
> BEcause, while grounded, this flying taxi could not use this belly
> antenna to talk to a eg Road Side Unit or a cellular base station.  At
> that point it would need to switch to using an antenna that is rather
> situated on the roof of the car.  That would amount to changing which
> egress interface is it using, so a sort of handover or so.
> 
> One might even think of a sort of a gradual switch between belly and
> roof, depending on the altitude at which the vehicle evolves.  So for
> example at 50m altitude maybe the V2Ground traffic would be split 50-50
> between roof and belly, instead of a total handover all-or-nothing for
> each interface.
> 
> I guess an OMNI interface concept could qualify for such a behaviour,
> because of its virtual nature.  But there would be a need to clarify the
> mechanism of that virtuality.
> 
> Alex
> 
> >
> > Fred
> >
> > *From:*Mr. Jaehoon Paul Jeong [mailto:[e-mail]]
> > *Sent:* Monday, July 06, 2020 9:24 AM *To:* Templin (US), Fred L
> > <[e-mail]> *Cc:* Peter E. Yee <[e-mail]>;
> > Zeungil Kim <[e-mail]>; Yong-Joon Joe
> > <[e-mail]>; skku-iotlab-members
> > <[e-mail]>; [e-mail]; Mr. Jaehoon
> > Paul Jeong <[e-mail]> *Subject:* Re: [ipwave] Re: I-D
> > Action: draft-ietf-ipwave-vehicular-networking-15.txt
> >
> >
> >
> >
> > Hi Fred,
> >
> > I will update the text about the OMNI link model to accommodate
> > general vehicles including UAMs in Section 4.1.
> >
> > For the use cases, I will include UAMs (e.g., drones) as example
> > vehicles in V2V and V2I scenarios:
> >
> > - V2V: UAM collision avoidance in air
> >
> > This is an extension of Context-Aware Navigator for terrestrial
> > vehicles:
> >
> > http://iotlab.skku.edu/publications/international-conference/ICCE-ASIA-CAN.pdf
> >
> >
> >
> >
> >
> - V2I: UAM navigation with efficient battery charging scheduling
> >
> > UAM can communicate with TCC for its flying trajectory (i.e.,
> > navigation path) via RSU:
> >
> > http://iotlab.skku.edu/publications/international-journal/CBDN-2019.pdf
> >
> >
> >
> >
> >
> Thanks.
> >
> > Best Regards,
> >
> > Paul
> >
> > 2020년7월7일(화) 오전12:13, Templin (US), Fred L
> > <[e-mail] <mailto:[e-mail]>>님이작성:
> >
> > Paul, my intended meaning is that the text from the UAM document is
> > intended
> >
> > to apply generically to all manners of vehicular communications,
> > including cars,
> >
> > trucks, taxis, pedestrians and any other ipwave use cases that are
> > considered
> >
> > by your document. So, the text should be phrased as generically as
> > possible, and
> >
> > not specific to just UAM.
> >
> > This brings me to a point that we might want to consider. I believe
> > that the
> >
> > ipwave approach should apply not just for traditional terrestrial
> > vehicles but
> >
> > also for the coming influx of low-altitude urban air mobility
> > scenarios such as
> >
> > flying cars and taxis. The Jetsons vision is close at hand, and in
> > the coming
> >
> > decades we are certainly going to see an increasing mix of
> > terrestrial and
> >
> > low-altitude air vehicles all sharing the same frequency spectrum
> > and data
> >
> > communications architecture. That is why I wrote the UAM document,
> > but
> >
> > should we consider bringing the UAM use case into ipwave?
> >
> > Thanks - Fred
> >
> > *From:*its [mailto:[e-mail]
> > <mailto:[e-mail]>] *On Behalf Of *Mr. Jaehoon Paul Jeong
> >  *Sent:* Monday, July 06, 2020 7:02 AM *To:* Templin (US), Fred L
> > <[e-mail] <mailto:[e-mail]>> *Cc:*
> > Peter E. Yee <[e-mail] <mailto:[e-mail]>>; Zeungil
> > Kim <[e-mail] <mailto:[e-mail]>>; Yong-Joon
> > Joe <[e-mail] <mailto:[e-mail]>>;
> > skku-iotlab-members <[e-mail]
> > <mailto:[e-mail]>>; [e-mail]
> > <mailto:[e-mail]> *Subject:* Re: [ipwave] [EXTERNAL] Re: I-D
> > Action: draft-ietf-ipwave-vehicular-networking-15.txt
> >
> >
> >
> > This message was sent from outside of Boeing. Please do not click
> > links or open attachments unless you recognize the sender and know
> > that the content is safe.
> >
> >
> > Hi Fred,
> >
> > I have reflected your comments about the references and OMNI link
> > model on the next revision as follows.
> >
> > ----------------------------------------------------------------------------------------
> >
> >
> >
> >
> >
> Section 4.1. Vehicular Network Architecture
> >
> > Wireless communications needs to be considered for end systems for
> > Urban Air Mobility (UAM)
> >
> > such as flying cars and taxis [UAM-ITS].. These UAM end systems may
> > have multiple wireless
> >
> > transmission media interfaces (e.g., cellular, communications
> > satellite (SATCOM), short-range
> >
> > omni-directional interfaces), which are offered by different data
> > link service providers.
> >
> > To support not only the mobility management of the UAM end systems,
> > but also the multihop
> >
> > and multilink communications of the UAM interfaces, the UAM end
> > systems can employ an
> >
> > Overlay Multilink Network (OMNI) interface [OMNI-Interface] as a
> > virtual Non-Broadcast
> >
> > Multiple Access (NBMA) connection to a serving ground domain
> > infrastructure. This
> >
> > infrastructure can be configured over the underlying data links. The
> >  OMNI interface and its
> >
> > link model provide a means of multilink, multihop and mobility
> > coordination to the legacy
> >
> > IPv6 ND messaging [RFC4861] according to the NBMA principle. Thus,
> > the OMNI link model
> >
> > can support efficient UAM internetworking services without
> > additional mobility messaging,
> >
> > and without any modification to the IPv6 ND messaging services or
> > link model.
> >
> > ----------------------------------------------------------------------------------------
> >
> >
> >
> >
> >
> I attach a temporary pdf file for the revision.
> >
> > Is this text fine to you?
> >
> > Thanks.
> >
> > Best Regards,
> >
> > Paul
> >
> > On Sun, Jul 5, 2020 at 1:40 AM Templin (US), Fred L
> > <[e-mail] <mailto:[e-mail]>>
> > wrote:
> >
> > Paul, thank you for your efforts. Please note that the references
> > you have
> >
> > included for AERO and LISP are out of date. The correct references
> > are:
> >
> > LISP:  draft-ietf-lisp-rfc6830bis
> >
> > AERO: draft-templin-intarea-6706bis
> >
> > About OMNI, the text you have offered does not quite capture the
> > concepts
> >
> > I believe should appear in your document. Please see Section 4 of
> >
> > “Urban Air Mobility Implications for Intelligent Transportation
> > Systems”:
> >
> > https://datatracker.ietf.org/doc/draft-templin-ipwave-uam-its/
> >
> > This explains the OMNI link model as applied to Urban Air Mobility
> > (e.g.,
> >
> > flying cars and taxis), but the concepts are one and the same with
> > what
> >
> > should be discussed for terrestrial vehicle and pedestrian
> > communications.
> >
> > Please review the text (see below) and adopt in your document.
> >
> > Thanks - Fred
> >
> > ---
> >
> > 4.  The Overlay Multilink Network (OMNI) Interface
> >
> > UAM end systems will often have multiple diverse wireless
> >
> > transmission media interfaces (including cellular, SATCOM, short-
> >
> > range omni-directional, etc.) offered by different data link service
> >
> > providers.  In order to provide mobility, multihop and multilink
> >
> > services, UAM end systems can employ an Overlay Multilink Network
> >
> > (OMNI) interface [I-D.templin-6man-omni-interface] as a virtual Non-
> >
> > Broadcast Multiple Access (NBMA) connection to the serving ground
> >
> > domain infrastructure configured over the underlying data links.
> >
> > The OMNI interface and link model provide a nexus for multilink,
> >
> > multihop and mobility coordination using standard IPv6 Neighbor
> >
> > Discovery (ND) messaging [RFC4861] according to the NBMA principle.
> >
> > The OMNI model therefore supports efficient UAM internetworking
> >
> > services with no need for adjunct mobility messaging, nor
> >
> > modifications to the IPv6 ND messaging services or link model.
> >
> > *From:*its [mailto:[e-mail]
> > <mailto:[e-mail]>] *On Behalf Of *Mr. Jaehoon Paul Jeong
> >  *Sent:* Monday, June 29, 2020 2:50 AM *To:* [e-mail]
> > <mailto:[e-mail]> *Cc:* Peter E. Yee <[e-mail]
> > <mailto:[e-mail]>>; skku-iotlab-members
> > <[e-mail]
> > <mailto:[e-mail]>>; Yong-Joon Joe
> > <[e-mail] <mailto:[e-mail]>>; Zeungil Kim
> > <[e-mail] <mailto:[e-mail]>>; Mr. Jaehoon Paul
> > Jeong <[e-mail] <mailto:[e-mail]>>
> > *Subject:* [EXTERNAL] Re: [ipwave] I-D Action:
> > draft-ietf-ipwave-vehicular-networking-15.txt
> >
> >
> >
> > This message was sent from outside of Boeing. Please do not click
> > links or open attachments unless you recognize the sender and know
> > that the content is safe.
> >
> >
> > Hi IPWAVE WG,
> >
> > I have submitted the revision of IPWAVE PS Draft as follows:
> >
> > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-15
> >
> >
> >
> >
> >
> >
> > The following 8 people reviewed this draft:
> >
> > Nancy Cam-Winget (Cisco),
> >
> > Fred L. Templin (The Boeing Company),
> >
> > Jung-Soo Park (ETRI),
> >
> > Zeungil (Ben) Kim (Hyundai Motors),
> >
> > Kyoungjae Sun (Soongsil University),
> >
> > Zhiwei Yan (CNNIC),
> >
> > Yong-Joon Joe (LSware), and
> >
> > Peter E. Yee (Akayla).
> >
> > I sincerely appreciate those reviewers' efforts to improve our
> > IPWAVE PS WG draft.
> >
> > I attach the revision letter to show how I have addressed their
> > comments.
> >
> > The reviewers above (i.e., Nancy, Fred, Jung-Soo, Zeungil,
> > Kyoungjae, Zhiwei, Yong-Joon, and Peter),
> >
> > Could you doublecheck whether or not my revision has addressed your
> > comments by July 5th, 2020 in EST?
> >
> > If you have further comments, please let me know.
> >
> > If this review during this period does not raise other further
> > comments, I would like to ask for a WGLC on this draft.
> >
> > Thanks.
> >
> > Best Regards,
> >
> > Paul
> >
> > --
> >
> > =========================== Mr. Jaehoon (Paul) Jeong, Ph.D.
> > Associate Professor Department of Computer Science and Engineering
> > Sungkyunkwan University Office: [phone] Email:
> > [e-mail] <mailto:[e-mail]>,
> > [e-mail] <mailto:[e-mail]> Personal Homepage:
> > http://iotlab.skku.edu/people-jaehoon-jeong.php
> > <http://cpslab.skku.edu/people-jaehoon-jeong.php>
> >
> > On Mon, Jun 29, 2020 at 6:22 PM <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories. This draft is a work item of the IP Wireless Access in
> > Vehicular Environments WG of the IETF.
> >
> > Title           : IPv6 Wireless Access in Vehicular Environments
> > (IPWAVE): Problem Statement and Use Cases Author          : Jaehoon
> > Paul Jeong (editor) Filename        :
> > draft-ietf-ipwave-vehicular-networking-15.txt Pages           : 39
> > Date            : 2020-06-29
> >
> > Abstract: This document discusses the problem statement and use
> > cases of IPv6-based vehicular networking for Intelligent
> > Transportation Systems (ITS).  The main scenarios of vehicular
> > communications are vehicle-to-vehicle (V2V),
> > vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X)
> > communications.  First, this document explains use cases using V2V,
> > V2I, and V2X networking. Next, for IPv6-based vehicular networks, it
> > makes a gap analysis of current IPv6 protocols (e.g., IPv6 Neighbor
> > Discovery, Mobility Management, and Security & Privacy), and then
> > lists up requirements for the extensions of those IPv6 protocols for
> > IPv6-based vehicular networking.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/
> >
> >
> >
> >
> >
> There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-15
> >
> >
> >
> >
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-15
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-vehicular-networking-15
> >
> >
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at
> > tools.ietf.org <http://tools.ietf.org>.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp..ietf.org/internet-drafts/
> > <ftp://ftp.ietf.org/internet-drafts/>
> >
> >
> > _______________________________________________ its mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/its
> >
> >
> > --
> >
> > =========================== Mr. Jaehoon (Paul) Jeong, Ph.D.
> > Associate Professor Department of Computer Science and Engineering
> > Sungkyunkwan University Office: [phone] Email:
> > [e-mail] <mailto:[e-mail]>,
> > [e-mail] <mailto:[e-mail]> Personal Homepage:
> > http://iotlab.skku.edu/people-jaehoon-jeong.php
> > <http://cpslab.skku.edu/people-jaehoon-jeong.php>
> >
> >
> > _______________________________________________ its mailing list
> > [e-mail] https://www.ietf.org/mailman/listinfo/its
> >
> 
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its