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

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 2 Jul 2012 07:15:08 +0200

+++++++++++++++++  Possible Duplication  ++++++++++++++++++++++

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?  <Q2>Should it use Mobile IP?

>Open to discussion:<Q3> what are the scenarios? <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]. 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. 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.

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.

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.

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 1 Jul 2012 19:31:43 +0200

Hi Alex and All,

Regards

Abdussalam Baryun

Alex
[*]

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Jul 2012 09:59:26 +0200

Hi Abdussalam and thanks for the reply.

Le 01/07/2012 19:31, Abdussalam Baryun a écrit :
>>  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 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)

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

---

From: "John Dowdell" <[email-masked]>
Date: Tue, 3 Jul 2012 10:06:16 +0100

Alex, Abdussalam and all

Ref the discussion below, Q2 in particular, I'm happy to be corrected but I cannot see how Mobile IP will work with no infrastructure and direct node-to-node communications. Is not Mobile IP used when roaming onto another provider's network (termed the foreign network) to create a care-of address, and DIAMETER used to verify the roaming devices authorisation to access services on the home and foreign network? In this scenario using IPv4, home and foreign agent servers in the infrastructure are used to handle and validate the requests. In IPv6, I understand there is no foreign agent, but there is still a single home agent.

In the Q2 scenario below, surely IPv6 neighbour discovery is sufficient? ND is then linked to the routing protocol process to discover the adjacent routers.

But thanks for bringing ITS to my attention. I'm off to join the list.

John

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Jul 2012 11:38:25 +0200

Le 03/07/2012 11:06, John Dowdell a écrit :
> Alex, Abdussalam and all
>
> Ref the discussion below, Q2[Should it use Mobile IP?] in
> particular, I'm happy to be corrected but I cannot see how Mobile IP
> will work with no infrastructure and direct node-to-node
> communications.

Node-to-node communications may indeed not be the right application for
the Mobile IP protocol.  MIP has at least 3 entities: MN, HA and CN,
whereas node-to-node it's but 2.

A vehicular scenario would depict a vehicle as a set of nodes deployed 
in one vehicle; some of these nodes may be communicating with other 
nodes in another vehicle nearby; each vehicle would also hold a Router 
on-board.

In such a scenario, maybe 'node-to-node' may mean that one such node (an
LFN) communicates to another node (another LFN) in another vehicle
through their respective Mobile Routers.

This would become a problem of how to assign addresses or how to set up
routes between the two vehicles such that this node-to-node
communication can happen.

Protocols to assign addresses would be DHCP and Stateless Autoconf (not
DIAMETER since there is no central auth server) and maybe forming local
addresses based on manufacturer identifiers.

Protocols to establish routes would be routing protocols or simpler.

> Is not Mobile IP used when roaming onto another provider's network
> (termed the foreign network) to create a care-of address, and
> DIAMETER used to verify the roaming devices authorisation to access
> services on the home and foreign network? In this scenario using
> IPv4, home and foreign agent servers in the infrastructure are used
> to handle and validate the requests. In IPv6, I understand there is
> no foreign agent, but there is still a single home agent.

I agree with most points in this above paragraph.

> In the Q2 scenario below, surely IPv6 neighbour discovery is
> sufficient? ND is then linked to the routing protocol process to
> discover the adjacent routers.

I don't know.  I think ND is well adapted for simpler and well-defined
topologies.  A 'star' topology using nearby vehicles, and only one well
defined IP-subnet link between the egress interfaces between the mobile
routers may be such simple topology.

(even in the simpler topologies, ND has a shortcoming in that (1) does
not exchange routes and (2) does not assign prefixes - both could be
solved by extending ND).

The simple topologies are exposed in many real-world scenarios: incident
static scene, traffic jam, billboard advertisement vehicles, and more.

For more complex topologies, this could further be discussed.

Simple vs complex - I think it's impossible to define one protocol that
would be applicable in all vehicular scenarios.

Listening,

Alex

> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu Sent:
> 03 July 2012 08:59 To: Abdussalam Baryun Cc: manet; [email-masked]
>>> Scenario :  A router deployed in a moving vehicle, uses its
>>> egress interface to connect to larger-area access network(s) or
>>> to other vehicles.
>>
>
> 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.
>
>> 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?
>
>
>

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 3 Jul 2012 09:40:53 -0700

Alex,

> I am interested to hear others' oppinions as well.

One of the handful of requirements differences between emergency
services and the rest of us is higher availability and survivability
needs.  Skipping some analysis steps, this always boils down to >1
route.  

> >>  interface to connect to larger-area access network(s) or to other

So the English in the above statement is not quite right: 'interface'
MUST be plural in any practical situation: interfaces.  

LTE is likely to be the big player for the radio-WAN, but there won't be
just one instantiation.  A quick scenario: an instrumented ambulance may
have one or more LANs within the vehicle to which several end systems
are attached -- vital signs sensors, VOIP handset for the EMT, etc.
quite possibly a WiFi hotspot ...  All attached to a vehicle-mounted
router.  The router has interfaces to 1) wired ethernet (for use while
in the garage), 2) commercial LTE (where coverage exists), 3) emergency
services LTE (in US, this is earmarked for 700MHz band and does not yet
in fact exist), 4) WiFi -- pick up a neighborhood hotspot, 5) satellite
or other radio-WAN network for rural areas not reachable by other means.
Any sane high Ao engineering will be picking at least two of the
above.  

Any help?

On Tue, 2012-07-03 at 09:59 +0200, Alexandru Petrescu wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 3 Jul 2012 17:11:01 +0000

Yes, I agree - 1 route is better than 0. But at least for me, the point is that >1 route is always better than 1…. hence, "interfaces" instead of "interface"… ;-)  And which link is better, etc, etc… 

Regards,
Stan

On Jul 3, 2012, at 12:58 PM, Dearlove, Christopher (UK) wrote:

> There are emergency service requirements where even 1 route would be an improvement on the otherwise available 0 routes. Communications down to the platform on underground railway lines would have been one on 7/7 in London.
> 
> -- 
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> [email-masked] | http://www.baesystems.com
> 
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Rex Buddenberg
> Sent: 03 July 2012 17:41
> To: Alexandru Petrescu
> Cc: manet; [email-masked]; Abdussalam Baryun
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
> 
> Alex,
> 
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Jul 2012 16:58:03 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rex Buddenberg
Sent: 03 July 2012 17:41
To: Alexandru Petrescu
Cc: manet; [email-masked]; Abdussalam Baryun
Subject: Re: [manet] [its] Scenarios, potential topics...

Alex,

Any help?

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Jul 2012 17:27:15 +0000

The point about the 1 route (rather than 0 routes) case was just to note that the suggestion that the requirement for "always" >1 routes is too strong, not to suggest it was undesirable.

(Incidentally if you need redundancy, and are prepared to accept the additional overheads, then >1 routes isn't sufficient, you also need to consider whether they are disjoint or not.)

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: 03 July 2012 18:11
To: Dearlove, Christopher (UK)
Cc: Rex Buddenberg; Alexandru Petrescu; manet; [email-masked]; Abdussalam Baryun
Subject: Re: [manet] [its] Scenarios, potential topics...

Yes, I agree - 1 route is better than 0. But at least for me, the point is that >1 route is always better than 1.. hence, "interfaces" instead of "interface". ;-)  And which link is better, etc, etc. 

Regards,
Stan

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Jul 2012 17:12:20 +0200

Rex,

Yes, suggesting that several routes are needed in the case of emergency 
services like ambulance (and not only emergency, but also simply with 
train platforms where the service loss is undesirable) should be 
considered in the design of vehicular communications.

Also, I agree that the topology of a single vehicle is something with 
subnet(s) inside, subnet(s) outside, and a router in the middle.

The multiplicity of routes is something natural with this topology of a 
vehicle: it would need a route towards the inside, another towards the 
outside and maybe a default route.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Jul 2012 17:28:39 +0200

Colleagues subscribers to ITS email list at IETF,

Do you think some of the following scenarios should _not_ be worked on :

- Router to modem exchange about wireless status.

- DNS lookup by geo coordinates.

- Multicast dissemination by geo coordinates.

- V2V: mechanisms to form addresses and exchange routes directly
   between vehicles without help from the infrastructure.

- V2V2I: mechanisms to offer Internet connectivity to one vehicle
   through another vehicle.

- PMIP-NEMO: mechanisms to use 1-interface base-stations and moving
   networks.

- addressing: mechanisms to form IP addresses based on vehicle-
   specific identifiers.

- IPv6-over-802.11p: translate an 802.11p emergency message into a
   related IP message; form Interface Identifier based on a 802.11p MAC
   address.

- IPv6 and ETSI ITS: make sure ETSI ITS existing documents have no
   bugs about IPv6.

- work on Mobile IPv6 extensions about the above topics.

- work on ND extensions about the above topics.

- work on DHCPv6 extensions about the above topics.

- work on new protocol.

Yours,

Alex

Le 03/07/2012 18:40, Rex Buddenberg a écrit :
> So the English in the above statement is not quite right:
> 'interface' MUST be plural in any practical situation: interfaces.
>
>
> LTE is likely to be the big player for the radio-WAN, but there won't
> be just one instantiation.  A quick scenario: an instrumented
> ambulance may have one or more LANs within the vehicle to which
> several end systems are attached -- vital signs sensors, VOIP handset
> for the EMT, etc. quite possibly a WiFi hotspot ...  All attached to
> a vehicle-mounted router.  The router has interfaces to 1) wired
> ethernet (for use while in the garage), 2) commercial LTE (where
> coverage exists), 3) emergency services LTE (in US, this is earmarked
> for 700MHz band and does not yet in fact exist), 4) WiFi -- pick up a
> neighborhood hotspot, 5) satellite or other radio-WAN network for
> rural areas not reachable by other means. Any sane high Ao
> engineering will be picking at least two of the above.
>
>
> Any help?
>
>
>
>> 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.)
>>
>> specification in the case that the UE (User Terminal) is actually
>> a Mobile Router.  The Prefix Delegation part may be
>> underspecified.
>>
>> Hmm... that is a good question and much can be said about it.  I
>> am interested to liste others' oppinions as well.
>>
>> using RA) it may become apparent that interactions between Mobile
>> IP and this mechanism may be necessary.
>>
>> 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.
>>
>> 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].
>>
>> "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.
>>
>> 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.
>>
>>> 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.
>>
>>> From: Alexandru Petrescu <alexandru.petrescu at gmail.com> To:
>>> its at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100 Sub: [its]
>>> few), drafts were published [*].  At times people expressed
>>> interest to meet f2f.  Now there is this email list.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Open to discussion: what are the scenarios?  What are the
>>> potential work items?  What might be needed, if anything at all?
>>>
>>> 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.
>> _______________________________________________ manet mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/manet
>
>
>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 7 Jul 2012 11:52:11 +0200

Hi Alex,

I thank you for this email, because I was not sure of the charter, or
the scope of the ITS, so far, however, the below is my
suggestions/opinion (I did not exclude any), thanking you :)

I recommend we don't mix with MANET and ROLL scopes. I will comment on
full previous inputs in another post, and hope I can know a) ITS
Service Requirement (Application), b) ITS Applicability Statement
(Specific-purpose), c) Vesion of started works by the group,

> - Router to modem exchange about wireless status.
SHOULD [RFC2119] be in,
> - DNS lookup by geo coordinates.
MAY be
> - Multicast dissemination by geo coordinates.
SHOULD be in,

>    between vehicles without help from the infrastructure.
SHOULD be in,

> - V2V2I: mechanisms to offer Internet connectivity to one vehicle
SHOULD be in,

> - PMIP-NEMO: mechanisms to use 1-interface base-stations and moving
SHOULD be in,
> - addressing: mechanisms to form IP addresses based on vehicle-
SHOULD be in,

>    related IP message; form Interface Identifier based on a 802.11p MAC
MAY be in,

> - IPv6 and ETSI ITS: make sure ETSI ITS existing documents have no
SHOULD be in,

> - work on Mobile IPv6 extensions about the above topics.
MAY be in,

> - work on ND extensions about the above topics.
MAY be in,
> - work on DHCPv6 extensions about the above topics.
MAY be in,
> - work on new protocol.
This is general that SHOULD be in for any WG,
> Alex
** Add one what SHOULD be include:
1) Routings that SHOULD be for ITS, that MAY be MANET-Router [MAN] or
ROLL protocols (Specific purpose protocols). Please not that MANET and
ROLL are mostly for general purpose protocols, but their charter don't
restrict the purpose.

*** I will add what I think SHOULD NOT be in this ITS:
1) any network mechanism that does not involve ITS,
2) any service that uses ITS as transient net.
3) any routing that are MANET or ROLL that MAY include ITS requirements.

References:
=========
[RFC2119] http://www.ietf.org/rfc/rfc2119.txt
[MAN] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt
[ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt

Best Regards

Abdussalam Baryun
University of Glamorgan, UK
+++++++++++++++++++++++++++++++++++++++++++++++++++++
< In discussions one may be wrong, or may be right, but it does not
matter if we work together as a group to progress and resolve all
issues. WGs are always right >
*************************************************************************************

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 10 Jul 2012 14:03:29 +0200

Hello Abdussalam,

I wanted to react now about your comment of scope of the ITS list at 
IETF, just to mention as a reminder that the slides of the last informal 
meeting are at:

          http://imara.inria.fr/ietf-its

This may help as a refresher.  Of course, new comments are always 
welcome and I will write separately about your comments below.

Alex

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 11 Jul 2012 08:07:51 -0500

Hello,
Three Internet Drafts related to store, carry and forward (SCF) technologies have been submitted to the Internet Engineering Task Force for comment. These may be of interest to the Intelligent Transport System participants. Comments would be greatly appreciated as would possible scenarios that fit ITS needs that may not be presented in the problem statement.

The three drafts are:  Store, Carry and Forward Problem Statement; Store, Carry and Forward Requirements and Expectations; and Store, Carry and Forward Testing Requirements. The Store, Carry and Forward Problem Statement provides a problem statement for non-real-time communication between systems that are generally disconnected, requiring multiple network hops between source and destination, that may never be fully connected end-to-end at any given time. The Store, Carry and Forward Requirements and Expectations document describes the requirements for a Store, Carry and Forward (SCF) protocol, and the expectations placed upon the SCF agents and SCF applications. The Store, Carry and Forward Testing Requirements document provides guidelines and requirements for testing Store, Carry and Forward systems and protocols. This document, -00, is currently just a Skeletal Outline published so the other two SCF documents can reference it.  The skeleton will be filled in within the next month.

http://www.ietf.org/id/draft-ivancic-scf-problem-statement-00.txt

http://www.ietf.org/id/draft-ivancic-scf-requirements-expectations-00.txt

http://www.ietf.org/id/draft-ivancic-scf-testing-requirements-00.txt

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 11 Jul 2012 18:34:50 +0200

Hi William,

I am interested in these I-D and will comment when available,

I prefered that ITS in general has existed multihop connection
end-to-end when establish which may have high possibility of
disconnects for certain time so protocol re-establishes.

> source and destination, that may never be fully connected end-to-end at any
> given time.

the question for ITS WG: is DTN out of scope or in scope. I think it
is out of scope in general, but if there is possibility of delay for
few seconds, then maybe in scope,

Regards

Abdussalam Baryun
University of Glamorgan, UK
===========================
On 7/11/12, Ivancic, William D. (GRC-RHN0) <[email-masked]> wrote:
> Hello,
> Three Internet Drafts related to store, carry and forward (SCF) technologies
> have been submitted to the Internet Engineering Task Force for comment.
> These may be of interest to the Intelligent Transport System participants.
> Comments would be greatly appreciated as would possible scenarios that fit
> ITS needs that may not be presented in the problem statement.
>
> The three drafts are:  Store, Carry and Forward Problem Statement; Store,
> Carry and Forward Requirements and Expectations; and Store, Carry and
> Forward Testing Requirements. The Store, Carry and Forward Problem Statement
> provides a problem statement for non-real-time communication between systems
> that are generally disconnected, requiring multiple network hops between
> source and destination, that may never be fully connected end-to-end at any
> given time. The Store, Carry and Forward Requirements and Expectations
> document describes the requirements for a Store, Carry and Forward (SCF)
> protocol, and the expectations placed upon the SCF agents and SCF
> applications. The Store, Carry and Forward Testing Requirements document
> provides guidelines and requirements for testing Store, Carry and Forward
> systems and protocols. This document, -00, is currently just a Skeletal
> Outline published so the other two SCF documents can reference it.  The
> skeleton will be filled in within the next month.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Jul 2012 18:56:52 +0200

> few seconds, then maybe in scope,

In general, I think some aspects of vehicular communications may pertain 
to the store-and-forward paradigm.

However, one would need to look at the details before considering 
putting something in or out of scope.

One would wonder about existing DTN protocols; or about the Research 
counterparts in DTN RG (as opposed to Engineering).

One would also consider that DTN may be used on larger scale than just a 
highway, and at those scales also vehicles are used.  And maybe 
scalability would need to be accounted for right from the beginning.

I need to look at the SCF technology drafts before qualifying it.

YOurs,

Alex

> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Jul 2012 19:15:40 +0200

Le 07/07/2012 11:52, Abdussalam Baryun a écrit :
> I recommend we don't mix with MANET and ROLL scopes.

In general I would agree with this recommendation.  In particular, a
number of MANET protocols (OLSR, DSR,...)  and related specs exist, as
well as RoLL (RPL).  It may be foreseen to compare these and study for
adaptability to ITS work.  It may also be out of scope.

> I will comment on full previous inputs in another post, and hope I
> can know a) ITS Service Requirement (Application),

Do you think a list of Services used in vehicles could be formed?

> b) ITS Applicability Statement (Specific-purpose),

Do you think one could write something about how TCP/IP protocols could
be applied in ITS?

> c) Vesion of started works by the group,

Sorry, what version?  A version of Internet DrafT?

>> - Router to modem exchange about wireless status.

Well if yes, then maybe something could be written about this.  Some
proposals are written recently, like DLEP.

>> - DNS lookup by geo coordinates.

Why?  Or why not?

>>  related IP message; form Interface Identifier based on a 802.11p
>> MAC address.
> MAY be in,
>
>>

Well, some WGs design new protocols, others extend existing protocols.
And most if not all work with IP.

Alex

>>
>> Yours,
>>
>> Alex
>>
> ** Add one what SHOULD be include: 1) Routings that SHOULD be for
> ITS, that MAY be MANET-Router [MAN] or ROLL protocols (Specific
> purpose protocols). Please not that MANET and ROLL are mostly for
> general purpose protocols, but their charter don't restrict the
> purpose.
>
> *** I will add what I think SHOULD NOT be in this ITS: 1) any
> network mechanism that does not involve ITS, 2) any service that uses
> ITS as transient net. 3) any routing that are MANET or ROLL that MAY
> include ITS requirements.
>
> References: ========= [RFC2119] http://www.ietf.org/rfc/rfc2119.txt
> +++++++++++++++++++++++++++++++++++++++++++++++++++++ < In
> discussions one may be wrong, or may be right, but it does not

---

From: liu dapeng <[email-masked]>
Date: Wed, 25 Jul 2012 11:26:39 +0800

Hi Alex,

Regarding v2v communication:

1. If the mobile routers have LTE link and use IPv6, then v2v
communication can also rely on LTE? 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).

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.

Any comments?

Thanks,
Best regards,
Dapeng

-- 

------
Best Regards,
Dapeng Liu

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Jul 2012 16:18:08 +0200

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

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?

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

What do you think?

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

What do you think?

Alex

>
> Any comments?
>
> Thanks, Best regards, Dapeng
>

---

From: liu dapeng <[email-masked]>
Date: Thu, 26 Jul 2012 15:25:13 +0800

Hi Alex,
Please see my reply inline.

> for direct communications between vehicles, without the use of LTE

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

> high bandwidth, may be possible.

[Dapeng] LTE D2D maybe relevant to this topic?

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

> Advertisement) messages to achieve this, instead of BU.  But each has

[Dapeng] If use RA, that will limit the V2V communication to only
adjacent vehicle?

Thanks,
Best Regards,
Dapeng

-- 

------
Best Regards,
Dapeng Liu

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Jul 2012 18:37:20 +0200

Hi Dapeng,

Le 26/07/2012 09:25, liu dapeng a écrit :
> Hi Alex, Please see my reply inline.
>
>> Thank you for the interest in the v2v scenario.  Please see below
>> for answers to the questions.
>>
>> 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.
>
> 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.

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

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

>>> 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.
>
> Thanks, Best Regards, Dapeng
>
>> What do you think?
>>
>> Alex
>>
>>>
>>> Any comments?
>>>
>>>>>> egress interface to connect to larger-area access
>>>>>> network(s) or to other vehicles.
>>>>>
>>>>  earlier 3GPP specs were mentioning IPv6 but more like an
>>>> option feature.)
>>>>
>>>> specification in the case that the UE (User Terminal) is
>>>> actually a Mobile Router.  The Prefix Delegation part may be
>>>> underspecified.
>>>>
>>>> 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.
>>>>
>>>> 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
>>>> 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.
>>>>
>>>>> 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].
>>>>
>>>> "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.
>>>>
>>>>> 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?
>>>>
>>>>> 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.
>>>>
>>>>> 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.
>>>>
>>>>> To: its at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100
>>>>>
>>>>> 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.
>>>>>
>>>>> 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?
>>>>>
>>>>> 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.
>>>>>
>>>>> draft-karagiannis-traffic-safety-requirements-02.txt, Feb.
>>>>> 2010. draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008.
>>>>> 2010. draft-uehara-dtnrg-decentralized-probe-transport-00,
>>>>> Nov. 2010 draft-rosen-ecrit-ecall-04.txt, March 2010.
>>>> _______________________________________________ manet mailing
>>>> list [email-masked]

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 26 Jul 2012 10:12:00 -0700

>   For example, at an incident scene this is largely enough. 

Liu Dapeng,

The classical use case, in my mind, is the instrumented ambulance*.  The
casualty inside may have several end systems (sensors) attached.
Further, the ambulance will have end system nav receiver (to report
position) and the EMT may need several services, VOIP being an obvious
one.

The topology for such is a LAN within the ambulance and a router with
one or more outside interfaces.  Reaching to a neighboring vehicle (e.g.
with WiFi) is clearly not enough.  The router needs to get to the rest
of the internet in order to get the data to the hospital emergency room.
So the first thought is an LTE or IEEE 802.16 network segment for the
radio-WAN.  There's nothing wrong with more than one hop, so including a
WiFi interface on the router is OK too.  (Indeed with the balkanization
of the cellphone system, at least in US, multiple 4G cellphone
interfaces is likely to be needed).

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 26 Jul 2012 18:22:28 +0000

Rex,

> interfaces is likely to be needed).

FWIW, I think you've hit the nail on the head here. The WiFi connection to a neighboring vehicle might help, in cases where (1) the ambulance attendants want to do something like a VoIP call to the people in the neighboring vehicle, or (2) if said neighboring vehicle has Internet connectivity and can "share" (e.g. 802.16, or LTE, or maybe even a satellite modem). But having WiFi to a neighboring vehicle is, in and of itself, not necessarily a good thing. 

Regards,
Stan

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Jul 2012 14:38:36 +0200

Le 26/07/2012 20:22, Stan Ratliff (sratliff) a écrit :
>>> Is there some particular scenario that deserves more interest
>>> from your side?
>>>
>>>  spectrum, around 50meter range at a certain power level) may be
>>>  enough. For example, at an incident scene this is largely
>>> enough.
>>
>> Liu Dapeng,
>>
>> The classical use case, in my mind, is the instrumented
>> ambulance*. The casualty inside may have several end systems
>> (sensors) attached. Further, the ambulance will have end system nav
>> receiver (to report position) and the EMT may need several
>> services, VOIP being an obvious one.
>>
>> The topology for such is a LAN within the ambulance and a router
>> with one or more outside interfaces.  Reaching to a neighboring
>> vehicle (e.g. with WiFi) is clearly not enough.  The router needs
>> to get to the rest of the internet in order to get the data to the
>> hospital emergency room. So the first thought is an LTE or IEEE
>> 802.16 network segment for the radio-WAN.  There's nothing wrong
>> with more than one hop, so including a WiFi interface on the
>> router is OK too.  (Indeed with the balkanization of the cellphone
>> system, at least in US, multiple 4G cellphone interfaces is likely
>> to be needed).
>>
>
> FWIW, I think you've hit the nail on the head here. The WiFi
> connection to a neighboring vehicle might help, in cases where (1)
> the ambulance attendants want to do something like a VoIP call to
> the people in the neighboring vehicle, or (2) if said neighboring
> vehicle has Internet connectivity and can "share" (e.g. 802.16, or
> LTE, or maybe even a satellite modem). But having WiFi to a
> neighboring vehicle is, in and of itself, not necessarily a good
> thing.

WEll, I agree with the first points about potential necessity of WiFi
between ambulance and a neighboring vehicle.

One scenario that may be relevant is sharing information about the
casualty between the two different agencies running each vehicle (say
law enforcement and first aid); from an eHealth perspective this would
mean to share data like chemical substance history to medicals trying to
identify what happened, or between insurance company and the medical to
have first hand proof about accident conditions and reimbursement.  And
more.

I also agree about one vehicle offering Internet connection to nearby
vehicle (a case named sometimes V2V2I).

But I do not understand well why you're saying that having WiFi to a
neighboring WiFi (not for Internet access, not for data sharing like
ambulance-police) is not necessarily a good thing.  What do you have in
mind about it not being a good thing?

Alex

> Regards, Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 27 Jul 2012 15:10:18 +0000

> mind about it not being a good thing?

Again, let's consider the ambulance case. I've got a small subnet of devices in that ambulance, behind an on-board router. Let's also assume a scenario where *all* of my traffic needs are back to the hospital (via the Internet). From the ambulance, I have WiFi connectivity to, say, a neighboring police vehicle. But that police vehicle either doesn't have a router installed, or it doesn't have Internet connectivity. All I'm saying is that in that case, a WiFi connection from the ambulance to the police vehicle doesn't help a whole lot.

Regards,
Stan

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Jul 2012 17:17:55 +0200

Le 27/07/2012 17:10, Stan Ratliff (sratliff) a écrit :
>>>>> 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.
>>>>
>>>> Liu Dapeng,
>>>>
>>>> (sensors) attached. Further, the ambulance will have end
>>>> system nav receiver (to report position) and the EMT may need
>>>> several services, VOIP being an obvious one.
>>>>
>>>> The topology for such is a LAN within the ambulance and a
>>>> router with one or more outside interfaces.  Reaching to a
>>>> neighboring vehicle (e.g. with WiFi) is clearly not enough. The
>>>> router needs to get to the rest of the internet in order to get
>>>> the data to the hospital emergency room. So the first thought
>>>> is an LTE or IEEE 802.16 network segment for the radio-WAN.
>>>> There's nothing wrong with more than one hop, so including a
>>>> WiFi interface on the router is OK too.  (Indeed with the
>>>> balkanization of the cellphone system, at least in US, multiple
>>>> 4G cellphone interfaces is likely to be needed).
>>>>
>>>
>>> connection to a neighboring vehicle might help, in cases where
>>> (1) the ambulance attendants want to do something like a VoIP
>>> call to the people in the neighboring vehicle, or (2) if said
>>> neighboring vehicle has Internet connectivity and can "share"
>>> (e.g. 802.16, or LTE, or maybe even a satellite modem). But
>>> having WiFi to a neighboring vehicle is, in and of itself, not
>>> necessarily a good thing.
>>
>> WEll, I agree with the first points about potential necessity of
>> WiFi between ambulance and a neighboring vehicle.
>>
>>  casualty between the two different agencies running each vehicle
>> (say law enforcement and first aid); from an eHealth perspective
>> this would mean to share data like chemical substance history to
>> medicals trying to identify what happened, or between insurance
>> company and the medical to have first hand proof about accident
>> conditions and reimbursement.  And more.
>>
>> I also agree about one vehicle offering Internet connection to
>> nearby vehicle (a case named sometimes V2V2I).
>>
>> But I do not understand well why you're saying that having WiFi to
>> a neighboring WiFi (not for Internet access, not for data sharing
>> like ambulance-police) is not necessarily a good thing.  What do
>> you have in mind about it not being a good thing?
>
> Again, let's consider the ambulance case. I've got a small subnet of
> devices in that ambulance, behind an on-board router. Let's also
> assume a scenario where *all* of my traffic needs are back to the
> hospital (via the Internet). From the ambulance, I have WiFi
> connectivity to, say, a neighboring police vehicle. But that police
> vehicle either doesn't have a router installed, or it doesn't have
> Internet connectivity. All I'm saying is that in that case, a WiFi
> connection from the ambulance to the police vehicle doesn't help a
> whole lot.

Well, now I understand what you mean by a non-Internet WiFi access being
a bad thing.  It is a temptation to connect to and then a disillusion
that there is no Internet on it.

This is a good problem that deserves being explored.

I think the V2V without Internet may still be needed.  There may exist a
mechanism where one vehicle's MR detects the presence of the other
vehicle's MR and understands whether this latter may offer Internet
access or not.  This distinctor may be the presence of a default route
capability in the RA (or DHCP).  The presence/absence of default router
capability in the heard WiFi is what may help decide to follow/not
follow the path of connecting to that WiFi and avoid being deceived.

But I agree this risk of deceit by the presence of a non-Internet WiFi
is something not good, and we could look at it.

Or maybe you see some other solution to this?

Alex

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 27 Jul 2012 15:26:12 +0000

> follow the path of connecting to that WiFi and avoid being deceived.

Oh yes, I absolutely agree that the WiFi connection *could* be a useful thing - it just depends on what you are trying to do.

> Or maybe you see some other solution to this?

I don't know that it deceitful, it's just a scenario that could happen. As far as a solution goes, I think it's something that should be discussed, but from what I've seen, one way to address it is with multiple links in the ambulance. As was mentioned earlier in this thread - if the ambulance has an LTE connection to the Internet, then things work. In the case where the ambulance's WiFi happens to find an Internet-accessible hotspot to connect to, then there are a couple of paths back to the hospital - the question from the ambulance router perspective is "what's the best link?". But yes, I see this as an area for discussion/exploration and potential work. 

Regards,
Stan

---

From: "A. Riley Eller" <[email-masked]>
Date: Mon, 30 Jul 2012 10:19:37 -0700

> communication can also rely on LTE?

While the working item is still a fair distance from realizing standardization, I think it is worth mentioning that LTE Direct (a peer-to-peer channel and symmetric transmission/reception mode) is being proposed by Qualcomm. >From my interviews with their technical team, I am very excited about the possibility of mobile node to mobile node direct LTE link. If any of you are also interested, it might be good to check in on their progress and offer your comments.

Riley

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 30 Jul 2012 10:31:09 -0700

Le 30/07/2012 10:19, A. Riley Eller a écrit :
> While the working item is still a fair distance from realizing
> standardization, I think it is worth mentioning that LTE Direct (a
> peer-to-peer channel and symmetric transmission/reception mode) is
> being proposed by Qualcomm. From my interviews with their technical
> team, I am very excited about the possibility of mobile node to
> mobile node direct LTE link. If any of you are also interested, it
> might be good to check in on their progress and offer your comments.

Certainly I (and a group of people locally) are interested in the use of 
LTE for direct communications.

How would it be possible to check in on their progress and how could we 
offer our comments?

Alex

---

From: "A. Riley Eller" <[email-masked]>
Date: Mon, 30 Jul 2012 16:20:01 -0700

> Certainly I (and a group of people locally) are interested in the use
> of LTE for direct communications.
> 

I am not an expert on the 3GPP process, so rather than muddle about and confuse things, I will include the following article which I hope will offer clues. I believe that the standards body has agreed to investigate whether a direct mode is worth standardizing (??).

http://urgentcomm.com/networks_and_systems/news/direct-mode-lte-study-20110928/

My connection to this program came from direct industry contact, so I apologize for my obtuse response.

Riley

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 31 Jul 2012 09:29:45 -0700

Riley,

This has been kicking around in the emergency services broadband
discussion.  Most of the discussants are not long in understanding of
protocol stacks...  But they ARE long in experiencing 'the tower' going
away and need to talk with 'that guy over there that I can see'.  

Qualcom only announced the study group news.  This is not a product
announcement or even a proposed standard.

It appears that the alterations proposed would only affect layer 2 of
the LTE protocol.  Totally agnostic about anything above layer 2.  

This leaves two questions open: can it be done usefully and scaleably?
and 2) what value is it?  

Speculating a bit on where the study group is going....  LTE and IEEE
802.16 use a hub&spoke structure (for that matter, so does WiFi).  The
LTE base station manages about four dozen MAC messages, the chief one is
the UL-MAP (upload map in English) which tells each of the subscriber
stations when it's that station's turn to transmit.  The base station
also negotiates entry for new subscribers -- ranging messages, X.509
cert exchange, etc.  The processing load and the transmitting load on a
base station is significantly higher than a subscriber station.  

Our experience with IEEE 802.16 gear (LTE is a near-clone) is that the
hardware for both BS and SS is identical, only the software load
changes.  

My students have hauled .16 gear, both BS and SS, out into the field,
plugged them in and gotten them to work (we know if you drop the antenna
off the back of the truck that it will break).  At the layer 3
interface, all the gear we've ever seen is doing ethernet forwarding so
both SS and BS are passing ethernet frames out of the box, just like
your cable modem at home.  

Cellphone implementations will tend to load additional functions (like
beam steering) onto base stations to avoid having to do so with
subscriber stations (which may be embedded in cellphone handsets).  The
key diff between BS and SS here is electrical power usage -- a BS will
drain the battery a lot faster.  

So the first question to ask is what would be the study group's
criteria?  You can already make a subscriber station, with a new
software load, act like a base station.  If you have an adequate power
supply (e.g. vehicle mount rather than handset), then we have this
capability now and have had it for some years.  What's new?  

The second question is what value this would be to emergency services
(or ITS)?  Simply putting up a layer 2 network segment only gets you
layer 2 functionality -- all the rest of the applications are outside
scope.  DNS support?  PKI white pages?  SIP server?  There's a lot left
to do in a real-world usability exercise.

---

From: Okaytion <[email-masked]>
Date: Tue, 31 Jul 2012 13:44:47 -0300

Hi all,
Is any one here an expert in NS2 or knows someone who can help ?? Thanks

Sent from Al's iPhone

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 31 Jul 2012 18:18:35 +0000

First off, I think the discussions on ITS are interesting, worthwhile, and should continue. I wonder, though - aren't these scenarios essentially MANET's? I'm just asking whether one of the options here should be to pursue the work within the MANET WG.

Regards,
Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 31 Jul 2012 18:21:28 +0000

Regards,
Stan

---

From: Francisco Javier Ros Muñoz <[email-masked]>
Date: Tue, 31 Jul 2012 20:35:13 +0200

Hi Stan,

I guess that your comment refers to V2V communications (please correct me if I misunderstood you). There are other issues in ITS that, in my opinion, do not perfectly fit into the MANET WG (V2I among others).

For V2V, MANET routing solutions have been shown to perform poorly in vehicular scenarios. There are tons of references out there, check e.g. [1]. In fact, most research in the field borrows concepts from geographic routing and opportunistic communications. Standardization bodies like the ETSI have also followed this path.

To summarize: although the work could be undertaken by the MANET WG, I feel that ITS features enough peculiarities to deserve a different (more focused) WG.

[1] I. Khan and A. Qayyum, “Performance evaluation of aodv and olsr in highly fading vehicular ad hoc network environments,” in Proceedings of the 13th International Multitopic Conference (INMIC), December 2009, pp. 1–5.

Regards,
fran

--
Francisco J. Ros, PhD
Dept. of Information and Communications Engineering
University of Murcia, Murcia (Spain)
http://masimum.inf.um.es/fjrm/

---

From: "A. Riley Eller" <[email-masked]>
Date: Tue, 31 Jul 2012 12:27:52 -0700

Actually, Qualcomm announced a working product (FlashLinq) before pulling it from their feature road map. They chose to rewind and enter the standardization process from first principles. You can derive minimal, but interesting, details from the few press releases in that area. I believe that they are switching from experimental frames to 3GPP standard frame types in order to achieve greater adoption. 

To my understanding, which IS NOT RELIABLE, they have implemented a peer-to-peer TDMA solution (i.e. with distributed synchronization). I do not believe that they specify or implement any forwarding or routing in the module, but the engineers who ran the program seemed very familiar with the work of this group.

So, I would say that we are all waiting for 3GPP to acknowledge the work.

My (presumptive) conception of the value propositions goes like this:
1) standard peer-to-peer radio
2) low-power, moderate range delivery
3) availability in COTS 4G phones
4) flexible choice of forwarding strategy
5) SOME adoption by proximity based services (advertising, inventory, etc) to help push demand

All in all, it might be the best thing since sliced monitor mode.

Riley

> From: Rex Buddenberg [mailto:[email-masked]]
> Sent: Tuesday, July 31, 2012 9:30 AM
> To: A. Riley Eller
> Cc: Alexandru Petrescu; manet; [email-masked]; Abdussalam Baryun
> LTE base station manages about four dozen MAC messages, the chief one
> is the UL-MAP (upload map in English) which tells each of the
> subscriber stations when it's that station's turn to transmit.  The
> base station also negotiates entry for new subscribers -- ranging
> messages, X.509 cert exchange, etc.  The processing load and the
> transmitting load on a base station is significantly higher than a
> subscriber station.
> 
> plugged them in and gotten them to work (we know if you drop the
> antenna off the back of the truck that it will break).  At the layer 3
> > > > being proposed by Qualcomm. From my interviews with their
> > > > technical team, I am very excited about the possibility of mobile
> > > > node to mobile node direct LTE link. If any of you are also
> > > > interested, it might be good to check in on their progress and
> offer your comments.
> > >
> > > Certainly I (and a group of people locally) are interested in the
> > > use of LTE for direct communications.
> > >
> > > How would it be possible to check in on their progress and how
> could
> > > we offer our comments?
> > >
> > > Alex
> >
> > I am not an expert on the 3GPP process, so rather than muddle about
> and confuse things, I will include the following article which I hope
> will offer clues. I believe that the standards body has agreed to
> investigate whether a direct mode is worth standardizing (??).
> >
> > http://urgentcomm.com/networks_and_systems/news/direct-mode-lte-
> study-
> > 20110928/
> >

---

From: "A. Riley Eller" <[email-masked]>
Date: Tue, 31 Jul 2012 12:28:52 -0700

They intentionally do not specify the routing/forwarding strategy, so we might want to work on "which techniques work best with this radio" but QC will likely continue full steam ahead with "LTE Direct".

> Sent: Tuesday, July 31, 2012 11:19 AM
> To: Rex Buddenberg
> Cc: A. Riley Eller; Alexandru Petrescu; manet; [email-masked]; Abdussalam
> Baryun
> First off, I think the discussions on ITS are interesting, worthwhile,
> and should continue. I wonder, though - aren't these scenarios
> essentially MANET's? I'm just asking whether one of the options here
> should be to pursue the work within the MANET WG.
> 
> Regards,
> Stan
> 
> > protocol stacks...  But they ARE long in experiencing 'the tower'
> > going away and need to talk with 'that guy over there that I can
> see'.
> >
> > interface, all the gear we've ever seen is doing ethernet forwarding
> > so both SS and BS are passing ethernet frames out of the box, just
> > like your cable modem at home.
> >
> > subscriber stations (which may be embedded in cellphone handsets).
> > The key diff between BS and SS here is electrical power usage -- a BS
> > will drain the battery a lot faster.
> >
> > scope.  DNS support?  PKI white pages?  SIP server?  There's a lot
> > left to do in a real-world usability exercise.
> >
> >
> >
> technical
> study
> >> -20110928/

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 31 Jul 2012 19:51:57 +0000

Francisco,

> For V2V, MANET routing solutions have been shown to perform poorly in vehicular scenarios. There are tons of references out there, check e.g. [1]. In fact, most research in the field borrows concep…

Fair enough. But the "MANET" deployments I've been working on for a while now are pretty much exactly documented by the "instrumented ambulance" case. And I've also got V2V scenarios in these MANETs… so from where I'm sitting, they look pretty much alike to me. 

Regards,
Stan

---

From: Francisco Javier Ros Muñoz <[email-masked]>
Date: Wed, 1 Aug 2012 00:41:11 +0200

Stan,

> Fair enough. But the "MANET" deployments I've been working on for a while now are pretty much exactly documented by the "instrumented ambulance" case. And I've also got V2V scenarios in these MANET…
Thanks for sharing this, I'm glad to see that there are successful use cases. If they are publicly documented, I'd be happy to take a look to them. However, I'm not familiar with the instrumented ambulance case, except for the email exchanges that have taken place in this list. As I understand it, such use case mainly involves intra-vehicular communications along with direct V2I. Unless you're thinking about V2V2I, road-side units attached to the Internet, or something like that, I can't see what multi-hop MANET protocols would help here (sure I'm missing something).

By the way, I couldn't make last meeting and I'm not really sure whether multi-hop V2V protocols are being considered as a work item within ITS. I'll just stay tuned to see how all this evolves.

Regards,
fran

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 31 Jul 2012 22:47:37 +0000

Francisco, 

> Thanks for sharing this, I'm glad to see that there are successful use cases. If they are publicly documented, I'd be happy to take a look to them. However, I'm not familiar with the instrumented a…

There's not a lot of documentation on my deployments, unfortunately. They do require V2I, but also V2V. The primary uses for V2V are VoIP, and other collaboration tools. The V2V communication is what compels employment of MANET protocols. 

Regards,
Stan

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 31 Jul 2012 15:55:57 -0700

Le 31/07/2012 15:41, Francisco Javier Ros Muñoz a écrit :
>>> I guess that your comment refers to V2V communications (please
>>> correct me if I misunderstood you). There are other issues in
>>> ITS that, in my opinion, do not perfectly fit into the MANET WG
>>> (V2I among others).
>>>
>>> For V2V, MANET routing solutions have been shown to perform
>>> poorly in vehicular scenarios. There are tons of references out
>>> there, check e.g. [1]. In fact, most research in the field
>>> borrows concepts from geographic routing and opportunistic
>>> communications. Standardization bodies like the ETSI have also
>>> followed this path.
>>
>> Fair enough. But the "MANET" deployments I've been working on for
>> a while now are pretty much exactly documented by the
>> "instrumented ambulance" case. And I've also got V2V scenarios in
>> these MANETs… so from where I'm sitting, they look pretty much
>> alike to me.
>>
> Thanks for sharing this, I'm glad to see that there are successful
> use cases. If they are publicly documented, I'd be happy to take a
> look to them. However, I'm not familiar with the instrumented
> ambulance case, except for the email exchanges that have taken place
> in this list. As I understand it, such use case mainly involves
> intra-vehicular communications along with direct V2I. Unless you're
> thinking about V2V2I, road-side units attached to the Internet, or
> something like that, I can't see what multi-hop MANET protocols
> would help here (sure I'm missing something).

I tend to agree.  The instrumented ambulance use cases mentioned here
are mostly V2I unless V2V2I.

There may exist though ambulances that may need to talk just to the
police car nearby in order to exchange health data and police file.  At
an incident scene (accident on highway) this may prove useful.

> By the way, I couldn't make last meeting and I'm not really sure
> whether multi-hop V2V protocols are being considered as a work item
> within ITS. I'll just stay tuned to see how all this evolves.

Well... depends what is meant by multihop.

A connection from a laptop in a vehicle to a server in another vehicle
nearby, through each vehicle's mobile router, is already a 3-hop
communication.  To me this _is_ multihop.

However, other oppinions tend to see 'multihop' as more than just
vehicles nearby.  Maybe through specialized vehicles used to extend the
range.

As for consideration, there are at least two different partners
seriously considering to work on this V2V communication at IETF (maybe
ITS) and also contributing it to other SDO and back.

Alex

>
> Regards, fran
>
>> Regards, Stan
>>
>>
>>>
>>> To summarize: although the work could be undertaken by the MANET
>>> WG, I feel that ITS features enough peculiarities to deserve a
>>> different (more focused) WG.
>>>
>>> [1] I. Khan and A. Qayyum, “Performance evaluation of aodv and
>>> olsr in highly fading vehicular ad hoc network environments,” in
>>> Proceedings of the 13th International Multitopic Conference
>>> (INMIC), December 2009, pp. 1–5.
>>>
>>> Regards, fran
>>>
>>>> First off, I think the discussions on ITS are interesting,
>>>> worthwhile, and should continue. I wonder, though - aren't
>>>> these scenarios essentially MANET's? I'm just asking whether
>>>> one of the options here should be to pursue the work within
>>>> the MANET WG.
>>>>
>>>> Regards, Stan
>>>>
>>>>> This has been kicking around in the emergency services
>>>>> broadband discussion.  Most of the discussants are not long
>>>>> in understanding of protocol stacks...  But they ARE long in
>>>>> experiencing 'the tower' going away and need to talk with
>>>>> 'that guy over there that I can see'.
>>>>>
>>>>> Qualcom only announced the study group news.  This is not a
>>>>> product announcement or even a proposed standard.
>>>>>
>>>>> It appears that the alterations proposed would only affect
>>>>> layer 2 of the LTE protocol.  Totally agnostic about
>>>>> anything above layer 2.
>>>>>
>>>>> This leaves two questions open: can it be done usefully and
>>>>> scaleably? and 2) what value is it?
>>>>>
>>>>>
>>>>> Speculating a bit on where the study group is going....  LTE
>>>>> and IEEE 802.16 use a hub&spoke structure (for that matter,
>>>>> so does WiFi).  The LTE base station manages about four
>>>>> dozen MAC messages, the chief one is the UL-MAP (upload map
>>>>> in English) which tells each of the subscriber stations when
>>>>> it's that station's turn to transmit.  The base station also
>>>>> negotiates entry for new subscribers -- ranging messages,
>>>>> X.509 cert exchange, etc.  The processing load and the
>>>>> transmitting load on a base station is significantly higher
>>>>> than a subscriber station.
>>>>>
>>>>> Our experience with IEEE 802.16 gear (LTE is a near-clone)
>>>>> is that the hardware for both BS and SS is identical, only
>>>>> the software load changes.
>>>>>
>>>>> My students have hauled .16 gear, both BS and SS, out into
>>>>> the field, plugged them in and gotten them to work (we know
>>>>> if you drop the antenna off the back of the truck that it
>>>>> will break).  At the layer 3 interface, all the gear we've
>>>>> ever seen is doing ethernet forwarding so both SS and BS are
>>>>> passing ethernet frames out of the box, just like your cable
>>>>> modem at home.
>>>>>
>>>>> Cellphone implementations will tend to load additional
>>>>> functions (like beam steering) onto base stations to avoid
>>>>> having to do so with subscriber stations (which may be
>>>>> embedded in cellphone handsets).  The key diff between BS
>>>>> and SS here is electrical power usage -- a BS will drain the
>>>>> battery a lot faster.
>>>>>
>>>>> So the first question to ask is what would be the study
>>>>> group's criteria?  You can already make a subscriber
>>>>> station, with a new software load, act like a base station.
>>>>> If you have an adequate power supply (e.g. vehicle mount
>>>>> rather than handset), then we have this capability now and
>>>>> have had it for some years.  What's new?
>>>>>
>>>>> The second question is what value this would be to emergency
>>>>> services (or ITS)?  Simply putting up a layer 2 network
>>>>> segment only gets you layer 2 functionality -- all the rest
>>>>> of the applications are outside scope.  DNS support?  PKI
>>>>> white pages?  SIP server?  There's a lot left to do in a
>>>>> real-world usability exercise.
>>>>>
>>>>>
>>>>>
>>>>>>>> While the working item is still a fair distance from
>>>>>>>> realizing standardization, I think it is worth
>>>>>>>> mentioning that LTE Direct (a peer-to-peer channel and
>>>>>>>> symmetric transmission/reception mode) is being
>>>>>>>> proposed by Qualcomm. From my interviews with their
>>>>>>>> technical team, I am very excited about the
>>>>>>>> possibility of mobile node to mobile node direct LTE
>>>>>>>> link. If any of you are also interested, it might be
>>>>>>>> good to check in on their progress and offer your
>>>>>>>> comments.
>>>>>>>
>>>>>>> Certainly I (and a group of people locally) are
>>>>>>> interested in the use of LTE for direct communications.
>>>>>>>
>>>>>>> How would it be possible to check in on their progress
>>>>>>> and how could we offer our comments?
>>>>>>>
>>>>>>> Alex
>>>>>>
>>>>>> I am not an expert on the 3GPP process, so rather than
>>>>>> muddle about and confuse things, I will include the
>>>>>> following article which I hope will offer clues. I believe
>>>>>> that the standards body has agreed to investigate whether
>>>>>> a direct mode is worth standardizing (??).
>>>>>>
My connection to this program came from direct industry contact, so I
apologize for my obtuse response.
>>>>>>
>>>>>> Riley _______________________________________________
>>>>>> manet mailing list [email-masked]
>>>>> _______________________________________________ manet
>>>>> mailing list [email-masked]
>>>> _______________________________________________ its mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/its
>>>
>>> -- Francisco J. Ros, PhD Dept. of Information and Communications
>>> Engineering University of Murcia, Murcia (Spain)
> -- Francisco J. Ros, PhD Dept. of Information and Communications
> Engineering University of Murcia, Murcia (Spain)

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 31 Jul 2012 16:05:16 -0700

Le 31/07/2012 12:51, Stan Ratliff (sratliff) a écrit :
>> correct me if I misunderstood you). There are other issues in ITS
>> that, in my opinion, do not perfectly fit into the MANET WG (V2I
>> among others).
>>
>> For V2V, MANET routing solutions have been shown to perform poorly
>> in vehicular scenarios. There are tons of references out there,
>> check e.g. [1]. In fact, most research in the field borrows
>> concepts from geographic routing and opportunistic communications.
>> Standardization bodies like the ETSI have also followed this path.
>
> Fair enough. But the "MANET" deployments I've been working on for a
> while now are pretty much exactly documented by the "instrumented
> ambulance" case. And I've also got V2V scenarios in these MANETs… so
> from where I'm sitting, they look pretty much alike to me.

Excuse me for interfering here.  This is a discussion that should take
place and to which we can contribute.

In a sense yes, MANET protocols tend to be adapted for use cases of
vehicular communications.

This could be discussed further in order to identify whether MANET
protocols are adapted for the scenarios and use cases of V2V
communications.  Detail discussion may reveal some issues which may make
some existing MANET protocols less adapted for these cases.

For example, some MANET protocols are very powerful and may deal with
very complex topologies; at the same time some of the V2V topologies are
relatively simple: there's always a rigid network (within vehicle) and
loops never form, simply because of the design of the link layer.  It's
an inner circled star topology.

Other MANET protocols, as complete as they are in some cases, miss for
example some primary form of address autoconfiguration.

Finally, as much as I would like to see analysis of how MANET protocols
would be adapted for V2V2I, such work could be highly demanding - which
routing protocols precisely should we look at first.  Which manet
competitors would claim to this place as well.

Yours,

Alex

>>> worthwhile, and should continue. I wonder, though - aren't these
>>> scenarios essentially MANET's? I'm just asking whether one of
>>> the options here should be to pursue the work within the MANET
>>> WG.
>>>
>>> Regards, Stan
>>>
>>>> broadband discussion.  Most of the discussants are not long in
>>>> understanding of protocol stacks...  But they ARE long in
>>>> layer 2 of the LTE protocol.  Totally agnostic about anything
>>>> above layer 2.
>>>>
>>>> and IEEE 802.16 use a hub&spoke structure (for that matter, so
>>>> does WiFi).  The LTE base station manages about four dozen MAC
>>>> messages, the chief one is the UL-MAP (upload map in English)
>>>> which tells each of the subscriber stations when it's that
>>>> station's turn to transmit.  The base station also negotiates
>>>> entry for new subscribers -- ranging messages, X.509 cert
>>>> exchange, etc.  The processing load and the transmitting load
>>>> on a base station is significantly higher than a subscriber
>>>> station.
>>>>
>>>> Our experience with IEEE 802.16 gear (LTE is a near-clone) is
>>>> that the hardware for both BS and SS is identical, only the
>>>> software load changes.
>>>>
>>>> My students have hauled .16 gear, both BS and SS, out into the
>>>> field, plugged them in and gotten them to work (we know if you
>>>> drop the antenna off the back of the truck that it will
>>>> break). At the layer 3 interface, all the gear we've ever seen
>>>> is doing ethernet forwarding so both SS and BS are passing
>>>> ethernet frames out of the box, just like your cable modem at
>>>> home.
>>>>
>>>> embedded in cellphone handsets).  The key diff between BS and
>>>> SS here is electrical power usage -- a BS will drain the
>>>> battery a lot faster.
>>>>
>>>> criteria?  You can already make a subscriber station, with a
>>>> new software load, act like a base station.  If you have an
>>>> adequate power supply (e.g. vehicle mount rather than handset),
>>>> then we have this capability now and have had it for some
>>>> years.  What's new?
>>>>
>>>> segment only gets you layer 2 functionality -- all the rest of
>>>> the applications are outside scope.  DNS support?  PKI white
>>>> pages? SIP server?  There's a lot left to do in a real-world
>>>> usability exercise.
>>>>
>>>>
>>>>
>>>>>>> symmetric transmission/reception mode) is being proposed
>>>>>>> by Qualcomm. From my interviews with their technical
>>>>>>> team, I am very excited about the possibility of mobile
>>>>>>> node to mobile node direct LTE link. If any of you are
>>>>>>> also interested, it might be good to check in on their
>>>>>>> progress and offer your comments.
>>>>>>
>>>>>> Certainly I (and a group of people locally) are interested
>>>>>> in the use of LTE for direct communications.
>>>>>>
>>>>>> How would it be possible to check in on their progress and
>>>>>> how could we offer our comments?
>>>>>>
>>>>>> Alex
>>>>>
>>>>> that the standards body has agreed to investigate whether a
>>>>> direct mode is worth standardizing (??).
>>>>>
>>>>>
>>>>> Riley _______________________________________________ manet
>>> _______________________________________________ its mailing list
>>>  [email-masked] https://www.ietf.org/mailman/listinfo/its
>>