From nobody Mon Jan 19 07:52:49 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910551B2ABA for ; Mon, 19 Jan 2015 07:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiQzV2iIOvqQ for ; Mon, 19 Jan 2015 07:52:46 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5891B2AB0 for ; Mon, 19 Jan 2015 07:52:45 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t0JFqh0A022398 for ; Mon, 19 Jan 2015 16:52:43 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6D7912021A7 for ; Mon, 19 Jan 2015 16:53:01 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5A98E20216C for ; Mon, 19 Jan 2015 16:53:01 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t0JFqg4E029065 for ; Mon, 19 Jan 2015 16:52:42 +0100 Message-ID: <54BD284A.4080602@gmail.com> Date: Mon, 19 Jan 2015 16:52:42 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: its@ietf.org References: <544A6D4F.3060401@gmail.com> In-Reply-To: <544A6D4F.3060401@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, platooning X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 15:52:48 -0000 Hello geonet/its'ers, ETSI ITS continues work on C-ACC and Platooning. A f2f meeting a few days ago reveals, among other things, a possibility of developping a requirement for direct communication between vehicles ("The C-ACC system shall be able to receive data from other vehicle ITS-S or road side ITS-S"). What do you think? Alex Le 24/10/2014 17:16, Alexandru Petrescu a écrit : > Hello geonet/itsers, > > ETSI ITS group is an SDO in Europe. They produced many standards in the > past for vehicular communications, e.g. ETSI ITS geo-networking among > others. > > ETSI ITS recently agreed to start working on pre-standardization items > called "Cooperative Cruise Control" and "Platooning". These two > applications make automobiles (and trucks) talk to each other > continuously to keep speed constant. It helps relieve automobile driver > stress in jam situation or reduce gas consumption by 'platooning'. > > Currently the focus is on requirements including communication > requirements. > > In my oppinion, and this is why I forward it to this group, establishing > direct IP connections between vehicles may open paths for exchanging IP > data containing speed/location and trigger a control process of adapting > the speed. One already controls vehicles by sending IP data to them, > from the infrastructure. It would be a simple matter for IP experts to > send that same data from other vehicle, without going to the > infrastructure. > > Thoughts? > > Yours, > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Tue Jan 20 00:20:45 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C001B2D91 for ; Tue, 20 Jan 2015 00:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srhvcAT61I2O for ; Tue, 20 Jan 2015 00:20:32 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4661A1B2D8E for ; Tue, 20 Jan 2015 00:20:31 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFAI8OvlSHCzIm/2dsb2JhbABbgmQiUlgEs1wBAQEDBpJHhXECgR9DAQEBAQEBfIQMAQEBAQMSWQMXBAIBCA0EBAEBCx0HMhQJCAIEARIIGogKAQyvSZ5ZAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSGBYlDOAaDEIETBYlLhQ6DR4wVi2UigjKBPG+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.09,432,1418101200"; d="scan'208";a="88319510" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Jan 2015 03:20:28 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 20 Jan 2015 03:20:28 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Tue, 20 Jan 2015 09:20:26 +0100 From: "Romascanu, Dan (Dan)" To: Alexandru Petrescu , "its@ietf.org" Thread-Topic: [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, platooning Thread-Index: AQHQNAAJK1B7oHvhq0WoC+JIa/BULpzIq28w Date: Tue, 20 Jan 2015 08:20:25 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C96F7B7@AZ-FFEXMB04.global.avaya.com> References: <544A6D4F.3060401@gmail.com> <54BD284A.4080602@gmail.com> In-Reply-To: <54BD284A.4080602@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, platooning X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 08:20:34 -0000 This certainly sounds interesting, to the extent that the IETF can add valu= e to the work done in ETSI with our specific expertise. =20 Question - how does the ETSI work relate to IEEE 1609 and IEEE 802.11p?=20 Thanks and Regards, Dan > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Monday, January 19, 2015 5:53 PM > To: its@ietf.org > Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise con= trol, > platooning >=20 > Hello geonet/its'ers, >=20 > ETSI ITS continues work on C-ACC and Platooning. A f2f meeting a few day= s > ago reveals, among other things, a possibility of developping a requireme= nt > for direct communication between vehicles ("The C-ACC system shall be abl= e > to receive data from other vehicle ITS-S or road side ITS-S"). >=20 > What do you think? >=20 > Alex >=20 > Le 24/10/2014 17:16, Alexandru Petrescu a =E9crit : > > Hello geonet/itsers, > > > > ETSI ITS group is an SDO in Europe. They produced many standards in > > the past for vehicular communications, e.g. ETSI ITS geo-networking > > among others. > > > > ETSI ITS recently agreed to start working on pre-standardization items > > called "Cooperative Cruise Control" and "Platooning". These two > > applications make automobiles (and trucks) talk to each other > > continuously to keep speed constant. It helps relieve automobile > > driver stress in jam situation or reduce gas consumption by 'platooning= '. > > > > Currently the focus is on requirements including communication > > requirements. > > > > In my oppinion, and this is why I forward it to this group, > > establishing direct IP connections between vehicles may open paths for > > exchanging IP data containing speed/location and trigger a control > > process of adapting the speed. One already controls vehicles by > > sending IP data to them, from the infrastructure. It would be a > > simple matter for IP experts to send that same data from other > > vehicle, without going to the infrastructure. > > > > Thoughts? > > > > Yours, > > > > Alex > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mail > > man_listinfo_its&d=3DAwIF- > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQ > > > zvlsiLQfucBXRucPvdrphpBsFA&m=3D7phbjG6Z2qP7PNOqvxHWe2s55dJcKMrSyf > GAFrrU- > > ms&s=3DGtUI3ETS930uY9YD5VlodU3wr4wfc4BXjjteZu_242c&e=3D > > > > >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_its&d=3DAwIF- > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > rphpBsFA&m=3D7phbjG6Z2qP7PNOqvxHWe2s55dJcKMrSyfGAFrrU- > ms&s=3DGtUI3ETS930uY9YD5VlodU3wr4wfc4BXjjteZu_242c&e=3D From nobody Tue Jan 20 00:48:54 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357FE1B2DB3 for ; Tue, 20 Jan 2015 00:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o08UXhUZOtsm for ; Tue, 20 Jan 2015 00:48:50 -0800 (PST) Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210]) by ietfa.amsl.com (Postfix) with ESMTP id E3F031B2DB1 for ; Tue, 20 Jan 2015 00:48:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,432,1418079600"; d="scan'208";a="11340515" Received: from monza.eurecom.fr ([192.168.106.15]) by drago1i.eurecom.fr with ESMTP; 20 Jan 2015 09:48:48 +0100 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id AA93B1836; Tue, 20 Jan 2015 09:48:48 +0100 (MET) From: =?iso-8859-1?B?Suly9G1lIEjkcnJp?= To: "'Romascanu, Dan \(Dan\)'" , "'Alexandru Petrescu'" , References: <544A6D4F.3060401@gmail.com> <54BD284A.4080602@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA5C96F7B7@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C96F7B7@AZ-FFEXMB04.global.avaya.com> Date: Tue, 20 Jan 2015 09:48:48 +0100 Organization: EURECOM Message-ID: <007f01d0348d$e85b3930$b911ab90$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL3JLv7/NkHS7Gg/dI51+6O1yuKbQITENbgAeskKSaaWt68QA== Content-Language: en-us Archived-At: Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, platooning X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 08:48:52 -0000 Hi Dan, ETSI does not relate to IEEE 1609, as it proposes its own architecture, although having similar goals and principles. The ETSI architecture is = also based on IEEE 802.11p (a.k.a 802.11-2012 OCB @ 5GHz nowadays) but under = a specific denomination: ETSI ITS G5. As WAVE, the ETSI architecture = provide an IPv6 stack as well as a non-IP stack (called GeoNetworking). =20 The requirement is indeed described. Now the question is whether IP is required in this specific case(s). But at this time, the ETSI requires = use case formulations (as well as communication requirements from these use cases), so inputs from the IETF ITS WG would of course be welcomed. You should contact Lan Lin and Katrin Sj=F6berg, who are the two = rapporteurs for the CACC and platooning respectively.=20 Best Regards, J=E9r=F4me -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Romascanu, Dan = (Dan) Sent: Tuesday 20 January 2015 09:20 To: Alexandru Petrescu; its@ietf.org Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, platooning This certainly sounds interesting, to the extent that the IETF can add = value to the work done in ETSI with our specific expertise. =20 Question - how does the ETSI work relate to IEEE 1609 and IEEE 802.11p?=20 Thanks and Regards, Dan > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru=20 > Petrescu > Sent: Monday, January 19, 2015 5:53 PM > To: its@ietf.org > Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise=20 > control, platooning >=20 > Hello geonet/its'ers, >=20 > ETSI ITS continues work on C-ACC and Platooning. A f2f meeting a few=20 > days ago reveals, among other things, a possibility of developping a=20 > requirement for direct communication between vehicles ("The C-ACC=20 > system shall be able to receive data from other vehicle ITS-S or road = side ITS-S"). >=20 > What do you think? >=20 > Alex >=20 > Le 24/10/2014 17:16, Alexandru Petrescu a =E9crit : > > Hello geonet/itsers, > > > > ETSI ITS group is an SDO in Europe. They produced many standards in = > > the past for vehicular communications, e.g. ETSI ITS geo-networking=20 > > among others. > > > > ETSI ITS recently agreed to start working on pre-standardization=20 > > items called "Cooperative Cruise Control" and "Platooning". These=20 > > two applications make automobiles (and trucks) talk to each other=20 > > continuously to keep speed constant. It helps relieve automobile=20 > > driver stress in jam situation or reduce gas consumption by 'platooning'. > > > > Currently the focus is on requirements including communication=20 > > requirements. > > > > In my oppinion, and this is why I forward it to this group,=20 > > establishing direct IP connections between vehicles may open paths=20 > > for exchanging IP data containing speed/location and trigger a=20 > > control process of adapting the speed. One already controls=20 > > vehicles by sending IP data to them, from the infrastructure. It=20 > > would be a simple matter for IP experts to send that same data from=20 > > other vehicle, without going to the infrastructure. > > > > Thoughts? > > > > Yours, > > > > Alex > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mail > > man_listinfo_its&d=3DAwIF- > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQ > > > zvlsiLQfucBXRucPvdrphpBsFA&m=3D7phbjG6Z2qP7PNOqvxHWe2s55dJcKMrSyf > GAFrrU- > > ms&s=3DGtUI3ETS930uY9YD5VlodU3wr4wfc4BXjjteZu_242c&e=3D > > > > >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_its&d=3DAwIF- > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > rphpBsFA&m=3D7phbjG6Z2qP7PNOqvxHWe2s55dJcKMrSyfGAFrrU- > ms&s=3DGtUI3ETS930uY9YD5VlodU3wr4wfc4BXjjteZu_242c&e=3D _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Tue Jan 20 11:23:40 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A09F1B2B30 for ; Tue, 20 Jan 2015 11:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziOy2tiUYbYe for ; Tue, 20 Jan 2015 11:23:27 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2556D1B2B2E for ; Tue, 20 Jan 2015 11:23:27 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id bj1so47564189pad.9 for ; Tue, 20 Jan 2015 11:23:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=PxcNxZvoUvn5/H039yfoGDt4anfkcXGYqkQBJt576Gs=; b=qOt6Y2L6teRTF4cuYSu4nCqOkbd1CVaBxYJR5hAgCxCsVKtIzbAPDQIYho03z5d7En /yOgL54MeZDYGyVDkVObCmJY44FbEHRY/QLryHFqiJhBoGvwrGT5Vs35LKMCwldnyrRT gbdJd4bnyYUvRFW7pDQ/a1JDeo9RuplJs7NZ6n4lP/R8CK8HePFG7uTTielyz/LLmiVy 7cBof7wGETlO6W3pHJiOy1AWI+G8lTxvERRVWkCEGuog/neFR3hfMnle8flAOEvlBt+x xDyX6CVF4ZGYuyqRnb8vxLxQgy1wt86Ik0U/hgW4W64GS30JlPlXqYbABUIhClTW29BG PUqA== X-Received: by 10.68.197.72 with SMTP id is8mr56338619pbc.17.1421781806376; Tue, 20 Jan 2015 11:23:26 -0800 (PST) Received: from [192.168.1.102] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id mp6sm3649528pbc.69.2015.01.20.11.23.24 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Tue, 20 Jan 2015 11:23:25 -0800 (PST) Message-ID: <1421781803.13134.70.camel@localhost.localdomain> From: Rex Buddenberg To: =?ISO-8859-1?Q?J=E9r=F4me_H=E4rri?= Date: Tue, 20 Jan 2015 11:23:23 -0800 In-Reply-To: <007f01d0348d$e85b3930$b911ab90$@eurecom.fr> References: <544A6D4F.3060401@gmail.com> <54BD284A.4080602@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA5C96F7B7@AZ-FFEXMB04.global.avaya.com> <007f01d0348d$e85b3930$b911ab90$@eurecom.fr> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: "'Romascanu, Dan \(Dan\)'" , 'Alexandru Petrescu' , its@ietf.org Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, platooning X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 19:23:29 -0000 Dan, Let me try to complement Jerome's and others replies. There are two (at least) tacit philosophies here. With lots of bits and pieces that may or may not fit together. The more 'IETF view' is 'extend the internet to mobile platforms'. An example would be an instrumented ambulance where casualty vital signs would be telemetered to the hospital ER and the vehicle's position would be reported to the 911 dispatcher. This is very much an internetworking point of view where IP is the conventional layer 3 solution. The WAVE set of protocols eschews IP (and TCP) and is much more narrowly focused. The idea is vehicle-to-vehicle with collision avoidance in the requirements set. The repeated references in the e-mail to a specific flavor of ethernet and the eschewing of both TCP and IP in the layer 3-5 protocol space, and the rather tight apparent coupling to a specific application show a quite different philosophy. A use case here would be the same ambulance in the illustration above broadcasting its position and a 'virtual siren' message. I've poked at this paradigm a few times over the last year or so and don't quite swallow it all. By eschewing IP, the protocol apparently denies internetworking (meaning no LAN in the vehicle to internetwork with the radio link). And if you take the label 'TCP' out of the discussion but ask about the features (e.g. reliable delivery) you get a feature list that sounds eerily like TCP. The geonetworking discussion has the same kind of disquiets: if you code lat/long into a layer 3 datagram, then how do you read it at layer 6-7 without creating an insecurity vector (maybe we should be encoding the same data, in the same format, as part of the MIB?) In general, the vehicle-to-vehicle discussion (at least on this list) seems to confuse the 'what' (e.g. traffic alerts) with the 'how' (e.g. gotta use xyz flavor of ethernet with no internetworking). Not losing any sleep over this -- the protocol discussion routinely allows a dual stack with a conventional IP stack alongside the WAVE stack. So the virtual ambulance siren example does not exclude the instrumented ambulance example. The above is my take on what I've seen on the list (with a dollop of my own opinions and experiences plowed in). I've no problem whatsoever with the notion of a self-driving automobile and am a firm believer in better information having the potential for a safer environment. On Tue, 2015-01-20 at 09:48 +0100, Jérôme Härri wrote: > Hi Dan, > > ETSI does not relate to IEEE 1609, as it proposes its own architecture, > although having similar goals and principles. The ETSI architecture is also > based on IEEE 802.11p (a.k.a 802.11-2012 OCB @ 5GHz nowadays) but under a > specific denomination: ETSI ITS G5. As WAVE, the ETSI architecture provide > an IPv6 stack as well as a non-IP stack (called GeoNetworking). > > The requirement is indeed described. Now the question is whether IP is > required in this specific case(s). But at this time, the ETSI requires use > case formulations (as well as communication requirements from these use > cases), so inputs from the IETF ITS WG would of course be welcomed. > > You should contact Lan Lin and Katrin Sjöberg, who are the two rapporteurs > for the CACC and platooning respectively. > > Best Regards, > > Jérôme > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Tuesday 20 January 2015 09:20 > To: Alexandru Petrescu; its@ietf.org > Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise > control, platooning > > This certainly sounds interesting, to the extent that the IETF can add value > to the work done in ETSI with our specific expertise. > > Question - how does the ETSI work relate to IEEE 1609 and IEEE 802.11p? > > Thanks and Regards, > > Dan > > > > -----Original Message----- > > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru > > Petrescu > > Sent: Monday, January 19, 2015 5:53 PM > > To: its@ietf.org > > Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise > > control, platooning > > > > Hello geonet/its'ers, > > > > ETSI ITS continues work on C-ACC and Platooning. A f2f meeting a few > > days ago reveals, among other things, a possibility of developping a > > requirement for direct communication between vehicles ("The C-ACC > > system shall be able to receive data from other vehicle ITS-S or road side > ITS-S"). > > > > What do you think? > > > > Alex > > > > Le 24/10/2014 17:16, Alexandru Petrescu a écrit : > > > Hello geonet/itsers, > > > > > > ETSI ITS group is an SDO in Europe. They produced many standards in > > > the past for vehicular communications, e.g. ETSI ITS geo-networking > > > among others. > > > > > > ETSI ITS recently agreed to start working on pre-standardization > > > items called "Cooperative Cruise Control" and "Platooning". These > > > two applications make automobiles (and trucks) talk to each other > > > continuously to keep speed constant. It helps relieve automobile > > > driver stress in jam situation or reduce gas consumption by > 'platooning'. > > > > > > Currently the focus is on requirements including communication > > > requirements. > > > > > > In my oppinion, and this is why I forward it to this group, > > > establishing direct IP connections between vehicles may open paths > > > for exchanging IP data containing speed/location and trigger a > > > control process of adapting the speed. One already controls > > > vehicles by sending IP data to them, from the infrastructure. It > > > would be a simple matter for IP experts to send that same data from > > > other vehicle, without going to the infrastructure. > > > > > > Thoughts? > > > > > > Yours, > > > > > > Alex > > > > > > _______________________________________________ > > > its mailing list > > > its@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ietf.org_mail > > > man_listinfo_its&d=AwIF- > > g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQ > > > > > zvlsiLQfucBXRucPvdrphpBsFA&m=7phbjG6Z2qP7PNOqvxHWe2s55dJcKMrSyf > > GAFrrU- > > > ms&s=GtUI3ETS930uY9YD5VlodU3wr4wfc4BXjjteZu_242c&e= > > > > > > > > > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ietf.org_mailman_listinfo_its&d=AwIF- > > g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > rphpBsFA&m=7phbjG6Z2qP7PNOqvxHWe2s55dJcKMrSyfGAFrrU- > > ms&s=GtUI3ETS930uY9YD5VlodU3wr4wfc4BXjjteZu_242c&e= > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Wed Jan 21 01:17:20 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244591A0B00 for ; Wed, 21 Jan 2015 01:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55o1YgZpemz0 for ; Wed, 21 Jan 2015 01:17:12 -0800 (PST) Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7431A07BC for ; Wed, 21 Jan 2015 01:17:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,440,1418079600"; d="scan'208";a="11348917" Received: from monza.eurecom.fr ([192.168.106.15]) by drago1i.eurecom.fr with ESMTP; 21 Jan 2015 10:17:00 +0100 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 6024617BB; Wed, 21 Jan 2015 10:17:00 +0100 (MET) From: =?iso-8859-1?B?Suly9G1lIEjkcnJp?= To: , "'Rex Buddenberg'" References: <544A6D4F.3060401@gmail.com> <54BD284A.4080602@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA5C96F7B7@AZ-FFEXMB04.global.avaya.com> <007f01d0348d$e85b3930$b911ab90$@eurecom.fr> <1421781803.13134.70.camel@localhost.localdomain> <82835FE2A55F40E085DDE68ADAB7D45C@SRA4> In-Reply-To: <82835FE2A55F40E085DDE68ADAB7D45C@SRA4> Date: Wed, 21 Jan 2015 10:17:00 +0100 Organization: EURECOM Message-ID: <008a01d0355b$031bbd30$09533790$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL3JLv7/NkHS7Gg/dI51+6O1yuKbQITENbgAeskKSYBsi+e7AEiSj24AmrjBfuaMnjz8A== Content-Language: en-us Archived-At: Cc: "'Romascanu, Dan \(Dan\)'" , 'Alexandru Petrescu' , its@ietf.org Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, platooning X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 09:17:18 -0000 Dear Dick, dear All Nice that we could get various detailed feedback. And I agree with the = need to evaluate the required changes in the IPv6 suite for such application. = But I still would like to play the devil's advocate and suggest that we = should really differentiate the 'how' from the 'why'.=20 With modifications (if any), it is clear that IP could be allocated by = both ETSI and WAVE to handle C-ACC and Platooning. The question (again = playing the devil's advocate here..) is 'why would we need IP packets for C-ACC = and Platooning'?? =20 We need to build use cases before we even start thinking how this could = be done. According to the ETSI definition of C-ACC and Platooning, we are talking of local communication (either between a platoon leader and its followers, or between immediate C-ACC vehicles). As Dick mentioned, we = could use Facilities messages transmitted on CALM FAST, ETSI GeoNet, WAVE SMP = or any other non-IP protocol as well. One potential benefit from IP in this context would be if we use heterogeneous technologies (LTE-D, DSRC, = Visible Light Comm, etc..) and expect service continuity...maybe there are = others... Best Regards, J=E9r=F4me -----Original Message----- From: Richard Roy [mailto:dickroy@alum.mit.edu]=20 Sent: Wednesday 21 January 2015 04:10 To: 'Rex Buddenberg'; 'J=E9r=F4me H=E4rri' Cc: 'Romascanu, Dan (Dan)'; 'Alexandru Petrescu'; its@ietf.org Subject: RE: [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, platooning A few clarifications might be useful. First, the 1609 set of standards coupled with IEEE 802.11 at 5.9GHz form what is commonly referred to in the US as WAVE, and devices built = conformant to these standards are WAVE devices (see 1609.0). IPv6 is explicitly mentioned in 1609.3 (the networking services standard where you'll find = the specifications for the WAVE Short Message Protocol (WSMP) and the WAVE Service Advertisement (WSA), both of which are undergoing revision now). = In fact, included in the WSA is an (optional) WAVE Router Advertisement = (WRA) which contains sufficient information for an application in a WAVE = device to correctly form an IPv6 packet for transmission to the indicated service provider using the indicated RF resources. SLAAC is used by the mobile device to create a valid IPv6 address from the IPv6 pin the WRA. Thus, on the mobile side, there is not much to do except to implement = the various IPv6 functions necessary. Maintaining an IP-based session while moving from RSU to RSU travelling down the freeway is another story = which is still being worked on in the IETF as I understand it. =20 As far as ETSI is concerned, they are developing standards, built on the = ISO 21217 architecture of the ITS station (ITS-S), which are largely concentrated on V2V communications for safety applications. Nothing = they are doing prohibits the use of IPv6 at the network layer and all the transport protocols that are associated therewith. Furthermore, nothing prevents implementers, such as those working on the Corridor project, = from implementing ISO's Fast Network & Transport Protocol (which is being harmonized with 1609.3 WSMP at this moment) as a more effective and efficient protocol for V2V safety messages (esp. CAMs/DENMs/BSMs). That said, the question for the geonet/its group is/should be: what modifications, if any, to the IPv6 suite of protocols might be necessary = to support the use of IPv6 networking in platooning and C-ACC applications. All the issues surrounding the data to be exchanged to implement these services are application considerations and are therefore outside the = scope of the networking layer. =20 Hope this helps somewhat. Cheers, RR > -----Original Message----- > From: Rex Buddenberg [mailto:buddenbergr@gmail.com] > Sent: Tuesday, January 20, 2015 11:23 AM > To: J=E9r=F4me H=E4rri > Cc: 'Romascanu, Dan (Dan)'; 'Alexandru Petrescu'; its@ietf.org > Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise=20 > control, platooning >=20 > Dan, >=20 > Let me try to complement Jerome's and others replies. >=20 > There are two (at least) tacit philosophies here. With lots of bits=20 > and pieces that may or may not fit together. >=20 > The more 'IETF view' is 'extend the internet to mobile platforms'. An = > example would be an instrumented ambulance where casualty vital signs=20 > would be telemetered to the hospital ER and the vehicle's position=20 > would be reported to the 911 dispatcher. This is very much an=20 > internetworking point of view where IP is the conventional layer 3 solution. >=20 > The WAVE set of protocols eschews IP (and TCP) and is much more=20 > narrowly focused. The idea is vehicle-to-vehicle with collision=20 > avoidance in the requirements set. The repeated references in the=20 > e-mail to a specific flavor of ethernet and the eschewing of both TCP=20 > and IP in the layer 3-5 protocol space, and the rather tight apparent=20 > coupling to a specific application show a quite different philosophy. > A use case here would be the same ambulance in the illustration=20 > above broadcasting its position and a 'virtual siren' message. > I've poked at this paradigm a few times over the last year or so=20 > and don't quite swallow it all. By eschewing IP, the protocol=20 > apparently denies internetworking (meaning no LAN in the vehicle to=20 > internetwork with the radio link). And if you take the label 'TCP'=20 > out of the discussion but ask about the features (e.g. reliable=20 > delivery) you get a feature list that sounds eerily like TCP. The=20 > geonetworking discussion has the same kind of disquiets: if you code=20 > lat/long into a layer 3 datagram, then how do you read it at layer 6-7 = > without creating an insecurity vector (maybe we should be encoding the = > same data, in the same format, as part of the MIB?) > In general, the vehicle-to-vehicle discussion (at least on this > list) seems to confuse the 'what' (e.g. traffic alerts) with the 'how' = > (e.g. gotta use xyz flavor of ethernet with no internetworking). > Not losing any sleep over this -- the protocol discussion=20 > routinely allows a dual stack with a conventional IP stack alongside=20 > the WAVE stack. So the virtual ambulance siren example does not=20 > exclude the instrumented ambulance example. >=20 > The above is my take on what I've seen on the list (with a dollop of=20 > my own opinions and experiences plowed in). I've no problem=20 > whatsoever with the notion of a self-driving automobile and am a firm=20 > believer in better information having the potential for a safer environment. >=20 >=20 >=20 >=20 >=20 > On Tue, 2015-01-20 at 09:48 +0100, J=E9r=F4me H=E4rri wrote: > > Hi Dan, > > > > ETSI does not relate to IEEE 1609, as it proposes its own=20 > > architecture, although having similar goals and principles. The ETSI = > > architecture is > also > > based on IEEE 802.11p (a.k.a 802.11-2012 OCB @ 5GHz nowadays) but=20 > > under > a > > specific denomination: ETSI ITS G5. As WAVE, the ETSI architecture > provide > > an IPv6 stack as well as a non-IP stack (called GeoNetworking). > > > > The requirement is indeed described. Now the question is whether IP=20 > > is required in this specific case(s). But at this time, the ETSI=20 > > requires > use > > case formulations (as well as communication requirements from these=20 > > use cases), so inputs from the IETF ITS WG would of course be = welcomed. > > > > You should contact Lan Lin and Katrin Sj=F6berg, who are the two > rapporteurs > > for the CACC and platooning respectively. > > > > Best Regards, > > > > J=E9r=F4me > > > > -----Original Message----- > > From: its [mailto:its-bounces@ietf.org] On Behalf Of Romascanu, Dan > (Dan) > > Sent: Tuesday 20 January 2015 09:20 > > To: Alexandru Petrescu; its@ietf.org > > Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative=20 > > cruise control, platooning > > > > This certainly sounds interesting, to the extent that the IETF can=20 > > add > value > > to the work done in ETSI with our specific expertise. > > > > Question - how does the ETSI work relate to IEEE 1609 and IEEE = 802.11p? > > > > Thanks and Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru=20 > > > Petrescu > > > Sent: Monday, January 19, 2015 5:53 PM > > > To: its@ietf.org > > > Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative=20 > > > cruise control, platooning > > > > > > Hello geonet/its'ers, > > > > > > ETSI ITS continues work on C-ACC and Platooning. A f2f meeting a=20 > > > few days ago reveals, among other things, a possibility of=20 > > > developping a requirement for direct communication between=20 > > > vehicles ("The C-ACC system shall be able to receive data from=20 > > > other vehicle ITS-S or road > side > > ITS-S"). > > > > > > What do you think? > > > > > > Alex > > > > > > Le 24/10/2014 17:16, Alexandru Petrescu a =E9crit : > > > > Hello geonet/itsers, > > > > > > > > ETSI ITS group is an SDO in Europe. They produced many=20 > > > > standards in the past for vehicular communications, e.g. ETSI=20 > > > > ITS geo-networking among others. > > > > > > > > ETSI ITS recently agreed to start working on pre-standardization = > > > > items called "Cooperative Cruise Control" and "Platooning". =20 > > > > These two applications make automobiles (and trucks) talk to=20 > > > > each other continuously to keep speed constant. It helps=20 > > > > relieve automobile driver stress in jam situation or reduce gas=20 > > > > consumption by > > 'platooning'. > > > > > > > > Currently the focus is on requirements including communication=20 > > > > requirements. > > > > > > > > In my oppinion, and this is why I forward it to this group,=20 > > > > establishing direct IP connections between vehicles may open=20 > > > > paths for exchanging IP data containing speed/location and=20 > > > > trigger a control process of adapting the speed. One already=20 > > > > controls vehicles by sending IP data to them, from the=20 > > > > infrastructure. It would be a simple matter for IP experts to=20 > > > > send that same data from other vehicle, without going to the infrastructure. > > > > > > > > Thoughts? > > > > > > > > Yours, > > > > > > > > Alex > > > > > > > > _______________________________________________ > > > > its mailing list > > > > its@ietf.org > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > 3A__www.ietf.org_mail > > > > man_listinfo_its&d=3DAwIF- > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQ > > > > > > > zvlsiLQfucBXRucPvdrphpBsFA&m=3D7phbjG6Z2qP7PNOqvxHWe2s55dJcKMrSyf > > > GAFrrU- > > > > ms&s=3DGtUI3ETS930uY9YD5VlodU3wr4wfc4BXjjteZu_242c&e=3D > > > > > > > > > > > > > > > > > _______________________________________________ > > > its mailing list > > > its@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > 3A__www.ietf.org_mailman_listinfo_its&d=3DAwIF- > > > = g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > > rphpBsFA&m=3D7phbjG6Z2qP7PNOqvxHWe2s55dJcKMrSyfGAFrrU- > > > ms&s=3DGtUI3ETS930uY9YD5VlodU3wr4wfc4BXjjteZu_242c&e=3D > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its >=20 >=20 From nobody Wed Jan 21 05:27:20 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3C41A1AAB for ; Wed, 21 Jan 2015 05:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.683 X-Spam-Level: X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZHjvLvoHLxy for ; Wed, 21 Jan 2015 05:27:15 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091F11A1AB1 for ; Wed, 21 Jan 2015 05:27:14 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t0LDR5mL006977; Wed, 21 Jan 2015 14:27:05 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 88F0A202E16; Wed, 21 Jan 2015 14:27:26 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 767592007F7; Wed, 21 Jan 2015 14:27:26 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t0LDQwVG022409; Wed, 21 Jan 2015 14:27:05 +0100 Message-ID: <54BFA921.5000503@gmail.com> Date: Wed, 21 Jan 2015 14:26:57 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?windows-1252?Q?J=E9r=F4me_H=E4rri?= , dickroy@alum.mit.edu, "'Rex Buddenberg'" References: <544A6D4F.3060401@gmail.com> <54BD284A.4080602@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA5C96F7B7@AZ-FFEXMB04.global.avaya.com> <007f01d0348d$e85b3930$b911ab90$@eurecom.fr> <1421781803.13134.70.camel@localhost.localdomain> <82835FE2A55F40E085DDE68ADAB7D45C@SRA4> <008a01d0355b$031bbd30$09533790$@eurecom.fr> In-Reply-To: <008a01d0355b$031bbd30$09533790$@eurecom.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "'Romascanu, Dan \(Dan\)'" , its@ietf.org Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, platooning X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 13:27:19 -0000 Le 21/01/2015 10:17, Jérôme Härri a écrit : > Dear Dick, dear All > > Nice that we could get various detailed feedback. And I agree with > the need to evaluate the required changes in the IPv6 suite for such > application. But I still would like to play the devil's advocate and > suggest that we should really differentiate the 'how' from the > 'why'. > > With modifications (if any), it is clear that IP could be allocated > by both ETSI and WAVE to handle C-ACC and Platooning. The question > (again playing the devil's advocate here..) is 'why would we need IP > packets for C-ACC and Platooning'?? I think this is a good question that deserves discussion. My point of view is that C-ACC and Platooning are applications. For example, a java client in one vehicle connects to a server in the nearby vehicle and sends it its current location and speed. To have it work that easily, one would have to first establish and maintain an IP path between the two LANs in each vehicle. This is currently an unknown, although several people on the list have some precise - and contrasting - idea, about how to do it. But still C-ACC (cooperative cruise control) and Platooning are applications from my point of view. I wonder what the others think of why we need IP packets for C-ACC and Platooning? > We need to build use cases before we even start thinking how this > could be done. I agree. In that sense, we may discuss use cases. Several drafts were published in this list about use-cases. We need to write such a use-case draft which focuses on C-ACC and Platooning, and other use-cases which may need the same vehicle-to-vehicle communication technology (some that come to mind very quickly are: the ambulance use-case, and the "Sentinelle" system used since 2005 by Dakar vehicles to signal their presence to each other). > According to the ETSI definition of C-ACC and Platooning, we are > talking of local communication (either between a platoon leader and > its followers, or between immediate C-ACC vehicles). YEs, I agree. We need to list these cases. > As Dick mentioned, we could use Facilities messages transmitted on > CALM FAST, ETSI GeoNet, WAVE SMP or any other non-IP protocol as > well. YEs, we should. > One potential benefit from IP in this context would be if we use > heterogeneous technologies (LTE-D, DSRC, Visible Light Comm, etc..) > and expect service continuity... I agree. We should list these technologies as potential support to transmit data. > maybe there are others... YEs. I wonder what are the other use-cases akin to C-ACC and Platooning, needing V2V concepts, that members of this list are working with? Let us work on these use-cases. Alex > > Best Regards, > > Jérôme > > > > -----Original Message----- From: Richard Roy > [mailto:dickroy@alum.mit.edu] Sent: Wednesday 21 January 2015 04:10 > To: 'Rex Buddenberg'; 'Jérôme Härri' Cc: 'Romascanu, Dan (Dan)'; > 'Alexandru Petrescu'; its@ietf.org Subject: RE: [geonet/its] FYI - > ETSI ITS - work on cooperative cruise control, platooning > > A few clarifications might be useful. > > First, the 1609 set of standards coupled with IEEE 802.11 at 5.9GHz > form what is commonly referred to in the US as WAVE, and devices > built conformant to these standards are WAVE devices (see 1609.0). > IPv6 is explicitly mentioned in 1609.3 (the networking services > standard where you'll find the specifications for the WAVE Short > Message Protocol (WSMP) and the WAVE Service Advertisement (WSA), > both of which are undergoing revision now). In fact, included in the > WSA is an (optional) WAVE Router Advertisement (WRA) which contains > sufficient information for an application in a WAVE device to > correctly form an IPv6 packet for transmission to the indicated > service provider using the indicated RF resources. SLAAC is used by > the mobile device to create a valid IPv6 address from the IPv6 pin > the WRA. > > Thus, on the mobile side, there is not much to do except to > implement the various IPv6 functions necessary. Maintaining an > IP-based session while moving from RSU to RSU travelling down the > freeway is another story which is still being worked on in the IETF > as I understand it. > > As far as ETSI is concerned, they are developing standards, built on > the ISO 21217 architecture of the ITS station (ITS-S), which are > largely concentrated on V2V communications for safety applications. > Nothing they are doing prohibits the use of IPv6 at the network > layer and all the transport protocols that are associated therewith. > Furthermore, nothing prevents implementers, such as those working > on the Corridor project, from implementing ISO's Fast Network & > Transport Protocol (which is being harmonized with 1609.3 WSMP at > this moment) as a more effective and efficient protocol for V2V > safety messages (esp. CAMs/DENMs/BSMs). > > That said, the question for the geonet/its group is/should be: what > modifications, if any, to the IPv6 suite of protocols might be > necessary to support the use of IPv6 networking in platooning and > C-ACC applications. All the issues surrounding the data to be > exchanged to implement these services are application considerations > and are therefore outside the scope of the networking layer. > > Hope this helps somewhat. > > Cheers, > > RR > >> -----Original Message----- From: Rex Buddenberg >> [mailto:buddenbergr@gmail.com] Sent: Tuesday, January 20, 2015 >> 11:23 AM To: Jérôme Härri Cc: 'Romascanu, Dan (Dan)'; 'Alexandru >> Petrescu'; its@ietf.org Subject: Re: [geonet/its] FYI - ETSI ITS - >> work on cooperative cruise control, platooning >> >> Dan, >> >> Let me try to complement Jerome's and others replies. >> >> There are two (at least) tacit philosophies here. With lots of >> bits and pieces that may or may not fit together. >> >> The more 'IETF view' is 'extend the internet to mobile platforms'. >> An example would be an instrumented ambulance where casualty vital >> signs would be telemetered to the hospital ER and the vehicle's >> position would be reported to the 911 dispatcher. This is very >> much an internetworking point of view where IP is the conventional >> layer 3 > solution. >> >> The WAVE set of protocols eschews IP (and TCP) and is much more >> narrowly focused. The idea is vehicle-to-vehicle with collision >> avoidance in the requirements set. The repeated references in the >> e-mail to a specific flavor of ethernet and the eschewing of both >> TCP and IP in the layer 3-5 protocol space, and the rather tight >> apparent coupling to a specific application show a quite different >> philosophy. A use case here would be the same ambulance in the >> illustration above broadcasting its position and a 'virtual siren' >> message. I've poked at this paradigm a few times over the last year >> or so and don't quite swallow it all. By eschewing IP, the >> protocol apparently denies internetworking (meaning no LAN in the >> vehicle to internetwork with the radio link). And if you take the >> label 'TCP' out of the discussion but ask about the features (e.g. >> reliable delivery) you get a feature list that sounds eerily like >> TCP. The geonetworking discussion has the same kind of disquiets: >> if you code lat/long into a layer 3 datagram, then how do you read >> it at layer 6-7 without creating an insecurity vector (maybe we >> should be encoding the same data, in the same format, as part of >> the MIB?) In general, the vehicle-to-vehicle discussion (at least >> on this list) seems to confuse the 'what' (e.g. traffic alerts) >> with the 'how' (e.g. gotta use xyz flavor of ethernet with no >> internetworking). Not losing any sleep over this -- the protocol >> discussion routinely allows a dual stack with a conventional IP >> stack alongside the WAVE stack. So the virtual ambulance siren >> example does not exclude the instrumented ambulance example. >> >> The above is my take on what I've seen on the list (with a dollop >> of my own opinions and experiences plowed in). I've no problem >> whatsoever with the notion of a self-driving automobile and am a >> firm believer in better information having the potential for a >> safer > environment. >> >> >> >> >> >> On Tue, 2015-01-20 at 09:48 +0100, Jérôme Härri wrote: >>> Hi Dan, >>> >>> ETSI does not relate to IEEE 1609, as it proposes its own >>> architecture, although having similar goals and principles. The >>> ETSI architecture is >> also >>> based on IEEE 802.11p (a.k.a 802.11-2012 OCB @ 5GHz nowadays) but >>> under >> a >>> specific denomination: ETSI ITS G5. As WAVE, the ETSI >>> architecture >> provide >>> an IPv6 stack as well as a non-IP stack (called GeoNetworking). >>> >>> The requirement is indeed described. Now the question is whether >>> IP is required in this specific case(s). But at this time, the >>> ETSI requires >> use >>> case formulations (as well as communication requirements from >>> these use cases), so inputs from the IETF ITS WG would of course >>> be welcomed. >>> >>> You should contact Lan Lin and Katrin Sjöberg, who are the two >> rapporteurs >>> for the CACC and platooning respectively. >>> >>> Best Regards, >>> >>> Jérôme >>> >>> -----Original Message----- From: its >>> [mailto:its-bounces@ietf.org] On Behalf Of Romascanu, Dan >> (Dan) >>> Sent: Tuesday 20 January 2015 09:20 To: Alexandru Petrescu; >>> its@ietf.org Subject: Re: [geonet/its] FYI - ETSI ITS - work on >>> cooperative cruise control, platooning >>> >>> This certainly sounds interesting, to the extent that the IETF >>> can add >> value >>> to the work done in ETSI with our specific expertise. >>> >>> Question - how does the ETSI work relate to IEEE 1609 and IEEE >>> 802.11p? >>> >>> Thanks and Regards, >>> >>> Dan >>> >>> >>>> -----Original Message----- From: its >>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>> Sent: Monday, January 19, 2015 5:53 PM To: its@ietf.org >>>> Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative >>>> cruise control, platooning >>>> >>>> Hello geonet/its'ers, >>>> >>>> ETSI ITS continues work on C-ACC and Platooning. A f2f >>>> meeting a few days ago reveals, among other things, a >>>> possibility of developping a requirement for direct >>>> communication between vehicles ("The C-ACC system shall be able >>>> to receive data from other vehicle ITS-S or road >> side >>> ITS-S"). >>>> >>>> What do you think? >>>> >>>> Alex >>>> >>>> Le 24/10/2014 17:16, Alexandru Petrescu a écrit : >>>>> Hello geonet/itsers, >>>>> >>>>> ETSI ITS group is an SDO in Europe. They produced many >>>>> standards in the past for vehicular communications, e.g. ETSI >>>>> ITS geo-networking among others. >>>>> >>>>> ETSI ITS recently agreed to start working on >>>>> pre-standardization items called "Cooperative Cruise >>>>> Control" and "Platooning". These two applications make >>>>> automobiles (and trucks) talk to each other continuously to >>>>> keep speed constant. It helps relieve automobile driver >>>>> stress in jam situation or reduce gas consumption by >>> 'platooning'. >>>>> >>>>> Currently the focus is on requirements including >>>>> communication requirements. >>>>> >>>>> In my oppinion, and this is why I forward it to this group, >>>>> establishing direct IP connections between vehicles may open >>>>> paths for exchanging IP data containing speed/location and >>>>> trigger a control process of adapting the speed. One already >>>>> controls vehicles by sending IP data to them, from the >>>>> infrastructure. It would be a simple matter for IP experts >>>>> to send that same data from other vehicle, without going to >>>>> the > infrastructure. >>>>> >>>>> Thoughts? >>>>> >>>>> Yours, >>>>> >>>>> Alex >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=https- >>>> 3A__www.ietf.org_mail >>>>> man_listinfo_its&d=AwIF- >>>> g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQ >>>>> >>>> zvlsiLQfucBXRucPvdrphpBsFA&m=7phbjG6Z2qP7PNOqvxHWe2s55dJcKMrSyf >>>> >>>> >>>> >>>> >>>> >>>> >>>> GAFrrU- >>>>> ms&s=GtUI3ETS930uY9YD5VlodU3wr4wfc4BXjjteZu_242c&e= >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=https- >>>> 3A__www.ietf.org_mailman_listinfo_its&d=AwIF- >>>> g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd >>>> >>>> >>>> >>>> >>>> >>>> >>>> rphpBsFA&m=7phbjG6Z2qP7PNOqvxHWe2s55dJcKMrSyfGAFrrU- >>>> ms&s=GtUI3ETS930uY9YD5VlodU3wr4wfc4BXjjteZu_242c&e= >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> > > > > > From nobody Wed Jan 21 06:36:14 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A155E1A1ABE for ; Wed, 21 Jan 2015 06:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.639 X-Spam-Level: X-Spam-Status: No, score=0.639 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFgdVB2oe4gt for ; Wed, 21 Jan 2015 06:36:11 -0800 (PST) Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEBD1A1ABB for ; Wed, 21 Jan 2015 06:36:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,442,1418079600"; d="scan'208";a="11351382" Received: from monza.eurecom.fr ([192.168.106.15]) by drago1i.eurecom.fr with ESMTP; 21 Jan 2015 15:36:08 +0100 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id B9689186B; Wed, 21 Jan 2015 15:36:08 +0100 (MET) From: =?iso-8859-1?B?Suly9G1lIEjkcnJp?= To: "'Alexandru Petrescu'" , , "'Rex Buddenberg'" References: <544A6D4F.3060401@gmail.com> <54BD284A.4080602@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA5C96F7B7@AZ-FFEXMB04.global.avaya.com> <007f01d0348d$e85b3930$b911ab90$@eurecom.fr> <1421781803.13134.70.camel@localhost.localdomain> <82835FE2A55F40E085DDE68ADAB7D45C@SRA4> <008a01d0355b$031bbd30$09533790$@eurecom.fr> <54BFA921.5000503@gmail.com> In-Reply-To: <54BFA921.5000503@gmail.com> Date: Wed, 21 Jan 2015 15:36:08 +0100 Organization: EURECOM Message-ID: <013001d03587$9863d180$c92b7480$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL3JLv7/NkHS7Gg/dI51+6O1yuKbQITENbgAeskKSYBsi+e7AEiSj24AmrjBfsBap8NpgFcPQIkmhyfXuA= Content-Language: en-us Archived-At: Cc: "'Romascanu, Dan \(Dan\)'" , its@ietf.org Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, platooning X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 14:36:12 -0000 Dear Alex, > I think this is a good question that deserves discussion. > > My point of view is that C-ACC and Platooning are applications. For example, a java client in one vehicle connects to a server in the nearby vehicle and sends it its current location and speed. To have it work = that=20 > easily, one would have to first establish and maintain an IP path = between the two LANs in each vehicle. This is currently an unknown, although several people on the list have some precise - and contrasting > - idea, about how to do it. > > But still C-ACC (cooperative cruise control) and Platooning are applications from my point of view. > > I wonder what the others think of why we need IP packets for C-ACC and Platooning? > > We need to build use cases before we even start thinking how this=20 > could be done. Thanks for your feedback.. They are applications indeed, but it does not mean it must be IP. The = Road Hazard Warning is an application, but does not work on IP, and if I am = not wrong, the CORRIDOR project provides platooning applications that is not based on IP but rather on CALM FAST.=20 But it is important to describe the application in terms of functional elements (client, server, information flows, interfaces etc...) and then = see if IP is required or not. Just one point: Platooning could work based on = a client-server paradigm, as the platoon leader will gather and manage its platoon. As for C-ACC, it is less clear, as the ETSI definition of C-ACC = is that it is a fully distributed system: there is no leader, and as such, = a client-server paradigm might be more difficult. My suggestion if we want to go further into that direction (and not = spend our life exchanging ideas and point of views over a mailing list ;-) ) = is to gather the related documents on C-ACC and Platooning applications in the respective ITS standardization entities (ETSI, ISO, WAVE (if any), = SAE,..), talk to the rapporteurs of these documents and report a digest in an document. I can do this task from the ETSI side (actually contacting = the two ETSI rapporteurs that I previously named). Maybe others with ties at = ISO or WAVE could do the same... Best Regards, J=E9r=F4me From nobody Wed Jan 21 08:23:00 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D45E1A1B11 for ; Wed, 21 Jan 2015 08:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.683 X-Spam-Level: X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGAXaPeuxhn1 for ; Wed, 21 Jan 2015 08:22:51 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE14E1A1B0A for ; Wed, 21 Jan 2015 08:22:50 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t0LGMgj1026974; Wed, 21 Jan 2015 17:22:42 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4BE4320301D; Wed, 21 Jan 2015 17:23:03 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 39E2B202EC7; Wed, 21 Jan 2015 17:23:03 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t0LGMfif007155; Wed, 21 Jan 2015 17:22:41 +0100 Message-ID: <54BFD251.6040801@gmail.com> Date: Wed, 21 Jan 2015 17:22:41 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?windows-1252?Q?J=E9r=F4me_H=E4rri?= , dickroy@alum.mit.edu, "'Rex Buddenberg'" References: <544A6D4F.3060401@gmail.com> <54BD284A.4080602@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA5C96F7B7@AZ-FFEXMB04.global.avaya.com> <007f01d0348d$e85b3930$b911ab90$@eurecom.fr> <1421781803.13134.70.camel@localhost.localdomain> <82835FE2A55F40E085DDE68ADAB7D45C@SRA4> <008a01d0355b$031bbd30$09533790$@eurecom.fr> <54BFA921.5000503@gmail.com> <013001d03587$9863d180$c92b7480$@eurecom.fr> In-Reply-To: <013001d03587$9863d180$c92b7480$@eurecom.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "'Romascanu, Dan \(Dan\)'" , its@ietf.org Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, platooning X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 16:22:57 -0000 Le 21/01/2015 15:36, Jérôme Härri a écrit : > Dear Alex, > >> I think this is a good question that deserves discussion. >> >> My point of view is that C-ACC and Platooning are applications. For > example, a java client in one vehicle connects to a server in the nearby > vehicle and sends it its current location and speed. To have it work that >> easily, one would have to first establish and maintain an IP path between > the two LANs in each vehicle. This is currently an unknown, although > several people on the list have some precise - and contrasting >> - idea, about how to do it. >> >> But still C-ACC (cooperative cruise control) and Platooning are > applications from my point of view. >> >> I wonder what the others think of why we need IP packets for C-ACC and > Platooning? >> >> We need to build use cases before we even start thinking how this >> could be done. > > Thanks for your feedback.. > > They are applications indeed, but it does not mean it must be IP. The Road > Hazard Warning is an application, but does not work on IP, and if I am not > wrong, the CORRIDOR project provides platooning applications that is not > based on IP but rather on CALM FAST. > > But it is important to describe the application in terms of functional > elements (client, server, information flows, interfaces etc...) and then see > if IP is required or not. Just one point: Platooning could work based on a > client-server paradigm, as the platoon leader will gather and manage its > platoon. As for C-ACC, it is less clear, as the ETSI definition of C-ACC is > that it is a fully distributed system: there is no leader, and as such, a > client-server paradigm might be more difficult. > > My suggestion if we want to go further into that direction (and not spend > our life exchanging ideas and point of views over a mailing list ;-) ) is to > gather the related documents on C-ACC and Platooning applications in the > respective ITS standardization entities (ETSI, ISO, WAVE (if any), SAE,..), > talk to the rapporteurs of these documents and report a digest in an > document. I can do this task from the ETSI side (actually contacting the > two ETSI rapporteurs that I previously named). Maybe others with ties at ISO > or WAVE could do the same... At ISO there is something about vehicle-to-vehicle communications and I can ask a person in charge to provide a summary of it. However, I am not sure whether at IEEE WAVE there is anything that may pertain to Platooning and C-ACC, or V2V? We need to identify somebody to find out. Also, I dont think SAE has any activity about C-ACC and Platooning, or V2V. We need to identify somebody to find out. Alex > > Best Regards, > > Jérôme > > > > From nobody Wed Jan 21 19:51:07 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6541A01F6 for ; Wed, 21 Jan 2015 19:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEYRwAAqlujw for ; Wed, 21 Jan 2015 19:51:04 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151E51A01E7 for ; Wed, 21 Jan 2015 19:51:04 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id fa1so5707958pad.8 for ; Wed, 21 Jan 2015 19:51:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=i5N/5f79XlYJBWQl+qyFap1gJgvKkfeQpIpPtnPMeFo=; b=mjnkp27Tn8XAjB6e2PaJ4ClUaVPbYuasrZwLj7DAiukpSwRwTGIwkk3oyhvcQCk/ns 3QvQ431k5TQvjQ0/WoMW8mIOFxdGxxQ3aEBnhTZksfBkUr8QFIUQ6WCBQ/g8Dx/uLDXz lYjusZGhJc0PzJXy8KAikIw+PpXjgVbeKxBslWVCNSjRAnEqz1FOlzWWHVpH42H050xK ykjWMaGSYDeNzbuDDy0ZK/79llGTx8Lfy6iakrfZVZiR0aP+rWV+fUcW4GU6NtbBsL+s aI1+93d+H52x0VYClmbFCz4dn1ajwZVL4rCff/l+hBah8toc6nP2AUFpdafVZCTqzc94 l07w== X-Received: by 10.70.129.207 with SMTP id ny15mr19196533pdb.152.1421898663323; Wed, 21 Jan 2015 19:51:03 -0800 (PST) Received: from [192.168.1.103] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id bx13sm4482548pdb.19.2015.01.21.19.51.02 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Wed, 21 Jan 2015 19:51:02 -0800 (PST) Message-ID: <1421898661.13134.114.camel@localhost.localdomain> From: Rex Buddenberg To: dickroy@alum.mit.edu Date: Wed, 21 Jan 2015 19:51:01 -0800 In-Reply-To: <71030DA6A6EC423A8D94D94F74001797@SRA4> References: <544A6D4F.3060401@gmail.com> <54BD284A.4080602@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA5C96F7B7@AZ-FFEXMB04.global.avaya.com> <007f01d0348d$e85b3930$b911ab90$@eurecom.fr> <1421781803.13134.70.camel@localhost.localdomain> <82835FE2A55F40E085DDE68ADAB7D45C@SRA4> <008a01d0355b$031bbd30$09533790$@eurecom.fr> <54BFA921.5000503@gmail.com> <013001d03587$9863d180$c92b7480$@eurecom.fr> <71030DA6A6EC423A8D94D94F74001797@SRA4> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: "'Romascanu, Dan \(Dan\)'" , 'Alexandru Petrescu' , =?ISO-8859-1?Q?=27J=E9r=F4me_H=E4rri=27?= , its@ietf.org Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, platooning X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 03:51:06 -0000 RR, This time I disagree with your analysis on a quite specific protocol point. > imagine using MAC bridging to accomplish host-to-host comms Bridging is a Bad Idea, especially in this kind of application space where at least some applications will be mission critical. Ethernet frames (used by WiFi as well) lack the Time To Live value that exists in both IPv4 and IPv6 datagrams. So if they get into a loop, they will ring around the bridged set of LANs forever. In order to control this situation, IEEE 802.1 spanning tree algorithm was generated. Spanning tree changes the loop into a tree, thereby shutting off the ringing. But it does that by 'breaking' bridging associations -- effectively breaking links. What that does is chop off alternate routes -- that are critical to the high availability and what makes the internet so resilient. When ethernet became popular for building and campus LANs (in the '80s) some organizations had phobias about routers (and therefore IP) so they built these large bridged networks. They're all gone now ... there's a good reason. b On Wed, 2015-01-21 at 19:13 -0800, Richard Roy wrote: > All, > > Excellent analysis Jerome. While it may be possible to use IPv6 for these > applications, it may be overkill. Noting that there will be distributed > implementations of ITS stations, since these are point to point like apps, > one could easily imagine using MAC bridging to accomplish host-to-host comms > on the "wireless LAN connecting hosts inside ITS stations" without the need > for IP networking. This is one very strong argument for ditching LPD (LLC > Protocol Discrimination)in favor of EPD (Ethertype Protocol Discrimination) > in 5.9 radios, but that's a story for another day;^)) > > As for WAVE/SAE/ISO and C-ACC and platooning, the IEEE 1609 WG does not deal > with apps generally (though 1609.11 was developed in the WG as a special > case). SAE has taken on the task of looking into messages and message sets > for various V2V and V2I apps, not just core safety apps, and has decided to > work with ETSI TS ITS on three apps (vulnerable road users, C-ACC, and > platooning) so whatever comes out of ETSI TC ITS will presumably joint work > with SAE. Noting that ISO's work in ACC is in TC204 WG14 and the effort > there is largely autonomous, no comms, just radars/lidar/etc. but that's > slowly changing. > > So, at present, the good news is that there's currently not that much action > in these three areas for external bodies to coordinate. As far as VRUs go, > the bad news is there is not that much action to coordinate. Avoiding > collisions with road workers and other pedestrians is a day-one critical > safety app and the fact that people are just now starting to look at this is > somewhat disconcerting to say the least :^((( Oh well ... > > Cheers, > > RR > > > -----Original Message----- > > From: Jérôme Härri [mailto:jerome.haerri@eurecom.fr] > > Sent: Wednesday, January 21, 2015 6:36 AM > > To: 'Alexandru Petrescu'; dickroy@alum.mit.edu; 'Rex Buddenberg' > > Cc: 'Romascanu, Dan (Dan)'; its@ietf.org > > Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise > > control, platooning > > > > Dear Alex, > > > > > I think this is a good question that deserves discussion. > > > > > > My point of view is that C-ACC and Platooning are applications. For > > example, a java client in one vehicle connects to a server in the nearby > > vehicle and sends it its current location and speed. To have it work that > > > easily, one would have to first establish and maintain an IP path > > between > > the two LANs in each vehicle. This is currently an unknown, although > > several people on the list have some precise - and contrasting > > > - idea, about how to do it. > > > > > > But still C-ACC (cooperative cruise control) and Platooning are > > applications from my point of view. > > > > > > I wonder what the others think of why we need IP packets for C-ACC and > > Platooning? > > > > > > We need to build use cases before we even start thinking how this > > > could be done. > > > > Thanks for your feedback.. > > > > They are applications indeed, but it does not mean it must be IP. The Road > > Hazard Warning is an application, but does not work on IP, and if I am not > > wrong, the CORRIDOR project provides platooning applications that is not > > based on IP but rather on CALM FAST. > > > > But it is important to describe the application in terms of functional > > elements (client, server, information flows, interfaces etc...) and then > > see > > if IP is required or not. Just one point: Platooning could work based on a > > client-server paradigm, as the platoon leader will gather and manage its > > platoon. As for C-ACC, it is less clear, as the ETSI definition of C-ACC > > is > > that it is a fully distributed system: there is no leader, and as such, a > > client-server paradigm might be more difficult. > > > > My suggestion if we want to go further into that direction (and not spend > > our life exchanging ideas and point of views over a mailing list ;-) ) is > > to > > gather the related documents on C-ACC and Platooning applications in the > > respective ITS standardization entities (ETSI, ISO, WAVE (if any), > > SAE,..), > > talk to the rapporteurs of these documents and report a digest in an > > document. I can do this task from the ETSI side (actually contacting the > > two ETSI rapporteurs that I previously named). Maybe others with ties at > > ISO > > or WAVE could do the same... > > > > Best Regards, > > > > Jérôme > > > > > > From nobody Thu Jan 22 04:33:16 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2CE1ACC8B for ; Thu, 22 Jan 2015 04:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SE9-kxfmx6fD for ; Thu, 22 Jan 2015 04:33:12 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857A51ACC85 for ; Thu, 22 Jan 2015 04:33:08 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t0MCX3hF007436; Thu, 22 Jan 2015 13:33:03 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A103020344F; Thu, 22 Jan 2015 13:33:25 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 94DC120355E; Thu, 22 Jan 2015 13:33:25 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t0MCWvIT002418; Thu, 22 Jan 2015 13:33:02 +0100 Message-ID: <54C0EDF9.7000509@gmail.com> Date: Thu, 22 Jan 2015 13:32:57 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , "its@ietf.org" References: <544A6D4F.3060401@gmail.com> <54BD284A.4080602@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA5C96F7B7@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C96F7B7@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, platooning - 802.11p X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 12:33:14 -0000 Le 20/01/2015 09:20, Romascanu, Dan (Dan) a écrit : > This certainly sounds interesting, to the extent that the IETF can > add value to the work done in ETSI with our specific expertise. > > Question - how does the ETSI work relate to IEEE 1609 and IEEE > 802.11p? Hello Dan, With respect to 802.11p, it is good to know that IP runs over 802.11p links in a straightforward manner. Whether two vehicles directly exchange CAM messages, or UDP/IP messages, is some times a matter of programmer's expertise and allocated budget. A seasoned programmer with much budget and high stakes at SDOs will acquire expensive hardware, training and binary libraries, and will realize CAM/DENM/11p prototypes. A novice programmer on low budget with visceral drive in computing will acquire cheapest hardware, open source libraries and self-training, and will realize UDP/IP/11p prototypes. Tolerant implementations in vehicular Mobile Routers receive and interpret both CAM/DENM messages _and_ UDP/IP/80211p messages. Alex > > Thanks and Regards, > > Dan > > >> -----Original Message----- From: its [mailto:its-bounces@ietf.org] >> On Behalf Of Alexandru Petrescu Sent: Monday, January 19, 2015 >> 5:53 PM To: its@ietf.org Subject: Re: [geonet/its] FYI - ETSI ITS - >> work on cooperative cruise control, platooning >> >> Hello geonet/its'ers, >> >> ETSI ITS continues work on C-ACC and Platooning. A f2f meeting a >> few days ago reveals, among other things, a possibility of >> developping a requirement for direct communication between >> vehicles ("The C-ACC system shall be able to receive data from >> other vehicle ITS-S or road side ITS-S"). >> >> What do you think? >> >> Alex >> >> Le 24/10/2014 17:16, Alexandru Petrescu a écrit : >>> Hello geonet/itsers, >>> >>> ETSI ITS group is an SDO in Europe. They produced many >>> standards in the past for vehicular communications, e.g. ETSI >>> ITS geo-networking among others. >>> >>> ETSI ITS recently agreed to start working on pre-standardization >>> items called "Cooperative Cruise Control" and "Platooning". These >>> two applications make automobiles (and trucks) talk to each other >>> continuously to keep speed constant. It helps relieve automobile >>> driver stress in jam situation or reduce gas consumption by >>> 'platooning'. >>> >>> Currently the focus is on requirements including communication >>> requirements. >>> >>> In my oppinion, and this is why I forward it to this group, >>> establishing direct IP connections between vehicles may open >>> paths for exchanging IP data containing speed/location and >>> trigger a control process of adapting the speed. One already >>> controls vehicles by sending IP data to them, from the >>> infrastructure. It would be a simple matter for IP experts to >>> send that same data from other vehicle, without going to the >>> infrastructure. >>> >>> Thoughts? >>> >>> Yours, >>> >>> Alex >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_mail >>> man_listinfo_its&d=AwIF- >> g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQ >>> >> zvlsiLQfucBXRucPvdrphpBsFA&m=7phbjG6Z2qP7PNOqvxHWe2s55dJcKMrSyf >> GAFrrU- >>> ms&s=GtUI3ETS930uY9YD5VlodU3wr4wfc4BXjjteZu_242c&e= >>> >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_mailman_listinfo_its&d=AwIF- >> g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd >> rphpBsFA&m=7phbjG6Z2qP7PNOqvxHWe2s55dJcKMrSyfGAFrrU- >> ms&s=GtUI3ETS930uY9YD5VlodU3wr4wfc4BXjjteZu_242c&e= > > From nobody Mon Jan 26 04:04:58 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78C51A8935 for ; Mon, 26 Jan 2015 04:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y_H_yVbjnrl for ; Mon, 26 Jan 2015 04:04:53 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780141A898E for ; Mon, 26 Jan 2015 04:04:52 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t0QC4iwV013385; Mon, 26 Jan 2015 13:04:44 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 997122057A0; Mon, 26 Jan 2015 13:05:12 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 86F2F205761; Mon, 26 Jan 2015 13:05:12 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t0QC4gmR018300; Mon, 26 Jan 2015 13:04:43 +0100 Message-ID: <54C62D5A.2020808@gmail.com> Date: Mon, 26 Jan 2015 13:04:42 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: dickroy@alum.mit.edu, =?windows-1252?Q?=27J=E9r=F4me_H=E4rri=27?= , "'Rex Buddenberg'" References: <544A6D4F.3060401@gmail.com> <54BD284A.4080602@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA5C96F7B7@AZ-FFEXMB04.global.avaya.com> <007f01d0348d$e85b3930$b911ab90$@eurecom.fr> <1421781803.13134.70.camel@localhost.localdomain> <82835FE2A55F40E085DDE68ADAB7D45C@SRA4> <008a01d0355b$031bbd30$09533790$@eurecom.fr> <54BFA921.5000503@gmail.com> <013001d03587$9863d180$c92b7480$@eurecom.fr> <54BFD251.6040801@gmail.com> <06D80EF6A2BE4F54861D058C5541CEDF@SRA4> In-Reply-To: <06D80EF6A2BE4F54861D058C5541CEDF@SRA4> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "'Romascanu, Dan \(Dan\)'" , its@ietf.org Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, platooning X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 12:04:56 -0000 Le 24/01/2015 10:31, Richard Roy a écrit : > Alex, > > Answers to your questions: > > 1) ISO has been doing V2V comms for over 20 years in TC204 WG16 ( it > used to be called CALM). Steve Sprouffske is the current Convener of > WG16. I have been involved for the last 10 years working on ALL the > related ISO standards with a few other very good people. > > 2) IEEE 1609 (WAVE) doesn't deal with apps as I mentioned before > (1609.11 aside). Note: it may not deal with apps in the sense that 1609 people think of what apps are. But, if one asks Internet people whether a particular functionality is an app, then the perspective is different. E.g. whereas IEEE P1609.11 "OTA payment exchange protocol" is not an application in the eyes of IEEE people, in the eyes of Internet people it is a pure application - it may have been called "https-over-IPv6-over-80211p ecommerce with an Android browser". This apparent confusion is relevant to 'app layer' but also to 'networking layer', and the others. > It has developed the networking and security services standards for > V2V and V2I at 5.9GHz. (I have been working on these standards for 10 > years as well.) Here we talk services. I think 'services' are the same thing as 'applications'. > 3) SAE has just approved the joint work on VRU, C-ACC, and platooning > with ETSI. The work is to be done in the SAE DSRC TC (of which I > have been a member for about 5 years), and Jim Meisner is the current > Chairman of the DSRC TC. Thanks! We have to contact them proposing to synthesize the current SAE work on C-ACC and platooning by co-authoring an Internet Draft. Yours, Alex > > Cheers, > > RR > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, January 21, >> 2015 8:23 AM To: Jérôme Härri; dickroy@alum.mit.edu; 'Rex >> Buddenberg' Cc: 'Romascanu, Dan (Dan)'; its@ietf.org Subject: Re: >> [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, >> platooning >> >> Le 21/01/2015 15:36, Jérôme Härri a écrit : >>> Dear Alex, >>> >>>> I think this is a good question that deserves discussion. >>>> >>>> My point of view is that C-ACC and Platooning are applications. >>>> For >>> example, a java client in one vehicle connects to a server in the >>> nearby vehicle and sends it its current location and speed. To >>> have it work >> that >>>> easily, one would have to first establish and maintain an IP >>>> path >> between >>> the two LANs in each vehicle. This is currently an unknown, >>> although several people on the list have some precise - and >>> contrasting >>>> - idea, about how to do it. >>>> >>>> But still C-ACC (cooperative cruise control) and Platooning >>>> are >>> applications from my point of view. >>>> >>>> I wonder what the others think of why we need IP packets for >>>> C-ACC and >>> Platooning? >>>> >>>> We need to build use cases before we even start thinking how >>>> this could be done. >>> >>> Thanks for your feedback.. >>> >>> They are applications indeed, but it does not mean it must be IP. >>> The >> Road >>> Hazard Warning is an application, but does not work on IP, and if >>> I am >> not >>> wrong, the CORRIDOR project provides platooning applications that >>> is not based on IP but rather on CALM FAST. >>> >>> But it is important to describe the application in terms of >>> functional elements (client, server, information flows, >>> interfaces etc...) and then >> see >>> if IP is required or not. Just one point: Platooning could work >>> based on >> a >>> client-server paradigm, as the platoon leader will gather and >>> manage its platoon. As for C-ACC, it is less clear, as the ETSI >>> definition of C-ACC >> is >>> that it is a fully distributed system: there is no leader, and as >>> such, >> a >>> client-server paradigm might be more difficult. >>> >>> My suggestion if we want to go further into that direction (and >>> not >> spend >>> our life exchanging ideas and point of views over a mailing list >>> ;-) ) >> is to >>> gather the related documents on C-ACC and Platooning applications >>> in the respective ITS standardization entities (ETSI, ISO, WAVE >>> (if any), >> SAE,..), >>> talk to the rapporteurs of these documents and report a digest in >>> an document. I can do this task from the ETSI side (actually >>> contacting >> the >>> two ETSI rapporteurs that I previously named). Maybe others with >>> ties at >> ISO >>> or WAVE could do the same... >> >> At ISO there is something about vehicle-to-vehicle communications >> and I can ask a person in charge to provide a summary of it. >> >> However, I am not sure whether at IEEE WAVE there is anything that >> may pertain to Platooning and C-ACC, or V2V? We need to identify >> somebody to find out. >> >> Also, I dont think SAE has any activity about C-ACC and Platooning, >> or V2V. We need to identify somebody to find out. >> >> Alex >> >>> >>> Best Regards, >>> >>> Jérôme >>> >>> >>> >>> > > > > From nobody Tue Jan 27 06:33:31 2015 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A38B1A87C5 for ; Tue, 27 Jan 2015 06:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.784 X-Spam-Level: X-Spam-Status: No, score=-2.784 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43HqG0nLknLC for ; Tue, 27 Jan 2015 06:33:26 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0691A87AC for ; Tue, 27 Jan 2015 06:33:26 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t0REXJOB022044; Tue, 27 Jan 2015 15:33:19 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 60FBB2038E0; Tue, 27 Jan 2015 15:33:49 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4E5C220156F; Tue, 27 Jan 2015 15:33:49 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t0REXHvc010146; Tue, 27 Jan 2015 15:33:18 +0100 Message-ID: <54C7A1AD.3080309@gmail.com> Date: Tue, 27 Jan 2015 15:33:17 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: dickroy@alum.mit.edu, =?windows-1252?Q?=27J=E9r=F4me_H=E4rri=27?= , "'Rex Buddenberg'" References: <544A6D4F.3060401@gmail.com> <54BD284A.4080602@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA5C96F7B7@AZ-FFEXMB04.global.avaya.com> <007f01d0348d$e85b3930$b911ab90$@eurecom.fr> <1421781803.13134.70.camel@localhost.localdomain> <82835FE2A55F40E085DDE68ADAB7D45C@SRA4> <008a01d0355b$031bbd30$09533790$@eurecom.fr> <54BFA921.5000503@gmail.com> <013001d03587$9863d180$c92b7480$@eurecom.fr> <54BFD251.6040801@gmail.com> <06D80EF6A2BE4F54861D058C5541CEDF@SRA4> <54C62D5A.2020808@gmail.com> <50236FD5DBF04548B8CD083F44E575B2@SRA4> In-Reply-To: <50236FD5DBF04548B8CD083F44E575B2@SRA4> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "'Romascanu, Dan \(Dan\)'" , its@ietf.org Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, platooning X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 14:33:29 -0000 Le 27/01/2015 08:37, Richard Roy a écrit : > Alex, > > A few minor things below: > > Cheers, > > RR > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Monday, January 26, 2015 4:05 AM >> To: dickroy@alum.mit.edu; 'Jérôme Härri'; 'Rex Buddenberg' >> Cc: 'Romascanu, Dan (Dan)'; its@ietf.org >> Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise >> control, platooning >> >> Le 24/01/2015 10:31, Richard Roy a écrit : >>> Alex, >>> >>> Answers to your questions: >>> >>> 1) ISO has been doing V2V comms for over 20 years in TC204 WG16 ( it >>> used to be called CALM). Steve Sprouffske is the current Convener of >>> WG16. I have been involved for the last 10 years working on ALL the >>> related ISO standards with a few other very good people. >>> >>> 2) IEEE 1609 (WAVE) doesn't deal with apps as I mentioned before >>> (1609.11 aside). >> >> Note: it may not deal with apps in the sense that 1609 people think of >> what apps are. But, if one asks Internet people whether a particular >> functionality is an app, then the perspective is different. >> >> E.g. whereas IEEE P1609.11 "OTA payment exchange protocol" is not an >> application in the eyes of IEEE people, in the eyes of Internet people >> it is a pure application - it may have been called >> "https-over-IPv6-over-80211p ecommerce with an Android browser". > > [RR>] Actually, the reason I said 1609.11 aside is because 1609 people do > consider it an app, in particular, a toll-collection (or EFC) app! If they consider it an app, then can we ask them what is the networking layer used? >> This apparent confusion is relevant to 'app layer' but also to >> 'networking layer', and the others. > > [RR>] Remember that applications do not reside in the ISO application layer, > APIs among other things do. Many people get confused by this, but it is > nonetheless the case. At IETF there are APIs as well between apps and networking layer, such as the BSD Socket Interface. >>> It has developed the networking and security services standards for >>> V2V and V2I at 5.9GHz. (I have been working on these standards for 10 >>> years as well.) >> >> Here we talk services. >> >> I think 'services' are the same thing as 'applications'. > > [RR>] Yes, and so do others. The terms "services" and "applications" are > overloaded in comms speak. However, in the OSI model, functions in any > given layer are applications as seen by the layer(s) below, and at the same > time are services as seen by the layer(s) above. To make it more > complicated, functions in the management entity are often referred to as > management "services". So, all the security functions (which are actually > management functions from the OSI stack perspective) are called "security > services". > > Now, to make it even more complicated, stakeholders at the highest levels in > the system hierarchy use the term service to mean something porvided to a > user. So, an ITS service is defined as something of value provided to an > ITS user. ITS services are implemented using ITS applications whcih are > instantiated in ITS-S application processes (software) that actually do the > work! Is that clearer now? :^)))) It is terminology used by specifications. Thanks for the explanation. >>> 3) SAE has just approved the joint work on VRU, C-ACC, and platooning >>> with ETSI. The work is to be done in the SAE DSRC TC (of which I >>> have been a member for about 5 years), and Jim Meisner is the current >>> Chairman of the DSRC TC. >> >> Thanks! >> >> We have to contact them proposing to synthesize the current SAE work on >> C-ACC and platooning by co-authoring an Internet Draft. > > [RR>] Not sure what you mean by synthesizing the current draft. That said, Synthesizing _in_ a draft. Summarizing other activities in a few paragraphs. > I am in constant contact with ALL these guys. Let me know what you would > like to get from them, and I'll see what I can do. Yes, here is what I would like to get from them: what is the documented activity at SAE about C-ACC and Platooning? Could you please write a few paragraphs about these activities, together with a few of us, in an Internet Draft titled "C-ACC and Platooning use-cases at ETSI ITS, IEEE 1609, ISO WG, and at SAE". If so, this may help towards designing an IETF protocol for establishing IP networking paths between vehicles. Once paths are established, applications will fluorish. Alex > > Cheers, > > RR > >> >> Yours, >> >> Alex >> >>> >>> Cheers, >>> >>> RR >>> >>>> -----Original Message----- From: Alexandru Petrescu >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, January 21, >>>> 2015 8:23 AM To: Jérôme Härri; dickroy@alum.mit.edu; 'Rex >>>> Buddenberg' Cc: 'Romascanu, Dan (Dan)'; its@ietf.org Subject: Re: >>>> [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, >>>> platooning >>>> >>>> Le 21/01/2015 15:36, Jérôme Härri a écrit : >>>>> Dear Alex, >>>>> >>>>>> I think this is a good question that deserves discussion. >>>>>> >>>>>> My point of view is that C-ACC and Platooning are applications. >>>>>> For >>>>> example, a java client in one vehicle connects to a server in the >>>>> nearby vehicle and sends it its current location and speed. To >>>>> have it work >>>> that >>>>>> easily, one would have to first establish and maintain an IP >>>>>> path >>>> between >>>>> the two LANs in each vehicle. This is currently an unknown, >>>>> although several people on the list have some precise - and >>>>> contrasting >>>>>> - idea, about how to do it. >>>>>> >>>>>> But still C-ACC (cooperative cruise control) and Platooning >>>>>> are >>>>> applications from my point of view. >>>>>> >>>>>> I wonder what the others think of why we need IP packets for >>>>>> C-ACC and >>>>> Platooning? >>>>>> >>>>>> We need to build use cases before we even start thinking how >>>>>> this could be done. >>>>> >>>>> Thanks for your feedback.. >>>>> >>>>> They are applications indeed, but it does not mean it must be IP. >>>>> The >>>> Road >>>>> Hazard Warning is an application, but does not work on IP, and if >>>>> I am >>>> not >>>>> wrong, the CORRIDOR project provides platooning applications that >>>>> is not based on IP but rather on CALM FAST. >>>>> >>>>> But it is important to describe the application in terms of >>>>> functional elements (client, server, information flows, >>>>> interfaces etc...) and then >>>> see >>>>> if IP is required or not. Just one point: Platooning could work >>>>> based on >>>> a >>>>> client-server paradigm, as the platoon leader will gather and >>>>> manage its platoon. As for C-ACC, it is less clear, as the ETSI >>>>> definition of C-ACC >>>> is >>>>> that it is a fully distributed system: there is no leader, and as >>>>> such, >>>> a >>>>> client-server paradigm might be more difficult. >>>>> >>>>> My suggestion if we want to go further into that direction (and >>>>> not >>>> spend >>>>> our life exchanging ideas and point of views over a mailing list >>>>> ;-) ) >>>> is to >>>>> gather the related documents on C-ACC and Platooning applications >>>>> in the respective ITS standardization entities (ETSI, ISO, WAVE >>>>> (if any), >>>> SAE,..), >>>>> talk to the rapporteurs of these documents and report a digest in >>>>> an document. I can do this task from the ETSI side (actually >>>>> contacting >>>> the >>>>> two ETSI rapporteurs that I previously named). Maybe others with >>>>> ties at >>>> ISO >>>>> or WAVE could do the same... >>>> >>>> At ISO there is something about vehicle-to-vehicle communications >>>> and I can ask a person in charge to provide a summary of it. >>>> >>>> However, I am not sure whether at IEEE WAVE there is anything that >>>> may pertain to Platooning and C-ACC, or V2V? We need to identify >>>> somebody to find out. >>>> >>>> Also, I dont think SAE has any activity about C-ACC and Platooning, >>>> or V2V. We need to identify somebody to find out. >>>> >>>> Alex >>>> >>>>> >>>>> Best Regards, >>>>> >>>>> Jérôme >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> >> >> > > > >