Re: [manet] [its] Scenarios, potential topics...

[Alexandru Petrescu <[e-mail]>]

Hi Dapeng,

Le 26/07/2012 09:25, liu dapeng a écrit :
> Hi Alex, Please see my reply inline.
>
> 2012/7/25, Alexandru Petrescu <[e-mail]>:
>> Dear Dapeng,
>>
>> Thank you for the interest in the v2v scenario.  Please see below
>> for answers to the questions.
>>
>> Le 25/07/2012 05:26, liu dapeng a écrit :
>>> Hi Alex,
>>>
>>> Regarding v2v communication:
>>>
>>> 1. If the mobile routers have LTE link and use IPv6, then v2v
>>> communication can also rely on LTE?
>>
>> LTE use on a vehicle for V2V communication may be an option.  We
>> locally think currently more about the use of shorter-range links
>> (WiFi, other) for direct communications between vehicles, without
>> the use of LTE infrastructure.
>
> [Dapeng] May I ask what is the use case scenario of this V2V
> communication?

Well you may and there are many scenarios that we considered in the
past, as part of work with various partners specialized in particular
scenarios.

V2V concepts for public transportation scenarios are described in
section 3.3 of draft-petrescu-its-scenarios-reqs-01.

A fixed incident scene scenario for V2V is described in section 3 of
draft-petrescu-autoconf-ra-based-routing-02.

Peer-to-peer applications described in section 4.2 of
draft-ietf-mext-nemo-ro-automotive-req-02.

An advertising vehicle scenario is one where a 'billboard' vehicle runs
along the highway and distributes not only visual ads but also wireless
Internet.  This is to be used in many kinds of convoys like...

Generic use of V2V is described in section 3.3 of
draft-petrescu-its-scenarios-reqs-01.txt.

CALM describes some V2V scenarios as well.

Is there some particular scenario that deserves more interest from your
side?

> Whether the transmission range of Wi-Fi is enough for this use case?

Indeed in some use cases the WiFi transmission range (unlicensed
spectrum, around 50meter range at a certain power level) may be enough.
  For example, at an incident scene this is largely enough.

On another hand, vehicles in a convoy, or wifi billboard vehicle,  may
need more than 50m, otherwise one is tempted to approach more for better
reception.  In these cases maybe LTE may be necessary, or other forms of
longer-range wireless links, maybe with forms of 802.11p.

>> On another hand, the use of a fixed LTE base station or eNodeB to
>> achieve communication between Mobile Routers may be feasible.
>> Just one LTE base station, or femto cell, may be sufficient to
>> largely improve the V2V communications based on short-range links.
>>
>> Even more, it may be possible to use a LTE base-station on board of
>> vehicle, and maybe LTE Relay, on X2 interface.  In this way, direct
>> V2V communication without fixed infrastructure, and still LTE -
>> long range, high bandwidth, may be possible.
>>
>> What do you think?
>
> [Dapeng] LTE D2D maybe relevant to this topic?

LTE D2D would stand for "Device-to-Device"?  I am not aware of this
term, please explain.

(I am aware of an effort at ETSI called "GW-to-GW" communications which
may approach much to these V2V terms).

>>> The precondition is that one vehicle knows the other vehicle's
>>> identity (for example, every mobile router have a domain name
>>> and can be updated dynamically).
>>
>> Right, if a MR owns a fully qualified domain name, then it may try
>> to obtain an IP address dynamically from the LTE infrastructure,
>> and then update its ressource record in the DNS.  In this way,
>> another MR may contact the first by identifying it with the FQDN.
>>
>> But here, there may be some problems about the LFNs (Local Fixed
>> Nodes). It's the LFNs which woult typically communicate
>> application data, not the MRs.  Then I wonder how would it be
>> possible to have a FQDN for all the LFNs, and an entry in DNS about
>> such FQDN and the IP prefix.  And how would the prefix be allocated
>> too.
>
> [Dapeng] How about using NEMO in the MR? If that is the case, the
> LFNs will be the mobile node and only the LFN that need to
> communicate with another vehicle need to have a FQDN. The user can
> get the FQDN by registering the service to the the ITS operator.

Sounds reasonable.

However, running NEMO Mobile IP on MR would mean that LFN is not running
anything mobility-related and that MR does all mobility management on
its behalf.

In this sense, such a scenario would mean that MR updates the DNS with
an entire set of addresses (a prefix).  For example, instead of updating
it with mr.example.com - 1::1, it would update it with example.com -
1::/64, if that is at all possible.

In this way, whenever some LFN asks to talk to LFN.example.com then the
IP address would be within that prefix.

I am not sure I am not saying stupid DNS things, I stand correced.

I need to better understand a DNS part of the picture in this ITS
effort, please, and others help clarify it.

Yours,

Alex

>
>> What do you think?
>>
>>> 2. Even in the above v2v case, Mobile IP could also be useful?
>>> Since mobile IP can provide a stable IP address, the mobile
>>> routers do not need to update the domain name dynamically, it
>>> can use the home address when registering in the domain system.
>>
>> Mobile IP could be useful, yes.  And if it is used then
>> reachability at a permanent address and session continuity are
>> ensured, without needing to update the DNS.  But in order for
>> Mobile IP to work there would be a need for a Home Agent in the
>> fixed infrastructure.
>>
>> For direct V2V communications one MR may "nest" under another MR.
>> For their communication to work, there would be a need that one of
>> those two MRs to be connected to the infrastructure to the HA.
>>
>> Also, it may be possible that even though the HA is not reachable,
>> one MR sends a BU to another MR informing it about its prefix. This
>> is doable.  Until now we have much considered the use of RA (Router
>> Advertisement) messages to achieve this, instead of BU. But each
>> has its advantages.
>
> [Dapeng] If use RA, that will limit the V2V communication to only
> adjacent vehicle?
>
> Thanks, Best Regards, Dapeng
>
>> What do you think?
>>
>> Alex
>>
>>>
>>> Any comments?
>>>
>>> Thanks, Best regards, Dapeng
>>>
>>> 2012/7/3, Alexandru Petrescu <[e-mail]>:
>>>> Hi Abdussalam and thanks for the reply.
>>>>
>>>> Le 01/07/2012 19:31, Abdussalam Baryun a écrit :
>>>>> Hi Alex and All,
>>>>>
>>>>>> Scenario :  A router deployed in a moving vehicle, uses its
>>>>>> egress interface to connect to larger-area access
>>>>>> network(s) or to other vehicles.
>>>>>
>>>>> <Q1>Should it use IPv6-over-LTE?
>>>>
>>>> In our context we consider indeed IPv6 over LTE, for several
>>>> reasons. The 3GPP specs about LTE seem to be very specific and
>>>>  detailed about the use of IPv6.  (In the past, before LTE, the
>>>>  earlier 3GPP specs were mentioning IPv6 but more like an
>>>> option feature.)
>>>>
>>>> However, the 3GPP specs about the use of IPv6 have some lack of
>>>> specification in the case that the UE (User Terminal) is
>>>> actually a Mobile Router.  The Prefix Delegation part may be
>>>> underspecified.
>>>>
>>>>> <Q2>Should it use Mobile IP?
>>>>
>>>> Hmm... that is a good question and much can be said about it. I
>>>> am interested to liste others' oppinions as well.
>>>>
>>>> I think Mobile IP may be necessary but not sufficient.  In the
>>>> case of direct vehicle-to-vehicle IP communications (non
>>>> covered areas) Mobile IP may not be necessary.  It may be that
>>>> extensions to Neighbor Discovery and DHCP could help establish
>>>> paths within local topologies.
>>>>
>>>> And, when that is done (e.g. exchange routes between two
>>>> vehicles using RA) it may become apparent that interactions
>>>> between Mobile IP and this mechanism may be necessary.
>>>>
>>>>>> Open to discussion:<Q3> what are the scenarios?
>>>>
>>>> We are interested in describing the scenarios.  There may exist
>>>> several possibilities.  I think of the following lego-like
>>>> approach:
>>>>
>>>> - scenario of MR-to-infrastrucure - use Mobile IP, Prefix
>>>> Delegation. - scenario MR-to-MR - conceive prefixes in Router
>>>> Advertisements, compare to other dynamic routing approaches. -
>>>>  scenario MR-to-MR-to-Infrastructure - combine the above two.
>>>>
>>>> Another direction is classify the kinds of vehicles.  I think
>>>> of something like this:
>>>>
>>>> - Internet Vehicle (has a plethora of interfaces, long- and
>>>> short- range). - Range Extending Vehicle - extends the range of
>>>> reachability. - Leaf Vehicle - like and end-node.
>>>>
>>>> Then there are other scenario statements that could open the
>>>> path to the following: - addressability within vehicle, ULA,
>>>> VIN. - problem of bandwidth difference between inside and
>>>> outside the vehicle.
>>>>
>>>>> <Q4> What are the potential work items?  <Q5>What might be
>>>>> needed, if anything at all?
>>>>>
>>>>> I am interested  to work on Vehicle Ad-hoc NETwork (VANET)
>>>>> and ITS issues and in your questions directions. I will join
>>>>> the ITS-WG which I think can have relation to MANET
>>>>> [RFC2501].
>>>>
>>>> Well, hmm.  I am happy to hear that but let us go easy about
>>>> this.
>>>>
>>>> "ITS" at IETF is currently just an informal effort.  Its
>>>> future may be ambitious but right now it's not a WG.  To do
>>>> that, we'd need to make a BoF first (Birds-of-a-Feather) and
>>>> ask others' oppinion about way forward.
>>>>
>>>> Secod, RFC2501 and ad-hoc routing are just one possibility to
>>>> continue working on this.  Some people may express positive
>>>> technical feedback about MANET and others less so.
>>>>
>>>>> IMO that vehicle routers communications depend on both their
>>>>>  communication protocols and the used-network for such
>>>>> communication (my answer of both Q1 and Q2). In particular,
>>>>> to answer Q2, IMHO there is no doubt that Mobile IP
>>>>> [RFC6275] is needed for the router's if the communication is
>>>>> through the Internet's domain(s), but if it is through
>>>>> Ad-hoc networks' domain(s) it MAY not be used.
>>>>
>>>> I tend to agree that Mobile IP may not be needed between
>>>> vehicles which communicate directly without infrastructure.
>>>> Then one wonders _what_ is needed?
>>>>
>>>>> The Internet is an infrastructure network and Ad-hoc networks
>>>>> are infrastructure-less networks. Regarding Q3, Q4 and Q5 I
>>>>> agree with the WG answers, and will read more into the WG
>>>>> inputs regarding these issues.
>>>>
>>>> (see above note about this "WG" acronym which ITS is not
>>>> currently)
>>>>
>>>>> I will schedule to participate/prepare I-D in the future for
>>>>> ITS scenarios. I am preparing an I-D on DSRv2 routing which
>>>>> is a MANET routing protocol that fits the use-case of ITS
>>>>> and VANET as well.
>>>>
>>>> I am interested to work on scenario/reqs drafts for ITS.
>>>>
>>>> About "DSRv2" - is it still about Routing Headers?
>>>>
>>>> I am interested to hear others' oppinions as well.
>>>>
>>>> Yours,
>>>>
>>>> Alex
>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>> Abdussalam Baryun University of Glamorgan, UK
>>>>> =======================================================
>>>>>
>>>>> From: Alexandru Petrescu <alexandru.petrescu at gmail.com>
>>>>> To: its at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100
>>>>> Sub: [its] Scenarios, potential topics...
>>>>> --------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>
>>>>>
>>>>>
Welcome to the ITS list at IETF, an informal discussion.
>>>>>
>>>>> Earlier at IETF discussions related to vehicular
>>>>> communications happened in several groups (MEXT, AUTOCONF,
>>>>> 6MAN, to name but a few), drafts were published [*].  At
>>>>> times people expressed interest to meet f2f.  Now there is
>>>>> this email list.
>>>>>
>>>>> Participants are solicited to work on the topic of using IP
>>>>> in Intelligent Transportation Systems.  The term ITS is a
>>>>> placeholder that, in my oppinion, is generic enough to cover
>>>>> many aspects of vehicular communications; vehicles may be
>>>>> wheeled, watered, flown. Ambulance, fire engine, coastal
>>>>> ship are particular examples.
>>>>>
>>>>> Scenario :  A router deployed in a moving vehicle, uses its
>>>>> egress interface to connect to larger-area access network(s)
>>>>> or to other vehicles.  Should it use IPv6-over-LTE?  Should
>>>>> it use Mobile IP?
>>>>>
>>>>> Example potential work items: - Reqs for IPv6 in vehicular
>>>>> networks - V2V with RA - V2R(oadside) - VIN and IPv6
>>>>> addressing - ULA and IPv6 for vehicles - IPv6 multicast -
>>>>> ISO TC204 - IPv6 over 802.11p (IPv6-over-foo). - open.
>>>>>
>>>>> I am told about other vehicular drafts and discussions, that
>>>>> I have not cited, existed and still exist (about e.g.
>>>>> ecall). I am interested to learn about all the vehicular
>>>>> activities at IETF.
>>>>>
>>>>> Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO.
>>>>>
>>>>> Open to discussion: what are the scenarios?  What are the
>>>>> potential work items?  What might be needed, if anything at
>>>>> all?
>>>>>
>>>>> Alex [*] draft-ietf-mext-nemo-ro-automotive-req-02
>>>>> draft-jhlee-mext-mnpp-00.txt, October 2009.
>>>>> draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009.
>>>>> draft-karagiannis-traffic-safety-requirements-02.txt, Feb.
>>>>> 2010. draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008.
>>>>> draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011.
>>>>> draft-petrescu-mip4-tuntype-change-00.txt, March 2011.
>>>>> draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov.
>>>>> 2010. draft-uehara-dtnrg-decentralized-probe-transport-00,
>>>>> Nov. 2010 draft-rosen-ecrit-ecall-04.txt, March 2010.
>>>>> draft-singh-simple-vehicle-info, July 2007.
>>>>> draft-sijeon-mext-nemo-pmip6-00, Oct. 2010.
>>>>> draft-bauer-mext-aero-solspace, Sep. 2009.
>>>>> draft-bauer-mext-aero-topology, Sep. 2009.
>>>>> draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008.
>>>>> draft-rosen-ecrit-ecall-05.txt, March 2012.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________ manet mailing
>>>> list [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>
>>>
>>
>>
>>
>
>