From mcr@sandelman.ca Wed May 1 09:51:17 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E7A21F9A4F for ; Wed, 1 May 2013 09:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avsdj67Nrm9z for ; Wed, 1 May 2013 09:51:17 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id CCBF021F99FD for ; Wed, 1 May 2013 09:51:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4F7C720170; Wed, 1 May 2013 13:02:10 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3930963A62; Wed, 1 May 2013 12:50:45 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 29B3263A61; Wed, 1 May 2013 12:50:45 -0400 (EDT) From: Michael Richardson To: Alison Chaiken In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: its@ietf.org Subject: Re: [its] novel use case for intra-vehicular wireless X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 16:51:17 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Alison" =3D=3D Alison Chaiken writes: Alison> used for applications like back-seat media control. He said = that Alison> such tiny dispersed touch panels may operate via Zigbee, althou= gh I Alison> guess they could be active RFID as well. The idea that cars = will Alison> have far fewer cables and wires and more wireless is pretty Alison> fascinating. That may save on assembly costs although Alison> the question of battery-powering so many small devices is Alison> worrisome. Perhaps=20 Alison> energy harvesting is a real solution for vehicles? It seems to me that distributing 5V/12V is possibly easier than data cables. I realize that CAN has done lots in the space of data+power already.=20 For buttons and the like, energy harvesting can be done from the action of pushing the button itself.=20=20 Alison> Anyhow, I don't mean to drag the group off-topic, but the Alison> concept of the wireless control of media playing is Alison> generally intriguing. I'm=20 Alison> convinced that in some developing nations, the car will be the = main Alison> "PC" for the household, the source of email, music, movie strea= ming Alison> for the whole house when parked. Residents of such nations w= ill I think that this is entirely at odds with significantly reduced car ownership via car sharing co-ops, mobility-on-demand, driver-less vehicles, and peak-oil. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUYFH5YqHRg3pndX9AQK0iAP/VoXUDtCQYGtyAETUoDpnKfW7dk+f5s3H H+7b9b07YALhL0/A9yftjUEK4Rdcpt5fLryo2plcqJyoU6XGGHPzoIss0DdchkDA iUAfRxGAAXQST4kNaxFwuvMr+x9RevSdX8JBujtVT7jNm5nSTBLNKOUfbnEIjr4r X0JUMh2Ho3A= =JFWl -----END PGP SIGNATURE----- --=-=-=-- From Alison_Chaiken@mentor.com Thu May 2 11:46:05 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F0F21F8EC2 for ; Thu, 2 May 2013 11:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC9aJjvkIIGG for ; Thu, 2 May 2013 11:45:59 -0700 (PDT) Received: from relay1.mentorg.com (relay1.mentorg.com [192.94.38.131]) by ietfa.amsl.com (Postfix) with ESMTP id 7022B21F8EF7 for ; Thu, 2 May 2013 11:45:56 -0700 (PDT) Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1UXyVr-0002sf-9Z from Alison_Chaiken@mentor.com ; Thu, 02 May 2013 11:45:51 -0700 Received: from SVR-ORW-FEM-02.mgc.mentorg.com ([147.34.96.206]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 May 2013 11:45:51 -0700 Received: from NA-MBX-03.mgc.mentorg.com ([fe80::9a:1569:df57:45b8]) by SVR-ORW-FEM-02.mgc.mentorg.com ([147.34.96.168]) with mapi id 14.02.0247.003; Thu, 2 May 2013 11:45:47 -0700 From: "Chaiken, Alison" To: "automotive-announce@lists.linuxfoundation.org" Thread-Topic: proposed Linux Plumbers Conference Automotive Networking Discussion (RE: In Case You Missed It - Automotive Linux Webinar Recording) Thread-Index: AQHOR2UUppz8F7ZfHEuXzdjekQR++g== Date: Thu, 2 May 2013 18:45:46 +0000 Message-ID: <60BA5429A0E1584BA3633194F6F993B5023252D3@NA-MBX-03.mgc.mentorg.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.34.91.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 May 2013 18:45:51.0091 (UTC) FILETIME=[44BE3C30:01CE4765] X-Mailman-Approved-At: Thu, 02 May 2013 12:24:59 -0700 Cc: "eg-nw@mail.genivi.org" , "sameo@linux.intel.com" , "its@ietf.org" , "jkenney@us.toyota-itc.com" , Ravi Puvvala , "Marcel.Holtmann@intel.com" Subject: [its] proposed Linux Plumbers Conference Automotive Networking Discussion (RE: In Case You Missed It - Automotive Linux Webinar Recording) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 19:08:33 -0000 Let's follow-up Konstantin Khait's fine webinar on Automotive Wireless by o= rganizing a session to discuss open-source implementations of 802.11p drive= rs (DSRC) and IEEE-1609 (WAVE) stack at Linux Plumbers Conference in New Or= leans in September, =0A= =0A= http://wiki.linuxplumbersconf.org/2013:automotive=0A= =0A= I have already discussed the idea with Rudi Streif of Linux Foundation and = Daniel Wagner of BMW, the track conveners, and their feedback is positive. = A list of potential additional attendees is CC'ed. Let's get all the i= nterested parties together to have a discussion about moving ITS wireless f= orward in Linux.=0A= =0A= -- Alison Chaiken=0A= (void *) engineer=0A= Mentor Embedded Software Division=0A= GMT+8=0A= alison_chaiken@mentor.com= From alison@she-devel.com Thu May 2 13:39:13 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BD421F850F for ; Thu, 2 May 2013 13:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iX2gOk0Tr8OH for ; Thu, 2 May 2013 13:39:09 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF2221F8506 for ; Thu, 2 May 2013 13:39:08 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id r11so928361lbv.41 for ; Thu, 02 May 2013 13:39:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=QY/E5m3jbUWxkbeoUjxmvzMVMfYVQBFphdUT5FSFVqQ=; b=hVseFIbzLkN5cJ8DUArIZUoT8VNvhlLYoL1PD8dIhLJoifiBVWuN5gM3peCKDzeB3c V8e4TcHSWpK4zLSLu3y3iOjbbacJrWSvWYKiBm2HYqLalzzc/UKA2y+jHh3301nZKcvY +PFMKuszI7tVoZVr58/WzVwfif2KREkbHCFO00oiRvAzTF7db3fDL7gKCHX2RlrmGA1f US/LWiLGRleMCbUKEcC7SjduBhkNF82Inoe7rlorhYaJ7TRk7nLT9A+bFc3ujSn2Hw8I bI6xVo9QCeaQVg20YJ35W4fdPaEKLXzVD2QR9AxagLfbO+668D2X3ba3mXSJ1OdJt1Je /yNw== MIME-Version: 1.0 X-Received: by 10.152.29.132 with SMTP id k4mr3126309lah.46.1367527147333; Thu, 02 May 2013 13:39:07 -0700 (PDT) Received: by 10.112.158.136 with HTTP; Thu, 2 May 2013 13:39:07 -0700 (PDT) Date: Thu, 2 May 2013 13:39:07 -0700 Message-ID: From: Alison Chaiken To: its@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn2oA5ubLt+CQjJ/F1EsvlajaEL9Fc6bmMrw7XRybGng69djS4W7txUU2lEEMTEaAySQYwJ Subject: [its] an authoritative article on "IP and Ethernet in motor vehicles" in _EE Times_ X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 20:39:13 -0000 http://www.eetimes.com/General/PrintView/4412977 -- Alison Chaiken alison@she-devel.com 650-279-5600 http://{she-devel.com, exerciseforthereader.org} The intermediary between the head and the hands must be the heart. -- Thea von Harbou From Massimiliano.Lenardi@hitachi-eu.com Fri May 3 10:13:51 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E382721F9977 for ; Fri, 3 May 2013 10:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6 X-Spam-Level: X-Spam-Status: No, score=-6 tagged_above=-999 required=5 tests=[GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzNpQT--hqkK for ; Fri, 3 May 2013 10:12:55 -0700 (PDT) Received: from gatekeeper2.hitachi.eu (gatekeeper2.hitachi.eu [194.36.134.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8543F21F9813 for ; Fri, 3 May 2013 09:32:30 -0700 (PDT) X-ASG-Debug-ID: 1367598740-04ede30fa21864b0001-m4RtKs Received: from lhr-mta-int.hitachi-eu.com (lhr-mta-int.hitachi-eu.com [194.36.130.25]) by gatekeeper.hitachi.eu with ESMTP id zBPZPAFZxyICz91X (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 03 May 2013 17:32:20 +0100 (BST) X-Barracuda-Envelope-From: Massimiliano.Lenardi@Hitachi-eu.com X-ASG-Whitelist: Sender X-Barracuda-Apparent-Source-IP: 194.36.130.25 X-ASG-Whitelist: Client Received: from GSukMHDDCehcs01.service.hitachi.net (Not Verified[193.39.225.70]) by lhr-mta-int.hitachi-eu.com with MailMarshal (v6, 9, 9, 4075) id ; Fri, 03 May 2013 17:29:04 +0100 Received: from GSUKMHDDCEMBX02.service.hitachi.net ([169.254.2.222]) by GSukMHDDCehcs01.service.hitachi.net ([193.39.225.70]) with mapi id 14.01.0355.002; Fri, 3 May 2013 17:32:19 +0100 X-Barracuda-BBL-IP: 193.39.225.70 X-Barracuda-RBL-IP: 193.39.225.70 From: "Lenardi, Massimiliano" To: "its@ietf.org" Thread-Topic: [its] suppliers of 802.11p-over-ITS-G5; 802.11s-over-5875-5905MHz X-ASG-Orig-Subj: RE: [its] suppliers of 802.11p-over-ITS-G5; 802.11s-over-5875-5905MHz Thread-Index: AQHOQOHM0vyDMY529EKh7uclgedDMZjztNRw Date: Fri, 3 May 2013 16:32:19 +0000 Message-ID: <85C635C4D32378499484B2C61BD297A419E9993E@GSukMHDDCembx02.service.hitachi.net> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <511F7968.7090309@gmail.com> <5177C6BA.6020805@gmail.com> In-Reply-To: <5177C6BA.6020805@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.115.99.153] Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: lhr-mta-int.hitachi-eu.com[194.36.130.25] X-Barracuda-Start-Time: 1367598740 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.168.242.170:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at hitachi.eu Subject: Re: [its] suppliers of 802.11p-over-ITS-G5; 802.11s-over-5875-5905MHz X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:13:51 -0000 Dear All, please also add RENESAS ELECTRONICS to the list below of potential su= ppliers of 11p/DSRC enabled radio devices. Best, - Max -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Ale= xandru Petrescu Sent: 24 April 2013 13:49 To: its@ietf.org Subject: Re: [its] suppliers of 802.11p-over-ITS-G5; 802.11s-over-5875-59= 05MHz Recently I discovered that in addition to the posted list there is also C= ommsignia as a manufacturer of 802.11p compatible OBU and RSU. The list = is now: NEC NXP/Cohda Wireless Cisco/Cohda Wireless Denso Delphi Savari Kapsch Siemens ITRI AutoTalks Commsignia Yours, Alex Le 16/02/2013 13:19, Alexandru Petrescu a =E9crit : > Le 11/02/2013 14:50, Dowdell, John a =E9crit : >> Alex >> >> Is anyone making 802.11p radios commercially at reasonable cost? The = >> few I have seen seem to be very expensive (few k$) and there appears = >> to be little support in Linux. > > John, > > A person was kind enough to gather in one place information which is=20 > otherwise sparsely but publicly available; this information is about=20 > suppliers of 802.11p-over-ITS-G5 frequencies (5875-5905MHz,=20 > 5855-5875MHz, 5470-5725MHz; caveat - only some are allowed in some=20 > countries, check the local regulator before turning these on). > > NEC > NXP/Cohda Wireless > Cisco/Cohda Wireless > Denso > Delphi > Savari > Kapsch > Siemens > ITRI > AutoTalks > > I have some experience with ITRI equipment. In their offer there is a = > full-blown RSU, for around 1500EUR. This is for a RSU hardened box=20 > for outdoors, powerpc, GPS-enabled, 2x 802.11p interfaces, Ethernet=20 > with PoE, USB, and linux 2.6. Among these, it is the software which=20 > is expensive; this includes Atheros driver modifications, new kernel=20 > modules for "BTP" (Base Transmission Protocol?), 'geonetworking',=20 > 'wave'. > > OTher than a full-blown RSU, one could acquire also ITRI individual=20 > '802.11p' miniPCI cards which are in the order of couple hundreds of eu= ros. > > This is not a commercial advertisement. Technically speaking this=20 > means many things for designing protocols. For example: > > It means it is easily possible to run linux with IPv6 over a 'wave0' > interface. Just turn it on, watch the IPv6 link-local address, echo > the frequency value and ping. (no need to set ESSID, nor security). > > In addition to the Ethernet interfaces, the RSU has _2_ 802.11p=20 > different interfaces, and one Ethernet. Not just two antennas, but=20 > two interfaces (ifconfig 'wave0' and 'wave1'). This means one doesn't=20 > need to 'relay' packets and that one needs to 'route' packets, in the=20 > traditional sense of 'routing'. (compare this for example to RPL=20 > context where a sensor has a _single_ interface and there is no=20 > routing, but 'relaying'). > > Also this outdoors RSU has 1 GPS antenna. This means that=20 > geonetworking does not work if one tries to use this indoors in a lab=20 > where GPS signal does not reach. (unless one installs a GPS 'repeater' = > - easy to do but check with regulator in country, or use a GPS=20 > 'replayer' software to play pre-recorded NMEA sentences on /dev/tty). > > Note also it is strange to design an RSU Road Side Unit - designed to=20 > be fixed with respect to Earth, and put a GPS interface on it. It=20 > would have been easier to just record the GPS coordinates once and set = > them in a file for as long as that RSU stays there. I consider it as=20 > an extra, but cheaper RSU without GPS should be possible. > >> 802.11s on the other hand is available on standard Wi-Fi dongles=20 >> (from $15) and drivers are already available in Linux. Is it correct=20 >> that 802.11p is mandated for ITS in some regions? > > I doubt 802.11p be mandated for ITS. > > I think the regulator mandates the application which could be used on=20 > some frequencies. > > Where I live, the regulator mandates the use of vehicular 'safety' > applications at 5875-5905MHz. The technical 'conditions' are referred = > by the regulator to ETSI documents (the regulator is not ETSI, but=20 > often implements what ETSI wants, but not always). I doubt the=20 > regulator mandates 'geonetworking' for this band. > > I doubt 'IP' could be qualified as 'safety'. > > Hence I think 802.11s _could_ be used on the range 5875-5905MHz, as=20 > long as it does not transport IP. > > 802.11p has some features which could qualify as 'safety'. For=20 > example, it has some MAC-layer messages for 'emergency', and with=20 > timestamps (absent from .11 non-p standard), which don't transport IP. > > 'geonetworking' also has some features which could qualify as 'safety'.= > I just don't remember which. > > What features in 802.11s would qualify as 'safety'? > > Alex > >> >> John >> >> -----Original Message----- From: its-bounces@ietf.org=20 >> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: >> 31 January 2013 15:17 To: its@ietf.org Subject: Re: [its] IP over=20 >> 802.11p >> >> Le 31/01/2013 14:47, Thierry Ernst a =E9crit : >>> >>> Well, we do actually run IPv6 over 11p (with or without=20 >>> GeoNetworking), so I don't see what kind of issues there might be=20 >>> ... >> >> I have some clarification questions about EtherType and 802.11p and=20 >> GeoNetworking. >> >> I guess when you run IPv6 over 11p with GeoNetworking, the Ethernet=20 >> header uses EtherType soon-to-be-0x8947, whereas when you run IPv6=20 >> over 11p without GeoNetworking, the Ethernet header uses EtherType=20 >> 0x86DD. This is just a supposition, I don't know how you run it. >> >> Also, if I run IPv4 over 11p with GeoNetworking - should I use=20 >> EtherType soon-to-be-0x8947? Or other? I suppose that if I run IPv4 = >> over 11p without GeoNetworking I should use EtherType 0x0800, and if=20 >> it's ARP over 802.11p still without GeoNetworking then I should use=20 >> EtherType 0x0806. >> >> (the letter we've seen recently is not clear whether that allocation = >> is for GeoNetworking, for IP-over-802.11p, for ETSI ITS, for=20 >> GeoNetworking for IPv6, for GeoNetworking for IPv4, etc. It is not=20 >> clear either whether GeoNetworking supports IPv4 or not, or under=20 >> what form). >> >> I also have some questions about the relationship between the nature = >> of some 802.11p links (no ESSID, absence of link-layer security - as=20 >> opposed to WiFi which has ESSID and link-layer security) and IP. >> >> For example - will V2V prefix exchange using Router Advertisements=20 >> work easier on 802.11p links (easier than on WiFi), because the ESSID = >> does not need to be discovered, the ad-hoc network does not need to=20 >> be formed - suffices it to send packets on a certain channel. >> >> (in a V2V draft one seems to say that the presence of Access Point is = >> absolutely necessary in order for 802.11p to work; but in our=20 >> experimentations this is not the case - it is possible to establish=20 >> direct vehicle-to-vehicle IP-over-802.11p communications without the=20 >> presence of a fixed 802.11p Access Point). >> >> For another example - will IP prefer that the 802.11p channel in=20 >> France be 176, 178 or 180? (with WiFi, IP does not care because it=20 >> can work on any of the 11 channels equally well, but with 802.11p=20 >> each of these three channels seem to be reserved for "Services",=20 >> "Control" and "Services"). >> >> For another example - is all the security on these links entirely=20 >> relaying on IP layer security (IPsec, SeND, EAP, PANA)? >> >> I think finding consensus on some of these questions could lead to=20 >> interoperability. >> >> Alex >> >>> >>> Regards, Thierry >>> >>> >>> >>> On 31/01/13 13:55, Alexandru Petrescu wrote: >>>> Given current discussions, I think it may be worth considering a=20 >>>> work item about how to run IP over 802.11p. >>>> >>>> One of the things to say would be whether or not this is IPv6 only=20 >>>> or IPv4 also. >>>> >>>> This would say how this would work _without_ GeoNetworking. >>>> >>>> It would agree on the EtherType and/or whether there are new ones,=20 >>>> several or only one, or reusing existing EtherTypes. >>>> >>>> It could be as simple as to say that IP works over 802.11p just as=20 >>>> it works over 802.11b - no modifications. >>>> >>>> What do you think? >>>> >>>> Alex >>>> >>>> Le 30/01/2013 11:10, Alexandru Petrescu a =E9crit : >>>>> Le 30/01/2013 11:04, Romascanu, Dan (Dan) a =E9crit : >>>>>> Hi Alexandru, >>>>>> >>>>>> IEEE talk only hexa in their Ethertype files. >>>>> >>>>> I tend to agree that #8947 is a hexadecimal notation also because=20 >>>>> the sharp sign preceding it, and because if it were decimal it=20 >>>>> would convert to 22F3 which is already reserved for trill. >>>>> >>>>> I just watend to make sure. >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- From: its-bounces@ietf.org=20 >>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu=20 >>>>>>> Sent: Wednesday, January 30, 2013 12:00 PM To: >>>>>>> its@ietf.org Subject: Re: [its] What do we need to make ITS WG=20 >>>>>>> go forward? - EtherType for ITS >>>>>>> >>>>>>> Hello Dan, >>>>>>> >>>>>>> Thank you for the email. >>>>>>> >>>>>>> I think we definitely need a good interface with IEEE about=20 >>>>>>> this. >>>>>>> >>>>>>> Maybe you could ask them whether this number is hexa or decimal, = >>>>>>> so we know what to put in implementation (e.g. >>>>>>> wireshark packet analyzers, and 802.11p/etsi-its=20 >>>>>>> implementations). >>>>>>> >>>>>>> Also, I am interested to learn whether this deserves being=20 >>>>>>> reserved at IANA. >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> Le 30/01/2013 10:49, Romascanu, Dan (Dan) a =E9crit : >>>>>>>> Hi, >>>>>>>> >>>>>>>> The documents that you are referring (on the ETSI >>>>>>>> server) are not freely accessible. A password is required, and=20 >>>>>>>> probably only ETSI members have the access information. >>>>>>>> >>>>>>>> The responsibility for assigning EtherType values is with the=20 >>>>>>>> IEEE Registration Authority. They maintain a public list=20 >>>>>>>> (updated daily) at=20 >>>>>>>> http://standards.ieee.org/develop/regauth/ethertype/eth.txt >>>>>>>> >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > and according to this list the value 8947 is not allocated. >>>>>>>> Now, the public listing information for EtherTypes bears a=20 >>>>>>>> disclaimer that says >>>>>>>> >>>>>>>> * This is a partial listing of all assigned EtherType Fields.=20 >>>>>>>> Not >>>>>>> all >>>>>>>> recipients wish to publish their assignment at this time. >>>>>>>> >>>>>>>> Did ETSI require for this information not to be published? It=20 >>>>>>>> does not look useful if they want to encourage interoperability >>>>>>>> >>>>>>>> Value 0707 mentioned in the thread is not allocated either. >>>>>>>> >>>>>>>> Let me know if I can help (as IETF liaison to the IEEE-SA). >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> *From:*its-bounces@ietf.org >>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of *Thierry Ernst=20 >>>>>>>> *Sent:* Wednesday, January 30, 2013 11:11 AM *To:* its@ietf.org = >>>>>>>> *Subject:* Re: [its] What do we need to make ITS WG go forward? = >>>>>>>> - EtherType for ITS >>>>>>>> >>>>>>>> >>>>>>>> Alex, >>>>>>>> >>>>>>>> IEEE have assigned Ethernet Type Field number #8947 for ITS use = >>>>>>>> (ETSI TC ITS's GeoNetworking). Check the following document=20 >>>>>>>> available on the ETSI server: >>>>>>>> >>>>>>>> ITS(13)000020 >>>>>>>> >>>>>>> 2900002 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > 0_Ethernet_Type_Field_number_for_GeoNetworking.pdf> >>>>>>>> Ethernet Type Field number for GeoNetworking=20 >>>>>>>> http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS(13)000 >>>>>>>> 020_Eth >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > ernet_Type_Field_number_for_GeoNetworking.pdf >>>>>>>> >>>>>>>> Regards, Thierry. >>>>>>>> >>>>>>>> >>>>>>>> On 28/01/13 14:28, Alexandru Petrescu wrote: >>>>>>>> >>>>>>>> Le 28/01/2013 14:16, Joe Klein a =E9crit : >>>>>>>> >>>>>>>> I really dislike the fact that ISO is charging for the ISO=20 >>>>>>>> 21217 - Architecture & ISO 21210 - IPv6 Networking. >>>>>>>> >>>>>>>> Does this make it any better? Safer? Should ISO now have=20 >>>>>>>> cybersecurity and safety liability if the specification leads=20 >>>>>>>> to deaths and damage to property? >>>>>>>> >>>>>>>> >>>>>>>> Does it make any better interoperable as well? >>>>>>>> >>>>>>>> EtherType 0x0707 described in ITS documents, implemented, but=20 >>>>>>>> not specified by IEEE nor reserved at IANA - does not make it=20 >>>>>>>> interoperable. >>>>>>>> >>>>>>>> One wouldn't think that this 0x0707 ethertype be reserved by >>>>>>> somebody >>>>>>>> who is not IANA nor IEEE? >>>>>>>> >>>>>>>> (see a good example of interoperability: IPv6 0x86dd ethertype=20 >>>>>>>> is reserved at IEEE and at IANA >>>>>>>> >>>>>>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbe >>>>>>>> rs.xml) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > Alex >>>>>>>> >>>>>>>> Or should these standards remain in >>>>>>>> >>>>>>>> the public domain, for researches to review and validate? >>>>>>>> >>>>>>>> Just my 2 cents. >>>>>>>> >>>>>>>> Joe >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jan 28, 2013 at 6:31 AM, Thierry Ernst=20 >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Dear all, >>>>>>>> >>>>>>>> At this stage, I don't think a new working group is needed.=20 >>>>>>>> First, it would need a charter, and support from the industry. = >>>>>>>> But more importantly, IETF WGs are not usually sector-driven,=20 >>>>>>>> so it means the different issues pertaining to ITS should be=20 >>>>>>>> brought to >>>>>>> VARIOUS >>>>>>>> existing WGs, and a WG should only be created if there is an=20 >>>>>>>> important issue for which there is no existing WG that could=20 >>>>>>>> work on it. >>>>>>>> >>>>>>>> This said, as mentioned earlier, ITS is not only about=20 >>>>>>>> vehicular communications, though the issues listed by Alexandru = >>>>>>>> below mostly consider vehicular communications. >>>>>>>> >>>>>>>> What ITS really needs is the definition of a common=20 >>>>>>>> communication architecture and the definition of what features=20 >>>>>>>> should be comprised for an IPv6 networking stack deployed for=20 >>>>>>>> ITS use cases. This cannot be done at IETF, and actually=20 >>>>>>>> already exists at ISO: - ISO 21217 - Architecture - ISO 21210 - = >>>>>>>> IPv6 Networking >>>>>>>> >>>>>>>> As an input to the discussion, please consider reading=20 >>>>>>>> documents D2.1 and D2.2 available on the ITSSv6 project web=20 >>>>>>>> page: http://www.itssv6.eu/documentation/ D2.2 provides an=20 >>>>>>>> analysis of the currently published version of ISO 21210, but=20 >>>>>>>> new work items have been launched since then to address=20 >>>>>>>> remaining issues. >>>>>>>> >>>>>>>> Regards, Thierry. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 28/01/13 11:08, Alexandru Petrescu wrote: >>>>>>>> >>>>>>>> >>>>>>>> Le 28/01/2013 05:02, Stan Ratliff (sratliff) a =E9crit : >>>>>>>> >>>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> This is just one opinion, but I'd like to understand why ITS=20 >>>>>>>> would need its own IETF group. The work here is the same (IMO)=20 >>>>>>>> as what is taking place in MANET. I would vote that this work=20 >>>>>>>> be taken up in MANET. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Stan, >>>>>>>> >>>>>>>> Thank you for the offer. I considered this offer since some=20 >>>>>>>> time. >>>>>>>> >>>>>>>> I try to understand whether some of these items on which I=20 >>>>>>>> have interest could be brought in in MANET WG: - V2V using=20 >>>>>>>> prefix exchange - VIN-based IP addressing scheme - ND Prefix=20 >>>>>>>> Delegation - PMIP-based network mobility - >>>>>>>> IPv6 single-address connecion 'sharing' with a cellular=20 >>>>>>>> operator and a vehicular moving network (type '64share' >>>>>>>> of v6ops). - Default Route with DHCPv6. >>>>>>>> >>>>>>>> Please let me know. >>>>>>>> >>>>>>>> Yours, >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards, Stan >>>>>>>> >>>>>>>> On Jan 26, 2013, at 9:34 AM, Abdussalam Baryun wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi Nabil, >>>>>>>> >>>>>>>> I think we already done some steps but not sure how far now. We = >>>>>>>> will need to propose the WG and provide the WG charter, as use=20 >>>>>>>> cases and work to be done in this group. >>>>>>>> This charter needs to be approved by the IESG. I have not=20 >>>>>>>> attended the last meeting so not sure about the status now, >>>>>>>> >>>>>>>> AB >>>>>>>> >>>>>>>> On 1/26/13, Nabil Benamar =20 >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I'm still interested in this list and want to join voices=20 >>>>>>>> previously heard to make it a working group. So what should we=20 >>>>>>>> exactly do, to achieve this goal ? >>>>>>>> >>>>>>>> >>>>>>>> 2013/1/26 Abdussalam Baryun =20 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I was interested in this group but not sure where are we so=20 >>>>>>>> far. Is there progress, or is there issues/efforts that need to = >>>>>>>> be completed and volunteered. >>>>>>>> >>>>>>>> AB _______________________________________________ its mailing=20 >>>>>>>> list its@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- * * *=CA=CD=ED=C7=CA=ED =A1 **Cordialement, Regards* * * * * = *=E4=C8=ED=E1=20 >>>>>>>> =C8=E4=DA=E3=D1=E6Nabil Benamar* Professor of computer sciences = Simulation=20 >>>>>>>> and Modelisation Laboratory Human Sciences Faculty of Meknes=20 >>>>>>>> Moulay Ismail* *University* Meknes, Morocco *GSM: * *+ 212 6=20 >>>>>>>> 70832236 http://nabilbenamar.com/ >>>>>>>> >>>>>>>> * >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------- >>>>>>>> ------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > ---------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> * >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> its >>>>>>>> mailing list its@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>> mailing >>>>>>>> list its@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>> mailing >>>>>>>> list its@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its mailing >>>>>>> list >>>>>>>> its@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> _______________________________________________ its mailing=20 >>>>>>>> list its@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its mailing=20 >>>>>>>> list its@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its mailing=20 >>>>>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ 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 >>>> >>>> >>>> _______________________________________________ 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 >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its The >> information contained within this e-mail and any files attached to >> this e-mail is private and in addition may include commercially >> sensitive information. The contents of this e-mail are for the >> intended recipient only and therefore if you wish to disclose the >> information contained within this e-mail or attached files, please >> contact the sender prior to any such disclosure. If you are not the >> intended recipient, any disclosure, copying or distribution is >> prohibited. Please also contact the sender and inform them of the >> error and delete the e-mail, including any attached files from your >> system. Cassidian Limited, Registered Office : Quadrant House, Celtic >> Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 >> http://www.cassidian.com >> >> > > > _______________________________________________ > 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 E-mail Confidentiality Notice and Disclaimer.=20 This e-mail and any files transmitted with it are confidential and are in= tended solely for the use=20 of the individual or entity to which they are addressed. Access to this e= -mail by anyone else is=20 unauthorised. If you are not the intended recipient, any disclosure, copy= ing, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. E-m= ail messages are not=20 necessarily secure. Hitachi does not accept responsibility for any change= s made to this message=20 after it was sent.=20 Hitachi checks outgoing e-mail messages for the presence of computer viru= ses.=20 *************************************************************************= ************************* From jkenney@us.toyota-itc.com Fri May 3 15:25:54 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5582621F8E51 for ; Fri, 3 May 2013 15:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.117 X-Spam-Level: X-Spam-Status: No, score=-4.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4BiD8HElsGN for ; Fri, 3 May 2013 15:25:49 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with SMTP id AFF1921F8BF7 for ; Fri, 3 May 2013 15:25:49 -0700 (PDT) Received: from mail-pb0-f70.google.com ([209.85.160.70]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUYQ5bQS9ts+WoamsUw+tTVl5+rjkMdOh@postini.com; Fri, 03 May 2013 15:25:49 PDT Received: by mail-pb0-f70.google.com with SMTP id jt11so2153260pbb.1 for ; Fri, 03 May 2013 15:25:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=9P+85iHXZaCus1Db5NNi10+oTmsTG/XplbeC3bmlnlg=; b=eyACGLfPlRJacFggF5G+UpRRvXsF9uODGaFtJnIsMHnNbJjB9CR7sHo63MCBILYL9/ Qvir5mK+i5YVy69KnbIZdkmjXp/0UT1Zdm2dQPACWzT768KFvx0ijT/oPr8mkiN6uPgi yAXX9G7VkxCTqnAeLeZUGEXCk9on91hE2dX/ywDSNJBsIR7klCyX0eunNMS5rW1uglOc 8Kf1ce7I2CH7KyWDDJQflQNXQZYflS01TAV+oHFvzJaaIB+5DdI+zGEx/SEn20VfRshS Gtc5TV9/RSdKxwhd/sSQr1wiJHYH55m6Pz7M05XfdP4b0t0QpOz3KDMSh8wWoVkpwEJW PZdQ== X-Received: by 10.66.67.46 with SMTP id k14mr16427802pat.199.1367619948749; Fri, 03 May 2013 15:25:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.67.46 with SMTP id k14mr16427795pat.199.1367619948547; Fri, 03 May 2013 15:25:48 -0700 (PDT) Received: by 10.68.250.37 with HTTP; Fri, 3 May 2013 15:25:48 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 May 2013 18:25:48 -0400 Message-ID: From: John Kenney To: Alison Chaiken Content-Type: multipart/alternative; boundary=485b395e7d3338a52e04dbd7d533 X-Gm-Message-State: ALoCoQkfXAsfLaBxnYOt6wEk/4mFU8Fd2v0XVIoUo5dTj9OyoJOX5ZhZhyZM9HuZ+oxrFgOgqcCXRMIRip1BKFsN8FKU5ewQuK0XgychOwreGMkXRk+o4OD9Pu4a03zrTrj1uqz4xqyR Cc: its@ietf.org Subject: Re: [its] V2X webinar by Konstantin Khait X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 22:25:54 -0000 --485b395e7d3338a52e04dbd7d533 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the shout-out Alison! I'm happy to answer questions about DSRC. Best Regards, John -- John Kenney, Ph.D. Sr. Research Manager Toyota InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 On Tue, Apr 30, 2013 at 2:02 PM, Alison Chaiken wrote: > Excellent webinar, if difficult to follow and a bit Eurocentric: > > > http://automotive.linuxfoundation.org/webinars/watch-webinar-using-open-source-solutions-for-vtv-vti-communications > > My go-to reference for U.S. DSRC and WAVE info is John Kenney of > Toyota's excellent "Dedicated Short-Range > Communications (DSRC) Standards in the United States", Proceedings of > the IEEE | Vol. 99, No. 7, July 2011. I received a copy from the > author but will let John (CC'ed) distribute it if he wishes. I'm > not supposing that U.S. implementation is particularly important or > clever, just hope that IETF and other standards bodies like IEEE will > harmonize on APIs. > > -- > Alison Chaiken alison@she-devel.com > 650-279-5600 http://{she-devel.com, > exerciseforthereader.org} > The intermediary between the head and the hands must be the heart. > -- Thea von Harbou > --485b395e7d3338a52e04dbd7d533 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the shout-out Alison!
=A0
I'm happy= to answer questions about DSRC.

Best Regards,
John=


--
John Kenney, Ph.D.
Sr. Research Ma= nager
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
<= div>Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-66= 44
On Tue, Apr 30, 2013 at 2:02 P= M, Alison Chaiken <alison@she-devel.com> wrote:
Excellent webinar, if difficult to follow and a bit Euroce= ntric:

http= ://automotive.linuxfoundation.org/webinars/watch-webinar-using-open-source-= solutions-for-vtv-vti-communications

My go-to reference for U.S. DSRC and WAVE info is John Kenney of
Toyota's excellent "Dedicated Short-Range
Communications (DSRC) Standards in the United States", =A0Proceedings = of
the IEEE | Vol. 99, No. 7, July 2011. =A0 =A0I received a copy from the
author but will let John (CC'ed) distribute it if he wishes. =A0 =A0I&#= 39;m
not supposing that U.S. implementation is particularly important or
clever, just hope that IETF and other standards bodies like IEEE will
harmonize on APIs.

--
Alison Chaiken =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 alison@she-devel.com
650-279-5600=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://{she-devel.com,
exerciseforth= ereader.org}
The intermediary between the head and the hands must be the heart.
-- Thea von Harbou


=A0
--485b395e7d3338a52e04dbd7d533-- From alison@she-devel.com Sat May 4 10:14:44 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D45721F8C33 for ; Sat, 4 May 2013 10:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.481 X-Spam-Level: X-Spam-Status: No, score=0.481 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43j3J3nVLf5D for ; Sat, 4 May 2013 10:14:43 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id A625021F9663 for ; Sat, 4 May 2013 10:14:42 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id ar20so2905652iec.11 for ; Sat, 04 May 2013 10:14:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=PHgb4SSWYQDDEJGC+OWW3zhYwxy8BTM48YeCeW544kE=; b=GpHsdZXB3pHhrEBsT8P+oGpT6owzfkDzMgk4fO1wnJibKFK0TK1mDTUo3Ndy/PU9nW 0SrbLYoPSZY4MoO/RomJUY3YA1Skr4V31R3oSXfwPwcftP0wBdaJ7N//H/F218LsBPlQ 3/0E6DDQWKNmvKZVWxoGoArbbM2bFifSPDAyW8r8JAlviBLhJ4OtHEh0qZ0Ymx5DKLvZ YmpvJTxskVAENGC+4dF4aG3b9U3v+REGweiKRHBPqtfiPCjerI9RudLYMuNW+Z9wBvr7 Mf/PdSmqnqZ8n+XER+MHb4M5cIN4Nzor3n2MmisY5iZCBgwplptyMSr2jWyj1QFly3vf pUhw== MIME-Version: 1.0 X-Received: by 10.43.148.71 with SMTP id kf7mr5685802icc.42.1367687682124; Sat, 04 May 2013 10:14:42 -0700 (PDT) Received: by 10.42.197.3 with HTTP; Sat, 4 May 2013 10:14:41 -0700 (PDT) Date: Sat, 4 May 2013 10:14:41 -0700 Message-ID: From: Alison Chaiken To: its@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkUd1J9Ac55UHbCgcMi3NxiLXmd/luJzpH/xXwdVUK+a+NS9DBZswN84PnNtMM9by7Wgu9X Subject: Re: [its] novel use case for intra-vehicular wireless X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 17:14:44 -0000 Michael Richardson offers: > It seems to me that distributing 5V/12V is possibly easier than data cables. Every data cable in a car is a custom part that dealers and their distributors must stock. Consider the pain that the parts distribution problem causes smaller companies with limited distribution, and how much of a barrier to entry to new markets the parts problem represents. Tesla, for example, does not plan to have a dealer network. Also, cables have weight, especially copper ones. While wireless in the car initially struck me as crazy, further consideration shows that there are a lot of advantages, particularly for aftermarket devices with long battery life. What zeroconf, lightweight association protocol these devices might use (6LoWPAN?) and whether they would be routable from outside the car are the questions that pertain to IETF's areas of concern. Ethernet has had difficulty making inroads because pulling coax with adequate thermal stability and durability through body panels is slow and expensive. New demonstrations of twisted-pair Ethernet via Broadcom's new BroadR-Reach PHY are slowly prying that door open. User interface studies show that drivers can operate a display with at most 4 segments while driving. Mercedes and BMW reperesentatives in a panel discussion organized by German-American Business Association a year ago said that big consoles in the dash will be displaced by smaller touchscreens dispersed around the cabin in coming model years. > I realize that CAN has done lots in the space of data+power already. CAN is going away, although it will be with us for a long time. CAN is too slow, too hard to interoperate with other buses, and is insecure at OSI level 2 in a way that higher levels can only partly fix. -- Alison Chaiken alison@she-devel.com 650-279-5600 http://{she-devel.com, exerciseforthereader.org} The intermediary between the head and the hands must be the heart. -- Thea von Harbou From buddenbergr@gmail.com Sat May 4 14:52:42 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3830F21F96A1 for ; Sat, 4 May 2013 14:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPwRAMzUOCT9 for ; Sat, 4 May 2013 14:52:40 -0700 (PDT) Received: from mail-da0-x233.google.com (mail-da0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id C11E621F96A0 for ; Sat, 4 May 2013 14:52:40 -0700 (PDT) Received: by mail-da0-f51.google.com with SMTP id h15so1250184dan.10 for ; Sat, 04 May 2013 14:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:x-mailer:mime-version :content-transfer-encoding; bh=IxfgxUHI1UzvTEFj0WPNaez+TBvvor8ArALe8qvxFKw=; b=HDOrJWIqIHYb0Sk8gstH6Xr6+U5vPxETievCEFnrWxkSq/5N6flt8Azs27rxT1Sv6a NBWd7zNR1Pz3oZpjzG8lf0b5NcGs/zoX6UtHvAojBiAatq2zLbV7Pg++WXD+QpIB9UxT dOOOt86lt1JC505T3R4kk/TN6h5KVUfFlR+cYOqGmcXb4vePy9k5uR0SpvE2Sr6s0uAJ 9AzJTWTozZ+ujsDH9PsMYXpFYZRMzR4a5WuZWObCWpVCwLW5mxVcnrFUomKHiW1DIzTt r234P3gLQitbb7rx1P6O1eKz5wMK9IGZoJvkvYzRq8j2oCTqTIwGn/6o1Hu53c80vfZQ iejA== X-Received: by 10.68.136.198 with SMTP id qc6mr14952612pbb.117.1367704360475; Sat, 04 May 2013 14:52:40 -0700 (PDT) Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id sg4sm17155180pbc.7.2013.05.04.14.52.38 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 04 May 2013 14:52:39 -0700 (PDT) Message-ID: <1367704357.2014.102.camel@localhost> From: Rex Buddenberg To: Alison Chaiken Date: Sat, 04 May 2013 14:52:37 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: its@ietf.org Subject: Re: [its] novel use case for intra-vehicular wireless X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 21:52:42 -0000 This requires a reply. Having spent ~40 years or so in the comms business one way or another, one of the things I've learned is never to do with radio what you can do with wireline. There are lots of reasons, but a couple of the enduring ones are: - capacity. The diff is about four orders of magnitude. Or in terms that might make a bit more impact: a radio channel is about 1/10,000 the size attainable in a wired (either LAN or terrestrial-WAN) pipe. - error rate. Converse to the capacity issue, the error rate in radio is about three orders of magnitude greater than wireline. These are physics issues, not standards or engineering ones. Use the radio to reach to mobile. More in line below: On Sat, 2013-05-04 at 10:14 -0700, Alison Chaiken wrote: > Michael Richardson offers: > > It seems to me that distributing 5V/12V is possibly easier than data cables. > > Every data cable in a car is a custom part Which is a good reason to shift to UTP ethernet throughout. Several industries have gone through this custom cable evolution and the end is usually the same. - Navy ships have gone through this and ended up with multimode fiber as the backbone (between compartments, penetrations of watertight bulkheads) and wired ethernet elsewhere. (There's no problem lighting up a compartment with Wi-Fi). - About 15 years ago, the rage was hybrid cables in your house -- a bundle of fiber, coax and UTP put in before the drywall goes up. Nope, not anymore. Run ethernet. (Again, there's no problem with WiFi at the fringe). - PLCs seem to reappear on about a 7 year cycle. Only to get blown away with mainstream internet. Usually ethernet again. - electrical power industry. The legacy SCADA systems were stovepipe top-bottom 15 years ago. Increasingly they're internet style -- the standard SCADA application looks a lot like SNMP. - ... more.... > Also, cables have weight, especially copper > ones. So do it and do it once. There is a tail-dog issue here and know which is which. It's a usual habit in each of these industries to fix upon legacy end systems and try to work from there. Legacy end systems tend to be pretty dumb; they require some computing to finish the data back at the other end of the comms pipe. That usually results in poor modularization which usually results in a marketplace dead end. The point of the internet is that the smarts shift from the center to the edge ... and CPU horsepower remains cheap ... so the end systems get smarter (and more modular). It makes a lot of sense in the information systems design to start with 'routable network' at the foundation ... work from there. > While wireless in the car initially struck me as crazy, No it's not, but keep it in its place. I wouldn't use it for any of the automobile sensor/control functions. But it makes perfect sense to light up a WiFi hotspot so your iPad has something to latch onto. For the WiFi to make sense, you have to get beyond the automobile control discussion to the payload -- what's the four wheels supposed to do? If it's an ambulance, then you want to be able to use the same diagnostic instruments you have in the hospital ICU in the ambulance. > Ethernet has had difficulty making inroads because pulling coax Coax? I haven't seen operational Thicknet or Thinnet in a couple decades now. UTP hit the big time in the late '80s. Building installations with UTP tend to go through a couple phases. One is 'hub per room' distribution which minimizes cabling. But the second stage is to buy a big honkin' hub, stick it in a wiring closet and pull all the cable on the floor into that wiring closet -- lots more cable run, but lots more management/troubleshooting sanity. I don't know how a discussion in an automobile would come out, but we've been here before. > with > adequate thermal stability and durability through body panels is slow > and expensive. New demonstrations of twisted-pair Ethernet via > Broadcom's new BroadR-Reach PHY are slowly prying that door open. There are several flavors of ethernet that may be germane here. All share the same layer 3 interface, MAC, framing and addressing. The only diffs worth haggling are in the cable: - 'normal' ethernet cable usually comes with a 'Cat 5' label on the box. This cable usually has four pairs and the Cat 5 has to do with the number of twists/inch (noise cancellation reasons). Noise on the cable length itself is usually not a problem, the crosstalk issues appear at the hubs (near end crosstalk where 15689 cables are all crammed into the hub cheek-by-jowl). - earlier ethernet (10BaseT) uses two of the four pairs, the others are idle. So some el-cheapo cables only had two pairs in them (patch cords packed in your shiny new laptop, often). - with fast ethernet (100BaseT) at least some implementations used all four pairs. - Power over Ethernet is a trick that will undoubtedly be useful in automobiles -- grab a couple wires in the cable and energize them with 48v DC. The 48v is legacy telco, but the trick should work with 12v automotive too. - fiber Phy is common with ethernet. Often used for campus installations, run between buildings where the runs are >100 meters. Both the UTP and fiber implementations are physically point-point between hub and end system. This may not be what you want in a car. So it might indeed be worthwhile resurrecting a coax implementation and push the shared use back out onto the cable. I know of no company actually doing that, though. > > User interface studies show that drivers can operate a display with at > most 4 segments while driving. User interface? What to do with LAN? (I do agree with human-factors discussions on minimizing driver distractions, but that's a different discussion) > > I realize that CAN has done lots in the space of data+power already. > > CAN is going away, although it will be with us for a long time. CAN > is too slow, too hard to interoperate with other buses, and is > insecure at OSI level 2 in a way that higher levels can only partly > fix. Is CAN a routable network? If its not, then you'll need to build some layer 7 gateways. Probably easier to phase it out. Loop back to the other-industry evolution notes above. > Does anyone in [its] remember the SAE Ring Bus standardization effort? Late '80s. Was definitely intended for automotive use; eclipsed by FDDI (better technical solution all 'round and chipsets were actually being built). But why did the effort not pan out? From dhc2@dcrocker.net Sat May 4 17:04:21 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C36C21F8CE2 for ; Sat, 4 May 2013 17:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJHMB-mnTYrz for ; Sat, 4 May 2013 17:04:16 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9297B21F8FBE for ; Sat, 4 May 2013 17:04:15 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r45047Ar024129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 4 May 2013 17:04:13 -0700 Message-ID: <5185A1E9.9010205@dcrocker.net> Date: Sat, 04 May 2013 17:03:53 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Rex Buddenberg References: <1367704357.2014.102.camel@localhost> In-Reply-To: <1367704357.2014.102.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 04 May 2013 17:04:14 -0700 (PDT) Cc: Alison Chaiken , its@ietf.org Subject: Re: [its] novel use case for intra-vehicular wireless X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 00:04:21 -0000 On 5/4/2013 2:52 PM, Rex Buddenberg wrote: > This requires a reply. > > Having spent ~40 years or so in the comms business one way or another, > one of the things I've learned is never to do with radio what you can do > with wireline. There are lots of reasons, but a couple of the enduring > ones are: Yes, but... System design, integration and operations issues can create a mixture of tradeoffs that make one or the other choice of wire or wireless far better. We used to get television only over the air and telephone only over wires. Today, dominant usage has swapped these choices. I'm not trying to negate the factors of capacity and error rate that you cite, but merely to observe that they are but two of a larger set. Their importance in the mixture diminishes, for example as capacity demand reduces and upper-layer recovery mechanisms make errors (of certain types) less relevant. I'm also not taking a position on the particular choices in this thread. To me what is important is how those choices are evaluated. >> Also, cables have weight, especially copper >> ones. > > So do it and do it once. I did that with Cat 5 in my house, some years aback, and now can't get reliable Gigabit networking in my house. And yes, this has had a noticeable effect when trying to access my storage/media server... >> User interface studies show that drivers can operate a display with at >> most 4 segments while driving. > > User interface? What to do with LAN? The ability to physically distribute functions easily, but still have them interact well, could reasonably prompt having other design issues, such as UI human processing limits, dominate the choices. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mcr@sandelman.ca Mon May 6 06:09:45 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59BE21F905B for ; Mon, 6 May 2013 06:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZ8CYnXAd-R9 for ; Mon, 6 May 2013 06:09:36 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3FF21F9051 for ; Mon, 6 May 2013 06:09:36 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 79D7C2016E; Mon, 6 May 2013 09:20:46 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A5C1363A7C; Mon, 6 May 2013 09:08:31 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8BF32639DF; Mon, 6 May 2013 09:08:31 -0400 (EDT) From: Michael Richardson To: Alison Chaiken In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: its@ietf.org Subject: Re: [its] novel use case for intra-vehicular wireless X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 13:09:46 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Alison" =3D=3D Alison Chaiken writes: >> It seems to me that distributing 5V/12V is possibly easier than >> data cables. Alison> Every data cable in a car is a custom part that dealers and Alison> their distributors must stock. Consider the pain that the Alison> parts distribution problem causes smaller companies with Alison> limited distribution, and how much of a barrier to entry to Alison> new markets the parts problem represents. Tesla, for It seems that you are agreeing with me that data cables are hard, but=20 are you also saying that a single power lead (assuming chassis ground) is also hard? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUYerT4qHRg3pndX9AQItcQP/SHNgZbbkFrtuIyVxqNZgh2eRlIfeDbwr 8NQiDpgvH0/QRgRwwZLrJKGct/TqCeept/WSYcLm9IhOdxy/Z2SCch/kMIA1FimG PIwbS+LNlbi8MjgV6CYVueYZOL4i06mVsH33XP8edQjOJdXosZULFCVn976WYbMX cV3HWUbAibk= =uVSU -----END PGP SIGNATURE----- --=-=-=-- From alison@she-devel.com Sun May 12 13:32:37 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F97F21F8ADF for ; Sun, 12 May 2013 13:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wNYw+dQPEnt for ; Sun, 12 May 2013 13:32:36 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id F2DDB21F885A for ; Sun, 12 May 2013 13:32:35 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id at1so11032049iec.21 for ; Sun, 12 May 2013 13:32:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=+BzwLxCrArpU1hUSW9OiKuM+91TS0UAKX7Xr07HZoIM=; b=O5Oq0aK+8hWnE8ELrmSO6UmtsVM0P2Di63aOjkwGC+vXdbw8qlSvKjfWaaSxLGX2jh IIchLEq4FKmQ/oDPcIvfl5SDb6CjVQ3ayjgaYJe21bUOmOcW+fIs/3rv8q5wnmSTZyV5 PloDsioEiYkbEu/FDqMsO5UGv0mk6cN8ZtNLc55LSX7jZ654V8dKgFeFQnE6lCjj5+OA XZGa9yZjTZSEfkhTsuF6Mn0OGUTzP+J/PJDYS0DDQhMEF3tJW8jol+vxZk+wmMyFgWFs xUqUZ/Sv/Gr723JAorxr2m0yFEWzkDVudGHmR+8+PvZvHqSmJiX7mxGSDacWhLYCAhPk 7vPQ== MIME-Version: 1.0 X-Received: by 10.50.3.38 with SMTP id 6mr8213012igz.44.1368390755224; Sun, 12 May 2013 13:32:35 -0700 (PDT) Received: by 10.42.39.7 with HTTP; Sun, 12 May 2013 13:32:35 -0700 (PDT) Date: Sun, 12 May 2013 13:32:35 -0700 Message-ID: From: Alison Chaiken To: its@ietf.org Content-Type: multipart/alternative; boundary=089e013c684ee125b104dc8b4c64 X-Gm-Message-State: ALoCoQnoOyThXCX/901SXvdlsL3fM82F+USpn24K55ZGfUx0jcrTXLOCvNMv98QM6AcT0DdWsycm Subject: Re: [its] novel use case for intra-vehicular wireless X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 20:32:37 -0000 --089e013c684ee125b104dc8b4c64 Content-Type: text/plain; charset=ISO-8859-1 I apologize for taking so long to answer these thoughtful messages: I have simply been especially busy. Rex Buddenberg offers: Having spent ~40 years or so in the comms business one way or another, one of the things I've learned is never to do with radio what you can do with wireline. There are lots of reasons, but a couple of the enduring ones are: - capacity. . . . - error rate. . . . Rex, please note that the signals that Elo Touch Solutions suggested sending over radio were button presses, or perhaps arrow keys on 4-segment panels. Data rate and error tolerance are hardly challenging in those circumstances. In these messages I have been trying to summarize what experienced automotive designers tell me, and I have only been infrequently offering my own opinion. I was surprised, as I noted, to hear Elo advocate for wireless in this application, as I indicated. Rex added: shift to UTP ethernet throughout. Henry Ptasinski asks: Why (and when) were they trying to use coax? Too much electrical noise from the engine? Correct. In fact, the first automotive transceivers for UTP are starting to appear in cars just now via the Broadcom BroadR-Reach: http://www.eetimes.com/design/automotive-design/4410090/Automotive-Ethernet--Evolution-in-the-fast-lane Automotive environments are electrically noisy, with large temperature swings and lots of vibration and dirt. Most datacenter cabling solutions are simply inapplicable. Rex: Is CAN a routable network? CAN has no notion of an address, so no, to say the least, but that's a whole other discussion and far too off-topic. The industry wants to deprecate CAN, but it's going to take a while. Rex: It's a usual habit in each of these industries to fix upon legacy end systems and try to work from there. Legacy end systems tend to be pretty dumb No one disagrees, but if we don't want to end up with extremely expensive next-generation cars full of brand new microcontrollers with little field testing, we need to be patient! Henry: Multiple displays will only be an improvement if the information is well organized and presented. The multiple-display idea was presented by Mercedes and BMW at a German-American Business Association panel discussion I attended about a year ago. Mercedes and BMW based the idea of disaggregation of large console touch panels on data harvested from regular drivers who opted in to a monitoring program. They found that the drivers did not much use large touch panels and continued to prefer hard buttons when they offered the same function. These companies suggested that four-segment buttons are the most complex ones drivers can use without taking their eyes off the road. There is some notion that offering (for example) up-down-right-left arrow panels in the top of one or more rotary mechanical knobs is more usable than offering that functionality along with many others on a large touchscreen. Apparently currently shipping cars from the German automakers are trying this approach. Rex: User interface? What to do with LAN? I am trying to enumerate how UI design may dictate what hosts appear on an automotive intranet. Michael Richardson asks: It seems that you are agreeing with me that data cables are hard, but are you also saying that a single power lead (assuming chassis ground) is also hard? I'm not saying that. I work on automotive Linux kernel, not door-panel design, so please take my comments about distributed power and signals in that light! I would like to encourage a dialog among the various stakeholders so that best practices propagate into the automotive industry but am unable to offer an informed opinion on many questions you might ask. -- Alison Chaiken alison@she-devel.com 650-279-5600 http://{she-devel.com, exerciseforthereader.org} The intermediary between the head and the hands must be the heart. -- Thea von Harbou --089e013c684ee125b104dc8b4c64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I apologize for taking so long to answer these thoughtful messages: I have = simply been especially busy.

Rex Buddenberg offers:
Having spent ~40 years or so in the comms business one w= ay or another, one of the things I've learned is never to do with radio= what you can do with wireline. =A0There are lots of reasons, but a couple = of the enduring ones are:
- capacity. . . .
- error rate. . . .<= br>

Rex, please note that the signals that Elo Touch Solutio= ns suggested sending over radio were button presses, or perhaps arrow keys = on 4-segment panels. =A0 =A0Data rate and error tolerance are hardly challe= nging in those circumstances. =A0

In these messages I have been trying to summarize what experienced auto= motive designers tell me, and I have only been infrequently offering my own= opinion. =A0 I was surprised, as I noted, to hear Elo advocate for wireles= s in this application, as I indicated.

Rex added:
shift to UTP ethernet thr= oughout.

Henry Ptasinski asks:
Why (and when) were they trying to use coax? =A0Too much electrical noi= se from the engine?

Correct. =A0In fact, the first automotive transceivers for UTP ar= e starting to appear in cars just now via the Broadcom BroadR-Reach:
http://www.eetimes.com/design/aut= omotive-design/4410090/Automotive-Ethernet--Evolution-in-the-fast-lane<= br>
Automotive environments are electrically noisy, with large temperature = swings and lots of vibration and dirt. =A0 Most datacenter cabling solution= s are simply inapplicable. =A0 =A0

Rex:
Is CAN a routable network?

CAN has no notion of an address, = so no, to say the least, but that's a whole other discussion and far to= o off-topic. =A0 =A0The industry wants to deprecate CAN, but it's going= to take a while.

Rex:
It's a usual habit in each= of these industries to fix upon legacy end=A0 systems and try to work from= there. Legacy end systems tend to be=A0 pretty dumb

No one di= sagrees, but if we don't want to end up with extremely expensive next-g= eneration cars full of brand new microcontrollers with little field testing= , we need to be patient!

Henry:
Multiple displays will only = be an improvement if the information is=A0 well organized and presented.

The multiple-display idea was presented by Mercedes and BMW at a= German-American Business Association panel discussion I attended about a y= ear ago. =A0 Mercedes and BMW based the idea of disaggregation of large con= sole touch panels on data harvested from regular drivers who opted in to a = monitoring program. =A0 They found that the drivers did not much use large = touch panels and continued to prefer hard buttons when they offered the sam= e function. =A0 These companies suggested that four-segment buttons are the= most complex ones drivers can use without taking their eyes off the road. = =A0 =A0 There is some notion that offering (for example) up-down-right-left= arrow panels in the top of one or more rotary mechanical knobs is more usa= ble than offering that functionality along with many others on a large touc= hscreen. =A0 Apparently currently shipping cars from the German automakers = are trying this approach. =A0

Rex:
User interface? =A0What to do = with LAN?

I am trying to enumerate how UI design may dictate w= hat hosts appear on an automotive intranet.

Michael Richardson asks:=
It seems that you are agreeing with me tha= t data cables are hard, but are you also saying that a single power lead (a= ssuming chassis ground) is also hard?

I'm not saying that.= =A0 =A0I work on automotive Linux kernel, not door-panel design, so please= take my comments about distributed power and signals in that light! =A0 I = would like to encourage a dialog among the various stakeholders so that bes= t practices propagate into the automotive industry but am unable to offer a= n informed opinion on many questions you might ask.

--
Alison Chaiken =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 alison@she-devel.com
650= -279-5600 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://{she-devel.com, exerciseforthereader.org}
The intermediary between the head and the hands must be the heart. =A0 =A0-= - Thea von Harbou
--089e013c684ee125b104dc8b4c64-- From alexandru.petrescu@gmail.com Thu May 16 11:10:46 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627DF21F914C for ; Thu, 16 May 2013 11:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.334 X-Spam-Level: *** X-Spam-Status: No, score=3.334 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAcu7DYTJjMe for ; Thu, 16 May 2013 11:10:42 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id C0B4F21F90D2 for ; Thu, 16 May 2013 11:10:37 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 340C49402C2 for ; Thu, 16 May 2013 20:10:30 +0200 (CEST) Message-ID: <51952115.9090002@gmail.com> Date: Thu, 16 May 2013 20:10:29 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: its@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130516-0, 16/05/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [its] novel use case for intra-vehicular wireless X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 18:10:46 -0000 Alison, (sorry for my late reply. We have had a private exchange about open source licensing, and about new 802.11p drivers, which subsequently occupied me.) I have looked at the slide that is cited below, about how buttons on various consoles on infotainment display, on doors, over-head, control various things in the cabin (inside the car, 'habitacle', fr.). Indeed in next generation vehicles there are many kinds of such buttons on consoles. Each such console is a touch-screen display. More than screens there are other kinds surfaces as well. Moreover, touching a screen is just one manner of acting on an interface. Other means include but are not limited to gesture recognition (similar to gaming consoles), face recognition, temperature scanning, etc. All these must be connected together in the vehicle. Inside a vehicle the connection between these devices may be zigbee, bluetooth, wifi, Ethernet AVB or any other wired or wireless IP-friendly Local Area Network. There are more than just one IP subnets in the vehicle. This is not futuristic, it is there already. The problem I have is how to translate this requirement into a work item that can be performed in an Working Group at IETF. The one direction I can see is that there exist numerous IP devices in the vehicle, thus there is a need of IPv6 (as opposed to IPv4). But from this, what could we do at IETF about this numerous buttons and intra-vehicular wireless? Should we describe a scenario of use of wireless IP inside vehicle? What could be a working item? What do you think? Alex Le 28/04/2013 19:40, Alison Chaiken a écrit : > Slide 9 of this set from Elo Touch Solutions shows an "Automotive > Interior Touchscape": > > http://ewh.ieee.org/r6/scv/ce/meetings/Elo%20for%20Automotive%20APR%202013.pdf > > The presenter believes, with good reason, that today's large > console-mounted touch panels will disaggregate into many soft > buttons used for applications like back-seat media control. He > said that such tiny dispersed touch panels may operate via Zigbee, > although I guess they could be active RFID as well. The idea that > cars will have far fewer cables and wires and more wireless is > pretty fascinating. That may save on assembly costs although the > question of battery-powering so many small devices is worrisome. > Perhaps energy harvesting is a real solution for vehicles? > > Anyhow, I don't mean to drag the group off-topic, but the concept of > the wireless control of media playing is generally intriguing. > I'm convinced that in some developing nations, the car will be the > main "PC" for the household, the source of email, music, movie > streaming for the whole house when parked. Residents of such > nations will need cars, and even low-end cars will start to include > these features. There has been a presumption that cellular handsets > are the developing world PCs, but that strikes me as unclear. If > the car becomes the media center, then you might want to control the > music playing from your vehicle from another room by using IPV6 to > address the car's functions directly. > From alexandru.petrescu@gmail.com Thu May 16 11:14:51 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C64911E811B for ; Thu, 16 May 2013 11:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.241 X-Spam-Level: *** X-Spam-Status: No, score=3.241 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnA1DQv4YtQD for ; Thu, 16 May 2013 11:14:47 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id E524C21F9223 for ; Thu, 16 May 2013 11:14:45 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 186C09400F4 for ; Thu, 16 May 2013 20:14:39 +0200 (CEST) Message-ID: <5195220F.8010700@gmail.com> Date: Thu, 16 May 2013 20:14:39 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: its@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130516-0, 16/05/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [its] ITS-IETF and GENIVI X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 18:14:51 -0000 Alison, I met Intel about IVI at some point. Since then we use extensively an older IVI platform for demonstrating integration with smartphones in a vehicle, and even the use of OpenFlow. Yes, please make contact with these groups and try to formalize relationship with IETF. Ask GENIVI and Tizen whether their linux implementation includes direct IPv6 vehicle-to-vehicle communications. (or even V2V2I). Alex Le 30/04/2013 20:13, Alison Chaiken a écrit : > My employer is part of the GENIVI automotive industry consortium > that is promoting Linux standards. You can view some of GENIVI's > existing efforts here: > > http://projects.genivi.org/ > > GENIVI has something like 170 members, including most major car > manufacturers and represents, alongside Tizen-IVI, the most > important effort to standardize automotive software. To date, > GENIVI's networking discussions have mostly centered on car intranets > with AUTOSAR and EthernetAVB and the like, but inevitably, as GENIVI > partners with W3C, discussions will turn to V2X as well. I hope > that GENIVI and Tizen-IVI will cooperate with ITS-IETF in the > future. Is anyone besides me from these projects reading this email > list? > > My own participation in the GENIVI Networking Expert Group has been > limited by the fact that the meetings are held in the middle of the > night in my timezone. It would be great if someone who lives in > Central European Time would participate in the meetings! > > Please let me know if ITS-IETF would like to make contact with these > groups as it formalizes its own status within IETF. No one from > GENIVI or Tizen has deputized me to inquire; I just think it's a > good idea! > > Best wishes, Alison > From alexandru.petrescu@gmail.com Thu May 16 11:17:23 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B7111E8129 for ; Thu, 16 May 2013 11:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.987 X-Spam-Level: * X-Spam-Status: No, score=1.987 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGVbshw9Haud for ; Thu, 16 May 2013 11:17:19 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 25BFA11E813F for ; Thu, 16 May 2013 11:17:17 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id B4B0D940055; Thu, 16 May 2013 20:17:09 +0200 (CEST) Message-ID: <519522A4.9020601@gmail.com> Date: Thu, 16 May 2013 20:17:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Chaiken, Alison" References: <60BA5429A0E1584BA3633194F6F993B5023252D3@NA-MBX-03.mgc.mentorg.com> In-Reply-To: <60BA5429A0E1584BA3633194F6F993B5023252D3@NA-MBX-03.mgc.mentorg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130516-0, 16/05/2013), Outbound message X-Antivirus-Status: Clean Cc: "eg-nw@mail.genivi.org" , "sameo@linux.intel.com" , "its@ietf.org" , "jkenney@us.toyota-itc.com" , Ravi Puvvala , "automotive-announce@lists.linuxfoundation.org" , "Marcel.Holtmann@intel.com" Subject: Re: [its] proposed Linux Plumbers Conference Automotive Networking Discussion (RE: In Case You Missed It - Automotive Linux Webinar Recording) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 18:17:23 -0000 This is a good idea. In addition, I am interested to meet linux 'plumbers' about ITS at IETF in Berlin - end of July 2013. Alex Le 02/05/2013 20:45, Chaiken, Alison a écrit : > Let's follow-up Konstantin Khait's fine webinar on Automotive > Wireless by organizing a session to discuss open-source > implementations of 802.11p drivers (DSRC) and IEEE-1609 (WAVE) stack > at Linux Plumbers Conference in New Orleans in September, > > http://wiki.linuxplumbersconf.org/2013:automotive > > I have already discussed the idea with Rudi Streif of Linux > Foundation and Daniel Wagner of BMW, the track conveners, and their > feedback is positive. A list of potential additional attendees is > CC'ed. Let's get all the interested parties together to have a > discussion about moving ITS wireless forward in Linux. > > -- Alison Chaiken (void *) engineer Mentor Embedded Software Division > GMT+8 alison_chaiken@mentor.com > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From alexandru.petrescu@gmail.com Thu May 16 11:22:28 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884C011E8105 for ; Thu, 16 May 2013 11:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.777 X-Spam-Level: ** X-Spam-Status: No, score=2.777 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7emjP0bCRUi for ; Thu, 16 May 2013 11:22:24 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id C85B921F924A for ; Thu, 16 May 2013 11:22:21 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 3BD9094014D for ; Thu, 16 May 2013 20:22:16 +0200 (CEST) Message-ID: <519523D7.5090307@gmail.com> Date: Thu, 16 May 2013 20:22:15 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: its@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130516-0, 16/05/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [its] an authoritative article on "IP and Ethernet in motor vehicles" in _EE Times_ X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 18:22:28 -0000 This is a good article. Currently, my advice for Ethernet deployers inside vehicle ranges between two extremes: - deploy the most recent desktop Ethernet technology - 10Gb/s(?); this will address all bandwidth qos and reservation problems that may occur. When bandwidth is enough, there is no lost message. - deploy only qos-specific ethernet.. These are two different directions. But the deployers very easily go ahead and test what's the easiest and most convenient to do. Alex Le 02/05/2013 22:39, Alison Chaiken a écrit : > http://www.eetimes.com/General/PrintView/4412977 > From alexandru.petrescu@gmail.com Thu May 16 11:23:27 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AC511E8124 for ; Thu, 16 May 2013 11:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.87 X-Spam-Level: * X-Spam-Status: No, score=1.87 tagged_above=-999 required=5 tests=[AWL=0.722, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaVaAoPhRHCb for ; Thu, 16 May 2013 11:23:24 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC6621F907E for ; Thu, 16 May 2013 11:23:21 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id D0B69940185 for ; Thu, 16 May 2013 20:23:16 +0200 (CEST) Message-ID: <51952414.1050500@gmail.com> Date: Thu, 16 May 2013 20:23:16 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: its@ietf.org References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <511F7968.7090309@gmail.com> <5177C6BA.6020805@gmail.com> <85C635C4D32378499484B2C61BD297A419E9993E@GSukMHDDCembx02.service.hitachi.net> In-Reply-To: <85C635C4D32378499484B2C61BD297A419E9993E@GSukMHDDCembx02.service.hitachi.net> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130516-0, 16/05/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [its] suppliers of 802.11p-over-ITS-G5; 802.11s-over-5875-5905MHz X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 18:23:28 -0000 Yes, thank you. The list is now: RENESAS ELECTRONICS NEC NXP/Cohda Wireless Cisco/Cohda Wireless Denso Delphi Savari Kapsch Siemens ITRI AutoTalks Commsignia Yours, Alex Le 03/05/2013 18:32, Lenardi, Massimiliano a écrit : > Dear All, > please also add RENESAS ELECTRONICS to the list below of potential suppliers of 11p/DSRC enabled radio devices. > Best, > - > Max > > > -----Original Message----- > From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: 24 April 2013 13:49 > To: its@ietf.org > Subject: Re: [its] suppliers of 802.11p-over-ITS-G5; 802.11s-over-5875-5905MHz > > Recently I discovered that in addition to the posted list there is also Commsignia as a manufacturer of 802.11p compatible OBU and RSU. The list is now: > > NEC > NXP/Cohda Wireless > Cisco/Cohda Wireless > Denso > Delphi > Savari > Kapsch > Siemens > ITRI > AutoTalks > Commsignia > > Yours, > > Alex > > Le 16/02/2013 13:19, Alexandru Petrescu a écrit : >> Le 11/02/2013 14:50, Dowdell, John a écrit : >>> Alex >>> >>> Is anyone making 802.11p radios commercially at reasonable cost? The >>> few I have seen seem to be very expensive (few k$) and there appears >>> to be little support in Linux. >> >> John, >> >> A person was kind enough to gather in one place information which is >> otherwise sparsely but publicly available; this information is about >> suppliers of 802.11p-over-ITS-G5 frequencies (5875-5905MHz, >> 5855-5875MHz, 5470-5725MHz; caveat - only some are allowed in some >> countries, check the local regulator before turning these on). >> >> NEC >> NXP/Cohda Wireless >> Cisco/Cohda Wireless >> Denso >> Delphi >> Savari >> Kapsch >> Siemens >> ITRI >> AutoTalks >> >> I have some experience with ITRI equipment. In their offer there is a >> full-blown RSU, for around 1500EUR. This is for a RSU hardened box >> for outdoors, powerpc, GPS-enabled, 2x 802.11p interfaces, Ethernet >> with PoE, USB, and linux 2.6. Among these, it is the software which >> is expensive; this includes Atheros driver modifications, new kernel >> modules for "BTP" (Base Transmission Protocol?), 'geonetworking', >> 'wave'. >> >> OTher than a full-blown RSU, one could acquire also ITRI individual >> '802.11p' miniPCI cards which are in the order of couple hundreds of euros. >> >> This is not a commercial advertisement. Technically speaking this >> means many things for designing protocols. For example: >> >> It means it is easily possible to run linux with IPv6 over a 'wave0' >> interface. Just turn it on, watch the IPv6 link-local address, echo >> the frequency value and ping. (no need to set ESSID, nor security). >> >> In addition to the Ethernet interfaces, the RSU has _2_ 802.11p >> different interfaces, and one Ethernet. Not just two antennas, but >> two interfaces (ifconfig 'wave0' and 'wave1'). This means one doesn't >> need to 'relay' packets and that one needs to 'route' packets, in the >> traditional sense of 'routing'. (compare this for example to RPL >> context where a sensor has a _single_ interface and there is no >> routing, but 'relaying'). >> >> Also this outdoors RSU has 1 GPS antenna. This means that >> geonetworking does not work if one tries to use this indoors in a lab >> where GPS signal does not reach. (unless one installs a GPS 'repeater' >> - easy to do but check with regulator in country, or use a GPS >> 'replayer' software to play pre-recorded NMEA sentences on /dev/tty). >> >> Note also it is strange to design an RSU Road Side Unit - designed to >> be fixed with respect to Earth, and put a GPS interface on it. It >> would have been easier to just record the GPS coordinates once and set >> them in a file for as long as that RSU stays there. I consider it as >> an extra, but cheaper RSU without GPS should be possible. >> >>> 802.11s on the other hand is available on standard Wi-Fi dongles >>> (from $15) and drivers are already available in Linux. Is it correct >>> that 802.11p is mandated for ITS in some regions? >> >> I doubt 802.11p be mandated for ITS. >> >> I think the regulator mandates the application which could be used on >> some frequencies. >> >> Where I live, the regulator mandates the use of vehicular 'safety' >> applications at 5875-5905MHz. The technical 'conditions' are referred >> by the regulator to ETSI documents (the regulator is not ETSI, but >> often implements what ETSI wants, but not always). I doubt the >> regulator mandates 'geonetworking' for this band. >> >> I doubt 'IP' could be qualified as 'safety'. >> >> Hence I think 802.11s _could_ be used on the range 5875-5905MHz, as >> long as it does not transport IP. >> >> 802.11p has some features which could qualify as 'safety'. For >> example, it has some MAC-layer messages for 'emergency', and with >> timestamps (absent from .11 non-p standard), which don't transport IP. >> >> 'geonetworking' also has some features which could qualify as 'safety'. >> I just don't remember which. >> >> What features in 802.11s would qualify as 'safety'? >> >> Alex >> >>> >>> John >>> >>> -----Original Message----- From: its-bounces@ietf.org >>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: >>> 31 January 2013 15:17 To: its@ietf.org Subject: Re: [its] IP over >>> 802.11p >>> >>> Le 31/01/2013 14:47, Thierry Ernst a écrit : >>>> >>>> Well, we do actually run IPv6 over 11p (with or without >>>> GeoNetworking), so I don't see what kind of issues there might be >>>> ... >>> >>> I have some clarification questions about EtherType and 802.11p and >>> GeoNetworking. >>> >>> I guess when you run IPv6 over 11p with GeoNetworking, the Ethernet >>> header uses EtherType soon-to-be-0x8947, whereas when you run IPv6 >>> over 11p without GeoNetworking, the Ethernet header uses EtherType >>> 0x86DD. This is just a supposition, I don't know how you run it. >>> >>> Also, if I run IPv4 over 11p with GeoNetworking - should I use >>> EtherType soon-to-be-0x8947? Or other? I suppose that if I run IPv4 >>> over 11p without GeoNetworking I should use EtherType 0x0800, and if >>> it's ARP over 802.11p still without GeoNetworking then I should use >>> EtherType 0x0806. >>> >>> (the letter we've seen recently is not clear whether that allocation >>> is for GeoNetworking, for IP-over-802.11p, for ETSI ITS, for >>> GeoNetworking for IPv6, for GeoNetworking for IPv4, etc. It is not >>> clear either whether GeoNetworking supports IPv4 or not, or under >>> what form). >>> >>> I also have some questions about the relationship between the nature >>> of some 802.11p links (no ESSID, absence of link-layer security - as >>> opposed to WiFi which has ESSID and link-layer security) and IP. >>> >>> For example - will V2V prefix exchange using Router Advertisements >>> work easier on 802.11p links (easier than on WiFi), because the ESSID >>> does not need to be discovered, the ad-hoc network does not need to >>> be formed - suffices it to send packets on a certain channel. >>> >>> (in a V2V draft one seems to say that the presence of Access Point is >>> absolutely necessary in order for 802.11p to work; but in our >>> experimentations this is not the case - it is possible to establish >>> direct vehicle-to-vehicle IP-over-802.11p communications without the >>> presence of a fixed 802.11p Access Point). >>> >>> For another example - will IP prefer that the 802.11p channel in >>> France be 176, 178 or 180? (with WiFi, IP does not care because it >>> can work on any of the 11 channels equally well, but with 802.11p >>> each of these three channels seem to be reserved for "Services", >>> "Control" and "Services"). >>> >>> For another example - is all the security on these links entirely >>> relaying on IP layer security (IPsec, SeND, EAP, PANA)? >>> >>> I think finding consensus on some of these questions could lead to >>> interoperability. >>> >>> Alex >>> >>>> >>>> Regards, Thierry >>>> >>>> >>>> >>>> On 31/01/13 13:55, Alexandru Petrescu wrote: >>>>> Given current discussions, I think it may be worth considering a >>>>> work item about how to run IP over 802.11p. >>>>> >>>>> One of the things to say would be whether or not this is IPv6 only >>>>> or IPv4 also. >>>>> >>>>> This would say how this would work _without_ GeoNetworking. >>>>> >>>>> It would agree on the EtherType and/or whether there are new ones, >>>>> several or only one, or reusing existing EtherTypes. >>>>> >>>>> It could be as simple as to say that IP works over 802.11p just as >>>>> it works over 802.11b - no modifications. >>>>> >>>>> What do you think? >>>>> >>>>> Alex >>>>> >>>>> Le 30/01/2013 11:10, Alexandru Petrescu a écrit : >>>>>> Le 30/01/2013 11:04, Romascanu, Dan (Dan) a écrit : >>>>>>> Hi Alexandru, >>>>>>> >>>>>>> IEEE talk only hexa in their Ethertype files. >>>>>> >>>>>> I tend to agree that #8947 is a hexadecimal notation also because >>>>>> the sharp sign preceding it, and because if it were decimal it >>>>>> would convert to 22F3 which is already reserved for trill. >>>>>> >>>>>> I just watend to make sure. >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- From: its-bounces@ietf.org >>>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>>>>>> Sent: Wednesday, January 30, 2013 12:00 PM To: >>>>>>>> its@ietf.org Subject: Re: [its] What do we need to make ITS WG >>>>>>>> go forward? - EtherType for ITS >>>>>>>> >>>>>>>> Hello Dan, >>>>>>>> >>>>>>>> Thank you for the email. >>>>>>>> >>>>>>>> I think we definitely need a good interface with IEEE about >>>>>>>> this. >>>>>>>> >>>>>>>> Maybe you could ask them whether this number is hexa or decimal, >>>>>>>> so we know what to put in implementation (e.g. >>>>>>>> wireshark packet analyzers, and 802.11p/etsi-its >>>>>>>> implementations). >>>>>>>> >>>>>>>> Also, I am interested to learn whether this deserves being >>>>>>>> reserved at IANA. >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>> Le 30/01/2013 10:49, Romascanu, Dan (Dan) a écrit : >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> The documents that you are referring (on the ETSI >>>>>>>>> server) are not freely accessible. A password is required, and >>>>>>>>> probably only ETSI members have the access information. >>>>>>>>> >>>>>>>>> The responsibility for assigning EtherType values is with the >>>>>>>>> IEEE Registration Authority. They maintain a public list >>>>>>>>> (updated daily) at >>>>>>>>> http://standards.ieee.org/develop/regauth/ethertype/eth.txt >>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> and according to this list the value 8947 is not allocated. >>>>>>>>> Now, the public listing information for EtherTypes bears a >>>>>>>>> disclaimer that says >>>>>>>>> >>>>>>>>> * This is a partial listing of all assigned EtherType Fields. >>>>>>>>> Not >>>>>>>> all >>>>>>>>> recipients wish to publish their assignment at this time. >>>>>>>>> >>>>>>>>> Did ETSI require for this information not to be published? It >>>>>>>>> does not look useful if they want to encourage interoperability >>>>>>>>> >>>>>>>>> Value 0707 mentioned in the thread is not allocated either. >>>>>>>>> >>>>>>>>> Let me know if I can help (as IETF liaison to the IEEE-SA). >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> *From:*its-bounces@ietf.org >>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of *Thierry Ernst >>>>>>>>> *Sent:* Wednesday, January 30, 2013 11:11 AM *To:* its@ietf.org >>>>>>>>> *Subject:* Re: [its] What do we need to make ITS WG go forward? >>>>>>>>> - EtherType for ITS >>>>>>>>> >>>>>>>>> >>>>>>>>> Alex, >>>>>>>>> >>>>>>>>> IEEE have assigned Ethernet Type Field number #8947 for ITS use >>>>>>>>> (ETSI TC ITS's GeoNetworking). Check the following document >>>>>>>>> available on the ETSI server: >>>>>>>>> >>>>>>>>> ITS(13)000020 >>>>>>>>> >>>>>>>> 2900002 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> 0_Ethernet_Type_Field_number_for_GeoNetworking.pdf> >>>>>>>>> Ethernet Type Field number for GeoNetworking >>>>>>>>> http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS(13)000 >>>>>>>>> 020_Eth >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> ernet_Type_Field_number_for_GeoNetworking.pdf >>>>>>>>> >>>>>>>>> Regards, Thierry. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 28/01/13 14:28, Alexandru Petrescu wrote: >>>>>>>>> >>>>>>>>> Le 28/01/2013 14:16, Joe Klein a écrit : >>>>>>>>> >>>>>>>>> I really dislike the fact that ISO is charging for the ISO >>>>>>>>> 21217 - Architecture & ISO 21210 - IPv6 Networking. >>>>>>>>> >>>>>>>>> Does this make it any better? Safer? Should ISO now have >>>>>>>>> cybersecurity and safety liability if the specification leads >>>>>>>>> to deaths and damage to property? >>>>>>>>> >>>>>>>>> >>>>>>>>> Does it make any better interoperable as well? >>>>>>>>> >>>>>>>>> EtherType 0x0707 described in ITS documents, implemented, but >>>>>>>>> not specified by IEEE nor reserved at IANA - does not make it >>>>>>>>> interoperable. >>>>>>>>> >>>>>>>>> One wouldn't think that this 0x0707 ethertype be reserved by >>>>>>>> somebody >>>>>>>>> who is not IANA nor IEEE? >>>>>>>>> >>>>>>>>> (see a good example of interoperability: IPv6 0x86dd ethertype >>>>>>>>> is reserved at IEEE and at IANA >>>>>>>>> >>>>>>>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbe >>>>>>>>> rs.xml) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> Alex >>>>>>>>> >>>>>>>>> Or should these standards remain in >>>>>>>>> >>>>>>>>> the public domain, for researches to review and validate? >>>>>>>>> >>>>>>>>> Just my 2 cents. >>>>>>>>> >>>>>>>>> Joe >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Jan 28, 2013 at 6:31 AM, Thierry Ernst >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Dear all, >>>>>>>>> >>>>>>>>> At this stage, I don't think a new working group is needed. >>>>>>>>> First, it would need a charter, and support from the industry. >>>>>>>>> But more importantly, IETF WGs are not usually sector-driven, >>>>>>>>> so it means the different issues pertaining to ITS should be >>>>>>>>> brought to >>>>>>>> VARIOUS >>>>>>>>> existing WGs, and a WG should only be created if there is an >>>>>>>>> important issue for which there is no existing WG that could >>>>>>>>> work on it. >>>>>>>>> >>>>>>>>> This said, as mentioned earlier, ITS is not only about >>>>>>>>> vehicular communications, though the issues listed by Alexandru >>>>>>>>> below mostly consider vehicular communications. >>>>>>>>> >>>>>>>>> What ITS really needs is the definition of a common >>>>>>>>> communication architecture and the definition of what features >>>>>>>>> should be comprised for an IPv6 networking stack deployed for >>>>>>>>> ITS use cases. This cannot be done at IETF, and actually >>>>>>>>> already exists at ISO: - ISO 21217 - Architecture - ISO 21210 - >>>>>>>>> IPv6 Networking >>>>>>>>> >>>>>>>>> As an input to the discussion, please consider reading >>>>>>>>> documents D2.1 and D2.2 available on the ITSSv6 project web >>>>>>>>> page: http://www.itssv6.eu/documentation/ D2.2 provides an >>>>>>>>> analysis of the currently published version of ISO 21210, but >>>>>>>>> new work items have been launched since then to address >>>>>>>>> remaining issues. >>>>>>>>> >>>>>>>>> Regards, Thierry. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 28/01/13 11:08, Alexandru Petrescu wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 28/01/2013 05:02, Stan Ratliff (sratliff) a écrit : >>>>>>>>> >>>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> This is just one opinion, but I'd like to understand why ITS >>>>>>>>> would need its own IETF group. The work here is the same (IMO) >>>>>>>>> as what is taking place in MANET. I would vote that this work >>>>>>>>> be taken up in MANET. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Stan, >>>>>>>>> >>>>>>>>> Thank you for the offer. I considered this offer since some >>>>>>>>> time. >>>>>>>>> >>>>>>>>> I try to understand whether some of these items on which I >>>>>>>>> have interest could be brought in in MANET WG: - V2V using >>>>>>>>> prefix exchange - VIN-based IP addressing scheme - ND Prefix >>>>>>>>> Delegation - PMIP-based network mobility - >>>>>>>>> IPv6 single-address connecion 'sharing' with a cellular >>>>>>>>> operator and a vehicular moving network (type '64share' >>>>>>>>> of v6ops). - Default Route with DHCPv6. >>>>>>>>> >>>>>>>>> Please let me know. >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, Stan >>>>>>>>> >>>>>>>>> On Jan 26, 2013, at 9:34 AM, Abdussalam Baryun wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Nabil, >>>>>>>>> >>>>>>>>> I think we already done some steps but not sure how far now. We >>>>>>>>> will need to propose the WG and provide the WG charter, as use >>>>>>>>> cases and work to be done in this group. >>>>>>>>> This charter needs to be approved by the IESG. I have not >>>>>>>>> attended the last meeting so not sure about the status now, >>>>>>>>> >>>>>>>>> AB >>>>>>>>> >>>>>>>>> On 1/26/13, Nabil Benamar >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> I'm still interested in this list and want to join voices >>>>>>>>> previously heard to make it a working group. So what should we >>>>>>>>> exactly do, to achieve this goal ? >>>>>>>>> >>>>>>>>> >>>>>>>>> 2013/1/26 Abdussalam Baryun >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> I was interested in this group but not sure where are we so >>>>>>>>> far. Is there progress, or is there issues/efforts that need to >>>>>>>>> be completed and volunteered. >>>>>>>>> >>>>>>>>> AB _______________________________________________ its mailing >>>>>>>>> list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- * * *ÊÍíÇÊí ¡ **Cordialement, Regards* * * * * *äÈíá >>>>>>>>> ÈäÚãÑæNabil Benamar* Professor of computer sciences Simulation >>>>>>>>> and Modelisation Laboratory Human Sciences Faculty of Meknes >>>>>>>>> Moulay Ismail* *University* Meknes, Morocco *GSM: * *+ 212 6 >>>>>>>>> 70832236 http://nabilbenamar.com/ >>>>>>>>> >>>>>>>>> * >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------- >>>>>>>>> ------- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> ---------- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> * >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ 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 >>>>>>>>> >>>>>>>>> _______________________________________________ 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ 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 >>>>>> >>>>>> >>>>>> _______________________________________________ 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 >>>> >>>> >>>> >>>> _______________________________________________ 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 The >>> information contained within this e-mail and any files attached to >>> this e-mail is private and in addition may include commercially >>> sensitive information. The contents of this e-mail are for the >>> intended recipient only and therefore if you wish to disclose the >>> information contained within this e-mail or attached files, please >>> contact the sender prior to any such disclosure. If you are not the >>> intended recipient, any disclosure, copying or distribution is >>> prohibited. Please also contact the sender and inform them of the >>> error and delete the e-mail, including any attached files from your >>> system. Cassidian Limited, Registered Office : Quadrant House, Celtic >>> Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 >>> http://www.cassidian.com >>> >>> >> >> >> _______________________________________________ >> 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 > ************************************************************************************************** > E-mail Confidentiality Notice and Disclaimer. > > This e-mail and any files transmitted with it are confidential and are intended solely for the use > of the individual or entity to which they are addressed. Access to this e-mail by anyone else is > unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any > action taken or omitted to be taken in reliance on it, is prohibited. E-mail messages are not > necessarily secure. Hitachi does not accept responsibility for any changes made to this message > after it was sent. > Hitachi checks outgoing e-mail messages for the presence of computer viruses. > ************************************************************************************************** > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From alexandru.petrescu@gmail.com Thu May 16 11:27:47 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD4E11E8150 for ; Thu, 16 May 2013 11:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.118 X-Spam-Level: *** X-Spam-Status: No, score=3.118 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_50=0.001, FH_RELAY_NODNS=1.451, J_CHICKENPOX_45=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbdE5aly-D7b for ; Thu, 16 May 2013 11:27:31 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 2E65311E814D for ; Thu, 16 May 2013 11:27:29 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 429ED94024C for ; Thu, 16 May 2013 20:27:23 +0200 (CEST) Message-ID: <5195250A.5060907@gmail.com> Date: Thu, 16 May 2013 20:27:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: its@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130516-0, 16/05/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [its] novel use case for intra-vehicular wireless X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 18:27:47 -0000 Le 04/05/2013 19:14, Alison Chaiken a écrit : [...] >> I realize that CAN has done lots in the space of data+power >> already. > > CAN is going away, although it will be with us for a long time. > CAN is too slow, too hard to interoperate with other buses, and is > insecure at OSI level 2 in a way that higher levels can only partly > fix. I am not an expert of CAN. But I wouldn't see it disappearing altogether. I can see is that it becomes cheaper and cheaper, more and more available. I can see it multiplies (several CANs) in a vehicle, not that it disappears. I.e. several non-IP CANs, several IP subnets, several WiFi and bluetooth - all within one cabin. Alex From alexandru.petrescu@gmail.com Wed May 29 06:30:22 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4939721F9052 for ; Wed, 29 May 2013 06:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vhwR09M4Zqd for ; Wed, 29 May 2013 06:30:15 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6466A21F8FE8 for ; Wed, 29 May 2013 06:30:15 -0700 (PDT) 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 r4TDUDr0018209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 29 May 2013 15:30:13 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r4TDUD70005924 for ; Wed, 29 May 2013 15:30:13 +0200 (envelope-from alexandru.petrescu@gmail.com) 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 r4TDUCCW010974 for ; Wed, 29 May 2013 15:30:13 +0200 Message-ID: <51A602E4.8010501@gmail.com> Date: Wed, 29 May 2013 15:30:12 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [its] charter proposal - areas addressed. X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 13:30:22 -0000 Hello, Please see attached a significantly modified Charter proposal. It is much shorter. The following paragraph should be our main threefold areas addressed: > The areas addressed by the group are the following: (1) > establishment of IP networking between neighboring vehicles using > either MANET protocols or 1-hop ICMP protocol, (2) layering of IPv6 > over IEEE 802.11p communication technology and (3) IPv6-based > network-layer distribution of content in a geographic area. For each > of the three areas, security aspects will be considered: authenticity > of routing message exchanges, influence of the absence of link-layer > security of IEEE 802.11p, and security of multicast distribution. Please comment. Alex From alexandru.petrescu@gmail.com Wed May 29 06:31:11 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F5A21F8F62 for ; Wed, 29 May 2013 06:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.12 X-Spam-Level: X-Spam-Status: No, score=-10.12 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIxbKWWnc03k for ; Wed, 29 May 2013 06:31:07 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8B93A21F8F0E for ; Wed, 29 May 2013 06:31:06 -0700 (PDT) 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 r4TDV4Nk018606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 29 May 2013 15:31:04 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r4TDV4Xt006251 for ; Wed, 29 May 2013 15:31:04 +0200 (envelope-from alexandru.petrescu@gmail.com) 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 r4TDV34N030790 for ; Wed, 29 May 2013 15:31:04 +0200 Message-ID: <51A60317.7040601@gmail.com> Date: Wed, 29 May 2013 15:31:03 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: its@ietf.org References: <51A602E4.8010501@gmail.com> In-Reply-To: <51A602E4.8010501@gmail.com> Content-Type: multipart/mixed; boundary="------------050302020306000200020000" Subject: Re: [its] charter proposal - areas addressed. X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 13:31:12 -0000 This is a multi-part message in MIME format. --------------050302020306000200020000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit sorry, document attached. Alex Le 29/05/2013 15:30, Alexandru Petrescu a écrit : > Hello, > > Please see attached a significantly modified Charter proposal. It is > much shorter. > > The following paragraph should be our main threefold areas addressed: > >> The areas addressed by the group are the following: (1) >> establishment of IP networking between neighboring vehicles using >> either MANET protocols or 1-hop ICMP protocol, (2) layering of IPv6 >> over IEEE 802.11p communication technology and (3) IPv6-based >> network-layer distribution of content in a geographic area. For each >> of the three areas, security aspects will be considered: authenticity >> of routing message exchanges, influence of the absence of link-layer >> security of IEEE 802.11p, and security of multicast distribution. > > Please comment. > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --------------050302020306000200020000 Content-Type: text/plain; charset=windows-1252; name="its-11.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its-11.txt" Intelligent Transportation Systems at IETF Draft Charter Proposal May 29th, 2013 http://ietf.org/mailman/listinfo/its Intelligent Transportation Systems (its) ---------------------------------------- Current Status: Informal Chairs: TBD TBD Assigned Area Director: TBD () Mailing list Address: its@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/its Archive: http://www.ietf.org/mail-archive/web/its/current/maillist.html Additional web page http://www.lara.prd.fr/ietf-its Draft Charter Proposal: Context ------- Intelligent Transportation Systems (ITS) ITS is about extending the Internet to mobile vehicular platforms. These platforms include: vehicles and embedded devices (ruggedized units, actuators and sensors), mobile devices carried by passengers (tablets, smartphones) and fixed infrastructure units (Internet access points, charge stations, geo-broadcasting units). The entire system may be connected to the Internet with generic radio-WANs or radio-LANs specific to vehicular communications; in certain cases the vehicles are disconnected from the Internet yet may be inter-connected to each another, in an ad-hoc manner. Each moving vehicle may use disjoint heterogeneous radio systems (e.g. a vehicle employs two or more different radios which may be used simultaneously, or alternatively). They radios have the following characteristics: - lower capacity, higher noise than customary Internet plumbing. - presence of mission critical needs and safety applications. - stable in-vehicle network structure. - volatile topology as vehicles (and the routers they contain) move. An example scenario of vehicular communications is the following: an instrumented ambulance is connected to the Internet and offers access to individual equipments deployed in-vehicle; it moves through a traffic jam and may signal its direction by multicasting IP communication packets over IEEE 802.11p direct links, or it establishes direct subnets to vehicles to request their position. Other similar scenarios are described in a dedicated document. The areas addressed by the group are the following: (1) establishment of IP networking between neighboring vehicles using either MANET protocols or 1-hop ICMP protocol, (2) layering of IPv6 over IEEE 802.11p communication technology and (3) IPv6-based network-layer distribution of content in a geographic area. For each of the three areas, security aspects will be considered: authenticity of routing message exchanges, influence of the absence of link-layer security of IEEE 802.11p, and security of multicast distribution. In each of these areas, the problem space will be identified in detail, in a dedicated draft. The problem will be expressed in terms of protocol behaviour and point precisely to the lack of feature or other breaking points. For the IP addressing and mobility aspects of in-vehicle subnetworks, single-subnet V2V, and single-subnet V2I, the WG will consider and if necessary, profile, existing IPv6 network protocols. The protocols considered are: MANET protocols, ICMPv6, MLDv2. Other higher layer protocols, although relevant to geo-localization, will be considered as a complete reuse (e.g. RFC 5222). Establishment of networking from vehicle to ground is considered achieved to a large extent, by using existing IPv6 protocols (Mobile IPv6). This would be out of scope of work. Several Standards Development Organizations outside IETF work towards developing protocols for vehicular communications, in a non overlapping manner. In some cases IP protocols are used for transport, in other cases IP protocols are modified for purposes particular to vehicular communications. The group ISO TC204 describes ITS station architecture, IPv6 networking and security, and optimizations. The group ETSI ITS describes IPv6 for networking in vehicles. IEEE TGp, AUTOSAR, GENIVI and IPSO describe other aspects of vehicular communications. When possible, liaisons will be established with these organizations. This group will survey these SDO's documents to identify how it relates to this group's work. Potential new work items ------------------------ The following potential work items exist: Scenarios and requirements for vehicular communications will be developed which introduce at IETF the terms V2V, V2I, V2R and intra-vehicular paradigms. Define various possible scenarios for IP vehicular communications and identify requirements that are essential to support the defined scenarios. Practices and gap analysis for IP vehicular communications: document practices for the deployment of existing IP protocols and identify any limitation of the existing IP protocols to fulfill the scenarios and requirements for IP vehicular communications. The use of IP over 802.11p - with or without intermediary layers, with or without modifications - will de described. One particular practice to document is the IP addressing architecture within a vehicle, between vehicles, and between vehicle and infrastructure: the preferred address auto-configuration methods, the requirements for address stability and scope of visibility (in-vehicle, to vehicles nearby, to infrastructure, to Internet, etc.) A problem statement draft should be written which documents the problem which is a real-world problem, points precisely to the protocols which may break, and may easily lead to a solution that can be designed in a straightforward manner. Milestones: Jul 2013 - Meet in Berlin Jul 2013 - Present drafts "Scenarios and Requirements for IP in Intelligent Transportation Systems", and Gap Analysis Jul 2013 - Present drafts on Route Exchange between vehicles Jul 2013 - Present MANET landscape for V2V2V Nov 2013 - Present status from ISO Nov 2013 - Present gap analysis and requirements Mar 2014 - Present problem statement Jul 2014 - Present solution drafts Nov 2014 - Present solution drafts --------------050302020306000200020000-- From alison@she-devel.com Thu May 30 11:07:58 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8368621F8D90 for ; Thu, 30 May 2013 11:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.037 X-Spam-Level: * X-Spam-Status: No, score=1.037 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqGVCelgYrce for ; Thu, 30 May 2013 11:07:57 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5E24221F8CB4 for ; Thu, 30 May 2013 11:07:57 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e14so1421800iej.1 for ; Thu, 30 May 2013 11:07:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=mUdbHxL4IUkPS/fKOz9oICUn69wihUpRNleA6JQhmAk=; b=Z8nJjJZ5GOL+J8UwSR6NO30MxJSssw5pkLnOLGA+qyQ3fove+rWNeMWxgGKjZ3altz QJ188elewQEha0v4Gjh/tnjRAF2bvzoMvNw89R5tABlmyt+ITV1zP/Un6C7LJuE8iBQX KG1XaYH9ZGYWeEYhKjuYrDUQsbiCLxxOJKGp4od1AtsLJMPTAnCJ6kYG5AqJBt7R66Ot ycr/kr5/RfysVCKbskJ6FQgeiL0yfMSHGyVGHJRV/tsslxX2wTz7XQ2yGTSTrp40WAKL UdUN3iPRe9NovGtJo7y8cYsPO5CcEx+rw3kefwnWKQfHhc/DLYIhDqRrlDmacOh07sCM /LBA== MIME-Version: 1.0 X-Received: by 10.42.35.75 with SMTP id p11mr3620622icd.6.1369937276795; Thu, 30 May 2013 11:07:56 -0700 (PDT) Received: by 10.43.97.68 with HTTP; Thu, 30 May 2013 11:07:56 -0700 (PDT) Date: Thu, 30 May 2013 11:07:56 -0700 Message-ID: From: Alison Chaiken To: its@ietf.org Content-Type: multipart/alternative; boundary=90e6ba61452cbf903504ddf360c1 X-Gm-Message-State: ALoCoQmhec2gSIGPu+meuh1k22yXx36F9zQfzP3w0HW5B8vVSqfKcgakqYy7k581FqW0CitBMuFt Cc: khait@componentality.com Subject: [its] V2X equipment with (apparently) open-source 802.11p drivers X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 18:07:58 -0000 --90e6ba61452cbf903504ddf360c1 Content-Type: text/plain; charset=ISO-8859-1 See http://www.componentality.com/flexroad/ Note that V2X hardware with prices in Euros is actually listed! I learned about this product by attending the Automotive Grade Linux webinar presented by Kostantin Khait of Componentality: http://automotive.linuxfoundation.org/webinars/watch-webinar-using-open-source-solutions-for-vtv-vti-communications Inserting credentials gives access to video and slides. I'm CC'ing Kosta to rope him into the discussion. About the driver: http://www.componentality.com/res/OSS.Build.Instruction.En.txt I haven't tried building it yet. -- Alison Chaiken alison@she-devel.com 650-279-5600 http://{she-devel.com, exerciseforthereader.org} The intermediary between the head and the hands must be the heart. -- Thea von Harbou --90e6ba61452cbf903504ddf360c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable See

Note that V2X hardware with prices in Euros is actually listed!=A0=A0 I l= earned about this product by attending the Automotive Grade Linux webinar p= resented by Kostantin Khait =A0of Componentality:


Inserting credentials gives access to video and slides. =A0 I'= ;m CC'ing =A0Kosta to rope him into the discussion.

About the dr= iver:


I haven't tried building it yet.

--
Alison Chaiken= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 alison@she-devel.com
650-279-5600 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://{she-devel.com, exercis= eforthereader.org}
The intermediary between the head and the hands must be the heart. =A0 =A0-= - Thea von Harbou
--90e6ba61452cbf903504ddf360c1--