SPaT Challenge Webinar SeriesWebinar #3: Design Considerations, Part 2

2:00 – 3:30 PM (Eastern) | April 17, 2018

2

Webinar Logistics

• All lines are muted

• Webinar will be recorded

• Submit questions and comments in chat or Q&A section of webinar window

• Questions will be answered at webinar conclusion

3

Agenda• Welcome and Introduction

• Overview of MAP Messages David Kelley, SubCarrier Systems Corp.

• Utah DOT’s MAP Message Creation Approach Chuck Felice, Utah DOT

• Vehicle Position Correction Need and Solutions Caltrans

• Q&A

4

SPaT ChallengeTo challenge state and local public sector transportation infrastructure owners and operators (IOOs) to deploy DSRC infrastructure with SPaT (and MAP) broadcasts in at least one corridor or network (approximately 20 signalized intersections) in each state by January 2020

20 intersections in 50 states by 2020!

Two years of progress:35 Locations

25 States

500 RSUs Operating

2340 RSUs Planned

5

First SPaT Challenge WebinarMarch 6, 2018

• Topics included: Introduction to the SPaT Webinar Series and

SPaT Challenge Systems Engineering Approach to the SPaT

Challenge Overview of the Model Concept of Operations

and Requirements documents Costs, Procurement, and Corridor Selection

6

Second SPaT Challenge WebinarMarch 20, 2018

• Design Considerations, Part 1

• Topics included: SPaT Messages, Data Assembly, and the Signal

Controller Interface V2I Hub Overview Agency experience with deploying on-board

units

7

SPaT Challenge Resource Pagehttps://transportationops.org/spatchallenge/resources

8

SPaT Challenge Resource Pagehttps://transportationops.org/spatchallenge/resources

9

Upcoming SPaT Challenge Webinars• MAP Creator Tool Demonstration April 24, 2018 1:00-2:30pm ET Live technical demonstration and step-by-step training on

using the MAP creator tool

• Design Considerations, Part 3 May 15, 2018 2:00-3:30pm ET Backhaul infrastructure, intersection, and roadside equipment

specification, design and installation, and DSRC licensing

• Deployment & Validation June 12, 2018 2:00-3:30pm ET Procurement, validation, verification, and security of SPaT

deployments

Webinar Wrap-Up and Q&A

11

Next SPaT Challenge Webinars• MAP Creator Tool Demonstration

April 24, 2018 1:00pm-2:30pm ET A live technical demo that includes a step-by-step training on how to

use the MAP Creator Tool Registration: https://transportationops.org/event/spat-challenge-map-

creator-tool-demo-webinar

• Design Considerations, Part 3 May 15, 2018 2:00-3:30pm ET Backhaul infrastructure, intersection, and roadside equipment

specification Design and installation DSRC licensing Registration: https://transportationops.org/event/webinar-4-spat-

challenge-design-considerations-part-3

Q&ASubmit questions and comments in chat or Q&A section of webinar window

Upcoming SPaT Challenge WebinarsDesign Considerations, Part 2 April 17, 2018 2:00-3:30pm ETMAP Creator Tool Demonstration April 24, 2018 1:00-2:30pm ETDesign Considerations, Part 3 May 15, 2018 2:00-3:30pm ETDeployment & Validation June 12, 2018 2:00-3:30pm ET

Overview of MAP messagesDavid Kelley, SubCarrier Systems Corp. (SCSC)davidkelley@iTSware.net

2

Presentation Outline• MAP & SPaT• The Basics• The Generic Lane Explained• Multiple Lane Uses• A Typical ConnectsTo Example and SPaT• Pedestrian Crossing Examples• Putting it all Together• Creating MAP/SPaT, Key Steps• A “good” MAP has...• Further Resources

3

MAP and SPaT... Are tied at the hip, you must have one to use the other.

• When used together, they operate within the PSID called “Intersection safety and awareness” (0x84)

• MAP is also used for all general purpose road geometry needs in all of DSRC in the US (and in EU).

• There are 15 messages in the J2735 / J2945/x effort, and SRM SSM are also used with SPaT for preemption-priority.

• The SAE is at this time creating a recommended practices document to address deployment questions (J2945/10).

The goal of this briefing is to provide a basic understanding of MAP Content and Structures.

4

The Basics• MAPs represent sets of related lanes;

Each lane is a closed polygon with attributes• MAPs precisely translate between WGS-84 LLH to a

localized XYZ orthogonal system• MAPs support a 1 cm resolution• MAPs are compressed messages

(using a delta encoding system)• MAPS require (“flattening”)

before any application use• BSMs can easily be placed on a

flattened MAP for application use

One MAP message

One Intersection

sMany Lanes

1..32

1..255

5

The Basics, 2• SPATs represent one or more Intersection States

Typically just one for now (Key concept: 1 intersection ≠ 1 signal controller when needed)

• Each Intersection State holds The active Lanes (Key concept: More than just signal times) The active and future movements and times, Time is in UTC

One SPAT message

One Intersection

Inter. States

1..4

1..32

One Intersection State

A Movement State

Signal Group IDState

Times

1..255

Timing Data

6

A typical MAP, with some BSMs• If a MAP msg is rendered

into a simple graphical format and BSMs are placed on it; you get this.

• This is a 2009 edition fragment.

7

The Generic Lane Explained, 1

Based on early deployment experience, a common format was developed. Many separate needs were combined to make the “generic lane” used now.• Represents 8 different “lanes types” with a

common structure.• Includes: Motor Vehicles, Ped Lanes,

Medians, Bicycle Lanes, Trains, etc. • Each Lane Type has the attributes it

needs to describe its use case.• And within each lane, further attributes are

allowed, at a node and spanning nodes.• The system is expandable to provide for

attribute growth.

8

The Generic Lane Explained, 2

A bit more detail on contents...• Key concept:

Each Generic Lane has a context of default values for many items • A local anchor point is always used, and very precise

LLH -> XYZ conversion factors determined

• A sequence of offset nodes describes the polygon (next slide)• A set of Lane-level Attributes and Node-level Attributes • A list of ConnectsTo entries to link the stop line to the next lane and

to the signal groupID

• And a set of allowed maneuvers that can made at the stop line.

Left Side Not shown

9

Generic Lane, 3 Nodes in the Polygon

• Nodes describe the centerlines.• All Nodes are offsets from the

prior node (or anchor point).• The Lane is described from the

stop line backwards.• Widths can be changed as

required (a linear taper along the segment), or use the default.

• The angle of each new point is projected from the last.

• End skew is added when needed.

10

The Generic Lane Explained, 4

• Attributes, two examples: Do Not Block, (a segment use) Curb at Step Off (a node use)

• The ConnectsTo Concept (example in a moment)Key Concept: Link between Lane & SPAT

11

Multiple Lane UsesRecall:

A MAP Is Static, And contains all lane details deemed to be relevant

The SPAT Is Dynamic, All time of day details (hence which lane description is to be used at a given time of day)

This is used to have the SPaT enable: Reversible Lanes Time of Day Parking Lanes Right on Red and other

Crossing lanes that vary with timeKey takeaway: SPaT contains more than simply the signal controller state

12

A typical ConnectsTo ExampleA common left turn with an admissive ahead lane and a protected left turn lane.

• Note: a connectsTo can connect to lanes in another intersection

Example Left Turn LaneWith two ConnectsTo entries

Group A &Group B

Group B

Egress LaneEg

ress

Lan

e

13

Pedestrian Crossing Examples• Crosswalk Lanes are typically just 2-node lanes.• Features like a safety island are added

using the same basic constructs as lanes (uses same attribute system).

• Considerable style variations exists at ends.• Scrambles (Barnes Dance) are

also easily supported.• Crosswalk Lanes also have attributes

to support ADA accessibility issues.

14

Aside: Several subtle issueswith angles are seen here

Tapers for complex lane shapes• Widths and Tapers are Often needed for Crosswalks• Here is a two-point lane in NY

15

Putting It all together• A typical MAP message has

One Intersection withMany Lanes (each with a LaneID, and GroupIDs, in its ConnectsTo)

• A typical SPaT message has One Intersection (may not be one signal controller)

Active Movements (each with TimeMarks for GroupIDs

• MAP and SPaT are part of the Intersection safety PSID / App • Signal Request and Signal Status (not covered) provide priority and preemption

support. The Intersection Collision msg provides safety alerts. • To place a BSM on a map; Subtract anchor point from BSM data, scale by local rate. • On-line graphics from XML spy: http://dsrc-tools.com/xml/dsrc_70/dsrc/

16

Creating MAPs/SPaTs, the key steps

1. Gather map source materials, signal timing plan, and local signage.

2. Capture Centerlines / Widths / Stop Lines (with suitable GIS tools, KML, JSON, etc, and not ASN)

3. Add all Needed Attributes (weak tool support at this point, often added by hand)

4. Extract XML/JSON in full floating point precision (and do datum transformations, capturing the process details)

5. Reduce to ASN(and Merge Attributes if not done above)(filter unused lane content as needed here)

6. QC the work !!

• Perhaps do one/two in work shots of such tools as side slides.

17

A “Good” map has these testable features

• First and foremost: Only the content you need for your applications,Not every lane with every possible detail.

• Well formed ASNusing the correct compression choices (well encoded)

• Correctly placed stop lines and angles• Small Inter-lane to lane gaps under ~50cm• Spatial accuracy in the range of 20~40 cm absolute position

• Traceability to the source maps, the datum used, and coordinate transformation used, and the author

18

Pragmatic Deployment Advice for the Challenge

• Use the official PSID: 0x84 (or one of the test ones).• Use the experimental Intersection ID value ranges.• Use the numbering practices being developed by SAE.• MAP & SPaT & BSM will need differential corrections

(RTCM) to work for some applications. • Decide who is signing each message (local or central).• Add local content when you feel you need it,

we are all still learning.

• When in doubt, just ask.

19

Resources, 1

The SAE J2735 DSRC Message Set Standard Available at: https://www.sae.org/standardsdev/dsrc/ In XML image form: http://dsrc-tools.com/xml/dsrc_70/dsrc/

Good GIS Background Materials Understanding Coordinate and Datum issues:

https://www.ngs.noaa.gov/datums/newdatums/FAQNewDatums.shtml Understanding Precise Distances with Vincenty Methods:

https://www.movable-type.co.uk/scripts/latlong-vincenty.html A useful Google Datum conformance paper:

http://www.hydrometronics.com/downloads/Web%20Mercator%20-%20Non-Conformal,%20Non-Mercator%20(notes).pdf

20

Resources, 2

3rd Party Tools Used In this Presentation (all but one are free) ANS.1 viewer: https://www.obj-sys.com/products/asn1ve/ (free limited feature edition)

Global Mapper: www.globalmapper.com/ (commercial tool)

QGIS: https://qgis.org/en/site/ (open source)

Leidos “ISD Message Creator” tool:https://webapp2.connectedvcs.com/ (open source)

Additional Commentary on Proper MAP/SPaT usage http://dsrc-tools.com/map-spat/ (contents draft)

21

Thank you

David KelleyITS Programs Manager, SubCarrier Systems Corp. (SCSC)626-513-7715 (Office)davidkelley@iTSware.net

Chuck FeliceUtah Department of Transportation

April 17, 2018

Creating Road Intersection MAP Data for MMITSS

“ The NMAP File”

UDOT’s Methodology in Creating NMAP Files

2

“Multi-Modal Intelligent Traffic Signal System is the next generation of traffic signal systems that seeks to provide a comprehensive traffic information framework to service all modes of transportation, including general vehicles, transit, emergency vehicles, freight fleets, and pedestrians and bicyclists in a connected vehicle environment.”

Transit Signal Priority (TSP): This application allows transit agencies to manage bus service by adding the capability to grant buses priority based on a number of factors. The application provides the ability for transit vehicles to communicate passenger count data, service type, scheduled and actual arrival time, and heading information to roadside equipment via an on-board device.”https://www.its.dot.gov/research_archives/dma/bundle/mmitss_plan.htm

• Designed and created at the University of Arizona by Larry Head

• UDOT is using MMITSS for TSP and broadcasting of SPaT and MAP information

What is MMITSS?

3

• An urban arterial west of downtown Salt Lake City 30 signalized intersections (25 have DSRC road side units) 11 miles long Varies from 5 to 7 lanes ADT: 18,000 to 40,000; 60,000 peak at I-215 Truck Traffic: 24% Econolite Cobalt and Intelight MaxTime controllers Full fiber connectivity

• Transit Signal Priority UTA Bus Route 217 Goal: Improve schedule reliability

from 88% to 94%

UDOT MMITSS Corridor: Redwood Road

4

• An ASCII text file which contains intersection map data required by MMITSS

• MMITSS uses NMAP files to create J2735 MAP Messages (March 2016 release)

• Components of the NMAP File

• Intersection Information• Identification Number• Intersection Attributes (bit field definitions)• Reference Point (latitude, longitude)

The MMITSS NMAP File

5

• Components of the NMAP File (cont’d)

• Approach Information• Number of Approaches in the intersection• Approach Type (approach or an egress)• Number of traffic lanes in the approach

The MMITSS NMAP File

6

• Components of the NMAP File (cont’d)

• Traffic Lane Information• Lane identification number• Lane type (numeric value 1 – 5, 1 = motorized vehicle lane)• Lane attributes (bit field definitions)• Lane width (centimeters)• Number of lane nodes for a specified lane• Lane node coordinates (latitude, longitude)• Number of connected lanes• Connected lane identifiers

The MMITSS NMAP File

7

• ESRI ArcMap GIS Application

• Google 6 Inch per Pixel Satellite Imagery (validated by field surveys)

• Microsoft Excel

• Notepad++ file editor

• NMAP File Parser / Validation (C++ application)

Software Tools and Imagery used in NMAP Creation

8

• Create road intersection reference point and lane nodes in ArcMap using Google imagery.

• Export reference point and lane node data and coordinates (latitude, longitude) to a Microsoft Excel worksheet.

• Add additional road intersection information to spreadsheet required for NMAP file format.

• Transfer data from worksheet to NMAP file (NMAP file is created by and edited within the Notepad++ file editor).

• Validate the NMAP file by processing it with the NAMP Parser / Validation application.

• NMAP file is now ready to used by the MMITSS software.

NMAP File Creation Workflow

9

NMAP File Creation Workflow

ESRI ArcMAP Screen

10

NMAP File Creation Workflow

Microsoft Excel Worksheet

11

NMAP File Creation Workflow

12

NMAP File Creation Workflow

NMAP File being edited in Notepad++

13

NMAP File Creation Workflow

MAP_Name 4610SouthRedwoodRoadReduced.nmapRSU_ID 4610SouthRedwoodRoadIntersectionID 7605Intersection_attributes 00110011 /* elevation: Yes, lane width: Yes, Node data 16 bits, node offset solution: cm, geometry: Yes, navigation: Yes */Reference_point 40.6698353 -111.9388660 13110 /* lat, long, elevation (in decimeters) */No_Approach 8Approach 1Approach_type 1 /* 1: approach, 2: egress */No_lane 2Lane 1.1Lane_ID 1Lane_type 1 /* 1 to 5, for this intersection all 1: motorized vehicle lane */Lane_attributes 0000000000101010 /* Approach path, straight permitted, right turn permitted, no u-turn, turn on red, */Lane_width 365 /* in centimeter = 12 feet */No_nodes 21.1.1 40.6698529 -111.93866331.1.2 40.6698459 -111.9369704No_Conn_lane 26.1 4 /* Lane 1.1, Straight ahead */8.1 3 /* Lane 1.1, Right turn */end_laneLane 1.2Lane_ID 2Lane_type 1 /* 1 to 5, for this intersection all 1: motorized vehicle lane */Lane_attributes 0000000001010100 /* Approach path, left turn permitted, yield, u-turn allowed, no turn on red */Lane_width 305 /* in centimeter = 10 feet */No_nodes 21.2.1 40.6698201 -111.93866371.2.2 40.6698190 -111.9384932No_Conn_lane 14.3 2 /* Lane 1.2, Left Turn */end_laneend_approach..end_map

MMITSS NMAP File

14

NMAP File Creation Workflow

NMAP File Validation Application

15

Small Road Intersection

16

Large Road Intersection

17

Lessons Learned

• Good informative documentation is a must. Much time was spent determining what needed to be in the NMAP file: where information for the attribute bit field attributions could be found; how many lane nodes should be created for each lane; and other “gotcha’s”. Searching on the internet was done to obtain the above mentioned information along with making phone calls to people. Better documentation could have solved these problems and lessened the learning curve on how to create a NMAP file.

• NMAP file size is limited to approximately 1300 bytes. This limitation is due to the message packet size being sent from one DSRC radio to another DSRC radio. This size limitation issue required the number of lane nodes to be kept at a minimum. Future MapData compression algorithms should reduce these size limitations.

• The manual workflow process has given insight into how the process could be sped up using software to automate many of the tasks in creating a NMAP file.

• Intersections under construction.

18

UDOT MMITSS Corridor: Provo, Utah Bus Rapid Transit Project

• An urban arterial in downtown Provo and Orem, Utah• 47 signalized intersections with DSRC road side units• Approximately 12 miles long• Varies from 3 to 9 lanes• Econolite Cobalt controllers• Full fiber connectivity• Goal: Schedule reliability at 94%

19

UDOT MMITSS Corridor: Provo, Utah Bus Rapid Transit Project

North

20

Road Intersection under Construction

21

Road Intersection under Construction

22

Road Intersection under Construction

23

Future Needs

• Best Practices Guide for collecting intersection geometry

• Best Practices Guide for creating MAP Data.

• Methodology for automating MAP Data messages / file creation

• Validation of MAP Data Messages / files.

• Human readable form of MAP Data (XML / JSON).

24

• “MMITSS Final ConOps Applications User Guide” – University of Arizona and others, Version 3.0, October 21, 2012

• “MMITSS Field Applications User Guide” – University of Arizona, Version 1.0, July 7, 2015

• “Signal Phase and Timing and Related Message Binary Format (BLOB) Details” – FHWA Office of Operations Research and Development, Draft February 17, 2012

• An example of a NMAP file – “MMITSS Source Code Configuration Files directory”

Documents Referenced for NMAP File Creation

25

Questions?

Chuck FeliceUtah Department of Transportationcfelice@utah.govPhone: 801-718-4327

Utilizing RTCM Corrections via DSRC to Improve Vehicle Localization

Greg LarsonCaltrans Division of Research, Innovation and System

Information (DRISI)April 17, 2018

Background

• Many connected vehicle applications rely on continuous, reliable, and accurate vehicle localization (i.e., positioning)

• Standard DSRC OBU contains GPS; however, the position information is not always reliable and accurate

• It is possible to broadcast RTCM corrections via DSRC to improve reliability and accuracy

How Does GPS Works?• The Global Positioning System (GPS) is

a network of 31 satellites orbiting the Earth– Check online the total number of

operational GPS satellites• Each satellite transmits signal about its

position and the current time at regular intervals

• A GPS receiver needs at least 4 satellites to determine its location using triangulation– Source: http://giscommons.org/chapter-2-

input/

• One satellite locates you somewhere on a sphere• Two satellites intersection places you on a circle • Three satellites intersection places you on two possible

points• The last satellite gives you the exact location

GPS Accuracy• The basic GPS service provides users

with approximately 10 meter accuracy, 95% of the time

• However, any given position may result in accuracy as low as 5 meters or up to 40 meters

• Many factors can affect the accuracy of GPS data– Number of visible satellites (at least 4,

preferable 7+, the more the better)– Satellite geometry (spread apart vs.

clustered)– Multipath effect– ……

Good Poor

Source: https://gisgeography.com/gps-accuracy-hdop-pdop-gdop-multipath/

GPS Position Correction

• Position correction techniques use two GPS receivers to improve accuracy– A stationary GPS receiver, known as the base station, takes accurate

measurements of error, and sends the correction data to a roving GPS receiver

– The roving GPS receiver applies the corrections– Both receivers need to detect the same

satellite signals• Common position correction techniques

– DGPS – Differential GPS (sub-meter accuracy)– RTK – Real-Time Kinematic (centimeters)

Source: http://www.esri.com/news/arcuser/0103/differential1of2.htmlWe are using

Networked Transport of RTCM via Internet Protocol (NTRIP)

• NTRIP is an application-level protocol for streaming position correction data (DGPS or RTK) over the Internet, in accordance with specifications published by RTCM

• NTRIP streaming system consists of– NtripSources, generating data streams from base stations;– NtripServers, transferring data streams from a source to

NtripCaster;– NtripCaster, the major system component; and– NtripClients, receiving data streams of desired NtripSources

available on the NtripCaster– Source: BKG

• NTRIP is an open standard protocol and there are open source NTRIP streaming software packages available

NTRIP Streaming Data Message Format (RTCM Standard 10403.x)

• RTCMv3 defines new message data structure for RTK applications, and supports GPS and GLONASS RTK operations– RTCM DGNSS Standards

• Message types in RTCMv3 have been structured in different groups• For proper operation, the provider must transmit at least one

message type from each of the following groups:– Observations,– Station Coordinates, and– Antenna Description

RTCMv3 RTK Message GroupsGroup Name Message Type Message Description

Observations 1001 L1-Only GPS RTK Observables

1002 Extended L1-Only GPS RTK Observables

1003 L1&L2 GPS RTK Observables

1004 Extended L1&L2 GPS RTK Observables

1009 L1-Only GLONASS RTK Observables

1010 Extended L1-Only GLONASS RTK Observables

1011 L1&L2 GLONASS RTK Observables

1012 Extended L1&L2 GLONASS RTK Observables

Station Coordinates 1005 Stationary RTK Reference Station ARP

1006 Stationary RTK Reference Station ARP with Antenna Height

Antenna Description 1007 Antenna Descriptor

1008 Antenna Descriptor & Serial Number

Minimum Requirement

Note: Within each Message Group, the higher the Message Type number, the larger the message size. A longer message contains the shorter message plus additional information to enhance the performance.

Broadcast RTCM over DSRC

• NTRIP streaming system utilizes RTCMv3

• Over-the-air RTCM utilizes SAE J2735 message frame

• Requires NtripClient to encapsulate the received NTRIP-RTCMv3 in SAE J2735 message frame– Option I – Utilizing RSU ’s RTCM

application (serve as NtripClient)– Option II – Hosting NtripClient in a

separate processor (if desired) and utilizing RSU’s Immediate Forward application for broadcast over-the-air

• DSRC RTCM Message Frame

RTCMv3

Steps to Enable Broadcast RTCM over DSRC1. Identify base station(s) near your implementation site (within 50 km and supporting

NTRIP-RTCMv3)2. Create an account for NTRIP-RTCMv3 data streaming service

– There are base stations that provide free streaming service– Global List of Real-Time GNSS Data Streams From NTRIP Broadcasters

3. Set up NTRIP streaming system on a Linux server computer– Download open source NtripServer and NtripCaster (Various options are available online. This is

what is being used in the California CV Test Bed)– Follow the README instructions to configure connections with the NTRIP-RTCMv3 streaming

service at your desired based station(s)– Start NtripServer and NtripCaster, and verify NtripCaster is receiving data streams from your

desired base station(s)• The whole process is straight-forward; no knowledge of NTRIP, RTCMv3, and SAE J2735 is

required

Implementation Options• Option I – Utilizing RSU ’s RTCM application as NtripClient

– Suitable for implementations that do not require a standalone processor other than RSU and traffic signal controller

– Configure RSU’s RTCM application to connect with NtripCaster for receiving NTRIP-RTCMv3 data streams. The application handles SAE J2735 encapsulation and over-the-air broadcasting

• Option II – Hosting NtripClient in a separate processor– Suitable for implementations that require a standalone processor to host CV-based

signal control applications (e.g., MMITSS)– Download and run open source NtripClient– Encapsulate NTRIP data streams in SAE J2735 message frame– Configure RSU’s Immediate Forward application for over-the-air broadcasting– California CV Test Bed uses this option to gain more control on data sources

California Connected Vehicle Test Bed

• First-in-the-nation (2005) facility for testing CV applications using DSRC on public roads

• 2.1 miles long with 11 consecutive intersections; 6 more planned

• AADT: about 50K vehicles each day• Managed by UC Berkeley PATH• Running MMITSS-CA applications bundle

• I-SIG: BSM-based vehicular phase call and extension• TSP: Transit signal priority• FSP: Freight signal priority• PED-SIG: partner with Savari SmartCross Application

California Connected Vehicle Test Bed (Cont’d)

• Test bed website: http://caconnectedvehicletestbed.org/– Real-time test bed health status– User guide and FAQ– Data samples

Current Plan for Spring 2018

# of Intersections 11 17

Roadside Unit (RSU) Version 3.1 Version 4.1

Roadside Processor Ubuntu 16.04.4 (latest)Linux kernel 4.13.0 (latest)

Broadcast Messages MAP, SPaT, SSM, and RTCM

SAE J2735 Standard Version 2016-03 (latest)

Backhaul 4G/LTE

DSRC Messaging at California CV Test Bed

Message Abbreviation From Frequency To Channel PSID (Hex)

DSRC Message

ID

Basic Safety Message BSMOBU

10 HzRSU

172

0p20 (0x20) 20

Signal Request Message SRM Asynchronous

0p80-02 (0x82)

29

MAP/GID MAP

RSU

1 Hz

OBU

18

Signal Phase and Timing SPaT 10 Hz 19

Signal Status Message SSM 1 Hz 30

RTCM Corrections Message RTCM

Type 1004 – 5 Hz

182 0p80-01 (0x81) 28Type 1006 – 2 Hz

Type 1008 – 2 Hz

RTCM-NTRIP Implementation at California CV Test Bed

• Base Station (NTRIP Server): JRSC– Cooperatively operated by UC

Berkeley and Stanford University – Located at Jasper Ridge Biological

Preserve, Stanford, CA– About 5 miles west of the CV Test Bed– RTCMv3 type 1004, 1006, and 1008– Broadcasting at 1 Hz

• NTRIP Caster located at UC Berkeley PATH Headquarters

• NTRIP Client hosted by intersection MMITSS roadside processor

NTRIP Caster

Architecture

• Networked Transport of RTCM via Internet Protocol (NTRIP)– Streaming of

differential GPS correction data over the Internet

– RTK Base Station sends corrections to NTRIP Caster, enabling the NTRIP Caster to broadcast to all connected NTRIP clients

Architecture (Cont’d)

• Roadside Unit (RSU) is equipped with NTRIP Client to receive corrections from NTRIP Caster– RTCMv3

• RTCM is encoded into SAE J2735 message and broadcast over DSRC

• Onboard Unit (OBU) receives SAE J2735 message via DSRC, and decodes the message to correct the GPS position

NMEA

Apply RTCM Corrections to OBU GPS Receiver• This is where things get a bit complicated• It requires RTK-enabled GPS receiver to utilize over-the-air RTCM

corrections• The RTK-enabled GPS receiver applies RTCM corrections to the GPS data

and outputs position with corrections• Although OBU’s GPS chip may be capable of supporting RTCM corrections,

the application has not yet been implemented and enabled• Ideally, we would need OBU’s RTCM-correction application to support

position correction• Optionally, we can connect a RTK-enabled GPS receiver to the OBU for

achieving position correction with over-the-air RTCM

Understand the Effectiveness of Position Corrections with RTCM over DSRC

• The effectiveness of position corrections with over-the-air RTCM depends on various factors

• California is conducting experimental study to quantify the effectiveness of position corrections with RTCM over DSRC, which could provide reference for other SPaT Challenge implementations

• For research purposes, an RTK-enabled GPS and a laptop are used for the experimental system

• We are expecting RTCM-correction applications to be supported by OBUs in the near future

Positioning Experiments

DGPS (WAAS) w/ RTCMv3

Static Dynamic Static Dynamic

Open Sky UCR, completed UCR, completed UCR, completed UCR, planned

Rural Canyons UCR, completed UCR, completed UCR, planned UCR, planned

• Nearly all DSRC OBU devices utilize WAAS-corrected DGPS, typically providing 2-5 meter accuracy in Open Sky

• RTCMv3 provides correction information, communicated as a DSRC message

• Positioning experiments underway: