Subject: Re: [ipwave] LoRa and LoRaWan

From: STANICA Razvan <[email-masked]>
Date: Mon, 28 Jan 2019 20:47:10 +0100

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, [email-masked] 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/

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 28 Jan 2019 20:09:43 +0000

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"
<[email-masked] on behalf of [email-masked]> wrote:

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

---

From: STANICA Razvan <[email-masked]>
Date: Mon, 28 Jan 2019 21:54:17 +0100

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

-- 
Razvan Stanica
Associate Professor
INSA Lyon
CITI - INRIA UrbaNet Team
http://irt.enseeiht.fr/stanica/

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 28 Jan 2019 23:18:20 +0200

+1

Also the LoRa technology is better a discussion in the LPWAN WG, not IPWAVE
WG.

AB

On Mon, Jan 28, 2019 at 10:09 PM Sri Gundavelli (sgundave) <
[email-masked]> wrote:

> for autonomous driving.

ITS applications need high bit rates not low bit rates

> I would think, the requirement in vehicular

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 29 Jan 2019 00:00:22 +0000

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

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 28 Jan 2019 22:22:34 -0800

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:
> > > in the range 200/~300 meters and that¹s when the RF conditions
> > > are
> > > perfect
> > > etc), but I do not know if that can be used for ITS applications
> > > such
> > > as
> > > > group) that has been selling a tracker for fleet management
> > > > purposes
> > > > for
> > > > technologies (mainly Sigfox, but also LoRa) to collect the
> > > > location
> > > > data

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 29 Jan 2019 12:18:27 +0100

it could be advantageous indeed to add dGPS functionality to IP-enabled 
Road-Side Units connected to the Internet.  If that dGPS 'reference 
station' functionality runs on a cheap miniPCIe board in an RSU then it 
is even better.

there's an additional way, more Internet, to offer high-precision GPS to 
vehicles.  It is called 'AGPS' for Assisted GPS.  It is specific to some 
manufacturers.  It offers on servers on the Internet the planned paths 
of satellites, and 'ephemerides'.  It is sufficient that the car 
connects to Internet and downloads these corrections in order to get a 
time for position synthesis in the order of 2 or 3 seconds ('time to 
fix' - ttf, 'warm start') and position accuracy at tens of centimeters.

a third way is to consider Galileo which claims improved accuracy.

However, one should take great care when engaging on any one of these 
ways, because often they can be too expensive (in terms of money) for 
the service they actually deliver.  For example, use expensive RTK 
equipment, maybe pay a monthly plan (which is nothing else than a GPRS 
data plan), get centimeter precision, but still be influenced by meters 
by the presence of a nearby solid.

Satellite-based precision localisation has obvious competitors in the 
cheaper visual based and odometer localisations.

Alex

---

From: STANICA Razvan <[email-masked]>
Date: Tue, 29 Jan 2019 12:23:59 +0100

Hello,

I am talking about an actual company, who has been selling fleet 
management products in several Western European countries for more than 
5 years. And they are not alone on the market, other companies propose 
similar things.
Of course there would be no point in using LPWAN to collect this data 
if DSRC would be deployed :) But it is not, except for a couple of 
testbeds, so people need to come up with solutions to satisfy the 
existing demand. No one will wait for another 20 years to have DSRC 
coverage country-wide.
Using LTE is indeed another solution, but much more expensive, both 
financially and in energy terms.

Best,

Razvan

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 29 Jan 2019 13:43:41 +0100

Le 29/01/2019 à 12:23, STANICA Razvan a écrit :
> [...] if DSRC would be deployed :) But it is not, except for a
> couple of testbeds,[...]

It depends a lot on what one calls 'DSRC' and what calls a thing being
deployed, or not :-)

I am very encouraged about recent deployments of RSUs I see in more and
more places.  But certainly 802.11-OCB at 5.9GHz is not as widely
deployed as cellular networks are, even though it is more than testbeds
and certainly more than a couple :-)

The highway segment I take daily is covered by 3 Road-Side Units sending
unsecure CAM, DENM and IPv6 RA messages on 802.11-OCB at 5.9GHz.  They
contain valid position, accident warnings and ULAs.

Other highway segments I some times take feature new RSUs in recent
months: A10 direction Province before St Arnoult, on Francilienne.  A
road segment between Prague airport and its downtown featured
point-to-point RSUs for traffic lights at last Prague IETF.  A
deployment at Versailles/France, Brainport/Netherlands, New York/USA,
and a very early one in Hawaii.

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 29 Jan 2019 17:00:19 +0000

Sure, DSRC is not deployed and it may be a long tail before we get there,
but the real point here is if LPWAN type technology is even remotely
suitable for ITS applications?  Taking LoRaWAN, its operating in
Unlicensed band, designed for long range with no latency considerations,
with scheduled downlink transmissions windows etc.. I am thinking how that
can support an ITS application with stringent latency requirements. But,
again, not to throw water on this exploration idea of yours, I am just not
sure how it can be used here, and off course assuming LoRaWAN will find
huge traction with major world wide deployments and specially in light of
NBIOT.

Sri

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 29 Jan 2019 11:16:00 -0800

> station' functionality runs on a cheap miniPCIe board in an RSU then

The reference receiver problem is well understood.  Consists of a
rather ordinary GPS receiver, but planted on a known location.  It
compares the position it knows it is on with the position the
satellites are telling it and produces the differential (pseudorange).
That's what is transmitted to the user.  dGPS (and dGalileo if such
exists) would work alike.  The bit load is about 50 bits/second and
since the RSU is a comms node anyway, the marginal comms cost is low.  

> fix' - ttf, 'warm start') and position accuracy at tens of

There are a half dozen errors in the satellite positioning basket
(regardless of which satellite system you're trying to use):
- ephemeris error.  The satellites aren't quite where they are
predicted to be.  (is that what you're describing above?)
- clock drift.  GPS satellites have cesium clocks (with rubidium
backups) so they drift slowly but they do drift.  (See USNaval
Observatory web site for details).
- selective availability (null issue today)
- ionospheric distortion
- tropospheric distorion.  These two errors get larger as distance
between reference receiver and user grow.  In an [its] scenario they
would be insignificantly small
- receiver noise.  Untouchable by the differential mechanism but in the
early days, car bodies caused crazy amounts of multipath that the
receivers didn't know how to cope with ... receivers are smarter today.

The biggest cost component in a program would be equipping users with
dGPS receivers.  The rest is peanuts.

> a third way is to consider Galileo which claims improved accuracy.

Substantiate such claims.  The real problem is that all satellite nav
systems have problems (reach into tunnels, solar event susceptibility,
... for example).  It's an entirely different discussion item but
reliance wholly on satellite-based nav runs some brittleness risks.
Adding Galileo to GPS potentially improves things, but on the margin.

> the service they actually deliver.

The biggest cost component in a program would be equipping users with
dGPS receivers.  The rest of the program is peanuts.

  For example, use expensive RTK 
> by the presence of a nearby solid.

Perfect ephemerides won't cure multipath.  And in radionav, multipath
is always bad.

> > > one more radio into the equation. I tend to think, using DSRC
> > > radio
> > > at the
> > > On 1/28/19, 12:54 PM, "STANICA Razvan" <[email-masked]
> > > r>
> > > wrote:
> > > 
> > > > 
> > > > 
> > > > The error when using LPWAN for localisation purposes is close
> > > > to 1
> > > > km
> > > > > applications seems bit extreme to me. From my understanding
> > > > > and
> > > > > having
> > > > > worked with LoRaWAN, the best accuracy numbers I have seen
> > > > > with
> > > > > LoRaWAN is
> > > > > be OK for general fleet management applications (tracking
> > > > > FedEx
> > > > > truck
> > > > > 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
> > > > > 
> > > > > 
> > > > > 
> > > > > <[email-masked] on behalf of [email-masked]
> > > > > >
> > > > > wrote:
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > Hello all,
> > > > > > 
> > > > > > We have been working with a company in France (now part of
> > > > > > the
> > > > > > Coyote
> > > > > > https://traqueur.com/produit/traqueur-nano/). They are
> > > > > > using
> > > > > > LPWAN
> > > > > > from the vehicles, with rather good performance. If you
> > > > > > have
> > > > > > some
> > > > > > > services (those requiring low delay), but it could be
> > > > > > > really
> > > > > > > useful

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 29 Jan 2019 19:40:21 +0000

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

Sri

---

From: STANICA Razvan <[email-masked]>
Date: Wed, 30 Jan 2019 09:23:02 +0100

Hello,

Just to make it clear, this is not my company, I have no relationship 
with them other than a research project that already ended, and I am not 
pushing for any "exploration idea" here. Someone asked (rather 
off-topic) if we can point to any work on the use of LPWAN for ITS. I 
just answered with a clear product, used for several years by hundreds 
of companies to manage their fleets of vehicles. I am sorry if this 
product does not comply to your vision of the world, that it does not 
run DSRC/WAVE/ITS-G5/OBC or whatever. Hell, it does not even use IP, 
they should be totally worthless according to the specialists. But they 
are actually shipping products and selling ITS services, instead of 
waiting for 20 years for someone to install RSUs.

Best,

Razvan

On Tue, 29 Jan 2019 17:00:19 +0000, Sri Gundavelli (sgundave) wrote:
>>> dGPS system had a design spec (worst case, 2drms) of 10 meters 
>>> which
>>> is
>>>> On 1/28/19, 12:54 PM, "STANICA Razvan" 
>>>> <[email-masked]>
>>>> wrote:
>>>>
>>>> >
>>>> > The error when using LPWAN for localisation purposes is close to 
>>>> 1
>>>> > km

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 30 Jan 2019 11:37:48 +0100

> already there in the SAE message dictionary (J2735)?

Ah!  Surprising.

Do you mean the 'nmeaCorrections' in year 2009 J2735 freely available at 
http://asn1-playground.oss.com/Standards/ITS%20J2735.asn

It would be a great reason to put that in an IP-RSU in a BSM in Europe 
(because CAM cant).

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 30 Jan 2019 16:14:56 +0000

Hi Razvan,

Thanks! Its just a discussion. There is nothing right or wrong, just a
view.

Cheers!
Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 30 Jan 2019 16:21:00 +0000

Alex:

Yes, that’s my understanding. Hopefully, the SAE experts will comment on
this.

Sri