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

[liu dapeng <[e-mail]>]

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? Whether the transmission range of Wi-Fi is enough for
this use case?

> 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?


>> 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.

> 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
>>>
>>
>>
>
>
>


-- 

------
Best Regards,
Dapeng Liu