Re: [ipwave] LoRa and LoRaWan

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Tue, 29 January 2019 19:40 UTC

Return-Path: <sgundave@cisco.com>
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 0246F130FEB for <its@ietfa.amsl.com>; Tue, 29 Jan 2019 11:40:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.643
X-Spam-Level:
X-Spam-Status: No, score=-14.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIrfzdyfLoPy for <its@ietfa.amsl.com>; Tue, 29 Jan 2019 11:40:24 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9B1130FEA for <its@ietf.org>; Tue, 29 Jan 2019 11:40:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5283; q=dns/txt; s=iport; t=1548790823; x=1550000423; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FfnUSVf2LS83/HomH8GKHTp3iUI7VLHX18+NjjIccA8=; b=W774b5RT28MehIFEhEns6SVao5aHFxsk+JyG4O2QVtjH/GnVUNoWYF2F nUjkvhLkvDxVh010qaPS9JZ8gYcKAv24TmakTpuxXq4MG3HzfBSjwPJyt wF2Js40tJJteM8j0NB2BkVS7QP3HDf9HcUT4VGUkwsqot1qTIpf05j8M3 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAABVq1Bc/4QNJK1kFgMBAQEBAQEBAQEBAQEHAQEBAQEBgVEEAQEBAQELAYIDZ4EDJwqMEot5gg2JJo5jFIFnAwgBARgLhEkCgm8iNAkNAQMBAQIBAQJtHAyFSwEBAQMBAWwLDgICAQgYLhsGBgslAgQBDQUZgwqBaQMVD6l9AoJqhUOCSA2CHgUvgXqKEheBQD+BEYIUfoJXPAsBAYElQzGFKAKJUgIhCB6NZIobMwkChyyDXoNqgRCCKhiCO49zihiFKYEjgXmITwIRFIEnHziBVnAVO4JsCYIcg2R7Q4NWhT9BMQGOa4EfAQE
X-IronPort-AV: E=Sophos;i="5.56,538,1539648000"; d="scan'208";a="510575645"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jan 2019 19:40:22 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x0TJeMc6001374 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 Jan 2019 19:40:22 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 29 Jan 2019 13:40:21 -0600
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Tue, 29 Jan 2019 13:40:21 -0600
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Rex Buddenberg <buddenbergr@gmail.com>, STANICA Razvan <Razvan.Stanica@enseeiht.fr>
CC: "its@ietf.org" <its@ietf.org>
Thread-Topic: [ipwave] LoRa and LoRaWan
Thread-Index: AQHUuAp42SJcaFbQsEaE9zxZgo/ntA==
Date: Tue, 29 Jan 2019 19:40:21 +0000
Message-ID: <D875E8FC.2E6076%sgundave@cisco.com>
References: <mailman.2860.1548695015.5892.its@ietf.org> <0bfbf93807ca33180fef158c8f2365af@inp-toulouse.fr> <D8749F9E.2E5E76%sgundave@cisco.com> <c1bc3846d797bbe6691263e6404e18ed@inp-toulouse.fr> <D874D2A4.2E5EDF%sgundave@cisco.com> <1548742954.3320.29.camel@gmail.com>
In-Reply-To: <1548742954.3320.29.camel@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.188.53]
Content-Type: text/plain; charset="windows-1254"
Content-ID: <AC25313C851D734E97454D63C7DEDAF4@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/YTcudp-_pF9kGz3FnCHZbXmKbSw>
Subject: Re: [ipwave] LoRa and LoRaWan
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jan 2019 19:40:27 -0000

Makes lot of sense. I assume the differential correction support is
already there in the SAE message dictionary (J2735)?

Sri



On 1/28/19, 10:22 PM, "Rex Buddenberg" <buddenbergr@gmail.com> wrote:

>Perhaps the best way to 1) ensure integrity and 2) improve accuracy of
>GPS is to add differential GPS.  Since you have a bunch of roadside
>units anyway, they could have a dGPS functionality easily added to
>them.  This is not a comms issue, it's radionav one.  The Coast Guard's
>dGPS system had a design spec (worst case, 2drms) of 10 meters which is
>the size of the dot on harbor-scale charts for buoy locations.  In
>practice, the system was delivering about an order of magnitude better
>than that.  (GPS itself has improved over its life).
>
>
>On Tue, 2019-01-29 at 00:00 +0000, Sri Gundavelli (sgundave) wrote:
>> If the primary source for location is GPS, and if the vehicle is also
>> equipped with DSRC/LTE radio, I am not sure about the value of
>> bringing
>> one more radio into the equation. I tend to think, using DSRC radio
>> at the
>> RSU for more accurate location prediction (in addition to the GPS
>> feed)
>> might be interesting for this group.
>> 
>> Sri
>> 
>> 
>> 
>> On 1/28/19, 12:54 PM, "STANICA Razvan" <Razvan.Stanica@enseeiht.fr>
>> wrote:
>> 
>> > 
>> > The location is acquired using GPS. It is just collected on the
>> > fleet
>> > management side using LPWAN technologies.
>> > The error when using LPWAN for localisation purposes is close to 1
>> > km
>> > (but many companies are working on reducing this error).
>> > 
>> > Razvan
>> > 
>> > On Mon, 28 Jan 2019 20:09:43 +0000, Sri Gundavelli (sgundave)
>> > wrote:
>> > > 
>> > > Use of LPWAN (LoRaWAN / SIGFIX) for vehicular location for ITS
>> > > applications seems bit extreme to me. From my understanding and
>> > > having
>> > > worked with LoRaWAN, the best accuracy numbers I have seen with
>> > > LoRaWAN is
>> > > in the range 200/~300 meters and that¹s when the RF conditions
>> > > are
>> > > perfect
>> > > (remote areas with the gateways at a certain elevation). Such
>> > > accuracy may
>> > > be OK for general fleet management applications (tracking FedEx
>> > > truck
>> > > etc), but I do not know if that can be used for ITS applications
>> > > such
>> > > as
>> > > for autonomous driving. I would think, the requirement in
>> > > vehicular
>> > > context is more like Wi-Fi indoor location, with accuracy in few
>> > > feet, so
>> > > we can put the vehicle in a lane, but cannot afford to put the
>> > > vehicle in
>> > > the next street.
>> > > 
>> > > 
>> > > Sri
>> > > 
>> > > 
>> > > 
>> > > On 1/28/19, 11:47 AM, "its on behalf of STANICA Razvan"
>> > > <its-bounces@ietf.org on behalf of Razvan.Stanica@enseeiht.fr>
>> > > wrote:
>> > > 
>> > > > 
>> > > > Hello all,
>> > > > 
>> > > > We have been working with a company in France (now part of the
>> > > > Coyote
>> > > > group) that has been selling a tracker for fleet management
>> > > > purposes
>> > > > for
>> > > > a few years now (the website is in French, sorry:
>> > > > https://traqueur.com/produit/traqueur-nano/) They are using
>> > > > LPWAN
>> > > > technologies (mainly Sigfox, but also LoRa) to collect the
>> > > > location
>> > > > data
>> > > > from the vehicles, with rather good performance. If you have
>> > > > some
>> > > > precise questions, I can try to answer.
>> > > > 
>> > > > Best,
>> > > > 
>> > > > Razvan
>> > > > 
>> > > > On Mon, 28 Jan 2019 09:03:35 -0800, its-request@ietf.org wrote:
>> > > > > 
>> > > > > Hi Alex,
>> > > > > 
>> > > > > This technology is for sure not recommended for security-
>> > > > > related
>> > > > > services (those requiring low delay), but it could be really
>> > > > > useful
>> > > > > for monitoring services, involving on-board sensors, load
>> > > > > management
>> > > > > in logistics, etc.
>> > > > > 
>> > > > > In the papers I provided, we present some initial tests under
>> > > > > mobility conditions. The latency is something you have to
>> > > > > consider
>> > > > > depending on the service you want to implement, but
>> > > > > communication
>> > > > > range and coverage conditions are good points to be
>> > > > > considered.
>> > > > > 
>> > > > > In any case, this is just a technology that could be
>> > > > > complemented
>> > > > > with others in multi-RAT scenarios.
>> > > > > 
>> > > > > Regards,
>> > > > > 
>> > > > > --
>> > > > > José Santa Lozano
>> > > > > Department of Information and Communication Engineering
>> > > > > Faculty of Computer Science
>> > > > > University of Murcia
>> > > > > 30100 Murcia, Spain
>> > > > > Phone: +34-868-884616 / +34-868-884455
>> > > > > Fax: +34-868-884151
>> > > > > Web: http://ants.inf.um.es/~josesanta [5]
>> > > > > 
>> > > > --
>> > > > Razvan Stanica
>> > > > Associate Professor
>> > > > INSA Lyon
>> > > > CITI - INRIA Agora Team
>> > > > http://perso.citi.insa-lyon.fr/rstanica/
>> > > > 
>> > > > _______________________________________________
>> > > > its mailing list
>> > > > its@ietf.org
>> > > > https://www.ietf.org/mailman/listinfo/its