Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term - localisation sensors

[Rex Buddenberg <[e-mail]>]

None of the differential systems that I know of generate lat/long/alt
data.  dGPS generates delta pseudoranges -- the difference between the
satellite <--> receiver distance that it IS getting and that it SHOULD
be getting, based on it's known location.  dLoran (or eLoran in today's
buzz) generates delta TDs.  (It would be possible to squeeze out a box
location in lat/long/alt via an SNMP get -- the differential box must
know its location to function -- but that's administrative, not
operational).  

Nit aside, we're agreeing that it's app level data and putting it into
UDP PDUs and blasting it out makes sense.

On Sun, 2017-02-12 at 18:45 +0100, Alexandre Petrescu wrote:
> If the app-level data generated by these sensors (lat/long/alt,
> time) 
> are put in UDP or other payloads of IP then it makes sense to talk
> about 
> these sensors in these RSUs routers.
> 
> But, up to now, ITS deployments do this:
> - POI over something else than IP
> - TSA is not mandatory (Time Stamp Advertisement).
> 
> Alternatively, one would do something like this:
> - POI as PIDF-LO data (RFC5491) over IP
> - IP Router Advertisements containing timestamps (to be defined)
> - NTP over IP to send timestamps.
> 
> Then we can talk here about location sensors in RSU router boxes...
> 
> Alex
> 
> Le 10/02/2017 à 19:52, Rex Buddenberg a écrit :
> > 
> > Box <> function.
> > 
> > If you understand the fragility and warts in radionav systems (GPS,
> > Galileo, Glonass, Loran) then differential overlays to these
> > systems
> > makes a lot of sense.  And the most attractive place to put the
> > differential reference receivers is in the roadside boxes.  The
> > reference receiver function is a sensor function, not a routing
> > one.
> > But probably belongs in the same box.
> > 
> > 
> > On Fri, 2017-02-10 at 12:49 +0100, Jérôme Härri wrote:
> > > 
> > > Hi Alex,
> > > 
> > > It could actually be two different terms, depending of what we
> > > want
> > > to say in the draft. The RSU is no longer a pure C-ITS name, as
> > > even
> > > LTE-V2X adopted the LTE-UE operating in RSU mode for LTE-V2V
> > > communications (meaning you do not need to be a eNB/base station
> > > to
> > > be a RSU).
> > > I would tend to think that the RSU is more a function/service
> > > than an
> > > actual technology...but as I think the debate could be complex
> > > and
> > > suggest to follow Michelle suggestion to keep the RSU as a
> > > 'bigger'
> > > entity, and if you need it, a RSR as a potential sub-set of a
> > > RSU. As
> > > Michelle said, a RSU is not a router  by default...
> > > 
> > > BR,
> > > 
> > > Jérôme
> > > 
> > > -----Original Message-----
> > > From: its [mailto:[e-mail]] On Behalf Of Alexandre
> > > Petrescu
> > > Sent: Friday 10 February 2017 12:37
> > > To: Michelle Wetterwald
> > > Cc: [e-mail]
> > > Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU
> > > term
> > > 
> > > Hi Michelle,
> > > 
> > > Thank you for the suggestion.
> > > 
> > > But making RSR a component of RSU is different than making RSU a
> > > component of RSR, right?
> > > 
> > > Despite the widespread belief that RSU would have something to do
> > > with IP and Internet, rarely if ever was there an RSU connected
> > > to
> > > Internet that forwarded IP packets - most RSUs are disconnected
> > > from
> > > the Internet (the supposedly 'slaves' at FHWA) and the ones that
> > > are
> > > connected to the Internet (supposedly the 'masters' at FHWA) are
> > > so
> > > only in order to be SNMP-managed remotely, but not to forward.
> > > 
> > > If we know of some RSU which has this 'forwarding' flag set to 1,
> > > then we should talk about it, and call it a Router.
> > > 
> > > The "ITS station" term is not a term at IETF.  We could re-use
> > > the
> > > term "ITS station", but I would like to know whether "ITS
> > > Station" is
> > > a Router or a Host?
> > > 
> > > Yours,
> > > 
> > > Alex
> > > 
> > > Le 10/02/2017 à 12:18, Michelle Wetterwald a écrit :
> > > > 
> > > > 
> > > > Hi Alex,
> > > > 
> > > > Actually, an RSU is generally more than an RSR as it is an ITS
> > > > station
> > > > per se and may contain upper (e.g. service or even
> > > > application) layers. I suggest to keep the definition of RSU in
> > > > the
> > > > text, as it is a widely used term, but clarify that an RSR
> > > > could
> > > > be
> > > > one of the components of an RSU.
> > > > 
> > > > Best regards, Michelle
> > > > 
> > > > 2017-02-10 11:34 GMT+01:00 Alexandre Petrescu
> > > > <[e-mail]
> > > > <mailto:[e-mail]>>:
> > > > 
> > > > draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term
> > > > 
> > > > Hello IPWAVErs,
> > > > 
> > > > We received multiple comments about the RSU term.  The
> > > > strongest
> > > > issue
> > > > is that apparently there are conflicts between our assumption
> > > > of
> > > > RSU
> > > > to be a router and FHWA(?) thinking RSU is more like an
> > > > interface
> > > > to a
> > > > router, or something like a master-RSU controlling
> > > > (slave?) RSUs. Unless FHWA tells us they agree RSU is a router,
> > > > I
> > > > will
> > > > modify the following:
> > > > 
> > > > Old:
> > > > 
> > > > 2.  Terminology
> > > > 
> > > > [...]
> > > > 
> > > > RSU: Road Side Unit.
> > > > 
> > > > 
> > > > New:
> > > > 
> > > > RSR: Road Side Router; an IP router equipped with, or connected
> > > > to,
> > > > at
> > > > least one interface that is 802.11 and that is an interface
> > > > that
> > > > operates in OCB mode.
> > > > 
> > > > 
> > > > and substitute RSR for RSU throughout.
> > > > 
> > > > This old 'RSU' term, now RSR, is absolutely needed in the draft
> > > > when
> > > > discussing IP handovers and Mobile IP.
> > > > 
> > > > Alex
> > > > 
> > > > 
> > > > _______________________________________________ its mailing
> > > > list
> > > > [e-mail] <mailto:[e-mail]>
> > > > https://www.ietf.org/mailman/listinfo/its
> > > > <https://www.ietf.org/mailman/listinfo/its>
> > > > 
> > > > 
> > > > 
> > > > 
> > > > -- Michelle Wetterwald [e-mail]
> > > > <mailto:[e-mail]>
> > > _______________________________________________
> > > its mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/its
> > > 
> > > _______________________________________________
> > > its mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/its