Research, Development, and Technology

Turner-Fairbank Highway Research Center

6300 Georgetown Pike

McLean, VA 22101-2296

PUBLICATION NO. FHWA-HRT-23-030 MARCH 2023

Sharing and Using Connected Device Data 

to Improve Traveler Safety and Traffic 

Management—Concept of Operations, 

Use Cases, Traveler Information Needs, 

Messages, and Requirements
FOREWORD

New and emerging sources of data generated from travelers using mobile devices, vehicles, 

infrastructure, and other sources provide agencies with opportunities to change how they manage 

traffic and their transportation systems. These data sources offer agencies an incentive to 

enhance or develop the capabilities of their transportation management systems to collect, 

compile, save, use, and share the data.

The Federal Highway Administration Office of Safety Operations, Research and Development 

(HRSO-1) is pleased to present this report, which provides information and strategies that can 

assist agencies as they evaluate, plan, or explore efforts associated with electronic message 

sharing in support of improving the safety, mobility, and experience of travelers using mobile 

devices.

Brian Cronin, P.E. 

Director, Office of Operations

Research and Development

Notice

This document is disseminated under the sponsorship of the U.S. Department of 

Transportation in the interest of information exchange. The U.S. Government assumes no 

liability for the use of the information contained in this document. 

The U.S. Government does not endorse products or manufacturers. Trademarks or 

manufacturers’ names appear in this report only because they are considered essential to the 

objective of the document. 

Quality Assurance Statement

The Federal Highway Administration (FHWA) provides high-quality information to serve 

Government, industry, and the public in a manner that promotes public understanding. 

Standards and policies are used to ensure and maximize the quality, objectivity, utility, and 

integrity of its information. FHWA periodically reviews quality issues and adjusts its 

programs and processes to ensure continuous quality improvement. 
TECHNICAL REPORT DOCUMENTATION PAGE

1. Report No.

FHWA-HRT-23-030

2. Government Accession No. 3. Recipient’s Catalog No.

4. Title and Subtitle

Sharing and Using Connected Device Data to Improve 

Traveler Safety and Traffic Management—Concept of 

Operations, Use Cases, Traveler Information Needs, 

Messages, and Requirements

5. Report Date

March 2023 

6. Performing Organization Code:

7. Author(s)

Theodore Smith (0000-0002-0523-3634), Chris Toth (0000-

0002-385-7083), and Tom Timcho (0000-0001-6553-3930) 

8. Performing Organization Report No.

9. Performing Organization Name and Address

WSP USA under contract to:

Cambridge Systematics, Inc.

101 Station Landing Suite 410

Medford, MA 02155

10. Work Unit No.

11. Contract or Grant No.

DTFH61-16-D-00051 T-0005

12. Sponsoring Agency Name and Address

Office of Operations, Research, and Development

Federal Highway Administration

6300 Georgetown Pike

McLean, VA 22101-2296

13. Type of Report and Period Covered

Final Report; September 2017–December 2022

14. Sponsoring Agency Code

HRSO-50

15. Supplementary Notes

The contracting officer’s representative was Jon Obenberger (HRSO-50; ORCID: 0000-0001-9307-847X).

16. Abstract

The ability to exchange electronic messages with mobile devices in realtime can to improve travel safety, mobility,

and the experience for users of the surface transportation systems. Intelligent transportation system devices and 

traffic management systems using information derived from electronic messages travelers, vehicles, and other 

sources agree to offer new options for agencies to consider how to improve how they manage traffic and travelers. 

This report provides information and strategies that can assist agencies as they evaluate, plan, or develop efforts 

associated with electronic message sharing with mobile devices. As an introduction to the topic, the report 

provides an overview of the components involved with sharing and using these electronic messages and the needs 

of travelers to process and use this information.

17. Key Words

Connectivity, electronic messages, data sharing and 

uses, use cases, mobile devices, real-time data

18. Distribution Statement

No restrictions. This document is available to the public 

through the National Technical Information Service, 

Springfield, VA 22161.

http://www.ntis.gov

19. Security Classif. (of this report)

Unclassified 

20. Security Classif. (of this page)

Unclassified

21. No. of Pages

236 

22. Price

N/A

Form DOT F 1700.7 (8-72) Reproduction of completed page authorized
ii

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
iii

TABLE OF CONTENTS

CHAPTER 1. INTRODUCTION ................................................................................................ 1

Sharing of Electronic Messages with Connected Mobile Devices ...................................... 2

Current Capabilities ............................................................................................................... 4

Purpose of This Report ........................................................................................................... 5

Intended Audience and How to Use the Report ................................................................... 5

Document Organization ......................................................................................................... 6

CHAPTER 2. MOBILE DEVICE DATA SHARING AND USES .......................................... 9

Chapter Overview ................................................................................................................... 9

Sharing Information with Travelers ................................................................................... 10

Electronic Data Exchanges ................................................................................................... 11

Websites ............................................................................................................................ 11

Smartphone Apps .............................................................................................................. 12

RFID ................................................................................................................................. 12

NFC ................................................................................................................................... 12

Stored-Value Payment Cards ............................................................................................ 12

Mobile Devices ....................................................................................................................... 13

Enabling Electronic Message Sharing with Mobile Devices ............................................. 15

Electronic Messages.......................................................................................................... 16

Software and Hardware ..................................................................................................... 19

Communication ................................................................................................................. 20

Preparing for Successful Operations .................................................................................. 21

CHAPTER 3. CONCEPT DEVELOPMENT .......................................................................... 25

Chapter Overview ................................................................................................................. 25

User Classes ........................................................................................................................... 25

Pedestrian .......................................................................................................................... 26

Bicyclist ............................................................................................................................ 26

Traveler Using Personal Vehicle ...................................................................................... 27

Traveler Using Transit ...................................................................................................... 27

Traveler Using Ride-Hailing Service ................................................................................ 28

Traveler Using Shared Mobility ....................................................................................... 29

Traveler with Disabilities .................................................................................................. 29

Multimodal Traveler ......................................................................................................... 29

Use Cases................................................................................................................................ 30

Place Pedestrian Phase Call .............................................................................................. 30

Pedestrian in Crosswalk Intersection Safety ..................................................................... 31

Place Bicycle Phase Call................................................................................................... 31

En route Adjustment for a Driving Trip (Alternate Route) .............................................. 32

Driving Wayfinding—Tailored Roadway Signage .......................................................... 32

Provision of Toll Facility Information .............................................................................. 33

Adjust Transit Operations (Connection Protection) ......................................................... 33

Driver Notification of Passenger Waiting at Stop ............................................................ 34

Reserving Use of a Shared Mobility Device ..................................................................... 34

Transit Fare Payment (Pay When Boarding/Pay at Fare Gate) ........................................ 35
iv

Pay for Parking ................................................................................................................. 35

Expected Issues and Challenges .......................................................................................... 36

Travelers’ Needs for Information and Decisionmaking ................................................... 36

Electronic Messages.......................................................................................................... 36

Software and Hardware..................................................................................................... 37

Communication ................................................................................................................. 37

Agency Management Systems .......................................................................................... 38

CHAPTER 4. INFORMATION NEEDS OF TRAVELERS USING CONNECTED 

MOBILE DEVICES ................................................................................................................... 39

Chapter Overview ................................................................................................................. 39

How Travelers Use Information .......................................................................................... 39

Types of Information for Decisionmaking .......................................................................... 40

Safety Information ............................................................................................................ 40

Mobility Information ........................................................................................................ 40

Trip Planning Information ................................................................................................ 40

Information to Provide to Travelers Using Mobile Devices ............................................. 41

Spatial and Temporal Aspects of Decisionmaking ............................................................ 42

Spatial and Temporal Information Using Mobile Devices................................................ 42

Positive Guidance .................................................................................................................. 42

Positive Guidance Techniques .......................................................................................... 43

Positive Guidance in Mobile Devices ............................................................................... 44

CHAPTER 5. DEVELOPING A DESIRED OPERATING ENVIRONMENT ................... 45

Chapter Overview ................................................................................................................. 45

Planning ................................................................................................................................. 45

Metropolitan Transportation Plan ..................................................................................... 46

TSMO Plans ...................................................................................................................... 46

SE Process .............................................................................................................................. 47

Regional Architecture Development ................................................................................. 48

Project Purpose and Objectives ........................................................................................ 48

Feasibility/Concept Exploration ....................................................................................... 48

ConOps ............................................................................................................................. 49

System Requirements........................................................................................................ 51

Validation and Verification ............................................................................................... 51

System Design .................................................................................................................. 52

Testing............................................................................................................................... 53

Integration and Verification .............................................................................................. 53

Deployment ....................................................................................................................... 53

Validation .......................................................................................................................... 53

Operations and Maintenance (O&M) ............................................................................... 53

Agile Development Process .................................................................................................. 53

CHAPTER 6. CONOPS ............................................................................................................. 55

Chapter Overview ................................................................................................................. 55

Concept of Operation Scope ................................................................................................ 56

Current Operating Environment ........................................................................................ 56

Justification for Changes and User Needs .......................................................................... 58
v 

Desired Operating Environment ......................................................................................... 59

Operational Scenarios .......................................................................................................... 60

Validation............................................................................................................................... 62

Concepts Developed in this Document ................................................................................ 62

CHAPTER 7. REQUIREMENTS FOR SHARING ELECTRONIC MESSAGES WITH 

MOBILE DEVICES ................................................................................................................... 65

Chapter Overview ................................................................................................................. 65

System Requirements Scope ................................................................................................ 66

System Requirements ........................................................................................................... 66

Verification Methods ............................................................................................................ 69

Needs-to-Requirements Traceability .................................................................................. 70

CHAPTER 8. CONCEPT 1: TRAVELER WALKING AND USING A CONNECTED 

MOBILE DEVICE...................................................................................................................... 73

Changes Considered but not Included ................................................................................ 73

Chapter Overview ................................................................................................................. 73

Existing Conditions ............................................................................................................... 73

Justification for Changes ...................................................................................................... 74

Description of Desired Changes ........................................................................................... 75

Priorities Among Changes ................................................................................................ 78

Assumptions and Constraints ............................................................................................ 78

Proposed Operating Environment ...................................................................................... 78

Interfaces ........................................................................................................................... 79

Hardware ........................................................................................................................... 80

Messages ........................................................................................................................... 81

Facilities and External Systems ........................................................................................ 82

Modes of Operation .............................................................................................................. 82

User Classes and Involved Personnel .................................................................................. 84

Support Environment ........................................................................................................... 84

Operational Scenarios .......................................................................................................... 84

Use Case 1—Scenario 1.................................................................................................... 85

CHAPTER 9. CONCEPT 2: TRAVELER RIDING ON A BICYCLE AND USING A 

CONNECTED MOBILE DEVICE ........................................................................................... 99

Chapter Overview ................................................................................................................. 99

Existing Conditions ............................................................................................................... 99

Justification for Changes .................................................................................................... 101

Description of Desired Changes ......................................................................................... 101

Priorities Among Changes .............................................................................................. 102

Changes Considered But Not Included ........................................................................... 103

Assumptions and Constraints .......................................................................................... 103

Proposed Operating Environment .................................................................................... 103

Interfaces ......................................................................................................................... 104

Hardware ......................................................................................................................... 104

Messages ......................................................................................................................... 105

Facilities and External Systems ...................................................................................... 106

Modes of Operation ............................................................................................................ 106
vi 

User Classes and Involved Personnel ................................................................................ 106

Support Environment ......................................................................................................... 107

Operational Scenarios ........................................................................................................ 107

Use Case 2—Scenario 1 and Scenario 2 ......................................................................... 107

Use Case 2—Scenario 2.................................................................................................. 116

CHAPTER 10. CONCEPT 3: TRAVELER USING PUBLIC TRANSIT WHILE USING A 

CONNECTED MOBILE DEVICE ......................................................................................... 127

Chapter Overview ............................................................................................................... 127

Existing Conditions ............................................................................................................. 127

Justification for Changes .................................................................................................... 128

Description of Desired Changes ......................................................................................... 130

Priorities Among Changes .............................................................................................. 133

Changes Considered But Not Included ........................................................................... 133

Assumptions and Constraints .......................................................................................... 133

Proposed Operating Environment .................................................................................... 134

Interfaces ......................................................................................................................... 134

Hardware ......................................................................................................................... 135

Messages ......................................................................................................................... 136

Facilities and External Systems ...................................................................................... 138

Modes of Operation ............................................................................................................ 139

User Classes and Involved Personnel ................................................................................ 139

Support Environment ......................................................................................................... 140

Operational Scenarios ........................................................................................................ 141

Use Case 3—Scenario 1.................................................................................................. 142

Use Case 3—Scenario 2.................................................................................................. 153

Use Case 3—Scenario 3.................................................................................................. 162

Use Case 3—Scenario 4.................................................................................................. 170

CHAPTER 11. CONCEPT 4: TRAVELER RIDING IN A MOTOR VEHICLE USING A 

CONNECTED MOBILE DEVICE ......................................................................................... 187

Chapter Overview ............................................................................................................... 187

Existing Conditions ............................................................................................................. 187

Justification for Changes .................................................................................................... 188

Description of Desired Changes ......................................................................................... 189

Priorities Among Changes .............................................................................................. 191

Changes Considered But Not Included ........................................................................... 191

Assumptions and Constraints .......................................................................................... 191

Proposed Operating Environment .................................................................................... 192

Interfaces ......................................................................................................................... 192

Hardware ......................................................................................................................... 193

Messages ......................................................................................................................... 193

Facilities and External Systems ...................................................................................... 194

Modes of Operation ............................................................................................................ 195

User Classes and Involved Personnel ................................................................................ 195

Support Environment ......................................................................................................... 195

Operational Scenarios ........................................................................................................ 196

Use Case 4—Scenario 1.................................................................................................. 196
vii 

CHAPTER 12. CONCEPT IMPLEMENTATION ............................................................... 211

Chapter Overview ............................................................................................................... 211

Considerations for Local Agencies .................................................................................... 211

Identify Local Needs ....................................................................................................... 211

Establish a Working Group ............................................................................................. 212

Identify Regional Champion ........................................................................................... 212

Integrate with Existing Systems...................................................................................... 213

CHAPTER 13. SYSTEMS ISSUES TO CONSIDER............................................................ 215

Chapter Overview ............................................................................................................... 215

Operations Considerations ................................................................................................. 215

Organizational Considerations .......................................................................................... 216

Considerations During Development ................................................................................ 217

CHAPTER 14. ANALYSIS OF MOBILE DEVICE-BASED SYSTEMS ........................... 219

Chapter Overview ............................................................................................................... 219

Summary of Improvements ............................................................................................... 219

Disadvantages and Limitations.......................................................................................... 220

Alternatives and Tradeoffs Considered ............................................................................ 221

Performance Monitoring, Evaluation, and Reporting .................................................... 221

REFERENCES .......................................................................................................................... 223
viii

LIST OF FIGURES

Figure 1. Diagram. Mobile device communications with external systems. .................................. 4

Figure 2. Flowchart. Communications paths for mobile devices versus other technologies. ....... 14

Figure 3. Diagram. Vehicle operation primacy triangle (human factors).(11) ............................... 43

Figure 4. Diagram. SE Vee diagram.(14) ....................................................................................... 47

Figure 5. Diagram. ConOps in the SE process.(14) ........................................................................ 55

Figure 6. Diagram. System requirements in the SE process.(14) ................................................... 65

Figure 7. Screenshot. Needs-to-requirements traceability example. ............................................ 70

Figure 8. Diagram. Mobile device pedestrian system. .................................................................. 79

Figure 9. Diagram. Use Case 1—Scenario 1, steps 1–9. .............................................................. 86

Figure 10. Diagram. Use Case 1—Scenario 1, steps 10–18. ........................................................ 89

Figure 11. Diagram. Use Case 1—Scenario 1, steps 19–23. ........................................................ 92

Figure 12. Diagram. Use Case 1—Scenario 1, steps 24–30. ........................................................ 94

Figure 13. Diagram. Use Case 1—Scenario 1, data flows between four sources......................... 97

Figure 14. Photograph. Cyclist waiting at signalized intersection.............................................. 100

Figure 15. Photograph. Pedestrian/bicycle crossing with pushbutton-activated warning 

lights. ................................................................................................................................. 100

Figure 16. Diagram. Mobile device bicyclist system. ................................................................ 103

Figure 17. Diagram. Use Case 2—Scenario 1, four sources. ..................................................... 115

Figure 18. Diagram. Use Case 2—Scenario 2, four sources. ..................................................... 124

Figure 19. Diagram. Mobile device transit user system. ............................................................ 134

Figure 20. Diagram. Use Case 3—Scenario 1, data flows of steps 1–12. .................................. 144

Figure 21. Diagram. Use Case 3—Scenario 1, data flows of steps 13–24. ................................ 148

Figure 22. Diagram. Use Case 3—Scenario 1, four sources. ..................................................... 152

Figure 23. Diagram. Use Case 3—Scenario 2, steps 1–16. ........................................................ 154

Figure 24. Diagram. Use Case 3—Scenario 2, sources. ............................................................. 161

Figure 25. Diagram. Use Case 3—Scenario 3, steps 15–20. ...................................................... 164

Figure 26. Diagram. Use Case 3—Scenario 3, sources. ............................................................. 169

Figure 27. Diagram. Use Case 3—Scenario 4, steps 17–26. ...................................................... 171

Figure 28. Diagram. Use Case 3—Scenario 4, sources. ............................................................. 185

Figure 29. Diagram. Mobile device driver system. .................................................................... 192

Figure 30. Diagram. Use Case 4—Scenario 1, steps 23–26. ...................................................... 197

Figure 31. Diagram. Use Case 4—Scenario 1, steps 27–37. ...................................................... 206

Figure 32. Diagram. Use Case 4 – Scenario 1, sources. ............................................................. 209
ix

LIST OF TABLES

Table 1. Scope content for a ConOps. .......................................................................................... 56

Table 2. Current operating environment contents. ........................................................................ 57

Table 3. Justification for changes and user needs contents. ......................................................... 58

Table 4. Desired operating environment contents. ....................................................................... 60

Table 5. Types of requirements. ................................................................................................... 67

Table 6. Verification methods. ...................................................................................................... 69

Table 7. Pedestrian user needs. ..................................................................................................... 76

Table 8. Use Case 1—Scenario 1 details for each source, steps 1–9, key action, and 

associated comments. .......................................................................................................... 87

Table 9. Use Case 1—Scenario 1 details for each source, steps 10–18, key action, and 

associated comments. .......................................................................................................... 90

Table 10. Use Case 1—Scenario 1 details for each source, steps 19–23, key action, and 

associated comments. .......................................................................................................... 93

Table 11. Use Case 1—Scenario 1, steps 24–30. ......................................................................... 95

Table 12. Use case 1—Scenario 1, steps 31–34. .......................................................................... 96

Table 13. Bicyclist user needs. ................................................................................................... 101

Table 14. Use Case 2—Scenario 1 details for each source, steps 1–15, key action and 

associated comments. ........................................................................................................ 109

Table 15. Use Case 2—Scenario 1 details for each source, steps 1–20, key action, and 

associated comments. ........................................................................................................ 111

Table 16. Use Case 2—Scenario 2, steps 1–38. ......................................................................... 118

Table 17. Transit user needs. ...................................................................................................... 130

Table 18. Use Case 3—Scenario 1, steps 1–12. ......................................................................... 145

Table 19. Use Case 3—Scenario 1, steps 13–24. ....................................................................... 149

Table 20. Use Case 3—Scenario 2, steps 1–16. ......................................................................... 155

Table 21. Use Case 3—Scenario 3, steps 1–28. ......................................................................... 165

Table 22. Use Case 3—Scenario 4, steps 1–51. ......................................................................... 172

Table 23. Driver user needs. ....................................................................................................... 190

Table 24. Use Case 4—Scenario 1, steps 1–26. ......................................................................... 198

Table 25. Use Case 4—Scenario 1, steps 27–37. ....................................................................... 204

Table 26. Use Case 4—Scenario 1, steps 38–41. ....................................................................... 207
x 

LIST OF ACRONYMS

3G third generation 

4G fourth generation

5G fifth generation 

API application programming interface

ATTRI Accessible Transportation Technology Research Initiative

BIM basic information message

BSM basic safety message

CAM cooperative awareness message

CANbus Controller Area Network bus

CAV connected autonomous vehicles

ConOps concept of operations 

CORS continuously operating reference station

CV connected vehicle

C-V2X cellular vehicle-to-everything 

DENM decentralized environmental notification message

DMS dynamic message sign 

DSRC dedicated short-range communications 

ETSI European Telecommunications Standards Institute

FCC Federal Communications Commission

FHWA Federal Highway Administration

GNSS Global Navigation Satellite System 

HMI human-machine interface

HOT high-occupancy toll

ID identification

IT information technology 

ITS intelligent transportation system

LTE long-term evolution 

MAP map data message

MMTP multimodal trip planner 

MPO metropolitan planning organization 

MUTCD Manual on Uniform Traffic Control Devices

NFCs near-field communications 

O&M operations and maintenance

OBU On-board unity

O/D origin-destination

PDM probe data management 

PII personally identifiable information

PSM personal safety message

PVD probe vehicle data

RFID radio-frequency identification

RSE roadside equipment

RSU roadside unit

RTCM Radio Technical Commission for Maritime Services

SE systems engineering 
xi 

SPaT signal phase and timing

SRM signal request message

SSM signal status message

SysRS systems requirements specification

TIM traveler information message

TMC traffic management center

TMS traffic management system

TSMO transportation systems management and operations 

V2X vehicle-to-everything 

VRU vulnerable road user

1 

CHAPTER 1. INTRODUCTION

In the context of this document, mobile devices are defined as computers that can connect to the 

Internet and with other local devices, both stationary (i.e., traffic signal) and mobile (i.e., 

connected vehicles (CVs) or other mobile devices). The device is expected to be small enough 

for a traveler to hold and operate in their hand (e.g., mobile device, tablet). The device would 

typically have a liquid crystal display or an organic light-emitting diode flat-screen interface, and 

it would provide a touchscreen interface with virtual buttons and a keyboard. The connectivity 

feature and the ability to exchange electronic messages with other devices in realtime is 

fundamental to the goal to improve traveler safety and the experience for surface transportation 

system users. Information derived from electronic messages that travelers, vehicles, and other 

sources generate new options for agencies to improve how they manage traffic and travel when 

they are connected to existing intelligent transportation system (ITS) devices and traffic 

management systems (TMSs).1 In addition, sharing electronic messages with mobile devices 

could be integrated into and used by TMS or transit management systems to support and enhance 

the performance of these systems while providing information that could support new services 

for travelers using a connected mobile device.

Although the concept of travelers agreeing to allow their connected mobile devices to share 

electronic messages with other connected mobile devices, connected and automated vehicles, or 

TMSs is still relatively new, early testing and research show the potential to improve traveler 

safety, mobility, and experience. Sharing and using these electronic messages offers users the 

following potential real-time and near-real-time applications: 

• Realtime—Roadway hazard monitoring, speed warnings, cooperative intersection

collision systems, probe data collection, and electronic payments. 

• Near realtime—Traffic incident management (e.g., identification and verification of 

incidents), traffic signal operation and control, ramp management (e.g., metering), lane

management, traffic information, weather monitoring, and parking management. 

When appropriately configured, TMSs could share electronic messages with travelers using

mobile devices to complete travel and traffic management-related tasks. Due to the many 

varieties of travelers using connected mobile devices, the information needed to share to support 

specific types of trips, operating environments, and desired outcomes, implementations may be 

unique to each agency. As such, agencies must understand the needs, implications, and resources 

that could be necessary to develop the ability to share and integrate electronic messages sent 

from connected mobile devices into managing and operating TMSs.

This report provides information for agencies to consider if they evaluate, plan, or pursue efforts 

to share electronic messages with travelers using connected mobile devices. This report also 

provides an overview of the components, technologies, and issues to consider when enabling 

1

As more connected devices of different forms become available and are integrated into daily activities, 

additional electronic messages become available. Some of these messages may require or facilitate user consent to 

share (at least initially), but many, such as those generated by CVs, are shared as a function of their use in the 

connected ecosystem.
2 

TMSs to share, collect, and process electronic messages with travelers using connected mobile 

devices. This report details the processes an agency could consider when developing a project or 

fostering an ecosystem to enable travelers using connected mobile devices to exchange electronic 

messages with TMSs and other service providers for a range of different services or scenarios 

(e.g., parking, incidents, travel time, roadway condition information, and other possible uses). 

These processes could be initiated with a planning study (e.g., feasibility study, planning project) 

or by the development of a project followed by additional design and eventual implementation. 

Agencies are encouraged to follow a structured systems engineering (SE) process to ensure the 

proposed effort would align with the agency, an operations program, or TMS goals and with the 

needs and expectations of travelers who use connected mobile devices and agree to share and use 

electronic messages.

The concept of operations (ConOps), scenarios, and use cases included herein demonstrate how 

technology can serve the needs of travelers who agree to allow their connected mobile devices to 

share and use electronic messages to improve their trips, depending on the TMS or transit

management system’s vision, objectives, and capabilities. Several concepts, scenarios, and use 

cases are provided as examples of how the SE process can be used to align the unique needs of 

an agency as it assesses the feasibility and plans for a prototype or deployment of project or 

initiative to enable its TMS and/or transit management systems to share and use electronic

messages with connected mobile devices.

SHARING OF ELECTRONIC MESSAGES WITH CONNECTED MOBILE DEVICES

The collection of electronic messages and their sharing among transportation agencies’ TMSs, 

travelers using connected mobile devices, and others managing or supporting travelers on the 

surface transportation network has historically relied on permanent or portable ITS devices 

(e.g., changeable message signs, portable changeable message signs, rotating signs). In the past, 

travelers obtained information and directions solely through traffic control devices (e.g., signs, 

pavement markings, changeable message signs). While transportation agencies could monitor 

system conditions and collect data through various ITS components and TMSs, one limitation of 

TMSs was the inability to shift the location of installed vehicle detectors, surveillance cameras, 

and other sensors. The advent and prevalence of cellular phones—and particularly 

smartphones—provide a significant opportunity for agencies to share and collect electronic 

messages with these mobile sources to improve how they manage and operate the surface 

transportation system.

The current functionality and data available to travelers through their smartphones is 

significantly greater than 10 yr ago and continues to advance. Travelers use smartphones with 

nearly every travel mode—automobile, pedestrian, bicycle, transit—to plan routes, make en 

route adjustments, and even pay for services. These functions are typically performed by using 

applications installed on a mobile device or by using data generated and transmitted wirelessly 

by a service provider (e.g., subscription or service fee). This wireless transmission of information 

to or from a traveler’s mobile device requires an Internet connection (e.g., Wi-Fi, third 

generation (3G)/fourth generation (4G), and Long-Term Evolution (LTE)), which is typically 

obtained through a paid subscription service from a data provider. Although there are limitations 

to these proprietary Internet access subscription services to allow mobile devices to share and 

receive electronic messages, the value of these data is apparent in the growing use of third-party 
3 

data aggregators. These third-party companies—through user agreements—compile and sell 

information based on the use of this archived data from individual app services that show user 

locations and routing data. 

While not commercially available, as defined in this document, a mobile device would possess 

the same general capabilities and features as a smartphone, with the added ability to 

communicate directly with other devices or local infrastructure via short-range wireless 

communication technologies. Previous CV demonstration projects have modified and enabled 

mobile devices to send and receive electronic messages (e.g., tethering smart phones with a 

dedicated short-range communications (DSRC) radio in the 5.9-GHz spectrum). The specific 

technology is not critical, however, as long as it is interoperable with other mobile devices.

Research has shown that this configuration of handheld mobile devices could further leverage 

electronic messages through direct device-to-device or device-to-infrastructure interfaces, which 

would increase the functionality available to both travelers and agencies.(1)

In addition to the features generally provided on today’s smartphones, a mobile device’s wireless 

communication may allow for the following key benefits:

• Communication of a device’s current location with a high degree of accuracy. 

• Communication of safety-critical information at low latency. 

• Communication with other devices without user input. 

An added benefit (or expectation) of the short-range feature of the mobile devices is that it does 

not require use of a traditional mobile Internet service provider (i.e., no data plan). Thus, the 

messages exchanges are “free” when thought of in the context of traditional cellular plans. 

Limitations exist, however, including the following two: 

• Global Navigation Satellite Systems (GNSS) (known as the Global Positioning System in 

the United States), which are often used to determine device location, are subject to 

reduced accuracy or no service when a mobile device is located inside of a traveling

vehicle, and even more so, when that vehicle is traveling in dense urban environments, 

tunnels, parking structures, and other locations where a clear sky is not available.

• The hardware that supports low latency information exchange was generally designed by 

using fixed location installation with reliable power, and it was not battery powered. This 

installation type may limit the operational time for these mobile devices.

Neither of these limitations prevents mobile devices from performing as indicated in most of the 

use cases. Limitations aside, these features of a connected mobile device allow it to share data on 

user surroundings, thus eliminating required user actions and broadening the availability of 

service to the user. Agencies that opt to deploy infrastructure that allows mobile devices to 

wirelessly connect with local infrastructure are then able to aggregate data to better understand 

traveler behavior and system performance.
4 

Figure 1 provides a simplified overview of the breadth of systems that a traveler with a 

connected mobile device could choose or elect to exchange electronic messages. Later chapters

in this report describe how sharing these electronic messages could occur, along with the 

requirements and resources (e.g., application programming interface (API), software, antennas to 

send and receive messages) to enable this exchange. 

Source: FHWA. 

Figure 1. Diagram. Mobile device communications with external systems.

CURRENT CAPABILITIES

The concept of sharing electronic messages with connected mobile devices to improve a TMS’ 

traffic management capabilities is still relatively new. Research has been conducted nationally on 

the data that may need to be shared to meet a traveler’s decision and information needs for 

specific trips or use cases.

2

Related to vulnerable road user (VRU) safety, several transportation agencies have commenced 

pilot deployments of these concepts beyond simply preliminary research. New York, NY, and 

Tampa, FL, have both initiated systems by using connected mobile devices in two similar

applications: mobile accessible pedestrian signals, and pedestrian-in-signalized-crosswalk

warnings.(2,3) A mobile accessible pedestrian signal system allows low-vision or blind 

pedestrians to request a pedestrian crossing from a traffic signal controller using a portable 

personal device (e.g., smartphone) and provides audible information to the pedestrians regarding

the signal status, thus improving their ability to safely cross the street. The pedestrian using a 

signalized crosswalk warning application uses mobile devices and pedestrian detection

2

Use cases are used to define the purpose of systems and software. Use cases are often characterized as 

scenarios that demonstrate the interaction of systems and software from the viewpoint of the user.
5 

infrastructure to deliver warnings to CVs, alerting the vehicles of pedestrians in the roadway. At

the same time, pedestrians who carry a mobile device could be warned of any vehicles nearing 

them by using the same direct wireless technology, which would allow the pedestrian to take 

action to avoid conflict.

Currently, while many service providers offer free traveler-related information, there is no 

standard for the exchange of electronic messages with travelers using connected mobile devices 

Instead, each agency would decide to work with users of connected mobile devices and 

companies that support mobile devices to enable the agency to share and/or collect data with 

these devices.

PURPOSE OF THIS REPORT

This report is intended to support public agencies interested in planning for or developing a 

project or initiative to enable a TMS or transit management system to share and collect data from 

a connected mobile device being used by a traveler. This report presents how the SE process, 

including the development of a ConOps, scenarios, use cases, and requirements could lead to the 

sharing and use of data generated by connected mobile devices and traffic and transit 

management systems. Specifically, the report performs the following actions: 

• Explores how ConOps and use cases could be developed or used when planning, 

developing, and designing projects to facilitate data sharing between connected devices,

vehicles, and TMSs. 

• Identifies how agencies could develop or use system requirements, electronic messages

and data elements, and other issues that support any project to share or collect data

between these devices, systems, and vehicles. 

The report identifies issues from previous research and development efforts to consider when

assessing the capability of current or any planned future improvements to an agency’s TMS and 

or transit management systems in support of collecting, saving, using, and sharing electronic 

messages with connected mobile devices. The SE concepts detailed in this report can be used to

support tracing the applicable vision, goals, and objectives that may exist within a strategic plan

to the expected outcomes and performance of a proposed project by developing ConOps and 

operational scenarios. Several examples are provided of how the SE process can be used to 

identify and address the issues unique to the environment, where a project is being contemplated 

to enable the sharing and use of electronic messages with a TMS or transit management systems. 

INTENDED AUDIENCE AND HOW TO USE THE REPORT

The target audience for this document is primarily transportation operations professionals

involved in managing, participating in, and/or supporting efforts that collect or share messages, 

compile data, and use this information in operating TMS, transit applications, or transit 

management systems. Although the range of users may be large, the primary audience is 

anticipated to be the following types of audience groups: 
6 

• Transportation agency information technology (IT) staff—IT staff involved with 

supporting the data management and security issues surrounding the data exchange. 

• Transportation agency project managers—Research and/or project managers charged 

with delivering a framework for the data exchange. 

• TMS leadership—Managers of the TMS who operate and oversee the data exchange.

Each of the aforementioned audience groups have different roles, responsibilities, and concerns, 

and each agency’s project or use case would differ. A reader may focus on individual chapters, 

depending on which information is most necessary from their individual role or responsibility to 

move a project forward. The use of this report may include gathering background information; 

learning the requirements needed to share electronic messages; planning and developing a 

project; or defining a process for developing user needs, scenarios, use cases, and requirements. 

As such, the report is organized in a manner that does not require it to be read cover to cover. 

Early chapters provide foundational information, and concept development is widely understood. 

Later chapters, which focus on specific use-case development and technical requirements, are 

intended for operations and SE staff. 

DOCUMENT ORGANIZATION

Each chapter of this report is described as follows: 

• Chapter 1. Introduction:

o Provides the motivation for this research effort. 

o Explains the scope of the document. 

o Presents the target audience and document organization. 

• Chapter 2. Mobile Device Data Sharing and Uses—Describes the operations of 

existing systems that motivate the development of the proposed mobile device-based 

system.

• Chapter 3. Concept Development—Presents considerations for developing mobile 

device-based system concepts.

• Chapter 4. Information Needs of Travelers Using Connected Mobile Devices:

o Outlines the types of information travelers need. 

o Outlines spatial and temporal aspects of decisionmaking. 

o Introduces the concept of positive guidance. 
7 

• Chapter 5. Developing A Desired Operating Environment:

o Discusses the process of developing and defining the scope of a project, which could 

occur during the concept stage of a project. 

o Introduces the SE processes that would allow the desired environment to be 

successfully realized.

• Chapter 6. ConOps: 

o Provides an approach to support evaluating what may be needed to enable TMSs and 

transit management systems to support collecting and sharing messages with 

connected mobile devices.

o Identifies and addresses typical issues encountered in studies to assess and evaluate 

what improvements could be needed to support use cases where connected devices 

may share data with TMSs. 

• Chapter 7. Requirements for Sharing Electronic Messages with Mobile Devices—

Identifies possible system requirements to enable TMS and transit management systems 

to share messages with connected mobile devices.

• Chapter 8. Concept 1: Traveler Walking and Using a Connected Mobile Device—

Explores the process and issues to consider with developing or using a use case specific

for TMS and transit management systems that share messages with a pedestrian’s 

connected mobile devices.

• Chapter 9. Concept 2: Traveler Riding on a Bicycle and Using a Connected Mobile 

Device—Explores the process and issues to consider with developing or using a use case 

specific for TMS and transit management systems that share messages with a bicyclist’s 

connected mobile device.

• Chapter 10. Concept 3: Traveler Using Public Transit while Using a Connected 

Mobile Device—Explores the process and issues to consider with developing or using a 

use case specific for TMS that share messages with a transit rider’s connected mobile 

device.

• Chapter 11. Concept 4: Traveler Riding in a Motor Vehicle Using a Connected 

Mobile Device—Explores the process and issues to consider with developing or using a 

use case specific for TMS and transit management systems that share messages with a 

driver’s connected mobile device.

• Chapter 12. Concept Implementation—Discusses items local/State agencies could 

consider in the planning and possible deployment of the concepts described in 

chapters 8–11. 
8 

• Chapter 13. Systems Issues to Consider—Presents the potential implications (e.g., 

operations, maintenance, and organizational impacts) of making the changes to a TMS 

and transit management system to collect and share messages with connected mobile 

devices.

• Chapter 14. Analysis of Mobile Device-Based Systems—Analyzes the benefits, 

limitations, advantages, disadvantages, and alternatives and tradeoffs considered for the 

proposed changes to a TMS and transit management system to collect and share 

messages with connected mobile devices.
9 

CHAPTER 2. MOBILE DEVICE DATA SHARING AND USES

CHAPTER OVERVIEW

Sharing information between a transportation agency, service provider, and travelers using 

connected mobile devices requires a complex system of components working together in a 

collective ecosystem. To successfully transmit and receive messages, each connected mobile 

device, system (e.g., TMS, transit management system), or component needs to serve a defined

role and contribute to the overall system. Understanding these components and their relationship

within the ecosystem is an important step before any project planning, SE, or design takes place.

This chapter provides a high-level overview of each component required within the mobile 

device data-sharing ecosystem, including the following elements: 

• Mobile devices—Hardware that enables the information sharing to/from the traveler. 

• Electronic messages—Information that is exchanged or shared between various devices. 

• Software—Program that generates or synthesizes the shared information for the benefit 

of the traveler or the system (TMS, and so forth). 

• Communication services—Medium over which information is exchanged, including 

security and latency. 

• TMS (or similar infrastructure systems or devices)—Platform that collects and 

synthesizes traveler data to monitor and manage operations and provide information to 

the traveler. 

Each of the aforementioned components can be satisfied from a range of various options 

(i.e., vendors), which could potentially result in numerous ecosystems that are unique 

combinations specific to the situation. Agencies must understand each component as it applies to 

the specific situation. This document does not convey any of these components, but simply 

describes what capabilities must exist to fulfil the exchanging of electronic messages with a 

mobile device used by a traveler. 

The computing hardware, software, messages, and communication services that comprise the 

mobile device, as well as the types of information exchanges, would need to be identified for 

each situation and location. This assessment would ensure that the needs specific to the location, 

the modes of travel, and the traveler’s desired actions are considered. Similarly, the interface to 

display information or allow for traveler interaction on the mobile device can also vary, based on 

the project. 

Although there are numerous types of standardized electronic message to support the exchange 

of information, each situation might involve different electronic messages. As an example, 

specific information in new types of electronic messages may be needed to obtain the status, 

location, or issue and to receive an active request (e.g., request walk indication at traffic signal). 

The ecosystem within which this exchange of electronic messages occurs includes the hardware
10 

(e.g., mobile device, ITS device), software (e.g., mobile device API, ITS device), and available 

communication methods to enable the transmission and receipt of these messages. This 

ecosystem enables an agency or service provider to collect, distribute, and store information 

generated from these messages in support of managing and operating these services.

Detailed descriptions and examples for each of these components follow. This information is 

provided to identify the current capabilities of a TMS (i.e., would the TMS enable the required 

transmission and receipt of electronic messages) to prepare, send, receive, process, and use data 

from electronic messages to carry out the required functions to incorporate this information into 

the mobile device and TMS operation. A standalone planning study would be appropriate to 

evaluate the needs of travelers, agency resources that may be needed, changes required to ITS 

devices and the TMS, and other issues to consider as a part of a larger project scope to develop 

and initiate the ecosystem to enable the exchange of these electronic messages. 

SHARING INFORMATION WITH TRAVELERS

Many travelers rely on the ability to send and receive information to plan and execute their trips. 

The type of information that may be needed differs for each user, depending on the type of trip, 

mode of travel, and decisions by the traveler. The timing of information could also differ, 

depending on whether the decisions are made by the traveler en route or pretrip. 

What, when, and where information is needed by a traveler may vary based on the type of 

decision being made, mode of travel (e.g., driver of vehicle, pedestrian), facility (e.g., freeway, 

local street), and location (e.g., midblock, approach to intersection). Drivers require roadway

network information for routing decisions and roadway and weather conditions for timing

decisions. Roadway users require information for avoidance decisions. Pedestrians and bicyclists

rely on many of the same types of information as drivers but with additional nonmotorized needs

related to comfort and safety, crossing availability, and potential accessibility accommodations. 

Transit and shared-mobility users require information on service availability, schedules and 

routing, amenities, and cost. Transit and shared-mobility modes have the additional requirements 

of requesting service and providing payment. 

Traditional en route methods of information exchange are one-way and occur through 

agency-owned infrastructure within the public right-of-way. The information exchange is based 

on the location of the traveler, the decision being made, and the priority of what information 

could be provided through an agency’s traffic control devices. For roadway travel, signs are 

placed in advance of when a driver would need that information and are based on the driver’s 

expected speed of travel, visual ability, and perception and reaction times. For transit, exchanges 

typically occur at the station or on the vehicle when service is provided. Traffic control devices 

notify road users of regulations and provide warning and guidance needed for the uniform and 

efficient operation of all elements of the traffic stream.
11 

Based on the type of traffic control device, the 

exchange of information can be visual, audible, or 

haptic in delivery—whereby each relies on a 

different human sensory reception, traveler’s 

expectation, type of device, and information being 

conveyed. Examples of visual information

exchanges include traditional roadway signs, 

pavement markings, and electronic displays. 

Audible information could include vehicle horns 

or sirens, accessible pedestrian signals, and public address announcements. Haptic information

exchanges occur when there are changes in the texture of a surface, such as surface treatments

(e.g., transverse and longitudinal rumble strips, raised pavement markers, tactile curb ramps), or 

when feedback is received from input devices (e.g., vehicle switches, crosswalk pushbuttons, 

haptic feedback from a smartphone).

Over time, the addition of ITS devices has allowed for more dynamic and real-time information 

sharing, but that information sharing has largely remained static in location. As an example, an

agency could use loop detectors in a static location to detect congestion in realtime, which could 

then be converted to travel time and posted on a dynamic message sign (DMS). 

Drivers are becoming increasingly accustomed to using smartphones, integrated in-vehicle 

systems, or other connected devices to receive information in near realtime about wayfinding, 

crashes, and traffic conditions. Some travelers also use these devices to report information such 

as crashes observed while en route.

ELECTRONIC DATA EXCHANGES

Information exchange with transportation users, regardless of mode, has recently evolved to 

include many forms of portable electronic methods, such as websites, smartphone apps, 

radio-frequency identification (RFID) tags, near-field communications (NFCs), and stored-value 

payment cards. Each of these methods is described in the following subsections. 

Websites

Websites provide transportation users, agencies, and service providers with a wide range of 

information exchange options. Information can be disseminated to users related to roadway

conditions (e.g., closures, construction activity), traffic conditions (e.g., speed, congestion, 

incidents), service schedules (e.g., bus, train), and other data. This information dissemination can

be static or realtime in nature, although real-time information is more useful for user

decisionmaking. 

Transportation agencies typically host data on agency websites (e.g., a 511 (traveler information) 

website) that allow a limited one-way information exchange. Transit service agencies and 

providers typically utilize websites for two-way exchanges by offering account management,

status requests, service requests, and payment options. Access to these information sources 

requires Internet access, and users may need to visit separate sites for each entity. Advances in

open-source data and the monetization of transportation-related data has led to aggregator 

What, when, and where information is 

needed by a traveler will vary based on 

the type of decision being made, mode 

of travel (e.g., driver of vehicle, 

pedestrian), facility (e.g., freeway, local 

street), and location (e.g., midblock, 

approach to intersection).
12 

websites that combine numerous data sources and provide a single platform for users to plan, 

develop routing decisions, and execute their trips. However, the ability to make reservations and 

payments for all applicable services may not be possible through aggregator websites.

Smartphone Apps

Smartphone apps operate like websites and provide much of the same information and utility as

the full websites but in a mobile form. Like websites, these apps are distinct and self-contained

programs that run on the smartphone operating system. The primary benefit of apps is the 

portability of the data, which allows en route updates and real-time decisionmaking. Users can 

interface with the app through the smartphone’s controls and touchscreen. 

RFID

RFID, in the transportation environment, allows one-way information exchange to take place 

between an issued tag (user) and an infrastructure-based reader (owner). This technology is 

widely used in electronic tolling, parking, weigh-in-motion, fuel dispensing, and fleet 

management applications. RFID tags, which consist of a memory chip and antenna, are assigned 

a unique identifier that is linked to personal information, including, but not limited to, vehicle, 

driver, and account information. Infrastructure-based RFID radios detect the passage or presence 

of an RFID tag typically mounted on or carried within a vehicle. The technology allows for data 

exchange at high travel speeds and without contact—tolling on interstates is an example of both 

benefits. By linking the unique identifier to stored account information, the RFID systems can

include payment transactions.

NFC

NFC is a specialized subset of RFID technology that is characterized by devices being capable of 

being a tag and a reader. NFC is based on higher radiofrequencies and requires much closer 

proximity (several centimeters), which allows for more secure transactions. Nearly all 

smartphones sold in recent years contain NFC capabilities, which have allowed the development 

of contactless payment apps. These apps—once set up with payment information—can be used 

at a service provider’s payment terminal that is also equipped with NFC. The benefit of such 

payment services is that they are relatively quick, and an Internet connection is not needed for 

the transaction. 

Stored-Value Payment Cards

Stored-value payment cards are similar in form to credit or debit cards but differ significantly in 

their function. Unlike credit and debit cards, stored-value payment cards are not linked to 

financial institutions and are not associated with an individual or account. The amount of money 

stored on the card is deposited at the time of purchase and may be reloaded with additional funds 

or may be a one-time use. The cards are widely used in public transportation systems and 

parking venues to manage fare payment while eliminating the need to manage cash—funds are 

withdrawn directly from the card. Connecting or communicating with a central system is not 

needed to process the payment because there is no account. Like cash, stored-value payment 

cards are anonymous because any person holding the card can use the funds. One drawback is 

that lost cards cannot be traced to the previous owner.
13 

Although the electronic data exchange methods described in this chapter provide utility and 

convenience to the user and agency or service providers, several key shortcomings exist: 

• The most robust of the service platforms requires Internet access through cellular 3G/4G

LTE service or Wi-Fi (privately or publicly accessible) connectivity. In areas where 

Internet access is limited or for people who do not subscribe to a data plan, these

platforms and services may not function. 

• Several systems are limited to data consumption only and do not broadcast data, which

prohibits any communication with other devices. This communication constraint limits

functionality to user-provided input and eliminates potential data collection by the system

owner/operator, which could increase real-time situational awareness and future planning

efforts.

• Most of the systems are typically operated on proprietary platforms and/or devices 

requiring travelers to access and utilize different specialized applications to interact with

each service. Because the interface and content are based on proprietary and nonstandard

data messages, interoperability is limited, and data—even if provided open source—

require significant manipulation.

MOBILE DEVICES

As mentioned in chapter 1, a mobile device is a computer that can connect to the Internet, is 

small enough for a traveler to hold and operate in the hand, and has the same capabilities and 

features of a smartphone but potentially with the added ability to communicate via other wireless 

communications methods such as DSRC or cellular vehicle-to-everything (C-V2X). Since 

smartphones do not presently have vehicle-to-everything (V2X) capability, either in the form of 

DSRC or C-V2X, a mobile device consisting of a smartphone tethered to a mobile battery 

powered V2X radio via Bluetooth® would transmit and send electronic data.

One aspect that differentiates mobile devices from other existing technologies is the ability to 

communicate standardized messages with a computing platform. The computing platform 

utilizes APIs that “translate” similar types of data from different types of systems into 

standardized messages, which are then communicated to the mobile device via a wireless 

communications method. The advantage of mobile device communications is interoperability 

between multiple systems that have infrastructure that supports communications with mobile 

devices. Figure 2 illustrates the functionality of mobile devices in relationship to 

devices/platforms and smartphones and the role of APIs. 
14 

Source: FHWA. 

Comms = communications.

Figure 2. Flowchart. Communications paths for mobile devices versus other technologies. 

The extent to which a mobile device exists in today’s transportation environment is dependent on 

smartphones and other wireless electronic devices such as tablets’ ability to support the desired 

features of a mobile device. Thus, identifying the specific features of smartphones that provide 

utility to mobile devices is important. Smartphones are characterized as handheld computers 

exhibiting a set of standard features, such as an operating system, access to various 

communications technologies, and hardware/software sensors. Applications (apps) are the 

software installed on the smartphone that take advantage of the smartphone’s features to provide 

a service to the user. All components mentioned previously are contained in a mobile form

designed to be carried on the person. 
15 

The operating system manages the smartphone’s hardware (e.g., processor, memory, sensors) 

and software (i.e., application) resources. As of August 2022, the market share of smartphone 

operating systems in the United States is dominated by iOS (57.02 percent) and AndroidTM 

(42.69 percent) with less than 2 percent of smartphones using an operating system other than 

Android or iOS. Smartphones exhibit a variety of communications media, including cellular 

(3G/4G LTE), satellite, Wi-Fi, Bluetooth, and NFC, which are discussed in chapter 2, 

Communication subsection.1

Smartphones contain several sensors that detect movement and proximity of the device. An

accelerometer and gyroscope detect linear and angular acceleration along three axes. A 

magnetometer detects direction with respect to the smartphone’s reference axis. A proximity

sensor determines whether there is an object within a certain distance of the face of the phone 

(typically used during phone calls to determine when the screen should automatically turn off).

In addition, ambient light sensors are included (typically used to autoadjust screen brightness to

enhance usability).

Certain smartphone features may also be found in other forms, including, but not limited to, 

tablets and laptops. Though these devices are generally not as widely used as smartphones by 

travelers in the transportation environment, the use of these alternative methods to access data 

while en route should be considered. 

ENABLING ELECTRONIC MESSAGE SHARING WITH MOBILE DEVICES

The operation of a mobile device depends on the collective capabilities of systems within a 

region that provide the ecosystem that enables electronic message sharing and use with mobile 

devices. This ecosystem ultimately determines which traveler-based use cases can be supported; 

enables agencies and communities to improve safety, mobility, and reliability; and enables 

agencies and communities to provide increased services to travelers who carry a mobile device.

The information needed by travelers to make informed decisions throughout a trip relies on other

(external) systems that make that information available. For instance, a transportation agency 

maintains a system that makes transportation-related data available, or a transportation service 

provider maintains a system that makes the location of its fleet available. These external systems

can take several different forms: 

• Management systems—A traffic management center (TMC) (e.g., traffic speed data),

transit management system (e.g., real-time transit data), a toll management system, or a 

system that manages a ridesharing/ridesourcing platform or service.

• Infrastructure—Traffic signal controller, 

a DMS, an electronic toll sign, or a transit

arrivals board. 

1

GlobalStats Stat Counter. n.d. “Mobile Operating System Market Share United States Of America” (web page). 

https://gs.statcounter.com/os-market-share/mobile/united-states-of-america, last accessed September 12, 2022.

The information needed by travelers to

make informed decisions throughout a 

trip is reliant on other (external) systems

that make that information available. 
16 

• Payment systems—Transit payment system, a toll payment system, or a parking 

payment system.

• Mobile systems—In-vehicle CV devices, smartphones, or other mobile devices.

These external systems need data transmission and data collection capabilities and use methods 

compatible with mobile devices. Enabling electronic data sharing with mobile devices is 

characterized by the following three features:

• Electronic messages (content).

• Software and hardware (processing). 

• Communication media (transmission).

The remainder of this chapter provides an overview of these features of mobile device-based 

systems to send and receive messages with vehicles, other mobile devices, or systems

(e.g., transit management, traffic management). 

Electronic Messages

The transmission of electronic messages between mobile devices and other connected devices or 

systems relies on wireless technologies. These messages support the decisionmaking needs of the 

traveler. The transmission contains the necessary data related to the user, the transportation

system, and/or the requested service to provide the intended use case. However, if every system

provides different data or even the same data in a different format, any device that intends to

receive electronic messages from any of those systems would need to know the format of that

data to make use of it. Messages sent between mobile devices and other systems allow for 

interoperability across agencies and service providers and across geographic regions. 

Three primary standards are related to electronic messages in transportation:

• SAE J2735.(4)

• European Telecommunications Standards Institute (ETSI) TS 102 637.(5)

• General Transit Feed Specification—Realtime.

(6)

The following existing types of messages developed for SAE J2735 contain many of the 

elements that may be needed for future user applications.(4) It is possible that these messages

could directly support future operations; however, new electronic messages might also be needed 

to fully develop future concepts: 

• Basic Safety Message (BSM)—The BSM is used in a variety of applications to 

exchange safety data regarding vehicle location and motion. This message is broadcast 

frequently to surrounding vehicles with data content as needed for safety and other 

applications. Transmission rates are beyond the scope of this standard, but a rate 10 times 

per second is typical when congestion control algorithms do not prescribe a reduced rate.
17 

• Signal Phase and Timing (SPaT) message—The SPaT message provides signal phase 

and timing information for a signalized intersection. It can be linked to movements 

defined in a map data message (MAP) so that signal states can be applied to each 

movement.

• MAP—The MAP contains intersection/roadway geometry data and is typically broadcast 

from the roadside unit (RSU) and received by vehicles and mobile devices so that these 

devices can determine their position with respect to the roadway. At an intersection, a 

MAP can be paired with SPaT data so that an intersection state can be applied to each 

intersection movement.

• Traveler Information Message (TIM)—The TIM contains advisory information used 

by vehicle operators. A TIM is sent from the roadside to vehicles that subscribe to receive 

TIMs. The TIM protocol provides the location and situation (e.g., vehicle speed) 

parameters that must be met for the TIM to be delivered to the vehicle operator. For 

instance, a TIM that advises a vehicle operator of a speed limit in a designated area

would only be displayed to the vehicle operator when the vehicle is approaching the area 

and if the vehicle operator is traveling above the speed limit within the area.

• Signal Request Message (SRM)—The SRM contains data used to request signal 

preemption or signal priority from a signalized intersection. These data include the 

desired movement, the priority type (priority or preempt), and the priority level. In 

addition, the SRM includes the estimated time of arrival and duration of service data 

fields. These data items are essential to ensuring that all vehicles traveling in a platoon 

can be accommodated in the priority request and can move through the intersection at 

once if the request can be granted. These messages are sent from vehicles that require 

preemption or priority at an intersection and are received by a RSU and forwarded to the 

roadside equipment (RSE). When SRMs are received from multiple vehicles, the 

transportation service center or other processing equipment arbitrates the requests based 

on the priority level of the request.

• Signal Status Message (SSM)—The SSM contains data regarding the operational state 

of the intersection (e.g., normal, priority, preempt). This message is sent from an

intersection to relay information to a vehicle regarding whether the signal priority request

parameters were accepted by the intersection. Data contained in this message can be 

populated by using the output from a National Transportation Communications for 

Intelligent Transportation System Protocol 1202-compliant traffic signal controller.(7)

• Personal Safety Message (PSM)—The PSM transmits a mobile device’s position, 

speed, and heading, among other information. For a general collision avoidance 

application, surrounding vehicles could receive the PSM, and along with its own 

telematics, determine whether a collision is imminent. The V2X Hub broadcasts an early 

prototype version of this message that is slightly different than the approved standard but 

contains the same core elements.(8)
18 

• Probe Vehicle Data (PVD) message—The PVD message collects vehicle status data over 

a defined distance and/or time in a structured manner and provides it to the infrastructure. 

The infrastructure can forward these data to a TMC, where they can be used for traffic 

management purposes. A vehicle is expected to provide PVD in accordance with 

parameters specified in the probe data management (PDM) message.

• PDM—The PDM message could specify the data, the frequency of collection, and 

delivery from the connected autonomous vehicles (CAV) or connected mobile device 

back to the RSE. The limited range or number of RSU could influence the use of PVD 

messages (as described in the previous bullet) to fill in the gaps in coverage, in case 

cellular technology is not available. The probe management process involves sending the 

PDM message from RSUs to the vehicles to specify how the vehicles gather and report 

data (i.e., at what frequency and including what detail). 

The following are existing messages developed for ETSI TS 102 637 that contain many of the 

elements required for future user applications.(5)

 These messages could directly support future 

operations; however, new electronic messages might also be needed to fully develop future 

concepts: 

• Basic Information Message (BIM)—A BIM is a proposed new message format that 

enables the transmission of all required data elements for vehicle-to-infrastructure safety 

applications in a single message and is extensible to support future event-based 

applications. This concept of message structure uses existing SAE J2735 data elements.(4)

• Decentralized Environmental Notification Message (DENM)—The DENM provides 

information regarding 13 use cases: emergency electronic brake light, wrong way driving 

warning, stationary vehicle (e.g., accident, stationary vehicle), vehicle problem, traffic 

condition warning, signal violation warning, road work warning, collision risk warning, 

hazardous location, precipitation, road adhesion, visibility, and wind.

• Cooperative Awareness Message (CAM)—The CAM provides information on presence 

and positions as well as the basic status of communicating ITS stations to neighboring 

ITS stations located within a single-hop distance. This information includes vehicle 

position and vehicle basic data (e.g., acceleration, path history, curvature, vehicle size). 

CAM supports 32 use cases in 4 application classes, including active road safety 

(e.g., emergency vehicle warning), cooperative traffic efficiency (e.g., regulatory speed 

limit notification), cooperative location services (e.g., parking management), and global 

Internet services (e.g., insurance and financial services).

A known standard allows any device to receive the message, understand the data, and act on the 

information. When the data frames and data elements that are included in standardized messages

are developed, data contained in the message could enable the applications that they are intended 

to support. 

While existing standards are relatively robust, a specialized data structure may be needed, based 

on specific situations, to deliver content that current standards do not support. When specialized 

data structures are used, it is especially important to develop accompanying support materials 
19 

(e.g., a data dictionary and an API) to make the message data available, to support the developers 

of systems that may need to populate, or to decode the data contained in the specialized data 

structure.

Software and Hardware

The communication between mobile devices and other connected devices or systems relies on 

software and hardware that allow the devices or systems to carry out specific functions, tasks, or

actions. These software and hardware typically involve taking a data input, processing it

(potentially also using data from other sources), and generating an output that could be used as

input to another device.

Connected device hardware includes a processing unit, internal memory, communications 

antennas, and a human-machine interface (HMI) (e.g., audio, visual, and haptic). These physical 

components can be integral to infrastructure equipment and vehicle apparatus or provided in a 

separate form.

Software installed on the mobile device and connected devices/systems provides functionality. On 

a mobile device, for example, this software performs the computations necessary to interpret data 

received in an electronic message, determine whether conditions are met for an electronic message 

to be sent, determine whether information must be provided to the traveler near a decision point, or 

determine whether conditions warrant sending a safety warning to a traveler. On external systems, 

these software platforms could be APIs that allow system data to be communicated in electronic 

messages to mobile devices (or to receive electronic messages from mobile devices) and to decode 

and use these data for system management purposes.

Applications (service packages) are a combination of one or more functions that work together to 

deliver a given service and the information flows that connect them with other important external 

systems. Mobile devices typically access data provided by various external services using an 

API, which provides a means of receiving/providing data from/to systems using proprietary 

nonstandard messages.

One unique aspect of mobile devices is the concept of an intermediary computing platform that 

enhances connectivity between mobile devices and other connected systems. This computing 

platform enables the integration of data streams from multiple sources and standards and 

provides connectivity between various systems, such as ITS hardware, traffic or transit 

management centers, shared-mobility providers, smartphones, cloud services, and vehicle 

systems, using any number of communications methods. The major benefit of intermediary 

computing is that it can provide a single point of contact for the mobile device to allow it to 

connect to multiple external services.

As an example, the V2X Hub, which was developed as part of the U.S. Department of 

Transportation’s ITS program, is a software platform that enables CVs to talk to existing 

infrastructure and systems.(8) The V2X Hub simplifies integration by translating communication 

between different standards and protocols through APIs. On the roadside, a computing device 

hosts the computing platform and supports the exchange of electronic messages (such as BSM, 

SPaT, and MAP) between several devices on the roadside, including, but not limited to, a V2X
20 

radio, traffic signal controller, DMS, and TMSs (via backhaul). The in-vehicle device provides 

the interface between a V2X radio and a driver. The key feature of the V2X software is its 

modular architecture and use of customizable plugins, which allows the solution to be tailored to 

suit the needs of agencies, drivers, and mobile device users and allows an agency to easily 

expand or reconfigure the solution as needed. 

Communication

The data sharing between mobile devices and 

other connected devices or systems requires a 

communications path. Due to the nature of 

mobile devices, available communication 

methods are wireless. Wireless forms of 

communication available to mobile devices 

include cellular (3G/4G LTE), satellite, 

Wi-Fi, Bluetooth, and NFC. Emerging wireless technologies include C-V2X (based on LTE) and 

fifth generation (5G), which allow for low-latency, peer-to-peer connectivity: 

• 4G LTE mobile network—4G LTE is one of the most common methods of providing 

information to travelers. One of the major benefits of 4G LTE is its coverage area, 

particularly on highly traveled corridors. However, because communication between 

devices on a 4G LTE network are routed though fixed-location transceivers, 

communications latency could preclude a system network relying on 4G LTE from 

supporting safety-of-life applications. The 4G LTE network is managed through wireless 

telecommunications providers, so a subscription to a mobile data plan is required for 

individual access to 4G LTE.

• GNSS—GNSS is a generic term for systems available for satellite geolocation. GNSS is 

generally considered to provide position, speed, and time information for receivers. This 

information exhibits varying degrees of accuracy, depending on conditions such as the 

number of satellites and interference.

• Wi-Fi and Wi-Fi Direct®—Wi-Fi allows mobile device users to access a network when 

in range of Wi-Fi routers. When connected to a Wi-Fi router, the mobile device can send 

data to, and receive data from, other Internet-connected systems. Private Wi-Fi networks 

can be password protected, although owners can choose to keep these networks free or 

open, which many retail establishments do as an amenity to patrons. The coverage of a 

Wi-Fi network depends on the locations and range of accessible Wi-Fi routers. Wi-Fi 

Direct allows two consenting Wi-Fi-enabled devices to directly communicate information 

between each other.

• Bluetooth—Bluetooth establishes a consenting device-to-device connection and is generally 

used for data transfer and audio streaming. Triangulation of Bluetooth signals also allows for 

added precision for indoor positioning in places where other locating methods are not as 

accurate or accessible.

The major benefit of intermediary computing 

is that it can provide a single point of contact 

for the mobile device to allow it to connect to

multiple external services.
21 

• RFID and NFC—NFC is a specialized subset of RFID technology that supports 

low-latency information exchange and has low power consumption requirements. A 

powered device is capable of energizing and reading information from a tag (that does 

not necessarily have to be self-powered). A mobile device can function as a tag or a 

reader. Range depends on the power of the device; however, this dependence on power 

could be considered a security benefit because power can be adjusted to physically limit 

the potential of other unintended devices to receive information. The use of secure 

channels further improves the likelihood that only authorized devices (the intended 

recipients) can receive the information.

• DSRC—DSRC is a two-way, short- to medium-range wireless communications 

capability that permits data transmission critical in communications-based active safety 

applications. DSRC is characterized by low-latency transmission of data and had been a 

major focus of CV research over the past several years. Recent FCC rulemaking has 

effectively rendered DSRC obsolete, however, and the technology is expected to be 

superceded by C-V2X.

• C-V2X—C-V2X was developed by the 3GPP as a competitor to DSRC with the 

advantage of using the same chipset for both V2X communications as well as traditional 

cellular ‘network’ communications.

(9) The latter interface allows a device to 

communicate with the cellular network (known as the Uu interface). The Uu interface 

does require a subscriber identification (ID) module card, more commonly known as a 

SIM card,(and associated data plan from a service provider) to function. The former 

interface, known as PC5, can directly communicate to other devices independent of the 

cellular network. Current C-V2X technology is based on the LTE standard, but it has a 

forward-compatible evolution path to the 5G version of C-V2X. 

• 5G mobile network—5G is based on the 3GPP release 15 with enhancements found in 

both release 16 and, most recently (March 2022), release 17. 5G is quickly becoming the 

standard for U.S.-based cellular carriers and the rollout continues in more dense regions. 

5G promises higher speeds, greater capacity, and lower latency than LTE. Similar to 4G, 

a C-V2X (PC5-type) interface is available, but to date, very little work has been done 

with prototype of this next generation V2X technology.

Each medium has its advantages, disadvantages, and limitations; therefore, there may be certain 

situations under which it makes sense to use one communications media over another. The 

communications media selected to transmit a message is generally a function of coverage 

(i.e., range), reliability, and latency of the given data flow. Regardless of which communications 

medium is chosen, security protocols are followed to protect the authenticity and privacy of 

transmitted data to ensure trust and authenticity for users and systems connected by the network. 

PREPARING FOR SUCCESSFUL OPERATIONS

The successful data sharing with mobile devices involves not only the technical form and 

functions identified thus far, but also various institutional and organizational components. From 

the onset, participating agencies and service providers need to adequately address business 

requirements that may be needed to operate the mobile device-based systems.
22 

A planning study is expected to have taken place before the system development process. An 

agency may have a transportation systems management and operations (TSMO) strategy or plan 

(e.g., integrated corridor management, TMS, or ITS), whereby the need and overall framework 

around which the message sharing with connected mobile devices and the public agency managed 

systems (e.g., traffic, transit) would be documented. A part of the planning for this environment 

and the enabling systems (e.g., TMS, transit management) would support the sharing and use of 

data with travelers using connected mobile devices.

Facilitating a comprehensive concept development process and developing a ConOps would 

identify the partnerships and institutional resources needed to accomplish the desired use case. 

Agencies and service providers must understand their roles and the data, equipment, or 

manpower that may be expected of them before developing and building a mobile device-based 

system. As part of that effort, key stakeholders would answer and develop consensus on the 

following questions: 

• What service does the traveler, agency, or service provider want to use? 

• What information is needed to accomplish the desired service?

• What connectivity is needed to allow this communication to take place? 

• At what time and location does the information need to be provided to make effective 

decisions? 

• What equipment, hardware, or software is needed to provide the functionality? 

• How will the data be collected and used within agencies and service providers?

Although the answers to these questions are specific to the function of the connected system, 

they would also lead stakeholders to identify their internal shortcomings in terms of policy, 

business processes, staffing, and finances. Identifying and addressing these issues early would 

further develop the technical aspects of the data-sharing ecosystem. These same steps could be 

implemented later in the implementation or operation stages, when changes would be proposed 

to ensure stakeholder collaboration throughout the development. 

In some use cases, it would be advantageous to establish a lead agency to develop, test, and 

sustain the ecosystem. This ecosystem may involve project charters, interagency agreements, or 

contracts with third-party providers to memorialize the organizational structure and allow certain 

access or control of partner assets. In addition, rules governing data use would need to be 

established between agencies that own a connected system and other entities wanting to access 

the data.

The operations of a managed toll lane facility is an example where coordination between 

multiple agencies would be needed for the system to operate as intended. Typical toll operations 

would include the following institutional stakeholders:

• An agency or entity responsible for all toll tags for an entire region. 

• A traffic management agency responsible for freeway operations. 

• A group responsible for operations of the toll facility (e.g., monitoring real-time 

conditions, setting tolls). 

• An agency responsible for managing the backhaul network, the devices connected to it 

(including RFID tag readers), and the data that flow across it (toll tag account numbers). 
23 

• A group responsible for collecting tolls (e.g., managing customer accounts, payment 

information, customer billing). 

• An entity responsible for marketing and community outreach. 

Bringing stakeholders to the table, defining the relationship between stakeholders, and defining

roles and responsibilities for each stakeholder would be key components toward ensuring 

cooperation for a successful operation of the system.

25 

CHAPTER 3. CONCEPT DEVELOPMENT

CHAPTER OVERVIEW

The concept development process is a critical step in defining a project as it establishes the 

overall parameters for the information exchange between travelers and transportation 

agencies/services. A well-defined concept incorporates each stakeholder, their needs, and their 

roles and responsibilities in the overall process. Understanding a traveler’s environment, their 

interface abilities, their desired actions or decisions, and the available infrastructure and 

resources provides input to refining the information exchange needs. The resulting concepts 

subsequently provide the basis for further project development and SE efforts. 

This chapter provides an overview of the traveler (user class) and the desired action (use case). 

User classes are included for travelers using a variety of modes, including walking, cycling, 

driving, and using mobility options for transit and shared services. Use cases are provided for a 

variety of common applications, including requesting a traffic control change, conflict 

avoidance, rerouting, service reservations, and payments. Although examples are provided for 

both user classes and use cases, these examples do not comprise an exhaustive list. However, 

agencies could use the descriptions, combined with the messages and methods of message 

delivery described in the chapter 2, to develop their own concepts unique to their needs. 

This chapter concludes with a list of considerations that an agency would account for during the 

concept development, including a traveler’s need for information and decisionmaking, electronic 

messages, software and hardware, communication, and agency management systems. These 

categories are like those in chapter 2, Communication subsection, but provide specific issues, 

challenges, and questions that would be answered within the SE process.

USER CLASSES

The way mobile devices are used may ultimately drive their form and function. Different users

may need different types of information, different methods of interface for input and/or 

feedback, or even different spatial or temporal considerations. Users who have similar needs, 

encounter similar issues, and are expected to benefit in a similar fashion from the deployment of 

a system are arranged into groups called user classes. A common starting point for dividing users 

into user classes is by their mode of travel. 

This classification helps identify the appropriate user needs through the concept development 

and, ultimately, the system requirements. For each user class, example needs are listed that 

would apply to the users before or during their trip. Specific needs unique to an agency or region 

would be developed during the concept development. 

Although the needs of each user class are presented separately, there may be overlap between

user classes that would be identified and addressed during the concept refinement. These

overlaps can provide for synergies if they can be addressed through the communication of 

similar electronic messages. 
26 

As an example, one of the central needs of most users is access to a trip planning service both 

pretrip and en route. Access to a trip planning service allows users to determine whether there 

are better alternatives for reaching their destination as conditions change and whether those 

alternatives are on a different route on the same mode or a different mode. Because there are 

benefits of trip planning data for users of all modes, a synergy could be to provide a consistent 

message that can be used for multiple types of modes. Another common need is the ability to pay 

for a service. In these modes, a synergy could be provided through a common electronic message

to request payment (from the provider to the user) and authorize payment (from the user to the 

provider). 

Pedestrian

This user class represents travelers who are walking to complete their trip. These pedestrians 

typically use sidewalks, where available, and crosswalks to travel across portions of the

right-of-way, which is primarily used by motorized vehicles and bicyclists. Pedestrians are 

classified as VRUs because they are prone to physical harm when involved in a crash with a 

vehicle. Thus, drivers need to be made aware of pedestrians, especially when pedestrians are in a 

portion of the right-of-way where vehicles could be present. This classification also includes 

travelers using wheelchairs, electric personal-assisted mobility devices (e.g., a mobility scooter 

or a wheelchair), and bicyclists who use sidewalks (in jurisdictions where operating a bicycle on 

a sidewalk is legal). Examples of a range of pedestrian needs that could involve different 

electronic data exchanges are provided in the following text box. (Note: This list of needs is not 

intended to be exhaustive.) 

Bicyclist

This user class represents travelers using a bicycle to complete their trip. Bicyclists are a 

distinctive type of user because the use of a mobile device while en route may be particularly 

distracting because both hands are generally needed for the biking task. Interacting with the 

mobile device while on a bicycle could cause the bicyclist to make unpredictable movements, 

reducing their own safety and that of other road users. Therefore, the needs of bicyclists would 

be able to be met only if the system does not need the bicyclist to provide input to the mobile 

Pedestrians need to:

• Know when they are approaching a signalized intersection crosswalk. 

• Be able to activate a pedestrian crosswalk phase.

• Have additional time to complete crossing a crosswalk if they are still in the 

crosswalk and the pedestrian phase clearance time will soon expire. 

• Have their presence in a crosswalk be known to approaching drivers. 

• Have wayfinding and navigation solutions (for pedestrians with disabilities) to a 

complete trip between an origin and destination in the public right-of-way. (Note: 

The traveler needs wayfinding and navigation information before staring the trip 

and must be updated throughout the trip to account for changing conditions, such 

as a pedestrian signal.) 
27 

device (which is significantly distracting) while in the public right-of-way. This user class covers

bicyclists riding in the roadway as opposed to those on a sidewalk, and includes those using 

dedicated bicycle lanes (see Pedestrian class). Examples of bicyclist needs that may involve 

different electronic data exchanges are listed in the following text box. (Note: This list of needs 

is not intended to be exhaustive.) 

Traveler Using Personal Vehicle

This user class includes travelers who would use a personal vehicle to complete a trip and who 

would receive information before making the trip and en route. While en route, the driver would 

want continuous information on the most efficient route and adjust the trip in realtime to reduce 

delays. The user class could also use available toll facilities to reach their destination, but these

facilities also may involve payment for use. For drivers to make an informed decision about 

whether to take a toll facility, they need information about the toll facility, such as travel time

savings and associated costs for the length along the driver’s proposed route. Travelers using a 

personal vehicle have a unique need to park their vehicle when they reach their destination. In

these cases, the driver must be provided with information regarding the availability and cost of 

parking facilities in the vicinity of the driver’s destination. Example needs for travelers using a 

personal vehicle that could involve different electronic data exchanges are provided in the 

following text box. (Note: This list of needs is not intended to be exhaustive.) 

Traveler Using Transit

This user class uses one or more modes of transit to complete their trip (e.g., bus, train, streetcar,

or ferry). This user class requires pretrip and en route information that enables the traveler to

Bicyclists need to: 

• Activate a phase that they intend to utilize at a signalized intersection.

• Have their presence in the roadway known to approaching drivers. 

Travelers using personal vehicles need to: 

• Have spatially and temporally relevant roadway signage information. 

• Have traveler information that is customized to a predetermined route.

• Be able to constantly check for alternative routes to their destination to determine 

if they are on the most efficient route.

• Obtain tolling information for toll facilities that could be used to get to their 

destination when using a personal vehicle. 

• Have information about the location and cost of parking facilities in the vicinity of 

their destination. 

• Have a method to pay for tolls.

• Have a method to pay for parking. 
28 

choose or change modes or routes to obtain the most efficient trip. Users can measure efficiency

differently; some may select trips based on total time, whereas others may look to minimize costs

or transfers. Furthermore, travelers using transit need a method to conveniently pay for the 

service(s) that they utilize. Examples of needs for travelers using transit that could involve 

different electronic data exchanges are provided in the following text box. (Note: This list of 

needs is not intended to be exhaustive.) 

Traveler Using Ride-Hailing Service

This user class represents travelers using mobility service providers to travel, including, but not 

limited to, on-demand (e.g., flexible route) transit, taxis, ridesharing, and transportation network 

companies. Because these services operate outside traditional, fixed routes, the user needs to 

determine the availability of the services in a given area. In addition, their use often requires 

sending and accepting a request for service, the agreement of the fee, and a method by which to 

conveniently pay for the service. Examples of a range of needs for travelers using a ride-hailing 

service that could require different electronic data exchanges are listed in the following text box. 

(Note: This list of needs is not intended to be exhaustive.) 

Transit users need to: 

• Access to a multimodal trip planning service.

• Have alternative route or mode options that can be used by the traveler while en 

route to the destination.

• Be able to view the amount of time until the next arrival or locations of nearby 

transit vehicles occur. 

• Obtain information about approaching transit vehicles when waiting at a transit 

stop. 

• Be able to notify the transit vehicle operator when they intend to disembark from 

the transit vehicle.

• Be able to notify a transit manager (or transit management system) when they 

intend to make a scheduled connection.

• Be able to know the fare to take a trip using transit. 

• Have a method to pay for a trip taken using transit. 

Ride-hailing users need to: 

• Obtain information on the availability of flexible ride-hailing services in their 

vicinity.

• Be able to request service from the provider.

• Be able to know the fare of the ride-hailing service.

• Have a method to pay for a trip taken using ride-hailing services.
29 

Traveler Using Shared Mobility

The designation of shared-mobility devices is constantly growing and can include car sharing, 

bike sharing, scooter sharing, or other similar types of alternative transportation services. Users

of these devices are unique from users of ride-hailing services in that these travelers also operate 

a shared-mobility device (i.e., a traveler using a ride-hailing service does not operate the

vehicle). Users may opt for these modes in areas where the convenience is greater than walking, 

driving a personal vehicle, or transit options. The use of these modes requires the availability of 

devices and a payment typically measured by time or distance. Examples of a range of needs for 

travelers using a shared-mobility device that may require different electronic data exchanges are 

provided in the following text box. (Note: This list of needs is not intended to be exhaustive.) 

Traveler with Disabilities

Travelers with disabilities include those with vision, hearing, cognitive, mobility, or other

disabilities. Users with different disabilities have varying limitations that may require different

types of information from a mobile device to complete their trip. This user group may also

require unique methods by which information is input and presented to effectively communicate

(e.g., enlarged text, haptic responses, or text-to-speech conversions). Travelers in this user class

may also fall into other user classes, and needs from both classes could be combined. Examples 

of a range of needs for travelers with disabilities that may involve different electronic data 

exchanges are provided in the following text box. (Note: This list of needs is not intended to be 

exhaustive.) 

Multimodal Traveler

The multimodal traveler user class includes travelers who utilize more than one mode to

complete their trip. Like the traveler with disabilities user class, the multimodal traveler falls into

multiple user classes during their trip. Travelers using more than one mode may need not only 

Shared-mobility users need to: 

• Obtain information on the location and availability of shared-mobility devices in 

their vicinity.

• Be able to reserve the device for a given timeframe.

• Know the cost of the service.

• Have a method to pay for a trip taken using shared-mobility devices. 

Travelers with disabilities users need to: 

• Have adequate interface options to fit their disability (e.g., enlarged text, 

text-to-speech, or haptic responses). 

• Have complete wayfinding and navigation solutions for the entire trip while en 

route. 
30 

the information associated with the current mode but also additional information on all other

options and a method to compare costs, convenience, and time associated with each option. 

Depending on real-time conditions, the multimodal traveler may prioritize using one mode over 

the other while en route. 

USE CASES

Once user needs have been defined and the 

synergies between them have been identified,

an agency or region could identify use cases

that are expected to address these user needs. 

Due to the nature of mobile devices and the 

focus on satisfying user needs, use cases are

framed from a mobile device user

perspective. Specifically, the use cases need

to identify how mobile device users make 

decisions during typical trips, ascertain what

information is needed and how the user can interface with the device, determine how the

information can be packaged and sent as electronic messages, know when the messages need to

be delivered temporally and spatially, and recognize how these messages can be sequenced. 

As a traveler completes their trip from origin to destination, one or more of the use cases could 

occur. Ultimately, the use cases could be organized into scenarios to describe the entirety of a 

trip.

Example use cases are provided in the following subsections to illustrate the potential use cases

and to highlight the types of issues to be included in each. This list is not exhaustive because 

there are many use cases within each user class as well as specific use cases to individual 

agencies or regions. 

Place Pedestrian Phase Call

In the process of completing a trip, a pedestrian may need to cross a street at one or more

signalized intersections. In some cases, the crossing requires the pedestrian to provide an input to

activate the pedestrian phase at the next available opportunity in the signal timing plan.

Pedestrians typically press a pushbutton to complete this activation and then monitor the signal 

indication to determine when the crossing is allowed. 

Mobile devices could allow a pedestrian to request a pedestrian phase at an intersection. Such an

application could also provide specialized functionality to support the needs of travelers with

disabilities. The app could assist pedestrians with low vision who may have difficulty locating 

the pedestrian pushbutton, or pedestrians with a mobility impediment who may not be able to

access a poorly placed pushbutton. The mobile device could also provide audio and haptic

information regarding a signal state or the lack of a crossing to travelers who require additional 

inputs because of limited vision. This app could help pedestrians with intersections that may not 

have audible signals. 

Use cases need to identify how mobile device 

users make decisions during typical trips, 

what information is needed and how the user 

can interface with the device, how the 

information can be packaged and sent as 

electronic messages, when the messages need 

to be delivered temporally and spatially, and 

how these messages can be sequenced.
31 

To support this use case, the pedestrian needs information about the location of the intersection,

the signal state, and the ability to provide a signal priority request to the traffic signal controller.

The MAP contains intersection geometry information that allows the mobile device to position 

itself in relation to the intersection, and SPaT contains information about the state of each

movement as well as timing details (e.g., minimum time remaining, expected phase change). To

initiate the use case, a pedestrian with a mobile device would wirelessly issue an SRM to actuate

the pedestrian phase at the signal. By using the mobile device, the pedestrian would indicate

which crosswalk they intend to use, and they could cancel the request at any time. The SRM 

would contain information such as an intersection identifier, an identifier for the movement 

request, and the type of service requested (e.g., normal actuation, priority, preemption), which

the traffic signal would receive. An SSM would be provided back to the mobile device to

provide information regarding which signal requests would be served and the estimated timing of 

service.

Pedestrian in Crosswalk Intersection Safety

In environments where vehicles and pedestrians interact, an incident could occur. Pedestrians are

prone to injuries or fatalities when they are involved in a crash with a vehicle, so it is especially

important for drivers to be aware of the presence of pedestrians. Pedestrians and similar users are 

considered VRUs.

A mobile device could support the safety of the VRU by broadcasting the location and motion 

information of the VRU to other connected devices. Equipped vehicles would then process the 

information and provide a driver with advisories and warnings about the presence of the VRU. 

Similarly, the VRU could receive location, speed, and motion information from the vehicle to 

alert the VRU when a vehicle is approaching and a potential collision could occur unless 

immediate action is taken.

To support this use case, the VRU and surrounding vehicles need information regarding each 

other’s location, direction, and speed. The mobile devices would have to continually broadcast 

the information through standardized messages. Because this use case is for safety, it would not 

require any user input or activation. 

Place Bicycle Phase Call

Bicyclists riding on the roadway may not be detectable by traditional means (e.g., in-pavement 

loop detector or video detection) because these devices are typically calibrated to detect vehicles. 

In scenarios where the signal is not programmed to automatically service the signal phase that

the cyclist intends to utilize, the bicyclist may have to dismount to activate a pedestrian

pushbutton, wait for excessive periods, or cross against a red signal. 

Mobile devices could allow a bicyclist to request a pedestrian phase at the intersection in the 

direction of travel, which would prevent the bicyclist from traveling on the sidewalk or making

unsafe maneuvers. Although this action could be completed during a stopped condition, it would 

be beneficial if the actions were automatic and generated from a planned route to prevent a 

bicyclist from handling a device and not the handlebars of the bicycle. 
32 

To support this use case, the bicyclist would need information about the location of the 

intersection, the signal state, and the ability to provide a signal priority request to the traffic

signal controller. The MAP contains intersection geometry information that allows the mobile 

device to position itself in relation with the intersection, and SPaT contains information about the 

state of each movement and timing details (e.g., minimum time remaining, expected phase 

change). To initiate the use case, a bicyclist with a mobile device would wirelessly issue an SRM 

to actuate the pedestrian phase at the signal. The SRM would contain information—such as an

intersection identifier, an identifier for the movement request, and the type of service requested

(e.g., normal actuation, priority, preemption)—which the traffic signal would receive. An SSM

would be sent back to the mobile device to provide information regarding which signal requests 

would be served and the estimated timing of service.

En route Adjustment for a Driving Trip (Alternate Route)

Traffic conditions continuously change, and congestion caused by incidents or other temporary

factors may result in additional delays to a planned vehicular trip. Under these circumstances, an 

alternate route may be available that provides better travel time than the original route. Drivers

would need real-time comparative data to identify the alternate route and make the decision to

reroute. 

Mobile devices could provide access to a trip planning service that considers current roadway 

conditions and user location to develop route options while en route. The trip planning service

would obtain the information from the mobile device regarding current location, ultimate

destination, and any vehicle characteristics or preferences that could limit (or provide) access to

certain roadway facilities. This information, used along with an algorithm and information on 

system conditions, would determine an alternate route, which would then be returned to the 

mobile device.

To support this use case, the driver would have to develop a pretrip itinerary that identifies the 

destination and determines a baseline routing decision. The mobile device would automatically

track progress en route and communicate standard messages (including location, direction, and 

speed) to the trip planning service in realtime. The trip planning service would determine

alternate routes based on travel-time comparisons and deliver updated options to the mobile 

device via messages. The mobile device could provide the planned route to the driver as

navigation instructions with limited interface to avoid distractions.

Driving Wayfinding—Tailored Roadway Signage 

Transportation agencies provide permanent roadway signage for traffic control at locations

where conflicting movements occur to warn traveler about changes in roadway conditions and to 

offer directional guidance. These types of signs follow standard Manual on Uniform Traffic 

Control Devices (MUTCD) formats and are located at fixed positions for known, permanent 

conditions.(10)

 Examples include signing for intersections, curves, and stadiums. In situations 

where the condition is temporary, users often lack information because traditional signage is not 

applicable and dynamic message boards are not ubiquitous. 
33 

Mobile devices could provide real-time information to the driver based on prevailing conditions 

in the immediate area. This information could warn of traffic incidents, temporary weather

impacts (e.g., flooding), detours, or severe congestion that might affect the planned trip.

To support this use case, the mobile device would automatically communicate standard messages 

(including location, direction, and speed) to the TMC in realtime. The TMC would determine 

whether any temporary unexpected conditions exist in the area and deliver warnings to the 

mobile device via messages. The mobile device could provide the warning to the driver via 

audible interface to avoid distractions.

Provision of Toll Facility Information

Toll facilities users visually digest a significant amount of information regarding pricing, vehicle 

eligibility, hours of service, and enforcement/fines. The possibility of information overload 

increases when drivers are unfamiliar with their surroundings and are relying on guidance signs 

for directions. Drivers who are sensitive to pricing may also need to calculate total cost before 

committing to the toll facility.

A mobile device could be configured to deliver tailored information to a toll user to ensure the 

driver clearly understands the tolling information relevant only to the segment/duration 

applicable to their route. Furthermore, a mobile device would allow information to be arranged

and displayed in various dynamic modes to reduce the burden on the user of remembering

information that is placed only periodically along the freeway.

To support this use case, the user would have to develop a pretrip itinerary that identifies the

desired route adjacent to a toll facility. While en route, the mobile device would automatically

track progress and communicate information to the toll management agency in realtime. The

information may include planned route, current location and speed, and ultimate destination. The

toll management agency would evaluate the adjacent toll facility for potential use, based on the 

current location and destination, and then communicate back the location of adequate entrance

and exit points. If there is an adequate route using the toll facility, the toll management agency

would send information pertaining to the associated total travel time and total cost based only on 

the segment(s) pertaining to the user.

Adjust Transit Operations (Connection Protection)

Travelers on a multileg transit trip depend on reliable connections to arrive at their destination in

a timely manner. If the traveler misses the connection, waiting for the next transit vehicle to

service the stop may drastically increase travel time. Connection protection is the coordination 

between intersecting transit lines to protect the rider’s transfer. However, a transit agency may

require certain conditions be met to allow connection protection (e.g., a threshold on the number 

of travelers needing to make the transfer or a requirement for the connecting route to be low 

frequency in nature). 

A mobile device could be used to facilitate connection protection by communicating a traveler’s

anticipated transfer location and arrival time to the transit agency en route. This process could 

apply for connections within a single transit agency or across multiple agencies. While the 
34 

notification could be completed through user input, it would be beneficial if the actions were

automatic and generated from a planned route to eliminate distractions if the user is multimodal.

To support this use case, the user would have to develop a pretrip itinerary that identifies the

desired transit route both in terms of location and time. While en route to the transit boarding 

location (regardless of current mode), the mobile device would automatically track progress and 

communicate information to the transit provider in realtime. The information required would 

include desired transit route, boarding location, anticipated arrival time, and ultimate destination. 

If the ticket fare was prepaid, there may be a need to commute reservation data, and the transit

agency would evaluate the transfer based on their policies and communicate back the availability

for connection protection. If the transfer is not possible, the transit agency could utilize the user’s

current location and ultimate destination and send alternative routes, alternate boarding locations, 

and a list of the next boarding times.

Driver Notification of Passenger Waiting at Stop

Transit vehicle operators generally look for the presence of travelers waiting at a stop along the 

route to determine whether they provide service to the stop and allow boarding. There may be 

instances under which it might be difficult for the driver to see the waiting traveler due to

physical objects on the roadside that may occlude the travel from the driver’s view. Similarly,

during periods of low light, it might be difficult to see a traveler waiting at a bus stop, especially 

if it is not well lit. In addition, many designated transit stops serve multiple routes, meaning that

waiting passengers could be waiting for a different transit vehicle. Knowing whether passengers

are waiting for pickup and and for which route would help increase the efficiency of the transit

operator and reduce unnecessary stops. A mobile device carried by the transit user could be 

configured to communicate with the transit vehicle operator to ensure that the transit vehicle

stops when needed and the traveler boards the correct route.

To support this use case, the user would have to preselect the transit service and desired route for 

their trip. At the stop, the mobile device would broadcast a message to the operator of the 

approaching transit vehicle—either directly or through a transit management center—providing a 

notification that the traveler is waiting for pickup. The information sent could include the 

location of the stop, the intended route and direction of travel, and any special needs such as

handicap access. 

Reserving Use of a Shared Mobility Device

Travelers planning on using a carshare, bikeshare, or scooter-share service as a means of travel

need to ensure that the equipment is available when the traveler arrives. In some instances, the 

shared equipment may no longer be available by the time the traveler arrives at the designated 

pickup location. To prevent this equipment unavailability from occurring, a reservation system

would hold the shared equipment for a given amount of time based on the user’s request. 

Mobile devices could provide a common interface for shared mobility services to integrate with

existing reservation systems. This interface would not only add convenience for a traveler when

utilizing multiple systems but could also allow users the option to locate shared mobility devices 

from competing services, if the selected mode is unavailable.
35 

To support this use case, the user would select the preferred type of shared mobility equipment 

and a pickup location, either through a pretrip itinerary or realtime at their current location. The

mobile device would send location information to the different services requesting the location

and availability of equipment in the vicinity of the request. The user would need to select the 

preferred equipment based on previously identified preference or costs. The mobile device would 

send a reservation request to the system responsible for managing the shared equipment, 

including the location, time of pickup, and travelers trip information. If the reservation is

accepted, the user would be provided confirmation.

Transit Fare Payment (Pay When Boarding/Pay at Fare Gate) 

Transit users typically pay for service before entering the transit vehicle, and most transit

agencies have their own fare collection systems. However, completing a trip that uses multiple

modes of travel (or that uses multiple transit agencies) can become burdensome, particularly if

users carry multiple stored-value payment cards. 

A mobile device could provide a common interface for fare payments and integrate with the various 

fare collection systems. This process would not only add convenience for a traveler when utilizing 

multiple systems but could also allow fare transfers if multiple trips are taken within a given 

timeframe.

To support this use case, the user would first enter financial account information in an app to

allow a transaction to occur. Although most users may elect to use credit card accounts, the app 

could also accept payment from a common payment account that provides other options

(e.g., cash) to promote equity among users who do not have access to credit. At either the transit

fare gate or boarding location, the transit agency would request payment via a message

containing the transit route, boarding location, fare cost, and date/time. The user would accept

the terms and pay for the transit trip by returning a message containing the financial account 

information. The mobile device would then be used in lieu of a ticket or receipt.

Pay for Parking

Parking facilities charge users a fee for parking that is typically based on the length of stay. 

Some systems require prepayment, whereas others require payment on exit. Although most 

systems use cash or credit cards for transactions, employment-based garages may also include a 

proprietary system for regular users (e.g., monthly pass).

Similar to transit fare payments, a mobile device could provide a common interface for parking 

payments that integrates with the various parking collection systems. Users could pay in advance 

of arriving to the parking facility (for a reserved parking spot) or as they enter or exit the parking 

facility (for a spontaneous or unplanned trip).

To support this use case, the user would enter financial account information in the mobile device

on an app to allow a transaction to occur. Although most users may elect to use credit card

accounts, the app would also accept payment from a common payment account that provides 

other options (e.g., cash) to promote equity among users who do not have access to credit. Either 

at the parking facility or in advance of arrival, the parking manager would request payment via a 

message containing the facility name, parking spot ID, parking duration, cost, and date/time. The 
36 

user would accept the terms and pay for the parking by returning a message containing the 

financial account information. The mobile device would then be used in lieu of a ticket or 

receipt. In prepayment or hourly agreements, the mobile device could warn the user of expiration

and allow the user, via mobile device, to increase payment to extend the parking duration. 

EXPECTED ISSUES AND CHALLENGES

There are issues and challenges to consider when sharing electronic messages to meet or 

supplement the information needs of travelers based on current conditions and the decisions 

travelers make while they complete their trip. It is important to think about what, where, and 

when information is needed. Whereas chapter 2 provided some high-level details regarding the 

mobile device-based system concepts of electronic messages, software and hardware, and 

communication, this section highlights specific issues to consider for each of these areas.

Travelers’ Needs for Information and Decisionmaking

The key purpose of developing a ConOps is to elicit the needs of users of the system that would be 

developed. Thus, determining the travelers’ needs for information and decisionmaking is one of the 

most important steps of ConOps development. Interviews, workshops, and surveys are some of the 

techniques used to perform this activity. Without proper methods like these techniques, it may be 

difficult to differentiate between user needs (which are essential to the function of the system) and 

wants (which would be nice to have but are not essential).

When an elicited user need involves providing information to a traveler, another issue to

consider is the determination of when and/or where that information must be provided to make 

the most effective use of it.

Electronic Messages

Data-producing capabilities and data needs change as technology evolves and new innovative 

services/mobility providers are established, and, thus, the types of data contained in messages 

could be updated to reflect such changes. Standardized messages might not include data frames 

and data elements that may be needed to carry these new data elements. If there is a use case that 

can be better supported using this new data, then it may be advantageous to update the standard 

to accommodate the new data element. However, committees responsible for managing message 

standards might only periodically make changes to the standard to reflect the types of data that 

systems or travelers may need. 

It is not ideal to change standards frequently, because devices in a network would have to update 

firmware to be compliant with the updated standard. Firmware updates are not a trivial task for 

organizations that use the affected standardized messages.

Message size is also important to consider. In an environment with a growing number of mobile 

devices, the bandwidth of mid- to long-range communications (where many mobile devices are

within communications range of each other) may limit the amount of data that can be wirelessly

transmitted.
37 

Software and Hardware 

One of the major tasks associated with a mobile device is the ability to broadcast and receive 

messages to and from other, previously unknown, devices that a mobile device encounters during 

a trip. This messaging process requires the requisite software and computing hardware 

capabilities to be available on the mobile device. While today’s smartphones can utilize several 

forms of communication, the direct device-to-device communications necessary to support the

use cases of a mobile device as described within this ConOps do not currently exist as an 

integrated product. Examples of this technology include DSRC and a newer technology, C-V2X, 

which is expected to replace DSRC. 

Developing applications and APIs is one of the largest challenges to realizing a designed system. 

An app on a mobile device is software that processes various inputs (e.g., traveler input, mobile 

device sensor data, and data received via wireless communications media) to enable travelers to 

access various services and provides outputs to travelers that help them make informed decisions 

throughout the course of taking a trip. An API is a feature of a service or system that allows a 

mobile device (or another system) to provide data to or receive data from it. Data required by the 

traveler (or data that a traveler must provide) must be provided (or received) by the service or 

system.

Communication

There are issues to consider with using different telecommunication methods to send and receive

messages from mobile devices. The ability to connect mobile devices with other systems

depends on the availability of a communications network. Without the proper physical 

infrastructure in place, this communication is not possible. 

Certain applications require systems and mobile devices to remain connected (and to sustain this

connection throughout the entire course of a trip). Data-generating systems are static in nature—

they typically connect to the Internet or to a private network through a physical backhaul. 

However, when it comes to mobile device connectivity, wireless communications are crucial.

Several communications media could be used to send data to, and receive data from, mobile 

devices. However, as discussed in chapter 2, Communication, each communications media has 

its advantages and disadvantages, which need to be considered when establishing a wireless 

network that can be accessed by mobile devices. First and foremost, the ability of a mobile 

device to send and receive data over a particular communications medium is the ability for a 

particular mobile device to communicate via that communications medium. While certain media 

may be considered common (e.g., Wi-Fi), others may not (e.g., NFC). The more ubiquitous a 

communications media is on mobile devices, the more it can be leveraged by travelers on a large 

scale.
38 

Furthermore, different communications media have

different areas of coverage, which influence where a 

mobile device can communicate with a system via 

that communications medium. It is important to 

consider what level of connectivity may be needed

between the mobile device and other supporting 

systems. For applications where more constant 

connectivity is ideal, one strategy would be to allow communications to occur via multiple

mediums to allow for more continuous coverage, which ultimately provides a more robust user

experience. In other instances, it may be advantageous to limit communications to a small area 

when the need for a mobile device to be continuously connected is not required (for instance, the 

communication of payment information, or passing farecard credentials to gain access to a transit 

system).

Another aspect of wireless communications to consider is accessibility. Access to certain 

communications media (e.g., 4G LTE) requires the traveler to subscribe to a mobile Internet service 

provider. For a service to be ubiquitously available to all mobile device users, it would ideally be 

freely accessible and not require the user to subscribe to a data plan to be connected to other 

transportation systems. Addressing such concerns typically becomes the responsibility of local 

transportation or technology agencies. The local agency becomes responsible for providing the 

wireless communications infrastructure, backhaul connectivity (to other systems or the Internet), and 

a computing platform (if a translation of data is needed between systems).

Agency Management Systems

Mobile devices can only provide benefits to travelers if there are other systems sharing or using 

electronic messages for the mobile devices to access. If such systems are not available or are not 

collecting or sharing electronic messages, then the benefits that can be derived by the traveler are 

not realized. Specific systems that could share and use electronic messages with connected 

mobile devices used by travelers could include, but are not limited to, transit management 

systems, TMSs, shared-mobility device management systems, and payment systems. 

Agencies may need to deploy a network of devices in locations where they desire to support the 

exchange of information with mobile devices. The primary purpose of these field devices is to 

send messages to mobile devices, receive messages from mobile devices, and process these 

messages. Furthermore, communications between these field devices and a central system, 

software to process data, and database(s) with APIs to receive and process data are required. 

Although managing such a network for communicating with mobile devices is a large 

undertaking, doing so could vastly broaden the accessibility of electronic data to travelers and 

the ability of agencies to receive data from the travelers to more effectively manage their 

systems. 

Each communications media has 

inherent advantages and disadvantages, 

which are considered when 

establishing a wireless network that 

can be accessed by mobile devices.
39 

CHAPTER 4. INFORMATION NEEDS OF TRAVELERS USING CONNECTED

MOBILE DEVICES

CHAPTER OVERVIEW

Travelers can be presented with a vast amount of information in their environment that may or 

may not relate to travel. Understanding how the traveler prioritizes and consumes a wide variety

of information is an important step to ensure that planned information exchanges between a 

transportation agency and service provider occur in a safe and timely manner without causing 

undue distraction or overload. The desired type and frequency of information exchange governs 

when and how agencies deliver the information to ensure recognizing, processing, 

decisionmaking, and acting by the traveler. 

This chapter provides an overview of the human factors involved in information processing and 

decisionmaking. The following specific topics are discussed: 

• How Travelers Use Information. 

• Types of Information for Decisionmaking. 

• Spatial and Temporal Aspects of Decisionmaking. 

• Positive Guidance.

Each of the aforementioned topics are discussed in general and applied to mobile devices. Due to 

their design, mobile devices provide a new mechanism for information exchange that provides 

increased flexibility in terms of spatial, temporal, and formatted delivery. If used correctly, the 

unique characteristics of a mobile device can enhance the user’s ability to ensure the correct use 

of the information exchange. This usage includes addressing safety concerns by categorizing 

information in terms of control, guidance, and navigation—each with their own requirements in 

terms of latency and format.

HOW TRAVELERS USE INFORMATION

Travelers use information to become aware of surrounding conditions that may influence their

actions or planned trip and then react to the condition. Inherent differences in the type of 

information or level of importance influences how travelers use the information. This

information use in turn affects the design of the mobile device-based system.

The two primary groups of data essential to travelers are safety data and mobility data. Safety

data are used to make decisions related to avoidance of objects, users, and other environmental 

hazards that may cause personal injury. These data are transmitted constantly with high

frequency and low latency to ensure they will be of use to the mobile device user. Mobility data 

are used to make decisions on mode choice, routing, and timing of a trip. Although low latency is

not required, the data exchanges are expected to occur in near realtime. Constant connectivity is
40 

not necessary to exchange mobility data, but it is

expected that intermittent connectivity is needed at a 

minimum as the traveler completes a trip.

Other types of information that benefit travelers are

related to trip planning, wayfinding, and payment 

systems. Data transmitted for trip planning, 

wayfinding, or payment options may only be needed 

once for a trip, oftentimes before a trip begins or after

a service is provided. Low latency and constant

connectivity are not necessary for these functions. In

addition, most of these functions need to coordinate with other platforms or services, which may

introduce additional latency. 

TYPES OF INFORMATION FOR DECISIONMAKING

Safety Information

Safety information is critical to the well-being of travelers themselves and surrounding travelers. 

This information is processed immediately to determine preventive or corrective actions that may

involve the quick evaluation of multiple alternatives, each having unique advantages and 

disadvantages. An example of this type of safety situation is a pedestrian in the roadway. Drivers

first identify the pedestrian and determine the probability of impact based on distance and current 

speed. Once identified, the driver determines the appropriate countermeasures (e.g., use horn, 

abrupt stop, lane change), prioritizes each measure based on merit, and acts on the preferred

alternative. In this case, a mobile device-based system could assist in identifying the pedestrian

quickly and allowing the driver to focus on the appropriate reaction.

Mobility Information 

Mobility information influences the user’s trip in terms of routing, mode, and time. This

information is not critical to warrant immediate processing but could be evaluated continuously 

during the trip to maximize efficiency. Typical users, regardless of mode, would use mobility

information to weigh available options and select a preferred alternative based on time, cost,

comfort, or other personal criteria. An example of this type of mobility situation is an unexpected 

delay on the freeway. Drivers identify the change in congestion and determine the impact to their

travel time based on available information. Once identified, the driver determines appropriate 

options (e.g., stay on current freeway, use alternate route, switch to transit, cancel trip),

prioritizes each option based on merit, and acts on the preferred alternative. In this case,

mobile device-based information provided to a traveler could identify congestion and its location 

and then calculate the change in travel time and offer alternate routes.

Trip Planning Information

Travelers typically use trip planning information before a trip is executed but also during a trip if

a modification is needed. Trip planning information is not as time sensitive as safety or mobility

information; however, travelers place importance on the convenience of the information. In

general, trip planning considers available options in terms of mode, route, time, costs, and other 

Travelers need information on: 

• Safety.

• Mobility. 

• Trip planning.

• Wayfinding. 

• Payment options. 
41 

factors to allow a comprehensive evaluation. Once a trip is selected, the traveler needs access to

the trip details throughout the trip. A mobile device-based trip planner could provide access and 

comparative data to available modes and then provide updates and reminders throughout the trip.

Wayfinding information enables travelers to identify a route, maintain the route, and arrive at

their destination as planned. The information is relatively straightforward—inform the traveler of 

upcoming route names and necessary turn directions. Travelers need this information in near

realtime and continuously through the trip. In many instances, this information is visually

available through guide signs or transit maps but is not tailored to a specific traveler. A mobile

device could provide tailored wayfinding and route information to a traveler and then provide 

estimated arrival times. Mobile devices could also provide this information verbally to avoid 

potential distractions to travelers.

Payment information plays an important role in traveler decisionmaking when services are

available or needed. These services could take the form of transit, toll lanes, parking, shared

mobility, or ride hailing. Payment information allows users to make informed decisions on 

whether the costs are justified for their current situation, or if the user does not have flexibility,

the information allows the user to plan for the expense. Although the information does not need

to be immediate, it does need to be convenient. In many cases, the various services each need 

separate platforms to obtain information or make payments, which can result in additional steps

for a user. A mobile device could provide a single interface that allows travelers to access

pertinent payment information in one place and create a transaction based on their preference.

Information to Provide to Travelers Using Mobile Devices

When considering what information to provide to a traveler, certain attributes regarding the 

traveler and the trip govern what data are needed. For instance, the type of trip being taken, mode 

being used, available alternatives, and traveler limitations/preferences play a role in what

information could be displayed to a traveler to help them make decisions as they complete a trip.

Examples of various types of information include, but are not limited to, the following options: 

• Safety messages—Include a traveler’s location and motion to enable safety applications

that ultimately benefit the traveler.

• Roadway and intersection geometry—Include the infrastructure characteristics to allow

users to position themselves with respect to the physical environment. 

• Signal state information and priority request messages—Include the current signal

state to allow pedestrians and bicyclists to request a crossing at a signalized intersection.

• Payment information—Includes fare information from service providers to provide a 

convenient method for paying for various 

modes of transportation.

• Multimodal planning information—

Includes the most efficient route for a traveler

using a personal vehicle, transit, shared

mobility, and/or ride-hailing services (as

specified by the traveler).

A mobile device could tailor the spatial 

and temporal delivery of information to 

supplement what is provided within the 

public right-of-way, based not only on 

physical aspects of distance and speed, 

but also on user preferences.
42 

• Managed-lane information—Includes toll and travel time information between various 

ingress and egress locations along a managed lane.

• Roadway signage information—Includes the location and information displayed on 

static and dynamic roadway signs applicable to the route.

SPATIAL AND TEMPORAL ASPECTS OF DECISIONMAKING

Information exchanges with travelers need to consider many factors that influence the

decisionmaking process, but timing is essential. Travelers need time to process information,

make a decision, and then take the required actions before reaching the decision point. Some of 

these factors are driver-specific (e.g., reaction time), whereas some factors are 

environment-specific (e.g., congestion). To aid the decisionmaking process, a mobile device 

would need to account for the spatial and temporal aspects of the traveler’s information needs. 

As an example, vehicles generally travel at much higher speeds than bicycles and pedestrians. 

Therefore, drivers need information much earlier than pedestrians due to the larger distance 

traveled while comprehending and interpreting the message. This reaction time varies according

to whether the event is expected (more reaction time) or unexpected (less reaction time) as well

as the amount of information that might need to be processed. If deceleration is required, a 

vehicle’s weight and speed need a longer distance to safely decelerate than a nonmotorized 

mode. If lane changing is required in congested conditions, longer distances may be required 

because of the number of potential conflicts with other users.

Alternatively, a transit user is bound to a fixed route and is not actively engaged in operating the 

vehicle. As such, reaction times are not as important in terms of spatial and temporal delivery of 

information. Information delivery does need to account for transit vehicle speeds, walking distances, 

and service times. If a user has a planned transit ride, information would be delivered to allow 

enough time for the transit user to comfortably arrive at the stop before the transit vehicle.

SPATIAL AND TEMPORAL INFORMATION USING MOBILE DEVICES

One of the major benefits of delivering information through a mobile device is that a mobile 

device could tailor the information to the characteristics and needs of individual travelers. This 

type of information exchange differs from traditional signage, which accounts for an aggregated 

pool of users and situations when placing information in a static location. A mobile device could 

tailor the spatial and temporal delivery of providing this information to supplement what is 

provided within the public right-of-way, based not only on physical aspects of distance and 

speed, but also on user preference. As users age, they may need (or desire) more time (and 

distance) to make decisions, which a mobile device could customize. However, information 

provided via mobile device would be supplementary and would not be intended to replace laws, 

regulations, policies, or rules governing the behavior and responsibilities of a traveler for any 

travel mode.

POSITIVE GUIDANCE

One of the more comprehensive resources for determining when to provide information to 

travelers to improve their ability to make decisions is in a User’s Guide to Positive Guidance.

(11) 
43 

Although the guide mainly focuses on a driver’s perspective, the concept of positive guidance is 

based on knowledge rooted in human factors and can be applied to a broader range of 

transportation users.

Humans often filter vast amounts of information to prioritize and react to the most immediate, 

important events. Drivers tend to prioritize information by emphasizing information that affects 

control and by following guidance and then navigation (figure 3). Driver priorities are typically 

ordered as follows: 

• Control (highest importance)—Pertains to vehicle handling and response. 

• Guidance (medium importance)—Involves highway design, traffic operations, hazards,

and traffic control devices.

• Navigation (low importance)—Affects pretrip and in-transit phases and relates to

routes, service, and guide signs. 

Source: FHWA. 

Figure 3. Diagram. Vehicle operation primacy triangle (human factors).(11)

Although the guidance is mainly focused on visual information, the concepts can also apply to

audible alerts (e.g., siren or horn, audible pedestrian crossings, transit announcements) or haptic 

alerts (e.g., raised pavement markers, rumble strips, tactile curb ramps).(11)

Positive Guidance Techniques

As the amount of information available to a traveler increases, the required processing and 

reaction times increase. This same logic applies to the driver’s expectancy of information—if the 

driver’s expectancy of information is violated, the driver’s reaction time increases. Positive

guidance provides presentation principles and techniques that address the various considerations 

associated with the process of receiving and reacting to information. In general, the information

regarding hazards, routes, and services displays when needed, where required, and in a form best

suited to the user and task. However, too much information (overload) reduces the user’s ability

to prioritize and react to the critical task. Similarly, a lack of information (underload) may cause

a user to miss a critical task. The following techniques can improve the delivery of information 
44 

to ensure it is compatible with what drivers expect, does not surprise the drivers, and 

accommodates a wide range of users:

• Spreading—Technique that involves the spacing of information (such as longitudinally 

on a freeway) to reduce the chance for information overload to drivers at locations where 

several decisions might need to be made in a short period. 

• Coding—Concept that translates information into a graphic symbol for faster processing. 

When multiple codes are merged into larger units, it is known as chunking. 

• Repetition—Reiteration of information to ensure the intended audience is more likely to 

remember and act on it.

• Redundancy—Technique that uses multiple forms of communication (i.e., language, 

color, and shape) to ensure understanding. 

Positive Guidance in Mobile Devices

Positive guidance concepts could be applied to mobile device users as they complete a trip.

Although these concepts generally refer to the placement of information on freeways and visual 

techniques, mobile devices could provide visual information to a traveler on screen as well as 

provide audible information and haptic feedback to users.

The visual presentation of information to a traveler might be provided at a time and location in 

advance of a decision point (depending on how close the traveler is to that decision point) to 

reinforce behavior or to provide an alert about a safety situation that might demand the traveler’s 

attention. The audible and haptic aspects of mobile devices are also important to consider, 

because a traveler could be focused on other activities such as operating a vehicle or crossing a 

street. For drivers, mobile devices could be located outside their primary field of view, which 

would require an unsafe change in visual focus from the roadway. For pedestrians, the mobile 

device could be in a pocket or a tote (e.g., a purse or backpack) that prohibits visual exchanges. 

In certain jurisdictions, it is illegal to engage in smartphone activity during certain activities

(e.g., using a crosswalk). For bicyclists or scooter riders, using a handheld mobile device is

prohibitive because both hands are being used to steer. In these situations, positive guidance 

could be accomplished through audio and haptic outputs from the mobile devices. These audio 

and/or haptic outputs could be provided to the user at the same time that the user would expect to 

receive a visual cue and could be similar in nature to reflect the prominence of the information 

and its importance to the traveler.
45 

CHAPTER 5. DEVELOPING A DESIRED OPERATING ENVIRONMENT

CHAPTER OVERVIEW

The planning and design of information exchanges with mobile devices should involve a 

well-defined process to ensure that each component of the information ecosystem is properly 

included and integrated. Like other complex projects, it is important that a mobile device project 

follow an established SE process that incorporates the various components (e.g., the traveler, 

transportation agency/service provider, software/hardware, and communication platform). The 

benefit of this process is that SE follows a sequential path as a project progresses with various 

validation/verification checks to ensure that the product adequately represents the planning and 

design. For maximum efficacy, it is necessary that this process be initiated at the planning stage 

and align with regional goals and efforts to maximize stakeholder input and concept 

development. 

This chapter provides an overview of the project development processes applicable to developing 

a mobile device information exchange. The following procedures are outlined in this chapter: 

• Planning. 

• SE Process.

• Agile Development. 

Although each step of the project development process is described as a general reference for 

transportation agencies and/or transit service providers leading the development process, it is 

important to check for regional and/or local project development standards and guidelines. Many 

States and regions have developed individual SE requirements and ITS architectures.

PLANNING

Transportation services providers continually engage in a range of planning activities to advance 

their programs. The activities can also help to advance the development of mobile device-based

systems in the following ways: 

• Leveraging the interjurisdictional and interdisciplinary momentum that collaborative

planning activities foster. 

• Capturing the needs of diverse sets of user groups. 

• Identifying opportunities to leverage current and future investments in transportation

technologies.

• Defining a transportation ecosystem in which travelers using connected mobile 

device-based systems can be integrated into the management and operation of the surface 

transportation system, specific facilities, or services. 

• Supporting solutions that address travelers’ purpose and need and linking those needs to 

enhance access to or use of existing services and facilities. 
46 

• Addressing how purpose, need, and scope of the project fit in the project and planning 

process.

• Adding context for creating and using solutions that encompass mobile devices and data. 

• Identifying potential mobile device-based projects. 

Some of the planning activities that can be leveraged in the preparations of studies, proposals, or 

the development of projects to facilitate sharing and using data with mobile devices or for 

specific services are discussed in the following subsections. 

Metropolitan Transportation Plan 

Each metropolitan planning organization (MPO) develops a metropolitan transportation plan to 

accomplish the objectives outlined by the MPO and State and local transportation service providers 

with respect to the development of the metropolitan area’s transportation network. This plan 

identifies how the metropolitan area would manage and operate a multimodal transportation system 

(including transit, highway, bicycle, pedestrian, and accessible transportation) to meet the region’s 

economic, transportation, development, and sustainability goals for a minimum 20-yr horizon.(12)

Opportunities to implement an ecosystem that supports information exchange with mobile 

devices could be found in projects related to ITS, TMSs, and transit management services. It may 

be advantageous to look at the goals and objectives of such systems to determine how sharing 

data with mobile devices could support these systems and to advocate inclusion of the 

components necessary for these systems to share data with mobile devices.

TSMO Plans

Many States and regions are beginning to develop plans that specifically focus on TSMO to 

provide strategic direction, to provide program development, and to define strategic activities to 

enhance the operations and management of transportation systems. These planning projects are 

collaborative efforts whereby stakeholders work together to identify a vision, mission, and goals 

and objectives specifically for a TSMO program. The TSMO plan articulates the organization 

and operational procedures available within the State/region, the necessary resources and 

activities available to achieve the goals and objectives, and the services and goals needed to 

realize the TSMO goals and objectives. Generally, TSMO plans have three elements:

(13)

• Strategic—May include the business case for TSMO, vision and program mission, and 

goals and performance objectives. 

• Programmatic—May include leadership and organizational structure, staffing and 

workforce needs, and business processes. 

• Tactical—May include TSMO projects and services and implementation policies.

It is advantageous to identify the goals and objectives of within these plans where efforts to 

create or sustain an ecosystem for sharing messages with connected mobile devices can be 

included to enhance the effectiveness of the proposed system. 
47 

SE PROCESS

The SE process involves a top-down process whereby the mobile device-based system would be 

derived from developing functional and physical requirements as defined by stakeholders. The 

“Vee” diagram SE process—which can be applied to the design, development, implementation, 

startup, operation, and monitoring of a mobile device-based system development project—is 

illustrated in figure 4.

(14) This is a commonly accepted process for SE for transportation 

technology projects, and by extension, it is applicable to mobile device-based systems. 

Source: FHWA. 

Figure 4. Diagram. SE Vee diagram.(14)

The SE process starts in the upper left portion of the diagram, moves down and to the right in the 

decomposition and definition phases, undergoes the development process, and moves upward and 

to the right in the integration and recomposition phases of the process. The timeline of the process 

progresses from right to left, while the level at which the mobile device-based system is defined for 

each process is represented by the vertical location on the figure. High-level processes, near the top 

of the figure, represent specifications more abstract in nature, whereas low-level processes, near 

the bottom of the figure, provide detailed specificity regarding individual components of the 

mobile device-based system. Each step on the downward (left) side of the process is tested, 

verified, or validated through a corresponding step of the upward (right) side of the process. The 

documentation that captures the test, verification, or validation is represented by the dashed 

horizontal lines that connect the downward (left) and upward (right) sides of the diagram. An 

overview of these steps is provided in the remaining subsections in this chapter, with the primary 

focus on the ConOps and the systems requirements documentation.
48 

Regional Architecture Development

A key initial step in the planning for 

transportation technology projects, including 

mobile device-based systems, is the 

understanding of the existing regional and/or 

statewide ITS architecture. For regions where an ITS architecture does not exist, one should be 

developed to coordinate and facilitate the planning, development, and deployment of ITS 

projects.

The Federal Highway Admimistration (FHWA) defines a regional ITS architecture as “A 

specific tailored framework for ensuring institutional agreement and technological integration for 

the implementation of project of groups of projects in a region.” The regional ITS architecture 

defines what ITS elements are linked to others and what information is exchanged between them 

through the following actions:

(15)

• Providing each project sponsor with the opportunity to view their project in the context of 

other regional systems. 

• Prompting the sponsor to think about how a mobile device-based system would fit within

the overall transportation vision for the region. 

• Identifying the integration opportunities that would be considered and providing a 

headstart for the SE analysis needed to plan and develop a mobile device-based system. 

Developing the ITS architecture helps to understand what types of external systems and data 

might be available and how new components that would support the communication of 

electronic messages with mobile devices to share these data could be integrated with the existing 

system. Conversely, the architecture could be used to determine how existing ITS components 

could leverage information received from mobile devices to enhance operations. 

Project Purpose and Objectives

A transportation service provider or some other regional entity such as an MPO may decide to 

further explore a mobile device-based system project, thus it would be critical to identify the 

purpose and objectives of the systems. The definition of the project purpose would be rooted in 

the various needs or opportunities as defined by the various stakeholder groups. A definition of 

the project purpose and objectives would document the following elements: 

• Motivation for the mobile device-based system and the problems or opportunities for 

improvement that it is intended to address. 

• Objectives that need to be achieved for the mobile device-based system to be considered 

successful. 

• Anticipated benefits for each stakeholder and user group. 

Feasibility/Concept Exploration 

Feasibility/concept exploration entails making a business case for the potential mobile

device-based system. As part of this process, it would be considered in the context of the 

A key initial step in the planning for 

transportation technology projects, including 

mobile device-based systems, is the 

development of a regional ITS architecture. 
49 

technical, economic, and political feasibility of the region. The following activities would be 

commonly conducted during this step:

• Identify alternative concepts to address goals and objectives established by stakeholders. 

• Define evaluation criteria to evaluate candidate systems. 

• Conduct an initial risk analysis of each of the candidate systems. 

• Evaluate alternative systems. 

• Document results of the analysis activities in a format suitable for leadership use in 

decisionmaking. 

The primary goal in conducting feasibility/concept exploration would be to gain leadership 

approval so the candidate mobile device-based system may move forward.

ConOps

A ConOps serves as the first in a series of engineering documents in the SE process that would 

focus on clearly conveying a high-level view of the mobile device-based system to be 

implemented from the viewpoint of each stakeholder. The ConOps would frame the overall 

mobile device-based system, would set the technical course for the project, and would serve as a 

bridge between early project motivations and the technical requirements. The ConOps would be 

technology independent, would focus on the functionality of the proposed mobile device-based

system, and would form the basis of the project. The ConOps would also communicate the user’s

needs and expectations for the proposed mobile device-based system. The development of the 

ConOps would also provide stakeholders with the opportunity to provide input as to how the 

proposed mobile device-based system could function, which would help build consensus and 

create a single vision for the mobile device-based system being developed. Developing the 

ConOps would facilitate consensus among stakeholders, reduce the risks associated with the

mobile device-based system being developed, and improve the quality and overall operation of 

the mobile device-based system. The various sequential activities that would result in the

ConOps are described in the following subsections. 

Current Operating Environment

Analyzing and documenting the current operating environment would help define what/how 

current systems operate (even if it is a mostly manual process) or state that no system exists. The 

analysis would also describe the motivation for developing a new mobile device-based system 

and would identify how the users can achieve the goals/objectives established for the existing 

system. Modes of operation and users of the current system would also be defined in the analysis 

of the current operating environment. In addition, the analysis would provide an assessment of 

current capabilities; define what the system is aiming to accomplish; and describe benefits to 

users of devices, to the operation of mobile device-based systems, and to other travelers. 

Furthermore, the analysis would describe any operational policies and constraints that apply to 

the current system or situation. Operational policies would be predetermined by management 

decisions regarding the operations of the current system, normally in the form of general 

statements or understandings that guide decisionmaking activities.
50 

Justification for Changes

In developing a ConOps, it would be necessary to ensure that user capabilities and needs are

considered and that system capabilities and/or system needs are defined. The following activities 

would be necessary to accomplish these goals: 

• Summarize the new or modified missions, objectives, environments, interfaces,

personnel, or other factors to consider for a new or modified system. 

• Document and prioritize user needs as essential, desirable, or optional. 

• Identify if there are any alternative nonmobile device-based technologies that were

considered but not included in the concept. 

• Detail the deficiencies or limitations of the current system or situation that would make it

unable to respond to new or changed factors. 

• Provide justification for a new or modified system. 

Based on this information, performance measures necessary to assess the proposed mobile 

device-based system would also need to be considered at this point. 

Operating Environment

In developing the ConOps, it would also be necessary to define the operating environment. This

process would entail developing a summary of new or modified capabilities, functions, 

processes, interfaces, and other changes needed to respond to the factors identified. The 

summary would describe the proposed mobile device-based system at a high level, indicating the

operational features that would be provided without specifying design details and the operational 

policies and constraints that would apply to the proposed mobile device-based system. Physical 

aspects of the new mobile device-based system would be defined in terms of hardware, software,

system interfaces, communications, messages, facilities, security, and so forth. 

Operational Scenarios

The description of the operating environment is typically followed by the enumeration of 

scenarios that provide a step-by-step description of how the proposed mobile device-based

system would operate and interact with its users and its external interfaces under a given set of 

circumstances. Scenarios would be described in a manner that would allow readers to walk 

through them and gain an understanding of how all the various parts of the proposed mobile 

device-based system would function and interact. The scenarios would tie together all parts of 

the mobile device-based system, the users, and other entities by describing how they would 

interact. The scenarios could also be used to describe what the mobile device-based system 

would not do. 

Impact Summary

Understanding operational and organizational impacts resulting from implementing the proposed 

mobile device-based system and considering events that could occur during development that 

may affect mobile device-based system design would also be critical. In documenting and 
51 

analyzing the impacts, it would be necessary to consider the impacts from the perspective of each 

user. 

System Requirements

After a ConOps has been developed and stakeholders have agreed on the content in the ConOps, 

the system requirements documentation could begin to be developed. Requirements govern what,

how well, and under what conditions a mobile device-based system (or subsystem within a 

system) would achieve a given purpose. 

A clear requirement statement would provide a shared understanding of the problem to be solved

by a customer and a developer, a firm basis for managing project scope, the connection between

user needs and mobile device-based system design, and the foundation for mobile device-based

system verification/testing. If necessary, requirements could be defined as a hierarchy, whereby a 

parent requirement would be supported by one or more child requirements that would go into

greater detail and specificity.

Quality requirements would be necessary, unambiguous, complete, measurable, consistent, 

achievable, testable, and technology independent. (These requirements would be important to

consider because communications technologies are discussed with respect to mobile devices.). 

As each requirement is written, it would be inspected to ensure each of the following six criteria 

are met:

• Necessary—Traces to a user need or a parent requirement. 

• Clear—Does not use ambiguous language (e.g., user friendly, optimum, realtime, or

overly complex sentences). 

• Complete—Traces every user need to at least one requirement and ensures the need can

be fully met with the provided requirements. 

• Correct—Describes needed functionality and performance accurately. 

• Feasible—Is technically and financially achievable. 

• Verifiable—Is verifiable by using one of the four verification methods. 

Validation and Verification

Validation and verification provide means for checking the developed mobile device-based

system against the concepts and requirements that were defined in earlier steps (the 

down-sloping side of the Vee diagram) of the SE process. Though traceability throughout the SE 

process would minimize the likelihood that the system is not properly built or does not meet 

agency objectives or stakeholder needs, validation and verification provide documentation that 

this mobile device-based system is operating as intended. Verification provides a check against 

the established requirements to ensure the mobile device-based system that was built per the 

specifications as defined in the requirements document, whereas validation ensures that the 

mobile device-based system that was built ultimately solves the problem(s) that was/were

intended to be solved by the mobile device-based system. Validation is discussed in further detail 

in chapter 6, and verification is discussed in further detail in chapter 7. 
52 

Validation

The initial performance measures identified in the ConOps provide a foundation for the system 

validation plan. Although expectations for the mobile device-based system would change over 

time, the performance measures outlined in the ConOps force early consideration and agreement 

of how mobile device-based system performance and project success would be measured. 

Validation confirms that the user needs are met by the installed mobile device-based system and 

occurs throughout the SE process. Furthermore, the validation plan ultimately establishes that the 

right mobile device-based system was built (i.e., right business case, right needs, right

requirements, right design, and right implementation).

Verification

A plan for verifying the mobile device-based system based on the requirements would be 

defined. It would be critical that only verifiable requirements be included in the system

requirements document. A verification method would be identified for every requirement—

normally, through testing, demonstration, inspection, or analysis. The purpose of this early

assignment of a method, long before the requirements are verified, would be to make sure that

the authors think about how the requirement would be verified from the beginning. 

The system verification plan defines testing, demonstration, inspection, and analysis processes 

related to each requirement. Functionally related requirements would be demonstrated in each

test case. It is important to note that the verification plan would not be a test procedure. Test

procedures would be provided as part of the procurement process by vendors to define what is 

needed to carry out a test described in the verification plan. 

System Design

Once the ConOps and system requirements have been finalized, the system design could be 

developed. This documentation would contain the design factors and the choices made to satisfy

the requirements developed in the system requirements specification document, and it would

guide implementation of the system. The primary objective of the system design document 

would be to produce a design that meets the system requirements; defines key interfaces; and 

facilitates development, integration, and future maintenance and upgrades. Details could include, 

but would not be limited to, hardware and firmware specifications for various devices that would 

be deployed, configuration details for each device, and specific functions that each device might 

need to perform. 

Key activities of the system design process would be as follows:

• Evaluate off-the-shelf components. 

• Develop and evaluate alternative high-level designs. 

• Analyze and allocate requirements. 

• Document interfaces and identify standards. 

• Create an integration plan, subsystem verification plans, and subsystem acceptance plans. 

• Develop detailed component-level design specifications. 
53 

Once the detailed design has been reviewed and accepted, the mobile device-based system could 

be developed and procured. 

Testing

Once hardware and software have been procured, they would be tested to ensure that

off-the-shelf or designed components adhere to the system design specifications. Once tested, the 

components would be ready for integration and installation.

Integration and Verification

Software and hardware components that make up the system would be progressively combined 

into subsystems until the entire mobile device-based system is assembled. Verification would 

ensure that the completely assembled mobile device-based system could meet the system

requirements specifications.

Deployment

The mobile device-based system would be installed in the operational environment and

transferred from the project development team to the organization that would own and operate it.

The transfer would also include support equipment, documentation, operator training, and other 

enabling products that would support ongoing mobile device-based system operation and 

maintenance. Acceptance tests would be conducted to confirm that the system performs as

intended in the operational environment. A transition period and warranty would ease the

transition to full system operation. 

Validation

Once deployed, the system owner/operator would conduct user acceptance tests to make sure that

the deployed system meets the original needs identified in the ConOps—that is, the system 

would fulfill its intended use.

Operations and Maintenance (O&M)

Once the mobile device-based system has been installed and accepted, the system would operate 

in its typical steady state. System maintenance would be routinely performed, and performance 

measures would be monitored. The implication of potential changes in how a mobile

device-based system is managed and operated are discussed in further detail in chapter 6, 

ConOps. 

AGILE DEVELOPMENT PROCESS

Many ITS and CV systems (e.g., research, prototype, and deployment) are traditionally designed 

using the Vee diagram SE process.(14) However, it is worth noting that there is an alternative 

process (the Agile process), which some agencies may prefer (especially for the development 

and integration of mobile devices with the existing system).(16) The Agile process is an 

incremental and iterative method of designing a final product. The Agile process, which is used 

primarily, but not exclusively, in software engineering projects, is adept in its ability to create 
54 

and respond to change, especially when there is uncertainty that requires adaptation. One of the 

primary concepts used in the Agile process is “user stories.” Each user story yields a contribution 

to the value of the overall product, once implemented. 

Due to its prevalence, the remainder of the SE guidance provided in chapter 6 and chapter 7 

focuses on the Vee diagram SE process.(14)
55 

CHAPTER 6. CONOPS

CHAPTER OVERVIEW

A ConOps is the first step within an SE process that transitions from high-level planning and 

goal setting to design. Use of this detail-oriented process has been demonstrated to be effective

in helping stakeholders and system design experts alike in capturing the necessary elements of

the environment, needs, and future concept(s). For mobile device information exchange, a 

ConOps approach could be particularly important to document how mobile devices could play a 

role in a connected transportation environment. The resulting documentation would allow 

stakeholders—regardless of background—to understand the scope of the system, the desired 

operational capabilities, and the various support elements necessary. Figure 5 shows where this 

effort would align with the overall SE process. 

Source: FHWA. 

Figure 5. Diagram. ConOps in the SE process.(14)

This chapter provides an overview of the ConOps purpose, development process, and 

documentation. Chapter content generally follows the structure of a typical ConOps document as 

specified in Institute of Electrical and Electronics Engineers (IEEE) 1362-1998 and summarized in 

the bulleted list that follows.

(17) American National Standards Institute/American Institute of 

Aeronautics and Astronautics ANSI/AIAA-G-043B-2018 is another industry standard that can be 

used for developing a ConOps, and it has a very similar outline and content as IEEE 1362-1998, 

which could be considered as an alternative, depending on the preferences of project development 

stakeholders.(18) However, the remainder of the discussion on ConOps in this document uses the 

IEEE 1362-1998 outline.(17) Each of the following sections of a ConOps are discussed in this 

document, except for the Reference Documents section, which is a standard bibliography section: 
56 

• Concept of Operation Scope (see next section).

• Reference Documents. 

• Current Operating Environment (see chapter 6, Current Operating Environment 

subsection). 

• Justification for and Nature of Changes (see chapter 6, Justification for Changes and User 

Needs subsection).

• Proposed Operating Environment (see chapter 6, Desired Operating Environment 

subsection).

• Operational Scenarios (see chapter 6, Operational Scenarios subsection).

• Summary of Impacts (see chapter 14).

• Analysis of the Proposed System (see chapter 14).

CONCEPT OF OPERATION SCOPE

The ConOps defines the purpose of the document and the scope of the project under which the 

system would be developed. The scope could reference the high-level goals, define how the 

system requirements would build off the ConOps, and describe how the system requirements 

would support future documentation (table 1). 

Mobile devices have proven to be highly disruptive to the transportation space, but at present, most 

deployed applications have been developed by private companies with a strong motivation for 

profit-focused outcomes, with the possible exception of those applications that leverage transit 

data. When defining the system boundaries (i.e., the scope), the author would clarify what the 

agency has control of, what the agency may have some influence on, and what is outside of both 

control and influence and prioritize these factors accordingly. Furthermore, as the industry 

continues to evolve quickly, consideration of what data have proven to be from a sustainable 

source would be necessary.

Table 1. Scope content for a ConOps.

Subsection Description

Identification Identifies the document, its purpose, and its relationship to previous and subsequent 

documentation. 

Document 

Overview 

Lists all chapters in the document and provides a brief overview of what is included 

in each section.

System

Overview 

Provides the motivation for taking on the project, as well as any goals, objectives, 

vision, or mission statements for the project. If the system developed would be part of 

a larger system, this relationship would be defined. This section also provides a 

summary of the hardware, software, and functionality that would be deployed or 

prototyped.

CURRENT OPERATING ENVIRONMENT

The current operating environment would describe the existing systems, types of connected

devices supported now or planned for future, and what would be done to support the 

environment. This environment would include, but would not be limited to, field infrastructure, 

TMS and other management systems; other technologies (API for connected devices, vehicles); 
57 

and services (e.g., updating messages, message libraries, APIs, and coordinating updates). The 

description would address how the existing operating environment is working; how the existing 

systems would work with connected mobile devices (i.e., describe, identify components/systems 

and capabilities); the limitations of the existing system, and the potential impacts of planned 

improvements. Table 2 lists the expected content of each subsection within this section. In 

addition to the standard ConOps language, the descriptions include some considerations as they 

relate specifically to the use of mobile devices.

In general, however, unless an agency is already utilizing their own mobile device data

collection, the current operating environment would likely comprise traditional data collection

systems, possibly supplemented by third-party data aggregators. Even if an agency supports 

mobile devices, it would more likely be pushing data versus receiving data. This model would 

need to change to truly support the goals outlined in the report, but for now, understanding what

is available in today’s environment is important. 

Table 2. Current operating environment contents. 

Subsection Description

Background, 

Objectives, and 

Scope 

Describes existing plans that contain regional transportation goals and 

objectives. CV or CAV strategies and Vision Zero plans are two that are 

more recent additions to existing ITSs as well as transit and freight plans.(19)

A summary of targets and goals of the existing system would be provided. 

Operations 

Policies and 

Constraints

Provides a list of regulations and agency policies that govern the existing 

system. This list would include local ITS/CV architectures as appropriate.

Description of 

the Current 

System or 

Situation

Describes the current environment in which the implementation of mobile 

device technology would affect travelers. This description could include a 

physical description of impacted locations and a list of services or devices 

that comprise the current system. 

Modes of 

Operation for the 

Current System 

or Situation

Describes various modes of operation for the current system. This description 

would include normal operating conditions at a minimum but would also 

consider including nonnormal operating conditions to provide perspective on 

how the current system operates (or fails) when an issue arises.

User Classes and 

Other Involved 

Personnel 

Describes the various users of the current system, how they interact with the 

system, and how the current system benefits each user class. All users that 

fall within the same user class share common responsibilities, skill levels, 

work activities, and modes of interaction with the system. Only user classes 

that would be affected by the implementation of the mobile device-based

system would need to be included. 

Support 

Environment 

Provides a list of agencies involved in the management, operations, and/or 

maintenance of the current system. Agencies that would also play a role in 

the implementation of the mobile device-based system would need to be 

listed—if they do not play a supporting role in the current system, then this 

would be stated. 
58 

Recently, the trend has been for local infrastructure owner/operators to move away from their

own data collection equipment toward that of third-party providers. These various sources of 

data would need to be considered. 

JUSTIFICATION FOR CHANGES AND USER NEEDS

New and/or modified user needs supporting the identification of a new or modified system are

summarized in this section. It summarizes the deficiencies or limitations of the current system or 

situation that make it unable to respond to new or changed factors. It further discusses the 

development of user needs to enable information sharing between connected mobile devices and 

traffic or transit management systems.

The user needs development process is expected to be supported by justifying changes to the 

existing system (table 3). The process of justifying changes would be addressed first, followed 

by a process for eliciting and developing user needs. The user needs would then be addressed by 

enhancing the existing system (discussed in the next section). There may also be system needs 

that could be considered to enable electronic message sharing with connected mobile devices.

A user need would be uniquely identifiable, express a major desired capability or feature that the 

future system should support, and be developed without an end solution in mind. A user need is

strengthened by including a rationale that captures why the need is included. 

Table 3. Justification for changes and user needs contents. 

Subsection Description

Justification for 

Changes 

Provides the results of activities that indicates that the proposed system is

needed to (more adequately) meet user needs. This description could 

include, but would not be limited to, stakeholder engagement summaries,

technical working group meeting outcomes, and/or the results of data or

technical analyses that represent issues faced by existing system users. Part

of the challenge with the use of mobile devices is that the domain of use is

still evolving. Mobile devices are disruptive, and this trend is likely to 

continue. Although envisioning every use of that data is impractical, a 

general trend is to capture what can be made available, and as technology 

and/or research catch up, uses may be found. In other words, plan beyond 

the immediate use cases.

Description of

Desired Changes 

Presents user needs (derived from information presented in the

Justification for Changes section) for each user class. Also provides a 

high-level description of changes that would be made to meet the needs of

users. Measures that would be used to assess system performance would be 

introduced. User needs would reflect the specific use cases of interest, but

again, would be forward thinking, allowing for future uses of data that

have not yet been conceived.

Priorities Among

Changes 

Prioritizes user needs presented in the previous subsection. This

prioritization would be typically done by classifying each user need as

essential, desirable, or optional.
59 

DESIRED OPERATING ENVIRONMENT

This section would describe the proposed system and would include physical objects, functions 

performed by each object, and the messages sent between them. This section could also involve 

identifying constraints on the system. Various aspects of a mobile device-based system that could 

be discussed in this section would include, but would not be limited to, connected mobile devices, 

APIs, and supporting systems to meet user needs. The National ITS Architecture and the extension 

enabled through the Architecture Reference for Cooperative and Intelligent Transportation

framework would be used as a basis for developing system architecture and the system description, 

to the extent applicable to the proposed system and the local ITS architecture.(20)

The architecture for the proposed system could be illustrated in a system diagram. The diagram 

would distinguish between the existing and proposed system (e.g., the communications and 

physical objects in the proposed system would be represented using solid lines and colored 

boxes, while communications and physical objects in the existing system would be represented 

using dashed lines and gray boxes). 

The content in this section would be driven by the selected use cases. Text would establish the

types of physical objects, communications, interfaces, and functions in the system. As noted 

earlier in the scope section of this chapter, those elements of the system that are within control 

and possibly influence would be shown within the system boundary, otherwise they would be 

indicated outside of the boundary. Even if these elements are outside of the boundary, they 

would still be included because their systems, which are primarily envisioned to be third-party

data providers or consumers, could have a significant influence on the system. 

A description of the proposed system would be provided, including the following aspects, as

appropriate: 

• Operational environment and its characteristics. 

• Major system components and the interconnection among those components. 

• Interfaces to external systems or procedures. 

• Capabilities, functions, and features of the current system. 

• Charts and accompanying descriptions depicting inputs, outputs, data flows, control 

flows, and manual and automated processes, enough to understand the current system or 

situation from the user’s point of view. 

• Cost of system operations. 

• Operational risk factors. 

• Performance characteristics, such as speed, throughput, volume, frequency. 

• Quality attributes, such as availability, correctness, efficiency, expandability, flexibility,

interoperability, maintainability, portability, reliability, reusability, supportability, 

survivability, and usability. 

• Provisions for safety, security, privacy, integrity, and continuity of operations in

emergencies.

When describing the desired operating environment, it would be important to consider potential 

capability limitations and challenges that could be faced (table 4). 
60 

Table 4. Desired operating environment contents. 

Subsection Description

Background, 

Objectives, and 

Scope 

Summary of targets and goals that the proposed system would provide. 

Ideally, the proposed system would be in alignment with regional 

transportation goals and objectives for the current system.

Operations 

Policies and 

Constraints

List of regulations and agency policies that would govern the proposed 

system. This list would include local ITS architectures and network, as 

appropriate.

Description of the 

Proposed System 

or Situation

Description of the environment that includes the implementation of mobile 

device technology. This subsection could include a physical description of 

affected locations, a list of services, or devices that comprise the proposed 

system.

Modes of 

Operation for the 

Proposed System 

or Situation

Description of various modes of operation for the proposed system. This 

subsection would include normal operating conditions at a minimum, but 

it would also consider including nonnormal operating conditions to 

provide perspective on how the proposed system would operate (or fails) 

when an issue arises.

User Classes and 

Other Involved 

Personnel 

Description of the various users of the proposed system, how they would 

interact with the system, and how the proposed system would benefit each 

user class. All users that fall within the same user class would share 

common responsibilities, skill levels, and modes of interaction with the 

system.

Support 

Environment 

List of agencies that would be involved in the management, operations, 

and/or maintenance of the proposed system. 

OPERATIONAL SCENARIOS

Operational scenarios would be developed for various series of events (where the scenario would 

play out differently, depending on the types of events that would occur) and operating conditions 

(normal, degraded, failure). In the context of mobile devices, and more importantly, trip

planning/taking, an almost infinite number of combinations could be produced. 

When defining the scenario, the following elements would be captured. In lieu of providing 

examples of each of these elements, the reader can refer to the scenarios included in latter

chapters of this document: 

• Identification and title—Represents the scenario at hand. The title would be specific 

enough to differentiate it from other scenarios. The ID number would provide a shorthand 

method of referring to the scenario and would be generally useful for traceability 

purposes. 

• Description—Provides a high-level overview of the scenario.

• Objective—Describes the outcome that the system would be enabling. 
61 

• Overview of operational events—Provides a description of the system functions that 

would take place in the scenario that would ultimately be responsible for the objectives 

being met.

• Preconditions—Provide background information regarding the state of the system and 

the status of actors that would occur before the events described in the scenario.

• Description of actors—Provides a brief description and role of each actor that would 

appear in the Key Actions and Flow of Events sections.

• Key actions and flow of events—Provide a step-by-step description of how the proposed 

system would operate and interact with its users and its external interfaces to accomplish 

a given objective. Each action would be described using a step number, the actor taking 

the action, the key action taken, and any applicable comments related to the described 

action. 

• Postconditions—Provide information regarding the state of the system and the status of 

actors after the events described in the scenario have occurred.

• Messages (information requirements)—Provide an overview of the types of messages 

that would be exchanged within the system and between the system and external systems. 

Note: Scenarios do not typically include message content because this level of detail is 

usually defined in system requirements. However, the scenarios presented in chapters 8, 

9, 10, and 11 of this document do address message content because of its importance to

the establishment of a mobile device-based system.

• Traceability—Lists the user needs that would be satisfied in the scenario. Alternatively, 

it could describe which user needs would not be met (only if the scenario has nonnormal 

operating conditions). 

• Summary of inputs and outputs—Provides an overview of inputs and outputs external 

to the system.

These scenarios would provide a step-by-step

description of how the proposed system would 

be expected to operate. Scenarios would be 

described in a manner that would allow

readers to walk through them and gain an

understanding of how all the various parts of

the proposed system function and interact. The scenarios would tie together all parts of the 

system, the users, and other entities by describing how they would interact. Scenarios could also

be used to describe what the system would not do. 

Operational scenarios would be developed for various series of events (e.g., where the scenario

plays out differently, depending on the types of events that occur) and operating conditions 

(e.g., normal, degraded, failure). These scenarios would provide a step-by-step description of 

how the proposed system would be expected to operate.

A scenario is a step-by-step description of 

how the proposed system should operate and 

interact with its users and external systems 

under a given set of circumstances. 
62 

Although scenarios are traditionally developed from the perspective of various users of the 

system, the examples of scenarios provided in this document would contain application-level

details regarding the interface between various system components (i.e., internal and external) to 

ensure that the reader can understand how the data flows support each use case contained in the 

scenario and the timing of the delivery of information that would be needed for the traveler to

make decisions pertinent to their trip. Furthermore, the types of trips (e.g., home–work, 

home–shopping, home–recreational, etc.) are included in the example scenarios to add context. 

VALIDATION

A system validation plan would be developed to assess system performance and to ensure the 

system addresses the needs of the stakeholders as outlined during the development of the system

concept. Furthermore, the plan would ensure that the system would be effective in meeting its

intended purpose. It may be advantageous to perform these tests in a closed environment to gain

deployment expertise, minimize the likelihood of unintended operations, and allow revisions to

be made to the system. Furthermore, as system components (including firmware) are updated, 

they could be tested in a closed environment to ensure the system continues to operate as

intended once updates have been made. 

CONCEPTS DEVELOPED IN THIS DOCUMENT

Chapter 3, User Classes, defines several classes of users that could use mobile devices

throughout the course of their trip that would provide various safety, mobility, reliability, and 

wayfinding benefits. When developing concepts for sharing and using electronic messages with 

mobile device-carrying travelers, it would be important to consider the needs of local

stakeholders, local transportation infrastructure, and local transportation systems as well as

constraints and enablers that would need to be captured and reflected in SE documentation. 

Chapters 8, 9, 10, and 11 in this document provide four concepts that focus on the ability of

mobile devices to address various types of user needs. These concepts address the various issues

and activities associated with the implementation of connected mobile device-based systems.

This implementation includes activities that would occur before, during, and immediately after

the period in which the system would be physically deployed and operated. Each developed 

concept would focus on the following four aspects of the system:

1. System capabilities (which include area of coverage) needed to support complete trips of 

travelers. 

2. Capabilities of connected mobile devices to provide travelers with the information they 

may need when completing different type of trips. 

3. Electronic messages and data elements to ensure the information needed by systems and 

users of connected devices would be provided. 

4. Support and administrative issues for agencies to consider developing and sustaining to 

support an environment that would enable the sharing and use of electronic messages.
63 

Local agencies could use the concepts in chapters 8–11 as a starting point for developing SE 

documentation and could adapt the concepts, as necessary, to account for local needs and local

conditions. 

65 

CHAPTER 7. REQUIREMENTS FOR SHARING ELECTRONIC MESSAGES WITH 

MOBILE DEVICES

CHAPTER OVERVIEW

The development of system requirements for a mobile device information exchange system 

would identify the individual tasks and functions that each component of the ecosystem would 

perform. Requirements would be derived from the ConOps. While the ConOps would be a 

narrative description of the system, the requirements would be individual statements typically 

listed in a hierarchical manner that would define specific functions. For mobile device 

information exchange, each of these requirements would ultimately provide input to the design, 

procurement, installation, and operation of the system. In such a system, requirements would be 

necessary for the mobile devices, RSE, software, hardware, and communication systems, among 

other components. Figure 6 shows where this effort would align with the overall SE process. 

Source: FHWA.

Figure 6. Diagram. System requirements in the SE process.

(14)

This chapter provides an overview of the requirements purpose, scope, and format. 

Chapter content generally follows the structure of the systems requirements document as 

specified in International Organization for Standardization (ISO)/International Electrotechnical 

Commission(IEC)/IEEE 29148.2018 and indicated in the following sections:

(21)

• System Requirements Scope. 

• References (not described in the following subsections). 

• System Requirements.

• Verification Methods. 

• Needs-to-Requirements Traceability. 
66 

SYSTEM REQUIREMENTS SCOPE

The systems requirements specification (SysRS) communicates the requirements of the project to

the technical community that would specify and build the system. The SysRS would be a 

black-box description of what the project must do, but not how it would do it. The SysRS would 

contain descriptions of inputs, outputs, and required relationships between inputs and outputs. 

The first section of the SysRS would be similar in nature to the scope presented in the ConOps 

document and would define the purpose of the document and the scope of the project under 

which the system would be developed. This information 

would provide the reader with an expectation of what

they would expect to get out of the document. The scope 

would reference the ConOps, describe how the SysRS 

would build off the ConOps, and describe how the system

requirements would support future documentation. 

Most applications deployed on mobile devices have been developed by private companies. When 

developing the SysRS, the author must be cognizant and realistic about access to these private data 

sources and focus on what would be attainable. As such, when defining the system boundaries 

(i.e., the scope), the author would be clear about what the agency has control of, what it may have 

some influence on, and what would be outside of both control and influence and prioritize these 

factors accordingly.

SysRS can be integrated into the process of planning a study or developing a project to better 

define how the system intends to work to meet its goals and objectives and how it would be of 

use to the traveler or a system management agency. A SysRS also provides a starting point for 

procuring equipment that is necessary for implementing the designed system.

SYSTEM REQUIREMENTS

The system can be divided into various system components, which could include, but would not 

be limited to, the following features: 

• TMS. 

• Transit management systems. 

• Roadside infrastructure. 

• Mobile devices. 

• In-vehicle systems. 

• Interfaces. 

• Content and structure of electronic messages.

When forming requirements, it would be important to consider what each component must be 

capable of to enable the sharing and use of electronic messages as needed to meet the needs of 

users as defined in the ConOps. Thus, a component-by-component assessment would be 

undertaken to determine the requirements for a given component. 

When a requirement is written for a given component depends on a function performed by 

another component, a reciprocating requirement would be written (focused on the function 

Each system requirement is

traced back to one or more user 

needs, which were initially 

defined in the ConOps. 
67 

required of the other component), provided the other component being referenced would be 

inside of the system boundary. This reciprocating requirement would help a reader to understand 

specific system components or devices that need to work together. 

Requirements could be categorized to differentiate between different types of requirements.

Examples of various types of requirements are provided in table 5. Categorization serves to

group similar types of requirements so that they can be more easily interpreted and referenced by 

the reader. The assignment of a requirement to a specific category is not an exact science.

Discretion would be used—the requirements categories described in table 5 provide a rough 

outline for categorizing requirements. Furthermore, the descriptions provide various aspects of

the system for stakeholders and systems engineers to consider as requirements are developed. It

would not be necessary to generate a requirement within each category.

Table 5. Types of requirements. 

Requirement

Category Description

Functional Specifies actionable and qualitative behaviors (e.g., functions, tasks) of the 

core system of interest (e.g., mobile device, computing platform, RSE, other 

functional objects within the system of interest).

Data Defines the data collected, transformed, and stored from various sources;

identifies new data that would be expected to be generated; and may also 

specify the structure of messages that are used. Applicable standards would 

be referenced as necessary.

Interface Defines how the system would interact, communicate, or exchange data with 

external systems (interface with a system outside of the system of interest) and 

how core system elements would interact with other parts of the system 

(interface between functional objects within the system of interest). In the case 

of mobile devices, caution would be used to ensure that specific technology 

would not be required as it continues to evolve quickly. Instead, the 

requirements for interface would focus on the endpoints and not the medium.

Performance Specifies quantifiable characteristics of operations that define the extent, or 

how well, and under what conditions a function or task would need to be to 

be performed. Performance would be a very important requirement for 

mobile devices, because it typically relates to the reliability of outputs 

provided to the traveler. For certain use cases, data could be historic or 

required only at infrequent intervals, which would be more typical of 

today’s environment. However, as the demands and needs of travelers 

expand, access to timely and accurate data in near realtime has become 

necessary.
68 

Requirement

Category Description

Security Defines the integrity and operability of the system and its microservices, 

connections, and data. These features include physical security as well as 

cybersecurity, covering prevention, detection, identification, response, and 

recovery requirements. These features would be based on standards that 

typically define security protocols for various communications media. 

These features would be referenced in security requirements as appropriate.

Physical Specifies the construction, durability, adaptability, and environmental 

characteristics of the system, such as installation location, device weight 

limits, dimension and volume limitations, temperature regulations, layout, 

access for maintenance, and growth and expansion characteristics. For 

mobile devices, this requirement would be less important because, to a 

certain extent, the device would be dictated by the marketplace and would 

not be part of the design of the system discussed herein.

Availability 

and 

recoverability 

Defines the times of day, days of the year, and overall percentage of the 

system that can be used and when the system would not be available for use. 

These requirements also specify the recovery time objective of the system 

(which describes the timeframe permitted for a system to become 

operational), the recovery point objective (which specifies up to what point in 

time the data would be restored), and how the system would be expected to 

restore services (e.g., failover, backups) in an event of a failure. Availability 

would be a critical element of any ecosystem that depends on current data, 

such as those expected to be used by mobile devices.

Maintainability Specifies the level of effort required to locate and correct an error during 

operation to establish a quantitative requirement for planned and unplanned 

support (e.g., mean and maximum times to repair or resolve issues, number 

of people and skill levels required, support equipment necessary, 

maintenance staff hours, and time and frequency of preventive maintenance). 

As with the physical requirements, the maintainability of the mobile devices 

would be dictated by the market. However, maintainability of the back-office

systems that support data aggregation and dissemination and agency 

decisions would be relevant.

Storage and 

transport 

Specifies the physical location and environment for the system, including 

designated storage facility, installation site, repair facility, and requirements 

for transporting equipment. Specific to this system, the context of storage for 

the mobile devices, as compared to that of the back office, would be dictated 

by the market and practical use. The back office would probably be cloud 

based, so concepts such as physical location would become less critical.

Disposal Specifies the items related to the disposal of project/system components that 

are attributable to either failure replacements, removal, end-of-life upgrade, 

or retirement. This type of requirement tends to be less relevant from the 

agency perspective as systems move to cloud-hosted systems. The disposal of 

mobile devices would be dictated by the consumer.
69 

Requirement

Category Description

Information 

management 

Specifies the acquisition, management, and ownership of information from one 

or more sources, the custodianship and the distribution of that information to 

those who need it, and its ultimate disposition through archiving or deletion. 

Lifecycle 

sustainment

Defines what items the project or system reviews, measures, and analyzes as 

part of its commitment to quality during the lifecycle of the system. The 

capacity to change or enhance the product and lifecycle processes could be 

designed into the system architecture to enable the cost-effective sustainment 

of the system throughout its lifecycle.

Policy and 

regulation 

Specifies relevant and applicable organizational policies and regulations that 

would affect the development, operation, or performance of the system (e.g., 

IT and labor policies, reports to regulatory agencies, and health or safety 

criteria). This section would also include new policies and regulations 

imposed to realize the system.

VERIFICATION METHODS

Verification confirms that all interfaces have been correctly implemented and that all

requirements and constraints have been satisfied. The ability to assess each requirement must be

considered when assigning a verification method. A verification method would be assigned to

each requirement, based on the ability of a requirement to be assessed and the rigor of which it

must be assessed. Table 6 defines the four fundamental verification methods that would be used

for requirements, along with a description of situations in which each method would be used. 

The step-by-step process by which each requirement would be assessed would not need to be 

specified in the System Requirements document because the process would be specified in the 

test plan.

Table 6. Verification methods. 

Verification

Method Description Typical Use

Test Direct measurement of system

operation. Controlled and

predefined inputs and other 

external elements (e.g., data,

triggers) cause the system to

produce the output specified

by the requirement.

Tests typically include some level of 

instrumentation. Note: Tests would be more

prevalent during early verification when

component-level capabilities would be 

exercised and verified.

Demonstration Observation of system

operation in the expected or 

simulated environment 

without need for measurement

data.

Demonstrations are more prevalent in

system-level verification when the complete

system is available to demonstrate end-to-end 

operational capabilities. For example, a 

requirement that an alarm would be issued

under certain conditions could be verified

through demonstration. 
70 

Verification

Method Description Typical Use

Inspection Direct observation 

(e.g., visual, auditory, or 

tactile).

Inspection is used typically for items such as

construction features, workmanship, dimensions 

and other physical characteristics, and software

language. 

Analysis Indirect and logical conclusion 

using mathematical analysis, 

models, calculations, testing 

equipment, and derived 

outputs based on validated 

datasets. 

Analysis is frequently used when verification by 

test would not be feasible or would be

prohibitively expensive. For example, a 

requirement that a website support up to

1,000 simultaneous users would normally be 

verified through analysis.

NEEDS-TO-REQUIREMENTS TRACEABILITY

Each requirement would be traced back to one or more user needs, which would be initially

defined in the ConOps. If there is a user need that cannot be traced to a requirement, then the 

user would only be considered if additional requirements may need to be developed. 

Subrequirements associated with a given parent requirement would also be traceable to the same

user need(s) as the parent requirement. Needs-to-requirements traceability would be typically

presented in a tabular format by listing each user need alongside each requirement that would be 

associated with it. An example format for documenting this traceability is provided in figure 7. 

Other attributes of requirements (used to organize/group similar requirements) may be specified 

as well—in figure 7, for example, functional group and subcomponent are used to group similar 

requirements.

Source: FHWA. 

Req. = required.

Figure 7. Screenshot. Needs-to-requirements traceability example.
71 

Similarly, reverse traceability ensures that all requirements would have at least one user need

associated with it (i.e., verifies that all requirements were included in the needs-to-requirements

traceability table). One or more user needs would be associated with each requirement. Reverse

traceability would be typically presented in a tabular format by listing each requirement 

alongside each user need that would be associated with it.

73 

CHAPTER 8. CONCEPT 1: TRAVELER WALKING AND USING A CONNECTED

MOBILE DEVICE

CHANGES CONSIDERED BUT NOT INCLUDED

This section identifies changes and new features that were considered but not included and the 

rationale for not including them, which could be attributable to difficulty of implementation,

technology limitations, or the ability of other systems to adequately meet the needs of users.

Changes considered but not included would vary from agency to agency and from region to 

region. 

CHAPTER OVERVIEW

This chapter is the first of four chapters that develop an example concept to showcase how 

mobile devices and electronic messages could be used to satisfy traveler needs. This chapter 

focuses on addressing an example set of needs for pedestrians carrying a mobile device. Through 

these example concepts, the reader would begin to understand the content included in a typical 

ConOps. A description specific to the concept walks through existing conditions, justification for 

changes, desired changes, operational policies and constraints, proposed operating environment, 

modes of operation, user classes, support environment, and operational scenarios. These example 

concepts begin to shape a system that enables the exchange of electronic messages with mobile 

devices to satisfy the needs of different types of travelers.

EXISTING CONDITIONS

Several features at pedestrian crossings are used for pedestrian navigation at signalized 

intersections. At certain signalized intersections, pedestrians are required to press a pushbutton to

receive a walk signal at an intersection. At most intersections with pushbutton requirements,

multiple pushbuttons give pedestrians a choice of crosswalks near a single location. Some (but

not all) pushbuttons provide a brief audible cue when pressed to indicate that the crossing request 

has been received.

Pedestrian signal heads also display the state of the pedestrian phase. The three pedestrian phases 

include walk, clearance (i.e., flashing do not walk), and do not walk.

• The WALK phase is indicated by a steady walking person signal indication and is 

typically white in color. Some older signals indicate this in text form. The pedestrian is 

permitted to start to cross the roadway in the direction of the signal indication.

• The pedestrian clearance phase is typically indicated by a flashing, red upraised hand. 

Some older signals indicate this phase in text form. During this phase, the pedestrian is 

expected to complete crossing the roadway, but not start to cross the roadway if still on 

the curb. 

• The DO NOT WALK phase is indicated by a steady upraised red hand. Some older 

signals indicate this in text form. The pedestrian is expected to have cleared the 

crosswalk at this time and not begin to cross the roadway. 
74 

• At some intersections, the WALK and/or pedestrian clearance phases are supplemented 

with a countdown until the end of the phase. The countdown typically indicates the 

amount of time remaining until the DO NOT WALK phase. This countdown can be used 

by a pedestrian to better anticipate the amount of time left to cross the street. A buffer 

interval minimum of three seconds is required between the time when the DO NOT 

WALK phase starts and the beginning of the next phase.(10)

Some intersections do not have pedestrian signal heads. In this case, pedestrians use the traffic

signal heads as a visual indication of when to cross the street. Signage is typically used to

indicate intersections where pedestrian crossings are prohibited. Furthermore, truncated domes 

(e.g., detectible warning pavers) are used by persons who are visually impaired to assist in

determining where to enter a location for crossing a street. Although truncated domes are 

commonplace on new sidewalk ramps, not all sidewalk ramps exhibit them. 

Some intersections have directed speakers that provide audible cues that correspond to the state

of the pedestrian signal head. A combination of voice, chirps, and/or rapid ticks (current

standard) provide these audible cues. Not all intersections are required to be equipped with

audible pedestrian cues. Audible cues are typically deployed at intersections as requested or in

areas where pedestrians with visual impairments are known to cross.

Even at intersections where the pedestrian WALK phase is automatically granted for every

phase, the visual walk signal is not automatically accompanied by an audible signal. Some

intersections require a pedestrian to press a pushbutton to receive an audible signal. When 

obtaining an audible signal is among the choices, multiple pushbuttons are present, giving the 

pedestrian a choice of crosswalks near a single location. 

JUSTIFICATION FOR CHANGES

Several aspects of the current conditions at signalized pedestrian crossings could warrant the 

addition of technology to enable communication to and from mobile devices. These aspects are 

discussed in detail in the following subsections. 

Place Pedestrian Phase Call

In the process of completing a trip, a traveler may need to cross a street at one or more signalized 

intersections. In some cases, this process requires the pedestrian to provide an input to activate the 

pedestrian phase at the next available opportunity in the signal timing plan. Pedestrians typically

have to press a pushbutton to complete this activation.

Pedestrians with low vision or blindness may have difficulty locating the pedestrian pushbutton 

due to contextual inconsistencies between intersections. Similarly, a pedestrian with a mobility

impediment may not be able to access a poorly placed pushbutton (e.g., not easily accessible

from a sidewalk). In another case, the pushbutton could be nonfunctional or not work properly. 

Pedestrians may also have challenges determining the state of the pedestrian signal because of 

low vision. Many intersections may not have audible signals, which limits the ability of that

intersection to communicate with the pedestrian. This situation is further complicated when a 

pedestrian crossing is limited to certain legs of an intersection. Transportation agencies may
75 

decide to eliminate a pedestrian crossing on certain intersection movements due to the large

volume of left-turning vehicles (typically at interchange ramp intersections). The lack of a 

crosswalk and pedestrian phase must be communicated to a traveler with a disability. Finally,

pedestrians naturally move at different speeds; therefore, the need exists for a pedestrian phase to

have a flexible duration so that it can better accommodate slower-moving pedestrians.

Extend WALK Signal Phase

The pedestrian phase may not be long enough to accommodate all pedestrians. A pedestrian who 

is unable to complete crossing a crosswalk during the allotted pedestrian phase could be placed

into a dangerous situation and could begin to move as conflicting traffic receives a green (go) 

indication. 

Pedestrian in Crosswalk Intersection Safety

In environments where vehicles and pedestrians interact, there is a possibility for an incident 

involving both to occur. Pedestrians, who are classified as VRUs, are prone to injury or fatality 

when involved in a crash with a vehicle. Thus, drivers must be made aware of the presence of 

pedestrians on roadways, given their vulnerability. 

Intersection Wayfinding

The Accessible Transportation Technology Research Initiative (ATTRI) program studied 

applications that improve mobility options for all travelers, particularly those with disabilities.(22)

These applications are cross-cutting in nature and can often be integrated with existing 

applications to enhance the user experience. In 2016, the ATTRI program undertook research to 

understand the needs and barriers to mobility for travelers with disabilities that can be solved by 

leveraging technology in these five areas: wayfinding and navigation solutions, assistive 

technologies, automation and robotics, data integration, and enhanced human services 

transportation. Research indicates that with the notable advancement in mobile and portable 

computing power and the continued rise of continuously connected mobile devices, many of the 

technology solutions that were identified as solutions for gaps in information are very realistic

for implementation within the next 3–5 yr.(23)

A traveler with low vision or blindness may have issues knowing their location while they are

traveling, due to a lack of signs and waypoints that are readily accessible for persons with a 

visual disability. Technology-based solutions to provide real-time assistance to travelers with

disabilities include the use of a virtual electronic guide dog, a wearable device to provide course 

corrections, and even semiautonomous technologies that detect when a traveler has departed

from their expected path and automatically begin to provide real-time guidance assistance

through an on-demand virtual concierge service, mobile application, or other method. 

DESCRIPTION OF DESIRED CHANGES

Examples of pedestrian user needs based on the justifications described in the four previous 

subsections are provided in table 7, followed by descriptions of mobile device-based applications 

that could address these needs.
76 

Table 7. Pedestrian user needs. 

User Need ID Title Description

Pedestrian

UN1

Approaching

Crosswalk

A pedestrian needs to know when they are

approaching a signalized intersection crosswalk.

Pedestrian

UN2

Activate Pushbutton A pedestrian needs to activate a pedestrian crosswalk

phase.

Pedestrian

UN3

Extend Crossing

Time

A pedestrian needs additional time to complete

crossing a crosswalk if they are still in the crosswalk

and the pedestrian phase clearance time will

imminently expire.

Pedestrian

UN4

Pedestrian Safety

Driver Awareness

A pedestrian needs their presence in a crosswalk to be

known to approaching drivers.

Pedestrian

UN5

Wayfinding and

Navigation at

Crosswalks

A pedestrian with a vision or hearing impairment 

needs wayfinding and navigation solutions for a 

complete trip between an origin and destination in the 

public right-of-way. Note: The traveler needs 

wayfinding and navigation information before starting

the trip and must be updated throughout the trip to

account for changing conditions, such as a pedestrian

signal.

UN = user need.

Mobile Pedestrian Phase Call

Mobile devices could allow a pedestrian to request a pedestrian phase at an intersection. Such an 

application could also provide specialized functionality to support the needs of travelers with 

disabilities. Accessibility issues associated with the activation of a pedestrian phase could be 

addressed using mobile device technology to request the appropriate pedestrian phase. 

Furthermore, the mobile device could also provide audio and haptic information regarding a 

signal state or the lack of a crossing to travelers who are not otherwise able to readily observe the 

signal state or available crosswalks at an intersection.

To support this use case, the pedestrian would need information about the location of the 

intersection, the signal state, and the ability to provide a signal priority request to the traffic 

signal controller at the intersections. To support this need, the MAP would contain intersection 

geometry information that would allow the mobile device to position itself in relation to the 

intersection, and the SPaT would contain information about the state of each movement and 

timing details (e.g., minimum time remaining, expected phase change). A pedestrian with a 

mobile device would wirelessly issue an SRM, to actuate the pedestrian phase at the signal. The 

SRM would contain information—such as an intersection identifier, an identifier for the 

movement request, and the type of service requested (e.g., normal actuation, priority, 

preemption)—which would be received by the traffic signal that services the request. An SSM

would be provided back to the mobile device to provide information regarding which signal 

requests would be served and the estimated timing of service. The pedestrian using the mobile 

device would need to be able to indicate which crosswalk they intend to use and have the ability 

to cancel the request at any time.
77 

Mobile Extend Pedestrian Phase

A walking speed could be specified in the message so that the signal could adjust the phase 

length to accommodate slower-moving pedestrians. Alternatively, a pedestrian mobile device 

could continuously provide the location of the pedestrian to the intersection to ensure the signal

could preemptively extend the phase until the mobile device is no longer determined to be in the 

crosswalk. Information regarding the pedestrian’s walking speed would be provided so that 

longer-than-normal crossing times could be accommodated.

Pedestrian in Crosswalk Intersection Safety

Ideally, VRUs would be able to move about in a roadway environment in a safe manner. A 

mobile device could support the safety of the VRU in a connected environment. The mobile 

device could receive location, speed, and motion information from the vehicle to alert the VRU 

when a vehicle is near the VRU, could issue an advisory when a vehicle is moving in the 

direction of the VRU, and could issue a warning when the vehicle may be at risk of colliding 

with the VRU unless immediate action is taken.

Conversely, the mobile device would broadcast the location and motion information of the VRU 

so that similar notifications, advisories, and warnings could be issued to a driver of an 

approaching vehicle. This would improve the vehicle operator’s awareness of VRUs to reduce 

the likelihood of a collision. 

Intersection Wayfinding

Technologies involving text-to-speech or speech-to-text mobile wayfinding and navigation 

applications and enhanced assistance technologies, such as on-demand assistance or virtual 

assistants, are frequently identified as potential solutions. Technologies that would reduce the level 

of information needed by travelers with disabilities, such as autonomous vehicles with 

preprogrammed door-to-door service, are also frequently cited.

Like all travelers, disabled travelers need additional travel options. Information systems

integrated into a single database across multiple agencies that could be accessed by a single piece

of technology unique to the traveler would enable personalized services and provide travel

options that account for disabled travelers’ individual mobility needs. For example, if payment 

and information systems were integrated with fixed-route transit services across both public and 

private providers, a traveler could be informed of alternative travel routes that are suitable for

their mobility needs. These options could be provided automatically, based on the travelers’ 

current location and transaction with the payment system. Their individual mobility needs could 

also be conveyed. 

Wayfinding and navigation technologies show significant potential to improve mobility.

Information before and during a trip was consistently cited as the greatest need, and wayfinding 

and navigation technologies could help address this need.(24) For instance, electronic orientation 

aids use RFID tags and mobile devices to determine a person’s exact location, which would be 

used to assist vision-impaired individuals in navigating a route to a destination. The strength of 

the application would be its ability to annotate the route a user wants to take and invite trusted
78 

sources (i.e., individuals or organizations) to enhance urban navigation decisions by blind or 

vision-impaired travelers.

Priorities Among Changes 

This section prioritizes the user-proposed functionality presented in the previous subsection. This

prioritization is typically done by classifying each possible change as essential, desirable, or 

optional. The classification method used would be determined by each deploying agency. 

Functions related to safety or other high-priority needs are essential, whereas desirable functions 

are considered to provide enhanced functionality but are not necessary for the system to meet

user needs. Optional needs are generally limited to needs that are discretionary in nature. 

Prioritizing user needs would be a subjective practice and would vary from agency to agency and 

from region to region.

Assumptions and Constraints

This section lists assumptions and constraints that would (or could) limit how the system can be 

designed and implemented. The following examples describe common assumptions and 

constraints that could affect the design of the proposed system:

• Communication, technology, hardware, or software availability. 

• Off-the-shelf technology procurement (as opposed to the development of a new device). 

• Operational policies and constraints. 

• Existing laws and regulations (e.g., governing the operations of motor vehicles,

pedestrians, and bicyclers on the roadways). 

PROPOSED OPERATING ENVIRONMENT

For this concept, the proposed operating environment includes the mobile device, RSE, a traffic

signal controller, and in-vehicle equipment.

Figure 8 illustrates a systems diagram for this concept. The interfaces, hardware, messages, 

facilities, and external systems that comprise this concept are discussed in detail in the 

proceeding subsections.
79 

Source: FHWA. 

Figure 8. Diagram. Mobile device pedestrian system. 

Interfaces

The following interfaces would be required to bring functionality to this concept: 

• A mobile device must be able to receive a BSM that would be broadcast from in-vehicle

equipment. 

• In-vehicle equipment must be able to receive a PSM broadcast from a mobile device. 

• A mobile device must be able to send an SRM that would be received by RSE. 

• The RSE must be able to make a priority request to the traffic signal controller and 

receive signal status information and phase information from the traffic signal controller. 

• The RSE must be able to send SPaT, MAP, and SSMs to the mobile device. 

• The RSE, mobile device, and in-vehicle equipment must interface with GNSS to receive 

location and time information. GNSS data allow time synchronization between devices 

and a mobile device and in-vehicle equipment to enable the device users to position 

themselves in the context of the roadway environment. 

• The RSE must interface with a continuously operating reference station (CORS) to 

receive localized Radio Technical Commission for Maritime Services (RTCM) data that 

would be used to populate RTCM messages. The RSU would forward this RTCM data to 

the mobile device and in-vehicle equipment to correct for errors in positioning.

All the messages exchanges using these proposed interfaces would occur within the vicinity of a 

signalized intersection.
80 

Hardware 

The following hardware would be required:

• Mobile device—A mobile device would be a self-contained apparatus that wirelessly

sends and receives messages, receives data from its onboard sensors, has a processor to

execute functions, and has an HMI that allows it to receive input from and provide output 

to the pedestrian (i.e., audio/visual/haptic). The mobile device would position itself in the 

roadway environment to provide wayfinding guidance, would enable the virtual 

pedestrian pushbutton, and would broadcast PSM (this PSM would enable safety 

applications on receiving devices). Using its positioning capability and information 

regarding intersection geometry, the mobile device would determine when the pedestrian 

is approaching a crosswalk. If the pedestrian’s route is known, the mobile device could 

automatically broadcast an SRM to place a call for the crosswalk that is part of the 

pedestrian’s planned route. If the pedestrian’s route is not known, the mobile device

could prompt the pedestrian to query whether they plan to cross the street, and if so, 

verify which crosswalk they intend to use before broadcasting the SRM. As the 

pedestrian approaches the intersection and uses the crosswalk, the mobile device would 

provide information to the pedestrian (e.g., when and where to wait, when to walk, the 

state of the pedestrian signal, and the amount of time left to cross). This information 

would be intended primarily to benefit pedestrians with disabilities who may have 

difficulty perceiving visual and audio cues provided for the pedestrian signal at an

intersection.

• RSE—The RSE would be capable of wireless communications with a mobile device

(method not specified), would contain a processor to execute functions, would be 

backhaul connected to a TMC, and would be locally connected to a traffic signal 

controller. The RSE would receive SRMs from mobile devices and determine whether

the type of priority being requested is valid; that is, is the mobile device authorized to 

make the request specified in the SRM? This may require the RSE to contact the TMC. If 

authorized, the RSE would place a call for the requested pedestrian phase on the traffic 

signal controller. The RSE would receive SPaT data and signal status data from the 

traffic signal controller and would forward this information to the mobile device in the 

form of SPaT and an SSM.

o The RSE would receive intersection geometry data from the TMC to generate and 

constantly broadcast the MAP. The RSE would also receive position-correction data 

to populate and broadcast the RTCM messages. These messages would be used by 

mobile devices and in-vehicle devices for positioning purposes. 

o When receiving a PSM, the RSE would use the positioning data to determine whether 

any pedestrians are remaining in the crosswalk as the pedestrian phase clears. If so, 

the RSE would place a call to interrupt phase progression to the traffic signal 

controller. This feature provides additional time for the pedestrian to finish crossing 

before advancing to the next phase.
81 

• Traffic signal controller—The traffic signal controller would be capable of receiving a 

priority request made by the RSE, processing the request, placing a call on the requested

phase, and outputting SPaT data and signal status data that could be received by RSE. 

• In-vehicle equipment—Like the mobile device, in-vehicle equipment would wirelessly

send and receive messages, would receive controller area network bus (CANbus) data,

and would have a processor to execute functions and an HMI that would allow it to 

receive input from and provide output to the driver (i.e., audio/visual). The in-vehicle 

equipment would receive PSMs from the mobile device. The in-vehicle equipment would 

use the data in this message, along with information regarding location and motion of the 

vehicle, to determine whether the vehicle is approaching the pedestrian and would notify 

the driver in safety-critical situations. 

Messages

The following messages would be required to enable this concept:

• BSM—The BSM would convey safety information about a given vehicle. Broadcast 

from a vehicle, core BSM data would comprise required data elements including, but not 

limited to, vehicle size, position (latitude/longitude), speed, heading, acceleration, and 

brake system status. These data would be used to support safety-critical applications on 

the mobile device that rely on frequent transmission of BSM data.

• PSM—The PSM would be the mobile device equivalent of the vehicle-based BSM. The 

PSM would provide safety information about a given VRU. PSM data, which would be 

broadcast from a mobile device, would comprise required data elements including, but 

not limited to, position (latitude/longitude), speed, and heading. These data would be 

used to support safety-critical applications on in-vehicle devices that rely on frequent 

transmissions of PSM data.

• SRM—The SRM would contain data that are typically used to request signal preemption 

or signal priority from a signalized intersection. In this case, the SRM would allow a 

mobile device to place a call for a pedestrian phase. These data would include the desired 

phase/movement and the priority type (phase call). In addition, the SRM would include 

the estimated time of arrival and duration required to cross (or crossing speed) to ensure

that the intersection could accommodate pedestrian crossing speeds.

• SSM—The SSM would contain data regarding the state of phase calls and would allow a 

mobile device to confirm that the pedestrian phase call requested in the SRM would be 

serviced by the intersection. Data contained in this message would be populated using the 

output from the traffic signal controller.

• SPaT—The SPaT message would be used to communicate the signal state of the 

pedestrian phase at a given intersection. SPaT would contain the signal indication for 

every phase of the intersection, phase timing information, crosswalk status, and a 

movement number, which would allow the data to be paired with the physical layout of 

the intersection described in the MAP, described in the next bullet. 
82 

• MAP—The MAP would contain the intersection geometry, the layout of all 

approaches/receiving lanes, sidewalks, and crosswalks. Phase numbers would be defined 

for each approach lane, sidewalk, and crosswalk. These phase numbers would be used to 

pair SPaT data with the appropriate approach lane/crosswalk. MAP data would be used to 

position a mobile device with respect to sidewalk/crosswalk geometries identified in the 

MAP. The data for this message type would be manually acquired though surveys, and 

these data must be converted into the MAP format. 

Facilities and External Systems

The following external systems would be required to enable this concept: 

• TMC—The TMC would be backhaul connected with the RSE. Traffic management staff 

would input MAP to the TMC. The TMC could send MAP data to the RSE, which would 

forward the MAP to mobile devices via communications equipment colocated at the 

intersection.

• Multimodal trip planner (MMTP)—The MMTP would receive the MMTP trip request 

message and would determine one or more potential options between the specified origin 

and destination that are within the constraints of the traveler’s specified preferences. For 

the MMTP to provide effective itineraries, it would need access to real-time data from 

external systems including, but not limited to, roadway traffic conditions, real-time transit 

data, bikeshare station availability, locations of shared-mobility devices, and 

ridesharing/ridesourcing availability information. The MMTP would provide a response 

containing route options to the mobile device in the MMTP trip options information 

message. 

MODES OF OPERATION

Mobile devices are intended to complement pedestrians and the interactions between pedestrians

and drivers of vehicles in the roadway environment. Pedestrians and drivers would continue to

follow the rules of the road and respond to traffic control devices, as they currently do, but they 

would be provided with additional information and notifications through their respective mobile

devices. This information and the notifications would improve the mobile device users’ safety, 

mobility, and ability to make informed decisions. Mobile devices are not intended to add to or 

override regulations that govern the movement of pedestrians and interactions between

pedestrians and vehicles. Thus, if the mobile device-based system experiences nonnormal modes 

of operations, it would still be up to pedestrians and drivers to exercise normal judgment in

accordance with existing roadway usage regulations. 

Normal operations indicate the system is functioning as intended, generating outputs when

necessary, and not generating outputs when unnecessary. Mobile device users would be expected

to adhere to existing regulations associated with traffic control devices (e.g., traffic signals,

signage, and lane markings), with the added benefit of information and notifications that

complement these regulations. Events that could result in nonnormal operations may include, but 

are not limited to, the following situations: 
83 

• Loss of connectivity with supporting systems—The mobile device would rely on 

communication between the mobile device and other systems or communications 

between other systems that would allow the system to function as intended to meet user

needs.

• Attenuation of wireless signal to mobile device (for any communications medium)—

Mobile devices use wireless forms of communication to exchange data with external

systems. These wireless forms of communication are subject to attenuation, which is the 

degradation in the strength of a wireless signal due to the location of obstructing objects

between sending and receiving devices. Attenuation can result from foliage, the body of 

vehicles, or various types of fabric (when held in a pocket or backpack). The extent of the 

attenuation could affect the ability of the mobile device to receive the information it

needs to meet user needs in a timely manner. 

• Slower than typical rate of data transfer—Wired and wireless network bandwidth 

limitations could result in data transfer rates that are less than typical performance, which

may not allow time-sensitive data to be received before being needed to support user

needs.

• Loss of power—An unpowered mobile device would be unable to send/receive

messages, process data, or provide information or notifications to travelers. This would 

affect the ability of the system to influence the current conditions.

• Inaccurate GNSS data—GNSS data would be used by mobile devices to provide 

position, speed, and heading. Inaccurate GNSS data would have the largest implications 

for determining when and at what time information or a notification would be displayed 

to the traveler holding the mobile device. Similar implications could be expected for 

other users of devices that rely on precise traveler position information from the mobile 

device. For example, vehicle onboard equipment would require precise pedestrian

positioning information to issue a pedestrian safety-related notification to the driver of a 

vehicle. Inaccurate positioning information could result in the system providing an output 

at the wrong time or not providing an output when one is needed, which would reduce the 

system’s perceived effectiveness and credibility.

• Time synchronization—When not synchronized, data originating from two devices may

not be paired properly, resulting in false-positive and false-negative notification outputs,

which would reduce the system’s effectiveness and credibility. Unsynchronized data 

would be an issue particularly when the data are being used for safety-related

applications.

• Processing limitations—If the amount of data that must be processed by the mobile

device is greater than its processing capability, alerts/warnings may not be provided in

time for the traveler to appropriately react.

These potential events that could result in nonnormal operating conditions are for illustrative 

purposes only and would be examined in detail on a case-by-case basis if such a system is 

considered for deployment. Thus, although it would be important to consider how the system 
84 

would behave and which such events would occur when developing the conceptual design of 

mobile device-based systems, the operational scenarios developed in chapter 8, Operational 

Scenarios, only consider normal operating conditions. 

USER CLASSES AND INVOLVED PERSONNEL

The two primary user classes are the traveler (pedestrian) and driver. The traveler user class

comprises pedestrians who carry a mobile device on their person. The traveler uses sidewalks

and crosswalks to complete their trip. Safely using the crosswalk at a signalized intersection may 

involve the traveler receiving information about the pedestrian signal state. Some intersections

require the traveler to use a pedestrian pushbutton to place a request on the traffic signal

controller to call the desired pedestrian walk phase. 

The driver operates a vehicle in a roadway environment. When navigating through intersections,

the driver would assess crosswalks for pedestrian activity before making a permitted right or left

turn. The driver would be expected to yield to pedestrians in the crosswalk.

SUPPORT ENVIRONMENT

The local transportation agency/TMC would be responsible for the following actions: 

• Operating and maintaining ITS/communications hardware on the roadside. 

• Controlling traffic signals. 

• Handling roadside communications. 

• Managing intersection geometry data. 

• Maintaining roadway signage inventory. 

The Internet Service Provider would provide the following options: 

• Cellular service (3G/4G/5G) to mobile devices. 

• Connectivity between two systems so that data can be exchanged between them to

support needs of travelers.

• Private networks used to establish communications to privately managed field devices.

OPERATIONAL SCENARIOS

The operational scenarios in this section intentionally contain details that would be typically 

beyond the scope of what would be necessary for ConOps, such as including the functions 

carried out by each component, detailing the sending and receiving of messages, and identifying

the content of those messages. This level of detail would be typically found in subsequent SE 

documentation. However, in this concept, these additional details are included to provide the 

reader with additional context about how such a system could work and how messages can be 

used to enable the use case to underscore the theme of sharing electronic messages with mobile 

devices to satisfy the needs of different types of travelers.
85 

Use Case 1—Scenario 1 

Use Case 1—Scenario 1 describes the virtual pedestrian pushbutton for Concept 1: Traveler 

Walking and Using a Connected Mobile Device. This scenario is identified and titled “UC1-S1: 

Virtual Pedestrian Pushbutton” with the following characteristics:

• Short description—A traveler (pedestrian) would use a mobile device to place a call on 

a pedestrian phase at a signalized intersection. Notifications from the mobile device 

would provide added wayfinding assistance, especially for travelers with disabilities.

• Scenario objective—To demonstrate the ability of a mobile device to provide the 

following options: 

o Mobile pedestrian phase call. 

o Mobile extend pedestrian phase. 

o Pedestrian in crosswalk intersection safety. 

o Intersection wayfinding. 

• Operational event(s)—The functioning-related events would take place in the following 

order: 

o Messages would be exchanged between the mobile device and RSE to enable the 

traveler to place a call on a pedestrian phase.

o The RSE would receive data from the mobile device to determine whether the 

crosswalk is occupied and would extend the phase if the crosswalk is occupied as the 

pedestrian clearance phase ends.

o The mobile device would receive messages from RSE to enable wayfinding and 

provide information regarding the pedestrian signal status to the traveler. 

• Preconditions—The traveler would walk toward an intersection with a pedestrian 

crosswalk that would be along a route (planned usage of a mobile device) that the 

pedestrian would be following.

• Traveler actor role—The traveler would effectively receive information regarding the 

pedestrian signal status and safely traverse the crosswalk.

• Driver actor role—The driver would safely navigate through the intersection, yielding to 

pedestrians, as indicated by the signal.

The scenario then describes key actions and the flow of events of four sources: mobile devices, 

pedestrian signals, RSE, and travelers. Figure 9 illustrates steps 1 through 9 as described in 

table 8. Figure 10 illustrates steps 10 through 18 as described in table 9. Figure 11 illustrates 

steps 19 through 23 as described in table 10. Figure 12 illustrates steps 24 through 30 as 

described in table 11. Table 12 describes the remaining steps 31 through 34. 
86 

Source: FHWA. 

Figure 9. Diagram. Use Case 1—Scenario 1, steps 1–9. 
87 

Table 8. Use Case 1—Scenario 1 details for each source, steps 1–9, key action, and associated comments. 

Source Step Key Action Comments

Mobile device 1 Receives MAP from a nearby intersection. Contains intersection geometry information about both 

vehicle lanes, crosswalks, and crosswalk approaches 

(i.e., sidewalks). 

Mobile device 2 Compares the pedestrian’s position against 

the intersection geometry information to 

determine whether the pedestrian is 

approaching a crosswalk. 

Compares pedestrian-planned path against crosswalk to 

determine which crosswalk they are approaching. 

Mobile device 3 Receives SPaT from the nearby 

intersection.

Time to next phase is unknown. Regarding the pedestrian 

phase, SPaT contains the following information: 

• Intersection number: 1248. 

• Phase ID: 12 (crosswalk east leg). 

• Description: High St. at First Ave. 

• Current state: red (solid red DON’T WALK). 

• Minimum end time: 20 s. 

• Time to next phase: indeterminite. 

Mobile device 4 Sends an SRM to the intersection. Enables a virtual pedestrian pushbutton. Other types of 

service that could be requested include preemption and 

priority, but these services would typically be available only 

to authorized system users. The SRM content includes: 

• Temp request ID: 123456. 

• Intersection number: 1248. 

• Phase ID requested: 12. 

• Service requested: normal detection. 

Pedestrian 

signal 

5 Indicates stop (solid red DON’T WALK) 

for the crosswalk that the traveler intends 

to use as the traveler reaches the corner.

N/A
88 

Source Step Key Action Comments

Mobile device 6 Provides an audible notification to alert 

the traveler that they are approaching a 

crosswalk as the traveler approaches the 

signalized intersection: 

“Approaching High St. Crosswalk at First 

Ave. Wait to Cross.” 

Provides a visual indication that the 

pedestrian signal state indicates stop (solid 

red DON’T WALK).

Pedestrian intends to cross First Ave.

RSE 7 Receives the SRM, which places a 

pedestrian phase actuation on the local 

traffic signal controller.

Traffic signal controller successfully accepts the actuation. 

RSE 8 Sends an SSM to the mobile device. The mobile device optionally displays confirmation to the 

traveler. SSM content: 

• Temp Request ID: 123456. 

• Status: accepted. 

Traveler 9 Waits at the corner of the intersection. N/A

N/A = not applicable.
89 

Source: FHWA. 

Figure 10. Diagram. Use Case 1—Scenario 1, steps 10–18. 
90 

Table 9. Use Case 1—Scenario 1 details for each source, steps 10–18, key action, and associated comments. 

Source Step Key Action Comments

Pedestrian 

signal 

10 Changes to indicate walk (solid white WALK). N/A

Mobile device 11 Receives SPaT from the nearby intersection. Regarding the pedestrian phase, the message 

contains the following information:

• Intersection number: 1248. 

• Phase ID: 12. 

• Description: High St. at First Ave. 

• Current state: green (solid white 

WALK). 

• Current state minimum end time: 20 s. 

• Time to next phase: 20 s. 

Mobile device 12 Provides an audible notification to the traveler that the 

pedestrian signal has changed: “Cross Parsons Ave.”

Provides an output (audio and visual) to the traveler 

that indicates that the pedestrian signal state indicates 

walk (solid white WALK).

N/A

Traveler 13 Begins to cross the crosswalk. N/A

Mobile device 14 Continues to provide a constant output that the 

pedestrian signal state is green (solid white WALK). 

N/A
91 

Source Step Key Action Comments

Mobile device 15 Sends a PSM containing the location of the pedestrian 

to nearby vehicles as the pedestrian traverses the 

crosswalk. 

Crosswalk ID corresponds to Crosswalk ID in 

the intersection geometry message. The PSM

content includes the following information: 

• Temp ID: 18459349. 

• Location: 

o Lat: 39.980873. 

o Long: −83.004160. 

• Heading: 0. 

• Crosswalk ID: 42. 

In-vehicle 

device

16 Receives the PSM. N/A

In-vehicle 

device

17 Alerts the driver who intends to turn across the path of 

the pedestrian that there is a pedestrian in the 

crosswalk: “Yield to pedestrian in crosswalk.” 

N/A

Driver 18 Waits for the pedestrian to clear. N/A

Lat = latitude; Long = longitude; Temp = temporary. 
92 

Source: FHWA. 

Figure 11. Diagram. Use Case 1—Scenario 1, steps 19–23. 
93 

Table 10. Use Case 1—Scenario 1 details for each source, steps 19–23, key action, and associated comments. 

Source Step Key Action Comments

Traveler 19 Clears the half of the roadway containing the receiving lane 

that the driver intends to use.

N/A

Driver 20 Completes their turning maneuver. The traveler continues 

crossing the second half of the roadway. 

N/A

Pedestrian 

signal 

21 Changes to the clearance phase (flashing red DON’T 

WALK—could be accompanied with a countdown timer). 

N/A

Mobile 

device

22 Receives SPaT from the nearby intersection. Regarding the pedestrian phase, the message 

contains the following information:

• Intersection number: 1248. 

• Phase ID: 12. 

• Description: High St. at First Ave. 

• Current state: yellow (flashing red 

DON’T WALK). 

• Current state minimum end time: 15 s. 

• Time to next phase: 15 s. 

Mobile 

device

23 Provides an audible notification to the traveler that the 

pedestrian signal has changed and provides a countdown: 

“Clear Crosswalk. 15, 14, 13, ...” 

Provides a constant visual output that the pedestrian signal 

state is clearance (flashing red DON’T WALK) and provides 

a countdown to the traveler to indicate when the pedestrian 

phase ends.

N/A
94 

Source: FHWA. 

Figure 12. Diagram. Use Case 1—Scenario 1, steps 24–30. 
95 

Table 11. Use Case 1—Scenario 1, steps 24–30. 

Source Step Key Action Comments

Pedestrian 

signal 

24 Reaches the point where it would normally transition to the 

stop phase (solid red DON’T WALK). 

The traveler is still in the crosswalk and needs more 

time.

Mobile 

device

25 Receives SPaT from the nearby intersection. Regarding the pedestrian phase, the message contains 

the following information:

• Intersection number: 1248. 

• Phase ID: 12. 

• Description: High St. at First Ave.

• Current state: yellow (flashing red DON’T 

WALK). 

• Current state minimum end time: 0.1 s. 

• Time to next phase: 0.1 s. 

Pedestrian 

signal 

26 Provides an additional 1 s of time for the pedestrian 

clearance phase.

N/A

Mobile 

device

27 Receives SPaT from the nearby intersection. Regarding the pedestrian phase, the message contains 

the following information:

• Intersection number: 1248. 

• Phase ID: 12. 

• Description: High St. at First Ave.

• Current state: yellow (flashing red DON’T 

WALK). 

• Current state minimum end time: 1 s. 

• Time to next phase: 1 s. 
96 

Source Step Key Action Comments

Mobile 

device

28 Provides a more urgent output that the pedestrian signal 

state is in clearance (flashing red DON’T WALK) and that 

the traveler must complete crossing immediately: 

“Clear Crosswalk immediately.” 

The previous four steps are repeated until the pedestrian 

clears the crosswalk. Note: Traffic management 

agencies could limit the amount of time allowed for 

pedestrian signal priority. 

Traveler 29 Finishes crossing the intersection. N/A

Pedestrian 

signal 

30 Changes to the stop phase (solid red DON’T WALK). N/A

The remaining steps in this scenario not illustrated in figures 9–12 are documented in table 12. 

Table 12. Use case 1—Scenario 1, steps 31–34. 

Source Step Key Action Comments

Mobile 

device

31 Receives SPaT from the nearby intersection. Regarding the pedestrian phase, the message contains 

the following information:

• Intersection number: 1248. 

• Phase ID: 12. 

• Description: High St. at First Ave.

• Current state: red (solid red DON’T WALK). 

• Current state minimum end time: 30 s. 

• Time to next phase: indeterminite

Traveler 32 Walks away from the intersection toward final 

destination. 

N/A

Mobile 

device

33 Stops outputting information about the pedestrian signal 

state at the intersection.

N/A

Traveler 34 Completes the trip at the final destination. N/A

To complete this scenario, six characteristics are included, along with a system diagram capturing the four sources included in the 

scenario, as shown in figure 13.
97 

Source: FHWA.

Figure 13. Diagram. Use Case 1—Scenario 1, data flows between four sources.
98 

The following characteristics complete the documentation for Use Case 1—Scenario 1:

• Postconditions—Additional crossing time would be provided, and the traveler would 

safely cross the crosswalk.

• Messages—The message types would include MAPs, SPaTs, SRMs, SSMs, and PSMs. 

• Traceability—The following user needs would apply to this scenario: 

o Pedestrian UN1—Approaching Crosswalk. 

o Pedestrian UN2—Activate Pushbutton. 

o Pedestrian UN3—Extend Crossing Time. 

o Pedestrian UN4—Pedestrian Safety Driver Awareness. 

o Pedestrian UN5—Wayfinding and Navigation at Crosswalks. 

• Mobile device inputs summary—Inputs would include time and location (from GNSS), 

MAPs (from RSE), SPaT messages (from RSE), and SSMs (from RSE).

• Mobile device—SRMs and PSMs. 

• Outputs summary—Outputs would include audio/visual/haptic notifications to the 

traveler who is approaching the crosswalk, pedestrian signal status alerts, and time 

remaining to cross warnings. 
99 

CHAPTER 9. CONCEPT 2: TRAVELER RIDING ON A BICYCLE AND USING A 

CONNECTED MOBILE DEVICE

CHAPTER OVERVIEW

This chapter is the second of four chapters that develop an example concept to showcase how 

mobile devices and electronic messages can be used to satisfy traveler needs. The concept in this 

chapter focuses on addressing an example set of needs for bicyclists carrying a mobile device. 

Through these example concepts, the reader can begin to understand the content included in a 

typical ConOps. A description specific to the concept is provided and walks through existing 

conditions, justification for changes, description of desired changes, operational policies and 

constraints, description of proposed operating environment, modes of operation, user classes, 

support environment, and operational scenarios. These example concepts begin to shape a system 

that enables the exchange of electronic messages with mobile devices to satisfy the needs of 

different types of travelers.

EXISTING CONDITIONS

Currently, many intersections have in-pavement loop detectors, video detection systems, and 

radar detection systems that are used to determine the presence of vehicles at an intersection 

approach. Some systems may not be calibrated properly to detect bicyclists as they approach 

these intersections. Loop detection systems may use pavement markings alongside signage to 

indicate to bicyclists where to stop to trip a loop detector.(10)

Bicyclists approaching a signalized roadway crossing (rectangular rapid flashing beacon, 

pedestrian hybrid beacon, or traffic signal) from a bike path may have to use a pushbutton to 

activate the pedestrian/bicyclist crossing phase at the intersection (figure 14). The rectangular 

beacon rapidly flashes when the pushbutton is pressed, which warns motorists of activity at the 

crossing location (figure 15). The rapid flashing continues for a predetermined period after the 

pushbutton has been pressed before going dark again. The pedestrian hybrid beacon transitions 

from a dark state to a yellow-flashing caution state when the pushbutton is pressed. After a 

predetermined period, the signal progresses to a solid yellow clearance phase, followed by a red 

phase. At this point, the pedestrians and bicyclists cross. The signal then changes to a flashing 

red—stop before proceeding—for a predetermined period before going dark again. The 

traditional signal transitions through a typical signal cycle when the pushbutton is pressed. 
100 

Source: FHWA. 

Figure 14. Photograph. Cyclist waiting at signalized intersection. 

Source: FHWA. 

Figure 15. Photograph. Pedestrian/bicycle crossing with pushbutton-activated warning 

lights. 
101 

JUSTIFICATION FOR CHANGES

An aspect of the current conditions at signalized intersections could warrant the addition of 

technology to enable communication to and from mobile devices. This aspect is discussed in 

detail in the following subsection. 

Bicyclist Intersection Detection

Bicyclists riding on the roadway may not be easily detected by traditional means

(e.g., in-pavement loop detector or video detection), because these devices are typically

calibrated to detect vehicles (which are much larger). In a scenario where a bicyclist cannot be 

detected at an intersection, and the signal is not programmed to recall to the phase for the 

maneuver for which the cyclist intends to make, the bicyclist could pass through the intersection

while the signal is red or leave the roadway to access the pedestrian pushbutton. In some cases,

bicyclists riding on the sidewalk to access this pushbutton could be illegal. 

In many urban areas, bicyclists are required to ride in the roadway. Detection systems at actuated

signalized intersections are typically designed to detect the presence of vehicles and could have 

difficulty determining when a bicyclist is waiting at a signal. A bicyclist could dismount the 

bicycle to push a pedestrian pushbutton, but this is not always practical (e.g., when making a left

turn from a left turn lane) or convenient. Furthermore, having to stop to press the pushbutton 

could discourage bicyclists from using the pushbutton, which could result in the cyclist crossing

the street without warning oncoming drivers or crossing against the signal indications. 

DESCRIPTION OF DESIRED CHANGES

Examples of bicyclist user needs are provided in table 13. 

Table 13. Bicyclist user needs. 

User Need ID Title Description

Bicyclist UN1 Activate Detector A bicyclist needs to activate a phase that they

intend to utilize at a signalized intersection.

Bicyclist UN2 Bicyclist Roadway Safety

Driver Awareness

A bicyclist needs their presence in the roadway

to be known to approaching drivers.

The following mobile device-based applications could address bicyclist user needs. 

Mobile Bicycle Phase Call

A mobile device application could support many of these user needs, including allowing a 

bicyclist to request a movement though an intersection. To support this use case, the mobile 

device would need information about the location of the intersection and the signal state and 

would need to have the ability to provide a signal priority request to the traffic signal controller

at the intersections. The MAP would contain intersection geometry information that would allow

the mobile device to position itself in relation to the intersection, and SPaT would contain 

information about the state of each movement and timing details (minimum time remaining, 

expected phase change, etc.).
102 

A bicyclist with a wireless mobile device would issue an SRM to actuate the pedestrian phase at

the signal. However, this option would be predicated on the mobile device having the bicyclist’s

route itinerary information. This option could be accomplished without prompting the bicyclist,

which could result in a distraction. The SRM would contain information, such as an intersection

identifier, an identifier for the movement request, and the type of service requested (e.g., normal 

actuation, priority, preemption), which would be received by the traffic signal that services the 

request. An SSM would be provided back to the mobile device to provide information regarding

which signal requests would be served and the estimated timing of service. The bicyclist using 

the mobile device would need to be able to indicate which movement they intend to make and 

would need to be able to cancel the request at any time.

Bicycle Intersection Movement Assist

This use case supports bicyclist safety at intersections by making the location of the bicyclist

available to vehicle systems and by making the location of vehicles available to the bicyclist’s

mobile device. The mobile device would constantly broadcast a PSM while in a location where 

the bicyclist is vulnerable (i.e., operating in a mixed environment with other vehicles). Similarly, 

vehicles constantly broadcast BSMs. The in-vehicle device would receive the PSM, and along 

with its internal location and motion information, would determine whether the vehicle is on a 

collision course with VRUs at an intersection. Similarly, the mobile device would receive BSMs 

and along with its internal location and motion information, would determine whether the 

bicyclist is on a collision course with a vehicle at an intersection. If either device detects a 

potential collision, a warning would be issued to the driver and bicyclist to ensure they are aware 

of the potentially unsafe situation. 

Bicycle Overtake Lateral Clearance Safety

This use case supports bicyclist safety biking on shared-use streets by making the location of the 

bicyclist available to vehicle systems and by making the location of vehicles available to the 

bicyclist’s mobile device. As with Bicycle Intersection Movement Assist, this use case depends 

on the mobile device broadcastings and the vehicle broadcasting BSMs. The in-vehicle device 

would receive PSMs that could be used to identify its location and motion information to 

determine whether it is passing a bicycle and if there is enough lateral clearance. If either device 

determines sufficient lateral distance is not going to be available, a warning would be issued to 

the driver and bicyclist to ensure they are aware of the situation.

Priorities Among Changes 

This section prioritizes user-proposed functionality presented in the previous subsection. This 

prioritization would be typically done by classifying each possible change as essential, desirable,

or optional. The classification method used would be determined by each deploying agency. 

Functions related to safety or other high-priority needs would be considered essential, whereas

desirable functions would be considered to provide enhanced functionality but would not be 

necessary for the system to meet user needs. Optional needs would be generally limited to needs 

that would be discretionary in nature. Prioritizing user needs would be a subjective practice and 

would vary from agency to agency and from region to region.
103 

Changes Considered But Not Included

This section identifies changes and new features considered but not included and the rationale for

not including them. Not including certain features could be due to implementation difficulties, 

technology limitations, or other systems’ ability to adequately meet the needs of users.

Consideration of changes that are considered but not included would vary from agency to agency 

and from region to region. 

Assumptions and Constraints

This section lists assumptions and constraints that could limit how the system could be designed 

and implemented. The following examples of common assumptions and constraints could affect 

the design of the proposed system:

• Communication, technology, hardware, or software availability. 

• Off-the-shelf technology procurement (as opposed to the development of a new device). 

• Operational policies and constraints. 

• Existing laws and regulations (e.g., governing the operations of motor vehicles,

pedestrians, and bicyclers on roadways). 

PROPOSED OPERATING ENVIRONMENT

This concept includes the mobile device, RSE, a traffic signal controller, and in-vehicle 

equipment. 

Figure 16 illustrates a systems diagram for this concept. The interfaces, hardware, messages, and

facilities and external systems that comprise this figure are discussed in detail in the proceeding

subsections.

Source: FHWA. 

Figure 16. Diagram. Mobile device bicyclist system. 
104 

Interfaces

The following interfaces would be required to support this concept: 

• A mobile device would be able to receive a BSM that would be broadcast from in-vehicle 

equipment. In-vehicle equipment would be able to receive a PSM broadcast from a 

mobile device. A mobile device would be able to send an SRM that would be received by 

the RSE. 

• The RSE would be able to make a priority request to the traffic signal controller and 

receive signal status information and phase information from the traffic signal controller.

The RSE would be able to send SPaT, MAPs, and SSMs to the mobile device. 

• The RSE, mobile devices, and in-vehicle equipment must interface with GNSS to receive 

location and time information. GNSS data allow time synchronization between devices, 

mobile devices, and in-vehicle equipment to position themselves in the context of the 

roadway environment. The RSE would interface with a CORS to receive localized 

RTCM data that would be used to populate RTCM messages. The RSU would forward 

this RTCM data to a mobile device and in-vehicle equipment to correct for errors in 

positioning. 

• All the messages exchanges described in this section would occur within the vicinity of a 

signalized intersection.

Hardware 

The following hardware would be needed to enable this concept: 

• Mobile device—The mobile device would be a self-contained apparatus that wirelessly

sends and receives messages, receives data from its onboard sensors, has a processor to 

execute functions, and has an HMI that allows it to receive input from and provide output 

to the bicyclist (audio/visual/haptic). The mobile device would position itself in the 

roadway environment to enable a call for a phase and broadcast PSMs (this enables safety 

applications on receiving devices). Using its positioning capability and information 

regarding intersection geometry, the mobile device would determine when the bicyclist is 

approaching an intersection. If the bicyclist’s route is known, the mobile device may 

automatically broadcast an SRM to place a call for the movement that is part of the 

bicyclist’s planned route. If the bicyclist’s route is not known, the mobile device can 

determine which lane the bicyclist is in and make a call for the corresponding movement 

in the SRM. As the bicyclist approaches the intersection, the mobile device would 

provide confirmation to the pedestrian that the call was successfully placed. 

• RSE—The RSE would be capable of wireless communications with a mobile device 

(method not specified), would contain a processor to execute functions, would be 

backhaul connected to a TMC, and would be locally connected to a traffic signal 

controller. The RSE would receive SRMs from mobile devices and would determine 

whether the type of priority being requested is valid (i.e., is the mobile device authorized 
105 

to make the request specified in the SRM?). This may involve the RSE contacting the 

TMC. If authorized, the RSE would place a call for the requested phase on the traffic 

signal controller. The RSE would receive SPaT data and signal status data from the 

traffic signal controller and would forward this information to the mobile device in the 

form of SPaT and SSM: 

o RSE would receive intersection geometry data from the TMC to generate and 

constantly broadcast the MAP.

o RSE would also receive RTCM data to populate and broadcast the RTCM messages.

o Mobile devices and in-vehicle devices would use these messages for positioning

purposes. 

• Traffic signal controller—The traffic signal controller would be capable of receiving a 

priority request made by the RSE, processing the request, placing a call on the requested 

phase, and outputting SPaT data and signal status data that can be received by the RSE. 

• In-vehicle equipment—Like the mobile device, in-vehicle equipment would wirelessly 

send and receive messages, receive (CANbus) data, and would have a processor to 

execute functions and an HMI that would allow it to receive input from and provide 

output to the driver (audio/visual). The in-vehicle equipment would receive PSMs from 

the mobile device. The in-vehicle equipment would use the data in these messages, along 

with information regarding location and motion of the vehicle, to determine whether the 

vehicle is approaching the bicyclist, and it would notify the driver in safety-critical

situations.

Messages

The following types of messages would enable this concept:

• BSM—The BSM would convey safety information about a given vehicle. Broadcast 

from a vehicle, core BSM data could include vehicle size, position (latitude/longitude), 

speed, heading, acceleration, and brake system status. These data could support safety 

applications on the mobile device that rely on frequent transmission of BSM data. 

• PSM—The PSM would be the mobile device equivalent of the vehicle-based BSM. It 

would provide safety information about a given VRU. Broadcast from a mobile device, 

PSM data could include position (latitude/longitude), speed, and heading. These data 

would be used to support safety-critical applications on in-vehicle devices that rely on 

frequent transmission of PSM data.

• SRM—The SRM would contain data that is typically used to request signal preemption 

or signal priority from a signalized intersection. In this case, the SRM would allow a 

mobile device to place a call for a phase for a bicyclist. These data would include the 

desired phase/movement and the priority type (phase call).
106 

• SSM—The SSM would contain data regarding the state of phase calls, and it would 

allow a mobile device to confirm that the bicycle phase call requested in the SRM would

be serviced by the intersection. Data contained in this message could be populated by 

using the output from the traffic signal controller.

• SPaT—The SPaT message would be used to communicate the signal state at a given 

intersection. SPaT would contain the signal indication for every phase of the intersection, 

phase timing information, and a movement number, which would allow the data to be 

paired with the physical layout of the intersection described in the MAP. 

• MAP—The MAP would contain the intersection geometry, the layout of all 

approaches/receiving lanes, sidewalks, and crosswalks. Phase numbers would be defined 

for each approach lane, sidewalk, and crosswalk. This phase number would be used to 

pair SPaT data with the appropriate approach for the bicyclist. MAP data would be used 

to position a mobile device with respect to lane geometries that are identified in the MAP. 

The data for this message would be manually acquired though surveys. These data would 

be converted into the MAP format. 

Facilities and External Systems

TMC

The TMC would be backhaul connected with the RSE. Traffic management staff would input 

MAP to the TMC. The TMC could send MAP data to the RSE, which would forward the MAP 

to mobile devices via communications equipment colocated at the intersection.

MODES OF OPERATION

Mobile devices are intended to complement existing regulations that govern the movement of

bicyclists and the interactions between bicyclists and drivers of vehicles in the roadway 

environment. Bicyclists and drivers would continue to follow the rules of the road and respond to

traffic control devices, as they currently do, but they would be provided with additional 

information and notifications through their respective mobile devices. This information and 

notifications are expected to improve the mobile device users’ safety, mobility, and ability to

make informed decisions. Mobile devices are not intended to add to or override regulations that

govern the movement of bicyclists and interactions between bicyclists and vehicles. Thus, if the

mobile device-based system experiences nonnormal modes of operations, it would still be up to

bicyclists and drivers to exercise normal judgment in accordance with existing roadway usage 

regulations. 

Various issues that could result in nonnormal operations are provided in general context in

chapter 8, Modes of Operation. 

USER CLASSES AND INVOLVED PERSONNEL

The two primary user classes are the traveler (bicyclist) and driver. The traveler user class

comprises bicyclists who carry a mobile device on their person. The traveler uses paved off-road 

(multipurpose) trails and the street network to complete their trip. For the traveler to request a 
107 

phase at an intersection, the traveler must be detected or able to place a call for service at the 

signal. Some multipurpose trail intersections (with roadways) require the traveler to use a 

pushbutton to place a request for the traffic signal controller to call the pedestrian phase or 

activate a pedestrian beacon. Finally, when riding on the roadway, a traveler must be aware of 

the movements of other vehicles that could result in a safety issue for the traveler.

A driver operates a vehicle in a roadway environment. When navigating through environments 

with bicycles, the driver could leave enough space between the vehicle and bicyclist when

making an overtaking maneuver, notice bicyclists at an intersection (to yield, as appropriate

when navigating the intersection), and be aware of bicyclists when opening the driver’s side 

doors after parallel parking. 

SUPPORT ENVIRONMENT

The local transportation agency/TMC would be responsible for the following actions: 

• Operating and maintaining ITS/communications hardware on the roadside. 

• Controlling traffic signals. 

• Handling roadside communications. 

• Managing intersection geometry data. 

OPERATIONAL SCENARIOS

The operational scenarios in this section intentionally contain details that are typically beyond 

the scope of what would be necessary for a ConOps, such as including the functions carried out 

by each component, detailing the sending and receiving of messages, and revealing the content 

of those messages. This level of detail is typically found in subsequent SE documentation. 

However, in this concept, this additional detail is included to provide the reader with additional 

context about how such a system could work and how messages could be used to enable the use 

case, to underscore the theme of sharing electronic messages with mobile devices to satisfy the 

needs of different types of travelers.

Use Case 2—Scenario 1 and Scenario 2

Use Case 2—Scenario 1: Virtual Bicyclist Detection and Scenario 2: Bicycle Street Safety

describe a traveling bicyclist using a connected mobile device. Scenario 1 is identified and titled 

“UC2-S1: Virtual Bicyclist Detection” with the following characteristics:

• Short description—A traveler (bicyclist) would use a mobile device to place a call for a 

phase at a signalized intersection that services the approach used by the bicyclist. A 

traveler (bicyclist) would use a mobile device to enable a rapid flashing beacon as they 

approach the crossing area. 

• Scenario objective—To demonstrate the ability of mobile device to provide a mobile 

bicycle phase call. 
108 

• Operational event(s)—The functioning-related events would take place in the following 

order:

o As the bicyclist approaches the intersection, the mobile device would send a message 

to infrastructure-based equipment to indicate that the bicyclist intends to pass through 

the intersection. 

o The phase requested by the bicyclist’s mobile device would be served (as allowed by 

the signal timing plan) and the bicyclist would pass through the intersection (even 

though no other vehicles are activating the signal with their presence). 

• Preconditions—The traveler (bicyclist) would use a mobile device to plan a trip from 

home to a grocery store. The trip would consist of cycling through a neighborhood and 

crossing an arterial at a signalized intersection to get from the neighborhood streets to the 

grocery store. In the past, the bicyclist has had limited success in activating the signal 

with their presence. The ITS detection equipment does not reliably detect the presence of 

bicyclists. Bicyclists, at times, may need to wait for a vehicle to activate the detection, 

move onto the sidewalk to press the pedestrian pushbutton, or cross during a red signal 

after waiting for a few minutes. 

• Traveler actor role—The bicyclist would have the ability to move through intersection 

in a timely and safe manner. 

• Driver actor role—The driver would safely navigate through the intersection, yielding to 

bicyclists, as indicated by the signal. 

The scenario then describes key actions and the flow of events of four sources: mobile devices, 

pedestrian signals, RSE, and travelers. Table 14 describes steps 1 through 15, which would occur 

when the RSU places a call requesting a phase, and table 15 describes steps 1 through 20, which 

would occur when the RSU places a call and initiates an action as described.
109 

Table 14. Use Case 2—Scenario 1 details for each source, steps 1–15, key action and associated comments. 

Source Step Key Action Comments

Traveler 1 Approaches intersection. N/A

Mobile 

device

2 Receives a SPaT and a MAP. Indicates intersection geometry and the current signal state. The 

SPaT contains the following content: 

• Intersection number: 1314. 

• Phase ID: 7. 

• Description: Whittier Ave. at High St.

• Current state: red. 

• Minimum end time: 20 s. 

• Next time: indeterminite. 

Mobile 

device

3 Positions itself (and the traveler) within 

the intersection geometry. 

Determines the intersection ID that it would be approaching. 

Mobile 

device

4 Broadcasts an SRM indicating approach 

time and anticipated movement.

System estimates the approach time based on current time, bicycle 

speed, and distance to intersection.

Note: The anticipated movement would be determined by the 

mobile device—the route (from trip planner, see preconditions) 

through the intersection would be compared with the intersection 

movements indicated in the intersection geometry message to 

determine which movement would be made by the bicyclist.

Alternatively, the anticipated movement could be determined based 

on the approach lane where the mobile device is positioned. 

The SRM contains the following content: 

• Temp request ID: 123456. 

• Intersection number: 1314. 

• Phase ID requested: 7. 

• Service requested: normal. 
110 

Source Step Key Action Comments

RSU 5 Receives an SRM broadcast from mobile 

device. 

Releases communication that would not necessarily have to come 

directly from mobile device to the RSU. 

RSU 6 Checks that the approach would be for the 

intersection where the RSU is assigned and 

that the movement being requested would 

be valid.

Determines the request would be made for the intersection and that 

the movement would be valid. 

RSU 7 Places a call for the requested phase to the 

traffic signal controller

N/A

Traffic

signal 

controller

8 Provides an indication that it has received 

the call for the requested phase.

N/A

RSU 9 Broadcasts an SSM indicating that the 

requested movement would be valid and 

that the traffic signal controller would 

service the phase for the requested 

movement.

The SSM contains the following content: 

• Temp request ID: 123456. 

• Status: accepted. 

Mobile 

device

10 Receives SSM indicating the requested 

movement would be valid and that the 

phase for the requested movement would 

be serviced. 

N/A

Mobile 

device

11 Provides an audio/visual notification to 

the traveler to confirm that the phase they 

need would be in the process of being 

serviced (optional). 

Could also provide intermittent countdown until the phase is be 

served.

Traveler 12 Receives notification as they approach the 

stop bar at the intersection (optional). 

N/A

Traveler 13 Waits at stop bar. N/A

General 14 Signal turns green. N/A

Traveler 15 Proceeds through intersection. N/A

A secondary flow of actions occurs in this scenario at step 7. Table 15 details the steps after the traffic signal controller initiates 

flashing (strobe) warning lights at intersection. 
111 

Table 15. Use Case 2—Scenario 1 details for each source, steps 1–20, key action, and associated comments. 

Source Step Key Action Comments

Traveler 1 Approaches intersection. N/A

Mobile 

device

2 Receives a SPaT and a MAP. Indicates intersection geometry and the current signal state. 

The SPaT message contains the following content: 

• Intersection number: 1314. 

• Phase ID: 7. 

• Description: Whittier Ave. at High St.

• Current state: red. 

• Minute end time: 20 s.

• Next time: indeterminite.

Mobile 

device

3 Positions itself (and the traveler) within the 

intersection geometry.

Determines the intersection ID that it would be approaching.
112 

Source Step Key Action Comments

Mobile 

device

4 Broadcasts an SRM indicating approach time 

and anticipated movement.

Estimates the approach time based on current time, bicycle speed, 

and distance to intersection. 

Note: The anticipated movement would be determined by the mobile 

device—the route (from trip planner, see preconditions) through the 

intersection would be compared with the intersection movements 

indicated in the intersection geometry message to determine which 

movement would be made by the bicyclist. Alternatively, the 

anticipated movement could be determined based on the approach 

lane where the mobile device is positioned.

The SRM contains the following content: 

• Temp request ID: 123456. 

• Intersection number: 1314. 

• Phase ID requested: 7.

• Service requested: normal.

RSU 5 Receives an SRM broadcast from mobile 

device.

Communication would not necessarily have to be directly from 

mobile device to the RSU.

RSU 6 Checks that the approach would be for the 

intersection where the RSU would be located 

and that the movement being requested 

would be valid.

Determines the request would be made for the intersection and that 

the movement would be valid.

RSU 7 Places a call for the requested phase to the 

pedestrian signal controller.

N/A

Traffic 

signal 

controller

8 Initiates flashing (strobe) warning lights at 

intersection.

N/A
113 

Source Step Key Action Comments

RSU 9 Broadcasts an SSM indicating that the 

requested movement would be valid and that 

the signal controller has accepted the request. 

SPaT indicates that the flashing warning 

lights are active.

The SSM contains the following content: 

• Temp request ID: 123456. 

• Status: accepted. 

The SPaT message contains the following content: 

• Intersection number: 1314. 

• Phase ID: 7. 

• Description: Whittier Ave. at High St.

• Current state: flashing. 

• Minute end time: 20 s.

• Next time: indeterminite.

Mobile 

device

10 Receives messages indicating the flashing 

warning lights are active.

N/A

Mobile 

device

11 Provides an audio/visual confirmation to the 

traveler that flashing warning lights are 

active (optional).

Notification would be continuous while warning lights are on and 

while traveler is approaching and crossing.

Traveler 12 Receives notification as they approach the 

bike/pedestrian crossing (optional).

N/A

OBU 13 Receives messages indicating the flashing 

warning lights are active. 

N/A

OBU 14 Provides an audio/visual confirmation to the 

driver that flashing warning lights are active.

Determines that it would be approaching the crossing while flashing 

warning lights are active.

Driver 15 Receives notification as they approach the 

bike/pedestrian crossing.

Notification would be continuous while warning lights are on.

Traveler 16 Slows down, checks conflicting traffic to 

ensure no vehicles would encroach the 

crosswalk while crossing.

N/A

Traveler 17 Proceeds through intersection. N/A
114 

Source Step Key Action Comments

RSU 18 Determines that the traveler has passed 

through the intersection.

Determines that no other cyclists/pedestrians are crossing or 

approaching the crosswalk.

General 19 Turns warning lights off. N/A

OBU 20 Ceases issuing notification to driver. N/A

OBU = on-board unit.

To complete this scenario, six characteristics are included, along with a system diagram capturing the four sources included in the 

scenario, as shown in figure 17. 
115 

Source: FHWA. 

Figure 17. Diagram. Use Case 2—Scenario 1, four sources.
116 

The following characteristics complete Use Case 2—Scenario 1: 

• Postconditions—The bicyclist would be detected and would proceed through the 

intersection when the signal changes after determining that all conflicting traffic has 

stopped. 

• Messages— The message types would include MAPs, SPaTs, SRMs, and SSMs. 

• Traceability—The Bicyclist UN1—Activate Detector applies to this scenario. 

• Mobile device inputs summary—Inputs would include time and location (from GNSS), 

MAPs (from RSE), SPaT (from RSE), and SSMs (from RSE). 

• Mobile device—The mobile device would send SRMs (to RSE). 

• Outputs summary—Outputs would include audio/visual notifications (optionally, to 

bicyclists) to confirm the phase would be serviced and to confirm that flashing warning 

lights are active. 

Use Case 2—Scenario 2

Use Case 2—Scenario 2: Bicycle Street Safety describes a traveling bicyclist using a connected 

mobile device. Scenario 2 is identified and titled “UC2-S2: Bicycle Street Safety” with the 

following characteristics:

• Short description—A traveler (bicyclist) would carry a mobile device that would 

receive vehicle safety data, and the bicyclist would be made aware of potential safety 

issues as they complete their trip. Drivers in CVs that receive safety data from the mobile 

device would be made aware of potential bicycle-related safety issues as they complete 

their trip. 

• Scenario objective—To demonstrate the ability of a mobile device to provide the 

following capabilities: 

o Bicycle intersection movement assist. 

o Bicycle overtake lateral clearance safety. 

• Operational event(s)—The functioning-related events would take place in the following 

order: 

o In-vehicle device receives safety messages broadcast from mobile device. 

o Mobile device receives safety messages broadcast from the in-vehicle device. 
117 

• Preconditions—The traveler (bicyclist) would take a trip from work to home. The trip 

would take place during rush hour in an urban environment on arterials with many 

intersecting cross streets and on local streets, where many vehicles parallel park to access 

residences and local businesses. Motor vehicle traffic would typically be able to move at 

a pace that would be faster than the traveler. Local regulation allows bicyclists to take the 

full lane and has provisions that allow drivers to pass bicyclists (i.e., no oncoming traffic, 

3-ft lateral clearance).

• Traveler actor role—The traveler would carry a mobile device while operating a bicycle 

on the roadway network in an environment with drivers. 

• Driver 1 actor role—The driver would operate a vehicle containing an in-vehicle device 

on a shared roadway in an environment with bicyclists. 

• Driver 2 actor role—The driver would operate a vehicle containing an in-vehicle device 

approaching an intersection with a roadway in an environment with bicyclists. 

The scenario then describes key actions and the flow of events of six sources: traveler, driver 1, 

mobile devices, in-vehicle device 1, driver 2, and in-vehicle device 2. Table 16 describes steps 1 

through 38 in this scenario.
118 

Table 16. Use Case 2—Scenario 2, steps 1–38. 

Source Step Key Action Comments

Traveler 1 Proceeds forward in a shared lane. N/A

Driver 1 2 Approaches the bicyclist from behind. Driver’s vehicle is moving faster than the bicycle. 

Mobile 

device

3 Broadcasts a PSM. Provides location and movement information about the bicycle. 

Note: It would be an inherent attribute of the message that the 

traveler would be a VRU. The mobile device would be assumed to 

be located on the person of the traveler and could communicate 

normally. Messages broadcast by the mobile device could be 

received by other local devices. 

The PSM contains the following contents: 

• Temp ID: 18459349. 

• Location: 

o Lat: 39.947081. 

o Long: −82.994952. 

• Heading: 348. 

• Speed: 10 mph. 
119 

Source Step Key Action Comments

In-vehicle 

device 1

4 Broadcasts a BSM. Provides location and movement information about vehicle 1.

Note: It would be an inherent attribute of the message that the 

driver would be in a vehicle (i.e., not a VRU). Messages broadcast 

by the in-vehicle device can be received by other local devices. 

The BSM contains the following contents: 

• Temp ID: 18459349. 

• Location: 

o Lat: 39.946905. 

o Long: −82.994938. 

• Heading: 348. 

• Speed: 30 mph. 

In-vehicle 

device 1

5 Uses the PSM received from the mobile 

device to determine whether the vehicle is 

approaching a bicyclist. 

Determines that the vehicle would be approaching the bicyclist. 

In-vehicle 

device 1

6 Provides notification that a driver is 

approaching a bicyclist. 

Issues a notification when the distance between the vehicle and the 

bicycle decreases beyond a threshold that may be variable as a 

function of the speed difference between the vehicle and the 

bicycle.

Driver 1 7 Receives a notification that they are 

approaching a bicyclist. 

N/A

Driver 1 8 Checks traffic in adjacent lane to 

determine whether it is safe to pass. 

No conflicting traffic.

Driver 1 9 Begins to move over to the left to overtake 

the bicyclist. 

Crosses double solid yellow lines if local traffic regulations allow. 

According to local traffic regulations, the vehicle would not 

provide sufficient lateral clearance, which would be 3 ft in most 

cases. 
120 

Source Step Key Action Comments

Mobile 

device

10 Uses the BSMs received from the 

in-vehicle device to determine that there is 

a vehicle about to overtake the cyclist. 

Determines that a vehicle is attempting a passing maneuver as the 

distance between the vehicle and the bicycle decreases beyond a 

threshold that may be variable as a function of the speed difference 

between the vehicle and the bicycle. 

Mobile 

device

11 Provides audio notification that the 

bicyclist will be overtaken by a passing 

vehicle. 

Issues a notification when the distance between the vehicle and the 

bicycle decreases beyond a threshold that may be variable as a 

function of the speed difference between the vehicle and bicycle. 

Note: In an alternative scenario, this notification may not be issued 

if the lateral distance between the bicycle and vehicle would be 

greater than a given threshold. 

Traveler 12 Continues proceeding forward in the 

shared lane. 

Becomes aware of movements of passing vehicles. This 

notification discourages the bicyclist from making movements 

without checking the movements of surrounding vehicles. 

In-vehicle 

device 1

13 Uses information received from the 

mobile device to determine the lateral 

clearance between the vehicle and the 

cyclist. 

Determines whether the lateral clearance is expected to be less 

than 3 ft.

Note: Other applications on the in-vehicle device could notify the 

driver of conflicting traffic movements (forward collision warning 

or lane change warning), but that is outside the scope of this 

concept. 

In-vehicle 

device 1

14 Provides notification that not enough 

lateral distance is being provided. 

Issues notification when the distance between the vehicle and the 

bicycle decreases beyond a threshold that may be variable as a 

function of the speed difference between the vehicle and the 

bicycle.

Note: In an alternative scenario, this notification may not be issued 

if the lateral distance between the bicycle and the vehicle would be 

greater than a given threshold. 

Driver 1 15 Receives a notification that not enough 

lateral clearance is being provided before

overtaking the bicyclist. 

Becomes aware of the lack of sufficient lateral clearance. This 

notification gives the driver an opportunity to provide additional 

lateral clearance for passing the bicyclist.
121 

Source Step Key Action Comments

Driver 1 16 Moves farther to the left as they overtake 

the bicyclist. 

N/A

In-vehicle 

device 1

17 Ceases issuing notification to the driver. Ceases issuing notifications as the lateral clearance increases 

above a sufficient threshold.

Note: The in-vehicle device would continue to process incoming 

safety messages received from the mobile device (carried by the 

traveler) and would continuously evaluate the position of the 

vehicle with respect to the cyclist to determine whether a 

notification needs to be issued again. 

Mobile 

device

18 Ceases issuing notification to the traveler. Ceases issuing notifications as the vehicle overtakes the bicycle. 

Driver 1 19 Moves back to the right into the shared 

lane of travel. 

N/A

Traveler 20 Continues proceeding forward in the 

shared lane. 

N/A

Traveler 21 Approaches a two-way stop intersection. Approaches on the through approach of the intersection. 

Mobile 

device

22 Continues to broadcast the PSM. The PSM contains the following content: 

• Temp ID: 18459349. 

• Location: 

o Lat: 39.949144. 

o Long: −82.995356. 

• Heading: 348. 

• Speed: 10 mph. 

Driver 2 23 Approaches a two-way stop intersection. Approaches the ame intersection as the travelers, but from a Stop 

approach. Intends to make a through maneuver.
122 

Source Step Key Action Comments

In-vehicle 

device 2

24 Broadcasts a BSM. The BSM contains the following contents: 

• Temp ID: 18459349. 

• Location: 

o Lat: 39.949241. 

o Long: −82.995281. 

• Heading: 258. 

• Speed: 0 mph.

Driver 2 25 Stops and checks for cross traffic. Does not notice any cross traffic. 

Driver 2 26 Begins to travel through the intersection. Fails to see the traveler approaching from the uncontrolled 

approach from the left. 

Mobile 

device

27 Uses information received from the 

in-vehicle device to determine potential 

collision courses between the vehicle and 

the cyclist. 

Determines that there would be a sufficient probability of 

collision. 

Mobile 

device

28 Provides a potential crash notification 

with a vehicle. 

Issues a notification when the distance between the vehicle and the 

bicycle decreases beyond a threshold that may be variable as a 

function of the speed difference between the vehicle and the 

bicycle. 

Traveler 29 Receives a potential crash notification. Becomes aware of an imminent crash situation. Notices vehicle 

moving forward. 

Traveler 30 Slows down to avoid a potential crash 

situation. 

N/A

In-vehicle 

device 2

31 Uses information received from the 

mobile device to determine potential 

collision courses between the vehicle and 

the cyclist. 

Determines that there would be a sufficient probability of 

collision. 

In-vehicle 

device 2

32 Provides a potential crash notification 

with a bicyclist. 

Issues a notification when the distance between the vehicle and the 

bicycle decreases beyond a threshold that may be variable as a 

function of the speed difference between the vehicle and the 

bicycle.
123 

Source Step Key Action Comments

Driver 2 33 Receives a potential crash notification 

with a bicyclist. 

Becomes aware of an imminent crash situation. 

Driver 2 34 Comes to an abrupt stop. N/A

Mobile 

device

35 Ceases potential crash notification. N/A

In-vehicle 

device 2

36 Ceases potential crash notification. N/A. 

Traveler 37 Continues proceeding forward through the 

intersection. 

N/A

Driver 2 38 Checks for cross traffic and proceeds 

through the intersection. 

Uses the in-vehicle device, which continues processing incoming 

safety messages received from mobile devices (carried by other 

VRUs) and continuously evaluates the position of the vehicle with 

respect to other cyclists to determine whether a notification needs 

to be issued again.

To complete this scenario, six characteristics are included, along with a system diagram capturing the four sources included in the 

scenario, as shown in figure 18. 
124 

Source: FHWA. 

Figure 18. Diagram. Use Case 2—Scenario 2, four sources.
125 

The following six characteristics complete Scenario 2:

• Postconditions—Driver 1 and driver 2 would be aware of the presence of the bicyclist in 

the roadway environment, and they would modify their behavior to ensure the bicyclist is 

identified. The bicyclist would be aware of presence of vehicles in various safety-critical 

situations. 

• Messages—The message types would include PSMs and BSMs. 

• Traceability—The Bicyclist UN2—Bicyclist Roadway Safety Driver Awareness applies 

to this scenario. 

• Mobile device inputs summary—Inputs would include time and location (from GNSS)

and BSMs from in-vehicle device 1 and in-vehicle device 2. 

• Mobile device—The mobile device would send PSMs to in-vehicle device 1 and 

in-vehicle device 2. 

• Outputs summary—Outputs would include audio/visual notifications to the traveler 

about overtaking by a passing vehicle and potential crashes.

127 

CHAPTER 10. CONCEPT 3: TRAVELER USING PUBLIC TRANSIT WHILE USING A 

CONNECTED MOBILE DEVICE

CHAPTER OVERVIEW

This chapter is the third of four chapters that develop an example concept to showcase how 

mobile devices and electronic messages could be used to satisfy traveler needs. The concept in 

this chapter focuses on addressing an example set of needs for public transit users carrying a 

mobile device. Through these example concepts, the reader can begin to understand the content 

included in a typical ConOps. A description specific to the concept is provided and walks 

through existing conditions, justification for changes, description of desired changes, operational 

policies and constraints, description of proposed operating environment, modes of operation, 

user classes, support environment, and operational scenarios. These example concepts begin to 

shape a system that enables the exchange of electronic messages with mobile devices to satisfy 

the needs of different types of travelers.

EXISTING CONDITIONS

Travelers have access to trip planning applications to determine a route and itinerary that most 

closely matches their preferences. Existing conditions for travelers include the following options 

and actions: 

• Trip planning applications (desktop- and mobile-based) typically use real-time data, but

do not continuously check for changing conditions once the trip has been started. Trip

planners cannot account for travelers who are en route (already on a transit vehicle). Trip

planners assume the traveler has not started their trip. 

• Transit agencies provide real-time information online and/or through a smartphone 

application. Planned routes could utilize this information. Arrival information could be 

provided at stations and bus stops, but not always.

• Transit buses typically display the route number and heading on exterior signs on the 

front and the side of the bus. An audio notification could also be provided as the bus or

train stops at each stop. Regarding bus systems, drivers visually detect pedestrians at a 

stop to know whether a traveler intends to get on at the stop. 

• The bus or train provides information regarding the next stop information to the traveler

in both audio and visual formats. This system could be electronic and automated, or the 

information could be provided via static maps and driver announcements.

• Passengers are required to pull a cord (or similar) to notify drivers to stop at next stop. 

• Passengers pay when boarding or by using a ticket machine at train station or near a bus

stop (typically high frequency or bus rapid transit), depending on the system. Commuter 

rail systems also allow payment to be made onboard, typically at a higher fare than if the 

passengers were buying the ticket before getting on the train.
128 

• Passengers add funds at a payment terminal or through an online portal. Once funds have 

been added, the traveler taps a fare payment card to gain access to a bus or train (fare

gate). Some systems also require the traveler to tap the farecard when exiting the system.

This is usually required when the system uses a distance-based or zone-based fare

system. Some systems can have an integrated fare payment that allows free or discounted 

transfers to another system.

JUSTIFICATION FOR CHANGES

Several aspects of the current conditions of traveling on public transit could warrant the addition 

of technology to enable communication to and from mobile devices. These aspects are discussed 

in detail in the following subsections. 

En route Adjustment for a Transit Trip (Alternative Route)

A transit trip planned by using an MMTP may not go as scheduled because traffic conditions 

continuously change, and transit vehicles might travel ahead of or behind schedule. Such 

unexpected changes could particularly affect a transit trip if transfers are involved. In a situation

in which the first leg of a trip is running ahead of the schedule, it could be more advantageous for 

the traveler to use a different route for the second leg of the trip to ensure they could reach their 

destination faster. Similarly, if the first leg of a trip is running behind schedule, the traveler 

might miss the connecting second leg. In this case, it could be advantageous for the traveler to be 

provided with an alternate route to get to their destination, especially if there are long headways

between arrivals on the connecting route. Furthermore, a traveler who is interested in receiving 

transit trip adjustments might need to provide their location and speed to a Transit Management 

Center to receive the benefit of en route adjustments.

En route Mode Adjustment for a Transit Trip (Alternative Mode) 

If a traveler intends to take transit to the final destination but the changing system conditions 

could result in severe delays for the traveler, the traveler might take alternative modes of travel. 

Adjust Transit Operations (Connection Protection and Variable Service Adjustment)

Travelers on a multileg transit trip depend on reliable connections to arrive at their destination in

a timely manner. Making a connection would be especially important to a traveler when the 

connecting line provides low-frequency (high-headway) service. If the traveler misses the 

connection, waiting for the next transit vehicle to service the stop would result in the traveler

arriving at their destination much later than intended. 

In addition, transit agencies might experience unexpected high demand along certain routes. 

When unexpected demand occurs, buses or trains could become overcrowded, resulting in delays 

(increased dwell times for boarding/alighting) and bus/train bunching. 

Driver Notification of Passenger Waiting at Stop

Transit stops with passengers waiting at them are typically served by transit vehicles that operate 

at those stops. Transit vehicle operators generally look for the presence of a traveler waiting at a 
129 

stop along the route to determine whether to service the stop to allow the traveler to board. It

may be difficult for a transit vehicle operator to determine whether a person is waiting if the

potential passengers or the stop itself is occluded by other objects on the roadside or if the 

potential passengers are sitting away from the roadway. Drivers are more likely to stop for 

passengers if they are standing alert at a bus stop. Similarly, during night hours, it might be 

difficult to see a traveler waiting at a bus stop if it is not well lit.

Traveler Notification When Transit Vehicle Approaching 

Travelers might not be able to readily read the heading sign on an approaching transit vehicle or

might not be able to hear audible external announcements provided by the transit vehicle or the 

operator (if the transit vehicle is not capable of providing external announcements).

Driver Notification of Stop Request

Traditionally, pull cords or pushbuttons are available for use by travelers to indicate whether the

bus may service the next stop so that the traveler can get off the bus. Passengers who are unable 

to locate the pull cord might have difficulty getting the bus to stop so they can alight at the 

proper location. Similarly, travelers who are unfamiliar with the transit system may not know 

when their stop is approaching and know when to use the pull cord (if required to stop). Ideally,

there would be an alternative method to accommodates passengers performing tasks needed to

request a bus to stop. 

Passenger Notification to Alight

When onboard a transit vehicle, travelers might not be able to readily read information or hear

audio notifications about the next stop. Also, travelers who are not familiar with the transit

system might have difficulty determining what stop they need to get off a transit vehicle to get to

their destination. 

Transit Fare Payment (Pay When Boarding/Pay at Fare Gate) 

Smartphones are becoming an increasingly popular method for travelers to pay for a fare to gain

access to transit or other shared services. Certain transit systems allow a traveler to purchase a 

trip through an application specific to the transit system(s) in the region before arriving at the 

transit vehicle. Travelers activate the trip just before entering the transit vehicle, and the mobile 

device screen shows a proof of payment, which is displayed to the transit vehicle operator, kiosk, 

turnstile, or enforcement agent when boarding. Completing a trip that uses multiple modes of 

travel (or that uses multiple transit agencies or first-mile/last-mile options) can be more

burdensome if each system has its own payment system.

Some systems do not allow for smartphone-based payments, requiring the traveler to pay 

onboard (typically limited to cash) or to use a fare payment machine before boarding. (In some

systems, fare payment machines might not be located at all transit stops, which places the burden 

of making a cashless payment on the traveler.) 
130 

DESCRIPTION OF DESIRED CHANGES

Examples of transit user needs are provided in table 17. 

Table 17. Transit user needs. 

User Need ID Title Description

Transit UN1 Continuous Efficient

Route Check

A transit user needs an alternative route or mode options

that could be used by the traveler while en route to the 

destination.

Transit UN2 Trip Planning Service

Access

A transit user needs access to a multimodal trip planning

service.

Transit UN3 Approaching Transit

Vehicle Information

A transit user needs to know information about 

approaching transit vehicles while waiting at a transit stop.

Transit UN4 Board/Alight

Notification

A transit user needs to notify the transit vehicle operator 

when they intend to enter/exit from the transit vehicle.

Transit UN5 Connection

Protection

A transit user needs to notify a transit manager (or a 

transit management system) when they intend to make a 

scheduled connection.

Transit UN6 Transit Fare A transit user needs to know the fare to take a trip using

transit.

Transit UN7 Transit Payment A transit user needs a method to pay for a trip taken

using transit.

Transit UN8 Transit Wayfinding

and Navigation 

A transit user with disabilities needs wayfinding and

navigation solutions for a complete trip between an

origin and destination in the public right-of-way. Note: 

The traveler needs wayfinding and navigation 

information before starting the trip and must be updated 

throughout the trip to account for changing conditions, 

such as arrival times of a transit vehicle.

The mobile device-based applications described in the following subsections could address 

transit user needs. 

En route Adjustment for a Transit Trip (Alternative Route or Alternative Mode)

As the traveler completes the trip, the mobile device could check to see whether other modes are 

available to continue to the final destination and avoid delays on the transit leg of the trip. For a 

mode adjustment to be feasible for the traveler, the traveler could consider alternative modes 

(within a certain given walking distance of the traveler’s current location). Furthermore, it would 

be expected that preference selections made by travelers who are not physically capable of using 

one or several of these modes would preclude an MMTP from returning trips that contain these 

alternative modes. Allowing the traveler to program their abilities and preferences into an 

MMTP (e.g., willingness to park and ride, preference of walking up to 1 mi over a 10-min wait at 

a transfer, inability to use a scooter-share or bikeshare) could allow the system to adjust to these 

preferences when displaying and prioritizing travel mode and route options.
131 

A mobile device could access real-time scooter-share and/or bikeshare data to periodically

provide updated optimal route options and trip time estimates to the traveler. If close enough to

the destination, walking to compete the trip may also be a feasible option. The traveler can use 

this information to better make decisions about using transit and other options to proceed to their

destination.

Adjust Transit Operations (Connection Protection and Variable Service Adjustment)

Connection protection seeks to protect transfers between both transit (e.g., bus, subway, and 

commuter rail) and nontransit (e.g., shared ride) modes, and to facilitate coordination between

multiple agencies to accomplish this protection. For a traveler to benefit from connection 

protection, they would provide information to the transit agency that specifies they intend to

make a transfer at a specific location/time to a specific line. This transfer alert could be

accomplished by sharing the itinerary with the transit agency. Once the transit agency receives

this transfer request, they can hold the transferring vehicle if it arrives at the transfer location 

early, or if the transit vehicle arrives behind schedule. The transit operations must be flexible to

allow transit vehicles to wait for a transferring traveler. The agency may put a limit on the 

amount of time it holds one of its vehicles at a location.

A transit agency may require certain conditions to be met to allow connection protection to be 

provided for travelers. There could be a threshold on the number of travelers needing to make the

transfer or for the connecting route to be of low capacity or low frequency in service. A transit

agency may also be more willing to allow connection protection to occur if the connecting transit

vehicle waits at the beginning of its route. 

A mobile device could be used to facilitate the communication of traveler information to the 

transit agency. The traveler could use a mobile device-based trip planner to get a trip itinerary.

The mobile device could be used to communicate a traveler’s anticipated transfer location to the

transit agency. Alternatively, if the traveler’s proposed route information were available to the 

transit agency, and the transit agency could confirm that the traveler is adhering to the provided 

itinerary, the transit agency could provide connection protection when necessary and as

operations allow. A response could be provided to the traveler through the mobile device to

indicate they are likely to make the connection. It may also be useful to the traveler to be 

provided with information on the amount of time needed to make the connection. 

If a transit agency has advance information about greater-than-usual demand (e.g., during peak 

travel periods or after a special event), extra buses could be added to certain routes to better

accommodate demand along the route. As travelers use a mobile device to plan a transit trip, they 

could provide the transit agency with their itineraries. The transit agency would aggregate the

itineraries received from all travelers to forecast demand to use certain transit lines in the system.

Transit vehicles could then be added to transit lines where demand is expected to exceed a given 

threshold to increase the frequency of bus arrivals (until demand falls below the threshold). This

itinerary aggregation and subsequent forecast would reduce the time travelers wait for buses,

assist in preventing delays and bus bunching, and improve the overall user experience along the 

affected line.
132 

Driver Notification of Passenger Waiting at Stop

To enhance transit vehicle operators’ awareness of when they need to service a stop to pick up a 

passenger, the traveler’s mobile device would notify the operator of the approaching transit

vehicle that the traveler is waiting at the stop. The notification could include the location of the

stop, the intended route, and direction of travel. This notification process would ensure that the 

traveler boards the correct bus. 

Traveler Notification when Transit Vehicle Approaching 

The basic premise behind this use case is to notify a traveler when a bus is approaching, along 

with information about the bus and its route. When coupled with a multimodal trip planning 

application, the mobile device could provide additional details to the traveler to indicate whether 

the approaching bus is the bus as indicated by the planned itinerary. A mobile device could 

provide an alternate means of providing this information to the traveler that would be consistent

and could be readily comprehended by the traveler. The approaching transit vehicle could send

the route number and heading and a specified stop number, so the traveler (or mobile device) 

could determine whether they want to board the approaching bus. This increase in the traveler’s

awareness of the approaching bus would give the traveler more time to prepare to board the bus, 

which could result in decreasing the amount of time it takes to board and improving schedule 

adherence.

Driver Notification of Stop Request

This use case would allow a traveler to use a mobile device to alert to the transit driver that they 

need to get off the bus at a certain stop. The mobile device would send the stop location to the 

driver at any point throughout the trip. The transit vehicle operator would then be notified as they 

approach the stop that they need to service the stop. When used along with a multimodal trip 

planning application, the mobile device could place an automated call to the driver without 

added input from the traveler. This notification option would provide wayfinding and navigation 

assistance to travelers who are unfamiliar with the route they are traveling.

Passenger Notification to Alight

This use case would notify the traveler when they are expected to get off a transit vehicle. The 

successful execution of this use case would be predicated on the traveler using an MMTP where 

the destination stops would be known to the mobile device. This use case would primarily benefit 

travelers who are unfamiliar with using public transit (or who are unfamiliar with the system they 

are on) or travelers who are unable to readily read or listen to onboard information regarding the 

next stop.

Transit Fare Payment (Pay When Boarding/Pay at Fare Gate) 

The integration of fare payment systems (i.e., a single method for paying fares on multiple 

systems) would add convenience for a traveler when utilizing multiple systems on the same trip. 

A mobile device could provide a common interface for paying for a trip. However, enabling this 

feature would also depend on the availability of a common payment platform and a service 
133 

provider’s (e.g., transit, ride hailing/sharing, carsharing) ability to accept payments using the 

common interface.

A common payment service typically involves a traveler carrying a device, such as a mobile 

device, that is compatible with the common payment system. The traveler would also provide 

account information in the device to enable a transaction to occur. As with many applications 

that are currently available on smartphones, this account information could be credit card 

information. However, to promote equity among users who do not have access to a credit card, 

the application would also accept payment from a common payment account that provides other 

options (e.g., cash) for the traveler to load funds into the account that could be used to pay for a 

trip. The traveler’s payment information could be used to complete a one-time payment for a 

single trip, or to purchase a monthly or yearly pass to access systems (e.g., transit or bikeshare

systems) that have a monthly or yearly access option. 

Priorities Among Changes 

This section prioritizes user-proposed functionality presented in the previous subsection. This

prioritization would be typically done by classifying each possible change as essential, desirable,

or optional. The classification method used would be determined by each deploying agency. 

Functions related to safety or other high-priority needs are considered essential, whereas

desirable functions are considered to provide enhanced functionality but are not necessary for the 

system to meet user needs. Optional needs are generally limited to needs that are discretionary in

nature. Prioritizing user needs would be a subjective practice and would vary from agency to 

agency and from region to region. 

Changes Considered But Not Included

This section identifies changes and new features considered but not included, and the rationale

for not including them. Not including certain features could be due to implementation 

difficulties, technology limitations, or other systems’ ability to adequately meet the needs of 

users. Changes that are considered but not included would vary from agency to agency and from 

region to region. 

Assumptions and Constraints

This section lists assumptions and constraints that would (or could) limit how the system can be 

designed and implemented. The following examples describe common assumptions and 

constraints that could affect the design of the proposed system:

• Communication, technology, hardware, or software availability. 

• Off-the-shelf technology procurement (as opposed to the development of a new device). 

• Operational policies and constraints. 

• Existing laws and regulations (e.g., governing the operations of motor vehicles,

pedestrians, and bicyclers on the roadways). 
134 

PROPOSED OPERATING ENVIRONMENT

As discussed in previous chapters, sharing and using electronic messages with connected mobile 

devices can be described as systems that work together. This concept includes the mobile device, 

GNSS, the transit in-vehicle equipment, an MMTP service, a shared-mobility device/service, a 

transit payment system, and a transit management center.

Figure 19 illustrates a systems diagram for this concept. The interfaces, hardware, messages, and 

facilities and external systems that comprise this figure are discussed in detail in the proceeding

subsections.

Source: FHWA. 

Figure 19. Diagram. Mobile device transit user system. 

Interfaces

The following interfaces would be required to bring functionality to this concept: 

• The transit in-vehicle equipment would provide a transit vehicle approaching message to

the mobile device. This message would be received by the mobile device as a transit

vehicle approaches the traveler’s location and while the traveler is inside the transit

vehicle.

• The mobile device would send a pickup request message and a stop request message to 

the transit in-vehicle equipment. The transit vehicle would receive this message as the 

transit vehicle approaches the traveler’s location and while the traveler is inside the 

transit vehicle.
135 

• The mobile device would send an MMTP trip request message to the MMTP service. The 

mobile device would send a reservation request message to the shared-mobility service. 

The mobile device would receive an MMTP trip options message from the MMTP 

service. Connectivity between the mobile device and the MMTP service, and between the 

mobile device and the shared-mobility service, would occur pretrip and while en route 

throughout the course of the traveler’s trip.

• The mobile device would send a shared-use device unlock request message and a shareduse device end trip message to the shared-mobility device. The mobile device would 

receive the shared-use device unlock response message from the shared-mobility device. 

These messages exchanges would occur when the mobile device is near the sharedmobility device.

• The mobile device would exchange payment messages with payment systems for all

services utilized by the traveler. (For this use case, the payment systems would include 

those used by both transit and shared-mobility systems.) Payment registration would be 

completed before the traveler uses the transit service or shared-mobility service, whereas

the payment user ID would be exchanged as the traveler enters and/or exits the transit

vehicle and when the traveler unlocks a shared-mobility device. 

Hardware 

The following hardware would be needed to enable this concept: 

• The mobile device would be a self-contained apparatus that wirelessly sends and receives

messages, receives data from its onboard sensors, and has a processor to execute 

functions and an HMI, which would allow it to receive input from and provide output to 

the pedestrian (audio/visual/haptic). The mobile device would position itself in the 

roadway environment to provide the traveler with local transit information. The mobile 

device would have access to an MMTP. The mobile device would accept MMTP inputs 

from the traveler, submit the request to the MMTP, receive trip planning results from the 

MMTP, and provide the results back to the traveler. Once the traveler selects a trip to 

take, the mobile device would forward the selected trip to all agencies that serve various 

legs of the trip. While en route, the mobile device would constantly exchange information 

with the MMTP to check for alternative trip options.

• As the traveler waits at the transit stop, the mobile device would receive transit vehicle 

approaching messages from incoming transit vehicles and would provide this information 

to the traveler waiting at the stop. If the traveler is in the process of taking a trip (selected 

a trip), the mobile device would also indicate whether the traveler should board the bus. 

As the transit vehicle approaches the stop where the traveler is waiting, the mobile device 

would send a pickup request message containing information about the transit vehicle 

that the traveler wants to board. 
136 

• The mobile device would be used to facilitate payment. A payment information message

would be sent to the transit vehicle system (when the traveler is boarding or alighting a 

transit vehicle, as necessary) or the shared-mobility device (when a traveler unlocks or 

ends a trip on a shared-mobility device).

• While the traveler is on the transit vehicle, the mobile device would send a stop request 

message to the transit in-vehicle equipment as the transit vehicle approaches the 

traveler’s stop. The mobile device would also notify the traveler that they are

approaching their destination stop. 

• The transit in-vehicle equipment would constantly broadcast a transit vehicle approaching 

message containing the information regarding the next stop. A pickup request message

would notify the transit vehicle operator that a passenger is waiting at the stop specified

in the message. Similarly, a stop request message would notify the transit vehicle 

operator that a passenger intends to alight at the stop specified in the message. The transit

in-vehicle equipment would also receive payment information messages and would 

forward the information to the transit vehicle payment system. 

Messages

Transit Vehicle Approaching Message

The transit vehicle approaching message would provide information to a mobile device about an

approaching transit vehicle. The mobile device could use information about the approaching 

transit vehicle and the pedestrian’s current location to determine whether the information about 

the approaching transit vehicle should be displayed to the pedestrian. The message contents 

could include the transit system operator’s name or ID, the route number, the final destination, a 

route shape identifier, the next stops along the route, and the ID number of the coach. This

message would help travelers better identify buses approaching a given bus stop. 

Pickup Request Message

The pickup request message would allow a mobile device-carrying traveler waiting on a transit

vehicle to notify the transit vehicle operator that they are waiting to board the transit vehicle at

the passenger’s given location. The contents of the message could include the transit system

operator’s name or ID, the route number, the final destination, and the pickup stop ID number. 

This type of message would be useful for transit services where stops are not serviced unless a 

passenger is waiting at the stop, especially under conditions in which the passenger might not be 

easily visible (e.g., when physical objects on the roadside are occluding the traveler from the

transit vehicle operator’s view or during nighttime hours). This message would be sent to an 

onboard transit vehicle device after the mobile device has received a transit vehicle approaching 

message from a transit vehicle that the pedestrian intends to take.

Stop Request Message

The stop request message would allow traveler with a mobile device to alert the transit vehicle 

operator about the stop where the traveler wants to get off the transit vehicle. This type of 
137 

message would be useful for transit service where stops are not serviced unless requested by a 

passenger. At a minimum, the content in this message could include the stop identifier or could 

simply specify the next stop (in case the mobile device does not have access to transit stop 

identification information).

Payment Account Registration Message

The payment account registration message would be sent from a mobile device to an agency’s 

payment system to register payment information and associate that payment information with a 

traveler. This message would contain the traveler’s payment account information (e.g., 

card/account number, name, billing address), agency payment identifier, and an account

activation period. This message would be sent only when the mobile device does not have an

active registration with the payment system for a given agency providing a service the traveler

intends to use.

Payment Account Confirmation Message

The payment account confirmation message would be sent to the mobile device once an agency’s 

payment system has determined whether a valid method of payment has been provided (the

registration was successful or not). Information in this message could include the payment status, 

an account ID, and a date of expiration for the account activation period. This account ID could 

be used in future transactions between the mobile device and the payment service with which the 

mobile device is registered until the end of the activation period (at which time, the payment 

account must be reactivated).

Payment User ID Message

The payment user ID message would be sent from a mobile device to pay for services once a 

payment account has been registered. This message could contain the intended payment system

ID along with the travelers account ID. No payment information would be exchanged. 

Payment User Confirmation Message

The payment user confirmation message would be sent in response to the payment user ID

message, and it would contain the payment system ID, the account ID, and the payment 

confirmation status.

MMTP Trip Request Message

The MMTP trip request message would provide a standardized format for sending a query from 

a mobile device to an MMTP service. At a minimum, it would contain the origin and destination 

locations and traveler preferences (mode, departure/arrival time, cost, etc.), and it would indicate 

whether the traveler is in a vehicle. This message would allow the MMTP to provide accurate 

route choices based on whether the traveler is already onboard a vehicle (or other mode of 

transport).
138 

MMTP Trip Options Message

The MMTP trip options message would be sent in response to the MMTP request message and 

would contain route options that satisfy the query and preferences specified by the traveler in the 

MMTP trip request message. Each route in this message would be broken into legs, whereby a 

single leg would be one segment of a trip taken in a single vehicle or on foot, without needing to 

make a transfer. The message would contain a polyline overview of the route, the route total 

duration, and the total cost. For each leg of the trip, the mode, starting location 

(latitude/longitude, descriptive name, stop ID), end location, service provider, route number, 

vehicle number, cost, duration, and waiting duration would be provided at a minimum. 

Reservation Request Message

The reservation request message would be sent from a mobile device to a shared-mobility service

to reserve a shared-mobility device, which would be identified in the message.

Shared-Mobility Device End Trip Message

The shared-mobility device end trip message would be sent from the mobile device to the 

shared-mobility device to end a trip on the shared-mobility device.

Facilities and External Systems

Transit Payment System

The transit payment system would receive payment information from the transit in-vehicle 

system and would charge the traveler’s account according to the services used. Payment 

information would be used as an identifying feature to enable and track transfers within the 

system. The transit payment system would track payment information received for the same

account (from the same mobile device). After the trip is complete, the payment system would 

determine the total cost of the trip (accounts for free/discounted transfers or upcharges for use of

higher tier services) and would charge the account accordingly. 

MMTP

The MMTP would receive the MMTP trip request message and would determine one or more 

potential options between the specified origins and destinations that are within the constraints of 

the traveler’s specified preferences. For the MMTP to provide effective itineraries, it would need 

access to real-time data from external systems, including but not limited to, roadway traffic 

conditions, real-time transit data, bikeshare station availability, the locations of shared-mobility 

devices, and rideshare/ridesourcing availability information. The MMTP would provide a 

response containing route options to the mobile device in the MMTP trip options information 

message.

Shared-Mobility Service

The shared-mobility service would provide management services for a system of shared-mobility

devices. The service would communicate with each shared-mobility device to obtain its location
139 

and to determine whether a user trying to unlock the device is registered, when a user has 

unlocked and started using the shared-mobility device, and when a user has ended a trip for the 

purpose of determining the trip cost. It would then use payment information (provided by the 

traveler) to charge the traveler’s account for the trip taken. Although most shared-mobility

service systems that exist do not allow reservations to be placed on a shared-mobility device, this

function could easily be integrated. 

Shared-Mobility Device

The shared-mobility device would typically be a powered device that would be located

throughout the city and would be wirelessly connected with the shared-mobility service. The

shared-mobility service may send a reservation request to the shared-mobility device so that only

a traveler holding the reservation credentials could unlock the shared-mobility device for use. It

would also receive the shared-user device unlock request message. If there is not a reservation on 

the shared-mobility device, then it would unlock for the traveler to use. However, if there is a 

reservation, the shared-mobility device would determine whether the reservation details in the

unlock request message match the reservation from the shared-mobility service before unlocking 

the mobile device for the traveler to use. The shared-mobility device would send an unlock

response message to the mobile device that provides details regarding whether the sharedmobility device was successfully unlocked. 

MODES OF OPERATION

Mobile devices are intended to complement existing methods of providing transit information, 

accessing an MMTP, wayfinding, and payment for utilizing a transit service or a shared-mobility 

service. Information and notifications provided to the traveler are expected to improve the 

mobile device users’ mobility, wayfinding, and ability to make informed decisions. Mobile 

devices are not intended override existing methods of receiving information or payment. If the 

mobile device-based system experiences nonnormal modes of operations, the mobile device user 

would have to rely on existing methods of receiving transit information, accessing an MMTP, 

wayfinding, and making payments. 

Various issues that could result in nonnormal operations are provided in general context in

chapter 8, Modes of Operation. 

USER CLASSES AND INVOLVED PERSONNEL

The traveler user class can be categorized as both a transit user and a shared-mobility device

user. Using transit, the traveler waits at a given location for a transit vehicle to arrive and boards 

the transit vehicle when it arrives. For these actions to occur successfully, the traveler should 

receive information regarding the transit vehicle that is approaching and stopping to ensure they 

are boarding the correct transit vehicle, especially when there is more than one transit route 

servicing the stop where the traveler is waiting. 

The traveler must pay for use of the transit service. At a bus stop, the traveler typically pays in

cash when boarding or taps a preloaded farecard against a terminal when boarding. Alternatively,

the traveler could use a farecard to pass through fare gates to gain access to a paid-fare zone. 

Fare gates, which are typically found at bus terminals or train stations, eliminate the need for 
140 

payment, and when the traveler enters the transit vehicle, fare gates increase boarding efficiency.

Proof-of-payment type systems do not have a fare gate but require the traveler to pay for a trip or

activate a trip before boarding. The traveler is then provided with a proof of payment, which is

validated from time-to-time by fare enforcement officials.

After boarding, the traveler rides on the transit vehicle approaching their destination (or end of 

the trip leg). The traveler is responsible for knowing the stop where they plan to alight the 

vehicle. Whereas certain services (e.g., subway, trolley) may stop at every stop, other services

(e.g., bus, light rail, streetcar) require the traveler to notify the transit vehicle operator when they 

plan to alight the transit vehicle. In this case, the traveler would use a pull cord (or stop button or 

press the yellow strip) to request getting off at the next stop. 

The traveler uses a shared-mobility device to access areas that are not easily accessible by transit, 

when traveling in an area where driving would be difficult or expensive and when other personal 

modes of transport are not practical (i.e., too long to walk or other personal mobility options are 

not available). These services require a traveler to be within the proximity where the 

shared-mobility device is present or to view real-time availability data to determine where to find 

the nearest shared-mobility device. The traveler cannot be guaranteed that a device that is shown as 

available would still be found at the indicated location because another traveler could reach the 

device first. If another traveler does reach the device first, the traveler must find (and navigate to) a 

different shared-mobility device to use. Dockless systems require the traveler to use a smartphone 

to unlock the device, whereas dock-based systems (e.g., bikeshare) typically require a credit card 

(short-term use) or fob (long-term membership) for access. A trip taken on a dockless system may 

end at any location within the service boundary; the traveler uses the smartphone to lock the 

device. The traveler then receives a fee for the trip, which they are responsible for paying. 

(Long-term bikeshare members may not be charged because they typically receive a free-use 

period.) Most shared-mobility systems require the traveler to keep credit card information on file 

(or carry credit on an account) to ensure that payment for the trip is automatically made once the 

trip ends.

The transit vehicle operator is responsible for stopping at all stops where passengers are waiting 

and for stopping when a passenger makes a stop request. As each passenger boards, the transit 

vehicle operator collects a fare from the passenger or verifies that the passenger has already paid 

(i.e., has a valid pass). When implementing connection protection, the transit vehicle operator

would also be responsible for performing a holdover when they reach the stop where connection 

protection would be granted. Ideally, the transit vehicle operator would be in a position where

they can see the arrival of the connecting transit vehicle, but they would verify that all

transferring passengers were able to make the transfer before continuing along the route.

SUPPORT ENVIRONMENT

The transit agency would be responsible for the following actions: 

• Operating and maintaining the transit service. 

• Making real-time transit data publicly available so that the information can be used on a 

mobile device to provide real-time transit data to travelers and for trip planning purposes. 
141 

• Making real-time transit fare data available (most fare structures are static, but some vary

depending on time of day, e.g., peak fares). 

• Collecting fares and verifying proof of payment when a traveler enters a bus or passes

through a fare gate. This step includes managing transfers that occur within the transit

network (e.g., from train to bus or from one bus to another). 

• Implementing connection protection under a given set of circumstances (i.e., a bus is

running late, and a rider has indicated they intend to make a transfer to another bus line). 

The personal mobility service provider (bikeshare, scooter-share) would be responsible for the 

following actions: 

• Operating and maintaining devices that can be used for personal mobility. 

• Making real-time data regarding the location of available bikes or scooters available. This

step includes data on docking stations (if required) and any applicable service areas’ 

boundaries. 

• Making real-time cost data available so that data can be used for trip planning purposes. 

• Collecting fees for use of service.

The ridesource/rideshare provider would be responsible for the following actions: 

• Matching travelers with nearby drivers to service a trip requested by the travelers. 

• Allowing a driver (actively servicing a traveler) to pick up another traveler (i.e., enable

ridesharing). 

• Maintaining real-time data regarding the availability of drivers. 

• Making real-time cost data available so that data can be used for trip planning services.

Cost may fluctuate based on number of drivers available to service current demand for

service. 

• Collecting payment for completed trips.

OPERATIONAL SCENARIOS

The operational scenarios in this section intentionally contain details that are typically beyond 

the scope of what would be necessary for a ConOps, such as including the functions carried out 

by each component, detailing the sending and receiving of messages, and revealing the content 

of those messages. This level of detail would be typically found in subsequent SE

documentation. However, in this concept, this additional detail is included to provide the reader 

additional context about how such a system could work, and how messages could be used to 

enable the use case, to underscore the theme of sharing electronic messages with mobile devices 

to satisfy the needs of different types of travelers.

Use Case 3 captures the traveler using public transit while using a connected mobile device and 

has the following four scenarios: 

• Transit System Navigation and Virtual Transit Vehicle Operator Notification. 

• Transit En Route Adjustment (Same Mode). 

• Transit Connection Protection. 

• Transit En route Adjustment (Alternative Mode). 
142 

Use Case 3—Scenario 1 

Use Case 3—Scenario 1 describes a traveler using public transit while using a connected mobile 

device. This scenario is identified and titled “UC3-S1: Transit System Navigation and Virtual 

Transit Vehicle Operator Notification” with the following characteristics:

• Short description—A traveler (transit user) would use a mobile device to navigate a 

transit system with which they are not familiar. 

• Scenario objective—To demonstrate the ability of the mobile device to provide the 

following options: 

o Driver notification of passenger waiting at stop. 

o Traveler notification when transit vehicle approaching. 

o Driver notification of stop request. 

o Passenger notification to alight. 

o Transit fare payment. 

• Operational event(s)— The functioning-related events would take place in the following 

order: 

o Approaching transit vehicles would send information about their route to the mobile 

device.

o The mobile device would determine whether the approaching transit vehicle is the 

one the traveler intends to take (according to the planned trip itinerary) and would 

notify the traveler via the mobile device when the transit vehicle is at the stop.

o The mobile device would send a notification that there is a traveler waiting at the stop 

to the transit vehicle that the traveler intends to take as it approaches.

o The mobile device would facilitate payment for the transit trip.

o The mobile device would send the location that the traveler intends to disembark to 

the transit vehicle.

o The transit vehicle would provide a relevant notification to the transit vehicle operator 

(and to the traveler) as it approaches the stop.

o The mobile device would notify the traveler via the mobile device when the transit 

vehicle is approaching the destination (alighting) stop. 

• Preconditions—The traveler (transit user) would use a mobile device to plan a trip from 

home to downtown. The trip would consist of a transit segment, but the traveler would be 

not familiar with the transit system. The traveler’s mobile device would have received a 

trip itinerary from an MMTP. The mobile device would use this trip itinerary to provide 

the traveler with step-by-step instructions for wayfinding purposes. The traveler would 

have limited vision, which would make it difficult for the traveler to know when a bus is 

approaching or to easily determine the status of a pedestrian crossing at a traffic signal. 

• Traveler actor role—The traveler would successfully and safely navigate the planned 

itinerary. 
143 

• Mobile device actor role—The mobile device would provide relevant wayfinding 

information to the traveler (based on the location of the mobile device in the 

transportation environment) and send and receive messages that enable the traveler’s 

needs to be met. 

• Transit vehicle in-vehicle device actor role—The in-vehicle device would release a 

transit vehicle approaching message and alert the transit vehicle operator when a stop 

must be serviced. 

• Transit vehicle operator actor role—The transit vehicle operator would service transit 

vehicle stops and monitor their surroundings for safety. 

The scenario then describes key actions and the flow of events of six sources: traveler, transit 

vehicle 2, mobile device, transit vehicle 1, transit vehicle 1 in-vehicle device, and transit 

payment system. Figure 20 and table 18 describe steps 1 through 12 of this scenario and table 19

further describes steps 13 through 24 as detailed in figure 21. 
144 

Source: FHWA. 

Figure 20. Diagram. Use Case 3—Scenario 1, data flows of steps 1–12. 
145 

Table 18. Use Case 3—Scenario 1, steps 1–12. 

Source Step Key Action Comments

Traveler 1 Navigates from home to the location of the bus 

stop. The traveler waits for the bus to arrive. The

bus stop serves two routes (Route 1 and Route 8).

Traveler needs to take Route 1 to get to the grocery store

(planned destination).

Transit

vehicle 2

2 Route 1 bus approaches the stop where the traveler 

is waiting.

N/A

Transit

vehicle 2

3 Sends a transit vehicle approaching message as it

travels along its route.

Route shape ID and next stops correspond to GTFS

(General Transit Feed Specification) Realtime data.(6)

The traveler waits at stop ID 7890. 

This transit vehicle does not service the traveler’s

intended stop (ID 7899). 

The transit vehicle approaching message contains the 

following content: 

• Operator: local transit authority. 

• Route number: 1. 

• Route heading: via Livingston. 

• Final destination: Reynoldsburg Park and Ride. 

• Polyline (of route). 

• Next stops: 

o Stop ID: 7890. 

o Stop ID: 7891. 

o Stop ID: ... 

o Stop ID: 8888. 

• Service provider ID: 12.

• Vehicle ID: 1234.
146 

Source Step Key Action Comments

Mobile 

device

4 Provides an output (audio and visual) to the traveler

that indicates that the approaching bus is not the 

correct bus: 

“Local transit authority—Route 1 toward

Reynoldsburg Park and Ride is approaching. 

Continue waiting to stay on planned itinerary.”

N/A

Transit

vehicle 2

5 Continues, and the traveler continues to wait at the

stop.

N/A

Transit

vehicle 1

6 Approaches the stop. N/A

Transit

vehicle 1

7 Sends a transit vehicle approaching message as it

travels along its route.

Route shape ID and next stops correspond to GTFS

Realtime data.(6) The traveler waits at stop ID 7890. The

traveler needs to get off the bus at stop ID 7899. 

The transit vehicle approaching message contains the 

following content: 

• Operator: local transit authority. 

• Route number: 8. 

• Route heading: via Parsons. 

• Final destination: Great Southern. 

• Polyline (of route). 

• Next stops: 

o Stop ID: 7890. 

o Stop ID: 8891. 

o Stop ID: 8892. 

o Stop ID: 9999. 

• Service provider ID: 12.

• Vehicle ID: 2345.
147 

Source Step Key Action Comments

Mobile 

device

8 Provides an output (audio and visual) to the

traveler that indicates that the Route 1 bus is

approaching: “Local transit authority—Route 8 

toward Great Southern is approaching. Board to

stay on planned itinerary.”

N/A

Mobile 

device

9 Sends a pickup request message to the bus. The pickup request message contains the following 

content: 

• Service provider ID: 12. 

• Vehicle ID: 2345. 

• Stop ID: 7890. 

• Require kneel: no.

• Require ramp: no.

Transit

vehicle 1 

in-vehicle

device

10 Provides an output to the bus driver to indicate that

the next stop must be serviced: 

“Pickup passenger at stop 7890.”

Note: This step would likely be optional because transit

system policies typically require a bus driver to stop at

any bus stop where a passenger is waiting. The output 

would simply provide added awareness to the bus driver.

Transit

vehicle 1

11 Stops at the bus stop. N/A

Traveler 12 Traveler boards the bus. N/A
148 

Source: FHWA. 

Figure 21. Diagram. Use Case 3—Scenario 1, data flows of steps 13–24.
149 

Table 19. Use Case 3—Scenario 1, steps 13–24. 

Source Step Key Action Comments

Traveler 13 Places mobile device near payment 

terminal.

Traveler has not used the transit payment system before.

Mobile 

device

14 Sends payment account registration

message to transit payment system.

The payment account registration message contains the following 

content: 

• Payment account information: 

o Account number: 1234567890123456. 

o Name: John Doe. 

o Payment billing address: 123 Main St. 

• Payee ID: 111222333 (corresponds to transit payment 

system). 

• Account activation period: 7 d. 

Note: The traveler would have previously entered payment 

information into the mobile device when it was initialized. If

multiple payment options have been entered, the mobile device may

prompt the traveler which payment method to use.

Transit

payment 

system

15 Receives payment account registration

message.

The transit payment system stores payment account information until 

the end of the account activation period.

Transit

payment 

system

16 Authorizes payment method. Payment method is authorized.
150 

Source Step Key Action Comments

Transit

payment 

system

17 Sends payment account registration

confirmation to mobile device.

The payment account registration confirmation message contains the 

following content: 

• Payee ID: 111222333 (corresponds to transit payment 

system). 

• Payment status: authorized. 

• Account ID: 1A2B3C4D5E. 

• Account activation period: 7 d. 

Payee ID and account ID would be used in the payment user ID

message for all trips taken using the transit agency during the account 

activation period (7 d). This activation period limits the number of 

times account information needs to be exchanged.

Mobile 

device

18 Sends a stop request message to the 

transit vehicle 1 in-vehicle device.

This message may be communicated from the mobile device to the 

bus directly or via a transit management center.

The stop request message contains the following content: 

• Service provider ID: 12. 

• Route ID: 8. 

• Stop ID: 8898. 

• Require kneel: No.

• Require ramp: No.

Transit

vehicle 1

19 Continues along its route. The mobile 

device provides an indication of how 

close the traveler is to their destination

stop.

N/A

Mobile 

device

20 Provides an output (audio and visual) to

the traveler that indicates that they are

approaching their stop: “Prepare to exit

bus to stay on planned itinerary.”

N/A
151 

Source Step Key Action Comments

Transit

vehicle 1 

in-vehicle

device

21 Provides an output to the bus driver to

indicate that a passenger needs to get off 

the bus at the next stop: “Drop off 

passenger at stop 8898.”

The bus driver is notified as the bus passes the stop immediately

before the traveler’s planned stop.

Transit

vehicle 1

22 Stops at the designated stop. N/A

Mobile 

device

23 Provides an output (audio and visual) 

that confirms that the traveler should get 

off at this stop: “Exit bus here to stay on 

planned itinerary.”

N/A

Traveler 24 Exits transit vehicle 1 and proceeds 

onward toward destination.

N/A

To complete this scenario, six characteristics are included, along with a system diagram capturing the four sources included in the 

scenario, as shown in figure 22. 
152 

Source: FHWA. 

Figure 22. Diagram. Use Case 3—Scenario 1, four sources. 
153 

The following characteristics complete Use Case 3—Scenario 1: 

• Postconditions—The mobile device would improve the traveler’s ability for wayfinding 

(approaching transit vehicle information, information regarding when to board/exit transit 

vehicle, and signal information). The transit vehicle operator would become more aware 

of the traveler waiting at the stop and the traveler’s intent to board the transit vehicle. 

• Messages—The message types would include transit vehicle approaching messages, 

pickup request messages, stop request messages, and PSMs. 

• Traceability—The following user needs would apply to this scenario:

o Transit UN3—Approaching Transit Vehicle Information. 

o Transit UN4—Board/Alight Notification. 

o Transit UN8—Transit Wayfinding and Navigation. 

• Mobile device inputs summary—Inputs would include time and location (from GNSS) 

and transit vehicle approaching messages (from transit vehicle in-vehicle equipment). 

• Mobile device—The mobile device would send pickup request messages (to transit 

vehicle in-vehicle equipment) and stop request messages (to transit vehicle in-vehicle 

equipment). 

• Outputs summary—Outputs would include audio/visual/haptic notifications to the 

traveler, such as “bus approaching” or “exit bus at next stop.” 

Use Case 3—Scenario 2 

Use Case 3—Scenario 2 describes a traveler using public transit while using a connected mobile 

device. This scenario is identified and titled “UC3-S2: Transit En route Adjustment (Same 

Mode)” with the following characteristics:

• Short description—A traveler (transit user) uses a mobile device to find a better route to 

navigate to their destination after the first leg of a two-leg transit trip is delayed. 

• Scenario objective—To demonstrate the ability of the mobile device to provide an en 

route adjustment (alternative route).

• Operational event(s)—The functioning-related events would take place in the following 

order: 

o The mobile device would periodically assess progress along the planned route (using 

an MMTP) to determine whether there is a more efficient route. 

o The mobile device would send a notification to the traveler when a more efficient 

route becomes available. 
154 

• Preconditions—A traveler (transit user) would use a mobile device to plan a trip from 

home to downtown. The trip would consist of two legs—both legs are different routes on 

the same transit system, but unforeseen congestion would cause a delay on the first leg. 

The trip would take place in a region where the transit network runs many parallel routes 

to accommodate regional needs. The traveler would indicate (i.e., provide input to the 

mobile device) that they prefer to use only transit to complete their trip. 

• Traveler actor role—The traveler would navigate the planned itinerary safely and 

successfully. 

• Mobile device actor role—The mobile device would provide relevant wayfinding 

information to the traveler (based on the location of the mobile device in the 

transportation environment) and send and receive messages that enable the traveler’s 

needs to be met. 

• Transit vehicle in-vehicle device actor role—The in-vehicle device would release a 

transit vehicle approaching message and alert the transit vehicle operator when a stop 

must be serviced. 

• Transit vehicle operator actor role—The transit vehicle operator would service the 

transit vehicle stops and monitor their surroundings for safety. 

The scenario then describes key actions and the flow of events of four sources: traveler, transit 

vehicle, mobile device, and MMTP service. Figure 23 and table 20 describe steps 1 through 16 

of this scenario. 

Source: FHWA. 

Figure 23. Diagram. Use Case 3—Scenario 2, steps 1–16. 
155 

Table 20. Use Case 3—Scenario 2, steps 1–16. 

Source Step Key Action Comments

Traveler 1 Boards transit vehicle 1. The traveler has an itinerary connecting to another bus line. The

itinerary, based on real-time transit data, anticipates a 5-min window 

for the traveler to make the connection.

Transit

vehicle

2 Encounters unexpected congestion 

along the route.

This congestion adds 10 min to the transit vehicle’s typical travel

time.

Mobile 

device

3 Continuously evaluates the traveler’s

progress along the selected itinerary.

As the bus sits in traffic, the mobile device compares the position of 

the bus against the anticipated position in the selected itinerary.

Mobile 

device

4 Determines that the traveler would miss

the connection as planned in the selected

itinerary.

Once the bus falls 5 min behind schedule of the planned itinerary,

the mobile device determines that the connection cannot be reliably

made.

Mobile 

device

5 Begins to assess alternative routes to get 

to the selected destination.

Utilizes the MMTP service.

Mobile 

device

6 Sends MMTP trip request to MMTP 

service.

The MMTP trip request message contains the following content: 

• Trip ID: 2468. 

• Origin (lat/long or address). 

• In vehicle: yes: 

o Service provider ID: 12. 

o Vehicle ID: 2346. 

• Destination (lat/long or address). 

• Preferences. 

• Mode: bus.

MMTP 

service

7 Receives trip request. N/A

MMTP 

service

8 Evaluates potential options based on

traveler preferences.

The MMTP service provides traveler preferences, including mode, 

travel time, trip cost, and maximum walking distance.
156 

Source Step Key Action Comments

MMTP 

service

9 Sends MMTP trip options information 

back to the mobile device.

The MMTP trip options information message contains the following 

content for trip ID 2468: 

• Route ID: 1 (selected route). 

o Polyline (of route). 

o Total duration: 35 min. 

o Total cost: $2.00. 

o Leg: 1: 

• Mode: transit. 

• Start location: 

 Lat/long: 39.9601, −83.0170. 

 Descriptive name: N/A. 

 Stop ID: N/A. 

• End location: 

 Lat/long: 39.9619, −83.0027. 

 Descriptive name: Broad St. at Front St. 

 Stop ID: 7890. 

• Service provider ID:12. 

• Route ID: 10. 

• Vehicle ID: 2346. 

• Cost: $2.00. 

• Travel duration: 3 min; wait duration: N/A. 
157 

Source Step Key Action Comments

MMTP 

service

9 Sends MMTP trip options information 

back to the mobile device.

• Route ID: 1 (selected route). 

o Leg: 2: 

• Mode: walk (transfer). 

• Start location: 

 Lat/long: 39.9619, −83.0027. 

 Descriptive name: Broad St. at Front St. 

 Stop ID: N/A. 

• End location: 

 Lat/long: 39.96177, −83.0024. 

 Descriptive name: Front St. at Broad St. 

 Stop ID: N/A. 

• Distance: 0.1 mi. 

• Travel duration: 1 min. 

• Wait duration: 15 min. 

o Leg: 3: 

• Mode: transit. 

• Start location: 

 Lat/long: 39.96177, −83.0024. 

 Descriptive name: Front St. at Broad St. 

 Stop ID: 8000. 

• End location: 

 Lat/long: 39.96186, −83.0012 

 Descriptive name: Parsons Ave. at Gates St. 

 Stop ID: 8210. 

• Service provider ID: 12. 

• Route ID: 4. 

• Vehicle ID: 2400. 

• Cost: $2.00. 

• Distance: 3 mi. 

• Travel duration: 16 min; wait duration: N/A.
158 

Source Step Key Action Comments

MMTP 

service

9 Sends MMTP trip options information 

back to the mobile device.

• Route ID: 2 (new route). 

o Polyline (of route). 

o Total duration: 30 min. 

o Total cost: $2.00. 

o Leg: 1: 

• Mode: transit. 

• Start location: 

 Lat/long: 39.9601, −83.0170. 

 Descriptive name: N/A. 

 Stop ID: N/A. 

• End location: 

 Lat/long: 39.9624, −82.9975. 

 Descriptive name: Broad St. at Third St. 

 Stop ID: 7892. 

• Service provider ID:12. 

• Route ID: 10. 

• Vehicle ID: 2346. 

• Cost: $2.00. 

• Travel duration: 5 min.

• Wait duration: N/A.
159 

Source Step Key Action Comments

MMTP 

service

9 Sends MMTP trip options information 

back to the mobile device. 

• Route ID: 2 (new route). 

o Leg: 2: 

• Mode: walk (transfer). 

• Start location: 

 Lat/long: 39.9624, −82.9975. 

 Descriptive name: Broad St at Third St. 

 Stop ID: N/A. 

• End location: 

 Lat/long: 39.96208, −82.9980. 

 Descriptive name: Third St. at Broad St. 

 Stop ID: N/A. 

• Distance: 0.1 mi. 

• Travel duration: 2 min. 

• Wait duration: 4 min. 

o Leg: 3: 

• Mode: transit. 

• Start location: 

 Lat/long: 39.96208, −82.9980. 

 Descriptive name: Third St. at Broad St. 

 Stop ID: 8100. 

• End location. 

 Lat/long: 39.96186, −83.0012 

 Descriptive name: Parsons Ave. at Gates St. 

 Stop ID: 8210. 

• Service provider ID: 12. 

• Route ID: 4. 

• Vehicle ID: 2500. 

• Cost: $2.00. 

• Distance: 3 mi. 

• Travel duration: 19 min; wait duration: N/A. 
160 

Source Step Key Action Comments

Mobile 

device

10 Receives trip options information from

the MMTP service. 

N/A

Mobile 

device

11 Determines there is another route that

the traveler can take to get to their

destination faster. 

The mobile device compares the alternate route to using the planned 

transfer point but waiting for the next bus along the connecting line. 

Mobile 

device

12 Presents alternative trip information to

the traveler. Prompts the traveler to

select a new route or stay on the current

route. 

The mobile device compares the travel time, modes, and cost of the 

alternatives against the current itinerary.

Note: It may be possible that the fastest travel time would be to wait

for the next connecting bus at the same transfer point as the original

itinerary. However, there may be an alternative route or modes for 

the traveler to take that they would not have considered or known 

about previously. 

Traveler 13 Selects the new route. N/A 

Mobile 

device

14 Begins to provide navigation guidance

along the newly selected route. 

N/A 

Mobile 

device

15 Continuously evaluates the traveler’s

progress along the newly selected

itinerary.

Neither the original bus nor the connecting bus on the newly

selected itinerary experience any further delays. Therefore, the

mobile device does not need to utilize the MMTP service to evaluate 

alternative routes. 

Traveler 16 Makes the planned connection and 

arrives at the destination. 

N/A

To complete this scenario, six characteristics are included, along with a system diagram capturing the sources included in the scenario, 

as shown in figure 24. 
161 

Source: FHWA. 

Figure 24. Diagram. Use Case 3—Scenario 2, sources. 
162 

The following characteristics complete Use Case 3—Scenario 2: 

• Postconditions—The mobile device would provide the traveler with timely alternative 

route information that allows the traveler to arrive at the destination sooner than they 

would have while waiting for the next connecting bus on the originally planned route. 

• Messages—The message types would include trip request messages, trip options 

messages. 

• Traceability—The following user needs would apply to this scenario: 

o Transit UN1—Continuous Efficient Route Check. 

o Transit UN2—Trip Planning Service Access. 

• Mobile device inputs summary—Inputs would include MMTP options (from travelers), 

select trip options (from travelers), and trip options messages (from the MMTP service).

• Mobile device—The mobile device would send trip request messages (to the MMTP 

service). 

• Outputs summary—Outputs would include audio/visual notifications to the traveler

about alternative trip information. 

Use Case 3—Scenario 3 

Use Case 3—Scenario 3 describes a traveler using public transit while using a connected mobile 

device. This scenario is identified and titled “UC3-S3: Transit Connection Protection” with the 

following characteristics:

• Short description—A traveler (transit user) would use a mobile device to confirm they 

are taking a transit trip. The transit agency servicing this trip would use the confirmation 

to provide connection protection after the first leg of a two-leg transit trip is delayed. 

• Scenario objective—To demonstrate the ability of the mobile device to enable 

connection protection.

• Operational Event(s)—The operational events would take place in the following order: 

o The mobile device would send a confirmed route itinerary to the transit management 

system.

o When the route servicing the traveler’s first leg is delayed, the transit agency would 

enable connection protection for the connecting leg and update its real-time transit 

data to reflect this delay. 

o The mobile device would periodically assess progress along the planned route (using 

an MMTP service) to determine whether there is a more efficient route.

o The mobile device would not modify the traveler’s itinerary because of the 

connection protection implementation. 
163 

• Preconditions—A traveler (transit user) would use a mobile device to plan a trip from 

home to downtown. The trip would consist of two legs—both legs are different routes on 

the same transit system—but unforeseen congestion causes delay on the first leg. The trip 

would take place in a region where transit service is less frequent and connections 

between multiple routes are strategically planned to enable connectivity. 

• Traveler actor role—The traveler would navigate the planned itinerary safely and 

successfully. 

• Mobile device actor role—The mobile device would provide relevant wayfinding 

information to the traveler (based on the location of the mobile device in the 

transportation environment) and send and receive messages that enable the traveler’s 

needs to be met. 

• Transit vehicle in-vehicle device actor role—The in-vehicle device would release a 

transit vehicle approaching message and alert the transit vehicle operator when a stop 

must be serviced. 

• Transit vehicle operator actor role—The transit vehicle operator would service transit 

vehicle stops and monitor their surroundings for safety. 

• Nearby vehicle in-vehicle device actor role—The in-vehicle device would receive 

pedestrian location and heading and alert the driver as necessary. 

• Driver actor role—The driver would operate the vehicle safely and react to alerts from 

the in-vehicle device.

• Pedestrian signal actor role—The pedestrian signal would control traffic and pedestrian 

movements at the intersection and exchange messages that allow a mobile device to 

request a pedestrian phase.

The scenario then describes key actions and the flow of events of eight sources: traveler, transit 

vehicle, mobile device, MMTP service, transit management center, transit management agency, 

transit vehicle 1, and transit vehicle 2. Table 21 describes steps 1 through 28 of this scenario, 

with greater detail shown in figure 25 of steps 15–20. 
164 

Source: FHWA. 

Figure 25. Diagram. Use Case 3—Scenario 3, steps 15–20. 
165 

Table 21. Use Case 3—Scenario 3, steps 1–28. 

Source Step Key Action Comments

Traveler 1 Starts a transit trip. The traveler uses a trip planner to find a suitable transit route from

their current location to their destination.

Traveler 2 Opens the trip planning application

on the mobile device and enters trip

details.

The traveler provides trip details, including origin (automatically

populated with current location), destination, preferred mode, and so 

forth.

Mobile 

device

3 Sends an MMTP trip request 

message to the MMTP service.

N/A

MMTP

service

4 Receives trip request. N/A

MMTP

service

5 Evaluates potential options based on

traveler preferences.

N/A

MMTP

service

6 Sends trip options information back

to the transit management center.

If a publicly available communications network will be used to

facilitate the connection between the mobile device and the MMTP 

service, then the MMTP service can capture the trip options easily (in

accordance terms of use established for utilizing the network). 

Otherwise, this step will require an established relationship between

the MMTP service and the transit management center or driver

incentivization through a reduction in fare or another incentive (such

as connection protection).

MMTP

service

7 Sends MMTP trip options 

information back to the mobile 

device.

N/A

Mobile 

device

8 Receives trip options information

from the MMTP service.

N/A

Mobile 

device

9 Presents transit route information to

the traveler. Prompts the traveler to

select the route and begin navigation.

The mobile device shows the selected route, which includes a single 

transfer.

Traveler 10 Confirms route by using a mobile 

device.

N/A
166 

Source Step Key Action Comments

Mobile 

device

11 Begins to provide navigation 

instructions to the traveler.

The mobile device is presumably in a location where it can be easily

seen and heard by the traveler, such as in the traveler’s hand, pocket, 

or backpack. The traveler may be using headphones to make it easier

to hear audio outputs from the mobile device.

Mobile 

device

12 Sends confirmation of route choice to

the transit management center.

N/A

Transit

management 

center

13 Receives route choice data. The transit management center uses route choice confirmation to

enable connection protection for this trip. The transit management 

center may require a certain minimum number of requested

connections before providing connection protection. 

Note: The transit management agency would take the itinerary 

information and uses it for management activities (e.g., dynamic transit 

operations, connection protection) that are available to the managing 

agency. The archived data could be used for long-term planning 

studies, O/D studies, and transit demand to influence route design and 

choice.

Traveler 14 Onboard transit vehicle 1. The traveler uses the itinerary to make a connection to another bus 

line. The itinerary, which is based on real-time transit data,

anticipates a 5-min window for the traveler to make the connection.

Transit

vehicle

15 Encounters unexpected congestion 

along the route.

This congestion adds 10 min to the transit vehicle’s typical travel

time.

Transit

management 

agency

16 Continuously evaluates the progress 

of the two buses.

As the bus (first leg) sits in traffic, the transit management agency

compares its position against its anticipated position.

Transit

management 

agency

17 Determines that the traveler will miss

the connection as planned in the 

selected itinerary.

Once the bus falls 5 min behind schedule of the planned itinerary, the 

transit management agency determines that the connection cannot be 

reliably made.
167 

Source Step Key Action Comments

Transit

management 

agency

18 Sends a notification to the transit

vehicle (second leg) to wait until a 

specified time (after the bus servicing

the first leg arrives).

The transit management agency intermittently evaluates the progress 

of the transit vehicle (first leg) and provides updates to the transit

vehicle (second leg). The transit management agency may decide not 

to provide connection protection if the amount of time the transit

vehicle (second leg) would have to wait exceeds a certain threshold. 

Note: The transit agency would update the “connection protection” 

status of the transit vehicle (second leg) in its real-time transit feed.

Mobile 

device

19 Continuously receives real-time

transit data and evaluates the 

traveler’s progress along the selected

itinerary.

N/A

Mobile 

device

20 Updates the traveler regarding the

trip status.

The mobile device indicates that connection protection would be 

provided for the next transfer and updates the anticipated arrival time

to reflect the delay.

Transit

vehicle 1

21 Continues along route. N/A

Transit

vehicle 2

22 Arrives at connection stop. Transit vehicle 2 stops and waits for transit vehicle 1 to arrive to the 

connecting stop.

Transit

vehicle 1

23 Arrives at connection stop. No further delays are experienced.

Traveler 24 Alights transit vehicle 1, navigates to

transit vehicle 2, and boards transit

vehicle 2.

N/A

Transit

vehicle 2

25 Leaves the connection stop after all

passengers have made transfer.

The transit management agency may also provide the number of 

passengers making transfer to ensure that the transit vehicle operator 

knows that all transferring passengers are accounted for.
168 

Source Step Key Action Comments

Transit

vehicle 2

26 Continues to service the trip of the 

traveler

N/A

Mobile 

device

27 Continuously evaluates the traveler’s

progress along the newly selected

itinerary.

Neither the bus nor the connecting bus on the newly selected itinerary

experience any further delays.

Traveler 28 Arrives at destination. N/A

O/D = origin-destination.

To complete this scenario, six characteristics are included, along with a system diagram capturing the sources included in the scenario, 

as shown in figure 26. 
169 

Source: FHWA. 

Figure 26. Diagram. Use Case 3—Scenario 3, sources. 
170 

The following characteristics complete Case 3—Scenario 3: 

• Postconditions—The traveler makes the planned connection and arrives at their 

destination slightly delayed. The transit management agency executes a connection 

protection holdover for Transit Vehicle 2 to allow the traveler to make the connection—

effectively accounting for the late arrival of Transit Vehicle 1. 

• Messages—The message types would include trip request messages and trip options 

information message. 

• Traceability— The following user needs would apply to this scenario: 

o Transit UN1—Continuous Efficient Route Check. 

o Transit UN2—Trip Planning Service Access. 

o Transit UN5—Connection Protection. 

• Mobile device inputs summary—Inputs would include MMTP options (from travelers) 

and trip options information messages (from the MMTP service).

• Mobile device—The mobile device would send trip request messages (to the MMTP 

service). 

• Outputs summary—Outputs would include audio/visual notifications to the traveler

about connection protection. 

Use Case 3—Scenario 4 

Use Case 3—Scenario 4 describes a traveler using public transit while using a connected mobile 

device. This scenario is identified and titled “UC3-S4: Transit En route Adjustment (Alternative 

Mode)” with the following characteristics:

• Short description—A traveler (transit user) would use a mobile device to find a better 

route to navigate to destination after the first leg of a transit trip is delayed. 

• Scenario objective—To demonstrate the ability of the mobile device to provide an en 

route adjustment (alternative mode). 

• Operational event(s)—The operational-related events would take place in the following 

order: 

o The mobile device would periodically assess progress along the planned route (using 

an MMTP service) to determine whether there would be a more efficient route.

o The mobile device would send a notification to the traveler when a more efficient 

route becomes available.
171 

• Preconditions—The traveler (transit user) would use a mobile device to plan a trip from 

home to downtown. The trip would consist of a single transit leg, but unforeseen 

congestion causes delay. The traveler would have indicated (provided input to the mobile 

device) that they would prefer to use transit, bikeshare, and shared electric scooters to 

complete their trip.

• Traveler actor role—The traveler would navigate the planned itinerary safely and 

successfully. 

• Mobile device actor role—The mobile device would provide relevant wayfinding 

information to the traveler (based on the location of the mobile device in the 

transportation environment) and send and receive messages that enable the traveler’s 

needs to be met. 

The scenario then describes key actions and the flow of events of six sources: traveler, transit 

vehicle, mobile device, MMTP service, transit management center, and transit management 

agency. Table 22 describes steps 1 through 51 of this scenario with greater detail shown in 

figure 27 of steps 17–26. 

Source: FHWA. 

Figure 27. Diagram. Use Case 3—Scenario 4, steps 17–26. 
172 

Table 22. Use Case 3—Scenario 4, steps 1–51. 

Source Step Key Action Comments

Traveler 1 Starts a transit trip. The traveler uses a trip planner to find a suitable transit route 

from their current location to their destination. 

Traveler 2 Opens a trip planning application on a 

mobile device and enters the trip details.

The trip details include origin (automatically populated with 

current location), destination, preferred mode, and so forth. 

Mobile 

device

3 Sends an MMTP trip request message to 

the MMTP service. 

N/A

MMTP 

service

4 Receives trip request. N/A

MMTP 

service

5 Evaluates potential options based on 

traveler preferences. 

N/A

MMTP 

service

6 Sends trip options information back to the 

transit management center. 

If a publicly available communications network will be used to 

facilitate the connection between the mobile device and the 

MMTP service, then the transit management center can easily 

capture the trip options (in accordance with terms of use 

established for utilizing the network). Otherwise, this step will 

require an established relationship between the MMTP service

and the transit management center or driver incentivization 

through a reduction in fare or other incentives (such as 

connection protection).

MMTP 

service

7 Sends the MMTP rip options information 

back to mobile device. 

N/A

Mobile 

device

8 Receives trip options information from 

MMTP service. 

N/A

Mobile 

device

9 Presents transit route information to the 

traveler. Prompts the traveler to select the 

route and begin navigation. 

The mobile device shows the selected route, which includes a 

single transfer.

Traveler 10 Confirms route by using mobile device. N/A
173 

Source Step Key Action Comments

Mobile 

device

11 Begins to provide navigation instructions 

to the traveler. 

The mobile device is presumably in a location where it can be 

easily seen and heard by the traveler, such as in the traveler’s 

hand, pocket, or backpack. The traveler may be using 

headphones to make it easier to hear audio outputs from the 

mobile device. 

Mobile 

device

12 Sends confirmation of route choice to the 

transit management center. 

The route choice confirmation message contains the following 

content: 

• Trip ID.

• Route ID.

Transit 

management 

center

13 Receives route choice data. The transit management agency uses route choice confirmation 

to enable connection protection for this trip. 

Note: The transit management center could require a certain 

minimum number of requested connections before providing 

connection protection. The transit management agency would 

take the itinerary information and use it for management 

activities (dynamic transit operations, connection protection, 

etc.) that would be available to the managing agency. Archived 

data could be used for long-term planning studies, O/D studies, 

and transit demand-influencing route design and choice.

Traveler 14 Onboard transit vehicle 1. The traveler follows the itinerary to make a connection to 

another bus line. The itinerary, which is based on real-time 

transit data, anticipates a 5-min window for the traveler to make 

the connection.

Transit 

vehicle

15 Encounters unexpected congestion along 

the route.

This congestion adds 10 min to the transit vehicle’s typical 

travel time.

Transit 

management 

agency

16 Continuously evaluates the progress of the 

two buses.

As the bus (first leg) sits in traffic, the transit management 

agency compare its current position against its anticipated 

position.
174 

Source Step Key Action Comments

Mobile 

device

17 Determines that the traveler will 

experience extreme delay on the current 

route.

N/A

Mobile 

device

18 Begins to assess alternative routes to get to 

the selected destination.

The mobile device utilizes the MMTP service to compare 

alternative routes.

Mobile 

device

19 Sends an MMTP trip request to the MMTP 

service.

The MMTP trip request message contains the following content: 

• Trip ID: 2468. 

• Origin (lat/long or address). 

• In vehicle: yes: 

o Service provider ID: 12. 

o Vehicle ID: 1010. 

• Destination (lat/long or address). 

• Preferences: 

o Mode: transit, shared scooter. 

o Accommodations: N/A. 

o Departure/arrival time: N/A.

o Cost: N/A.

MMTP 

service

20 Receives trip request. N/A

MMTP 

service

21 Evaluates potential options based on 

traveler preferences.

The traveler’s preferences include mode, travel time, trip cost, 

and maximum walking distance.

MMTP 

service

22 Sends MMTP trip options information 

back to the mobile device. 

N/A
175 

Source Step Key Action Comments

MMTP 

service

22 Sends MMTP trip options information 

back to the mobile device. 

The MMTP trip options information message contains the 

following content: 

• Route ID: 1 (selected route). 

• Trip ID: 2468: 

o Polyline (of route). 

o Total duration: 35 min. 

o Total cost: $2.00. 

o Leg: 1: 

• Mode: Transit. 

• Start location: 

 Lat/long: 39.9705, −83.0022. 

 Descriptive name: N/A. 

 Stop ID: N/A. 

• End location: 

 Lat/long: 40.0003, −83.0080. 

 Descriptive name: High St. at 15th Ave. 

 Stop ID: 7890. 

• Service provider ID: 12. 

• Route ID: 1. 

• Vehicle ID: 1010. 

• Cost: $2.00. 

• Travel duration: 25 min. 

• Wait duration: N/A. 
176 

Source Step Key Action Comments

MMTP 

service

22 Sends MMTP trip options information 

back to the mobile device. 

• Route ID: 1 (selected route). 

o Leg: 2: 

• Mode: walk (transfer). 

• Start location: 

 Lat/long: 40.0003, −83.0080. 

 Descriptive name: Broad St. at Front St. 

 Stop ID: N/A. 

• End location: 

 Lat/long: 40.0003, −83.0189. 

 Descriptive name: N/A. 

 Stop ID: N/A. 

• Distance: 0.25 mi. 

• Travel duration: 5 min. 

• Wait duration: N/A. 
177 

Source Step Key Action Comments

MMTP 

service

22 Sends MMTP trip options information 

back to the mobile device. 

• Route ID: 2 (new route):

o Polyline (of route).

o Total duration: 30 min. 

o Total cost: $2.00. 

o Leg: 1: 

• Mode: transit. 

• Start location:

 Lat/long: 39.9705, −83.0022.

 Descriptive name: N/A.

 Stop ID: N/A.

• End location: 

 Lat/long: 39.9727, −83.0025.

 Descriptive name: High St. at Spruce St.

 Stop ID: 7892. 

• Service Provider ID:12.

• Route ID: 1. 

• Vehicle ID: 1010.

• Cost: $2.00. 

• Travel duration: 3 min. 

• Wait duration: N/A.
178 

Source Step Key Action Comments

MMTP 

service

22 Sends MMTP trip options information 

back to the mobile device.

• Route ID: 2 (new route).

o Leg: 2: 

• Mode: walk (transfer).

• Start location: 

 Lat/long: 39.9624, −82.9975. 

 Descriptive name: Broad St. at Third St.

 Stop ID: N/A.

• End location: 

 Lat/long: 39.9722, −83.0039. 

 Descriptive name: N/A.

 Stop ID: N/A.

• Distance: 0.1 mi.

• Travel duration: 2 min.

• Wait duration: N/A.

o Leg: 3: 

• Mode: shared scooter. 

• Start location: 

 Lat/long: 39.9722, −83.0039. 

 Descriptive name: N/A.

 Stop ID: N/A.

• End location: 

 Lat/long: 40.0003, −83.0189. 

 Descriptive name: N/A.

 Stop ID: N/A.

• Service provider ID: 18. 

• Route ID: N/A.

• Vehicle ID: 614. 

• Cost: $2.00. 

• Distance: 2 mi.

• Travel duration: 10 min.
179 

Source Step Key Action Comments

Mobile 

device

23 Receives trip options information from the 

MMTP service. 

N/A

Mobile 

device

24 Determines that there is another mode the 

traveler can take to get to their destination 

faster. 

The mobile device compares alternate modes to staying on the 

existing route. 

Mobile 

device

25 Presents alternative trip information to the 

traveler. Prompts the traveler to select a 

new itinerary or stay on current route. 

The mobile device shows the travel time, modes, and cost of the 

alternative route and compares that route against the current 

itinerary.

Note: It could be possible that the fastest travel time would be to 

wait for the next connecting bus at the same transfer point as the 

original itinerary. However, there could be an alternative route 

or modes for the traveler to take that they would not have 

considered or known about previously. 

Traveler 26 Selects the new route. The traveler selects a route that requires them to get off bus at 

next stop and use a shared electric scooter to complete their trip.
180 

Source Step Key Action Comments

Mobile 

device

27 Sends a shared-use device reservation 

request to the shared-use device operations 

system. 

The mobile device sends a reservation request that includes the 

traveler’s account information. This scenario assumes the 

traveler has an active account with the shared-use device 

operations center. If the traveler does not have an active account, 

they will need to create one by using the payment account 

registration message and receiving a payment account 

registration confirmation.

The shared-use device reservation request message contains the 

following content: 

• Account ID: 12345ABCDE. 

• Service provider ID (Payee ID): 777888999 (corresponds 

to the shared-use device operations). 

• Vehicle ID: 614. 

• Requested period: 5 min. 

Shared-use 

device 

operations 

system

28 Receives the shared-use device reservation 

request from the mobile device.

The shared-use device operations system agrees to allow a 

“reserve” to be placed on a shared electric scooter for a 

predetermined period. The MMTP ensures that the traveler can

navigate to the shared electric scooter during this predetermined

period. 

Note: In a scenario where the shared-use device operations 

system does not accommodate reservations, the mobile device 

would continue to evaluate route options and provide the 

traveler with an updated route option if the availability of 

shared-use devices changes.

Shared-use 

device

operations 

system

29 Sends the reservation to the shared electric 

scooter.

N/A
181 

Source Step Key Action Comments

Shared 

electric 

scooter 

30 Receives the reservation. N/A

Traveler 2 31 Locates the shared electric scooter 614 

during the reserved period. 

N/A

Traveler 2 32 Uses a mobile device to attempt to unlock 

the shared electric scooter. 

In most cases, a traveler expects to use a mobile device to locate 

a shared electric scooter that has not been reserved and then 

reserve it for use. However, this scenario accounts for a case in 

which a traveler finds a shared electric scooter and decides to 

ride it before checking to see whether it is available.

Mobile 

device 

(traveler 2)

33 Sends a payment user ID message to the 

shared electric scooter. 

The payment user ID contains the following content: 

• Payee ID: 777888999 (corresponds to toll payment 

system). 

• Account ID: ABCDE12345.

Shared 

electric 

scooter 

34 Receives the payment user ID message 

from the mobile device.

The shared electric scooter determines that the account ID does 

not match the account ID of the reservation. 

Shared 

electric 

scooter 

35 Sends a payment user confirmation 

message back to traveler 2’s mobile device 

to indicate that it is reserved. 

The payment user confirmation message may include the 

amount of time left during the reservation period.
182 

Source Step Key Action Comments

Shared 

electric 

scooter 

36 Sends a payment user confirmation 

message back to traveler 2’s mobile device 

to indicate that it is reserved shared-use 

device unlock response message.

The payment user confirmation message may include the 

amount of time left during the reservation period.

The shared-use device unlock response message contains the 

following content: 

• Payee ID: 777888999 (corresponds to shared-use device 

payment system). 

• Account ID: ABCDE12345.

• User status: denied/reserved.

Mobile 

device 

(traveler 2)

37 Notifies traveler 2 that the shared electric 

scooter they are attempting to unlock has 

been reserved. 

N/A

Traveler 2 38 Finds another scooter to reserve/use. N/A

Mobile 

device

39 Continues to provide navigation 

instructions to the traveler. Notifies the 

traveler when they are approaching the 

stop. 

N/A

Traveler 40 Alights the transit vehicle and navigates to 

the location of the shared electric scooter. 

N/A

Mobile 

device

41 Determines that the traveler is near the 

shared electric scooter.

N/A

Mobile 

device

42 Prompts the traveler on whether they have 

identified the reserved shared electric 

scooter. 

N/A

Traveler 43 Confirms that they have identified the 

shared electric scooter. 

Traveler stands next to shared electric scooter.
183 

Source Step Key Action Comments

Mobile 

device

44 Sends a payment user ID message to the 

shared electric scooter. 

The payment user ID message contains the following content: 

• Payee ID: 777888999 (corresponds to shared-use device 

payment system). 

• Account ID: 12345ABCDE.

Shared 

electric 

scooter 

45 Receives the payment user ID message 

from the mobile device. Determines 

account ID matches the reservation and

becomes unlocked. 

N/A

Shared 

electric 

scooter 

46 Sends a payment user confirmation 

message back to mobile device to indicate 

that it is unlocked. 

The payment user confirmation message contains the following 

content: 

• Payee ID: 777888999 (corresponds to shared-use device 

payment system). 

• Account ID: 12345ABCDE. 

• User status: confirmed.

Mobile 

device

47 Receives an unlock indication. N/A

Mobile 

device

48 Notifies the traveler that the shared electric 

scooter has been unlocked. 

Notification: Unlocked—Ready for service. Ride safely. 

Traveler 49 Receives notification and uses shared 

electric scooter to navigate to final 

destination.

N/A

Traveler 50 Arrives at final destination. Uses mobile 

device to indicate that they have completed 

the trip on the shared electric scooter. 

N/A
184 

Source Step Key Action Comments

Mobile 

device

51 Sends shared-use device end trip message 

to the shared electric scooter. 

The shared-use device end trip message contains the account ID: 

ABCDE12345. 

Alternatively, the traveler may use a physical button on the 

shared electric scooter to indicate the trip has ended.

Shared 

electric 

scooter 

52 Receives an end trip message and sends 

this information to the shared-use device 

operations system. 

N/A

Shared-use 

device 

operations 

system

53 Determines the total cost of the 

shared-mobility device trip. 

The shared-use device operations system typically determines 

the cost of trip by using a fixed cost plus a per-minute usage 

rate.

Note: The cost could include a discount if there is an agreement 

between the transit agency and scooter-share agency. For 

instance, if a cumulative usage is determined to be $2.00. The 

traveler’s account would be charged. 

To complete this scenario, six characteristics are included, along with a system diagram to capturing the sources included in the 

scenario, as shown in figure 28. 
185 

Source: FHWA. 

Figure 28. Diagram. Use Case 3—Scenario 4, sources. 
186 

The following characteristics complete Use Case 3—Scenario 4: 

• Postconditions—The traveler would use a mobile device to find a better route to 

navigate to the destination after the first leg of a transit trip is delayed. 

• Messages—The message types would include trip request messages, trip options 

messages, route choice messages, shared-use device reservation request messages, and 

shared-use device end trip messages. 

• Traceability—The following user needs would apply to this scenario: 

o Transit UN1—Continuous Efficient Route Check 

o Transit UN2—Trip Planning Service Access.

• Mobile device inputs summary—Inputs would include MMTP input (from travelers), 

trip options information messages (from the MMTP service), and shared-use device 

unlock response messaged (from a shared-use device). 

• Mobile device—The mobile device would send trip request messages (to the MMTP 

service), route choice messages (to MMTP), shared-use device reservation request 

message (to the share-use device operations system), shared-use device unlock requests 

(to a shared-use device), and shared-use device end trip message (to a shared-use device).

• Outputs summary—Outputs would include audio/visual notifications to the traveler

about alternative trip information. 
187 

CHAPTER 11. CONCEPT 4: TRAVELER RIDING IN A MOTOR VEHICLE USING A 

CONNECTED MOBILE DEVICE

CHAPTER OVERVIEW

This chapter is the final of four chapters that develop an example concept to showcase how 

mobile devices and electronic messages can be used to satisfy traveler needs. The concept in this 

chapter focuses on addressing an example set of needs for drivers using a mobile device. 

Through these example concepts, the reader can begin to understand the content included in a 

typical ConOps. A description specific to the concept is provided and walks through existing 

conditions, justification for changes, description of desired changes, operational policies and 

constraints, description of proposed operating environment, modes of operation, user classes, 

support environment, and operational scenarios. These example concepts begin to shape a system 

that enables the exchange of electronic messages with mobile devices to satisfy the needs of 

different types of travelers.

EXISTING CONDITIONS

Toll facilities require travelers to pay to use a roadway. Some toll facilities have physical toll

booths that allow a driver to stop and pay with cash or credit. These types of facilities are slowly

falling out of favor because of their high O&M costs. Other tolls facilities provide electronic toll

collection, which requires the driver to have a transponder in their vehicle. The transponder has 

an identifying feature that can be linked to the traveler’s personal information and payment 

information. Travelers use an online tool to maintain a balance on the account that is deducted as

the traveler passes through toll facilities. Toll agencies are using toll-by-plate, an increasingly

popular method by which toll agencies collect payment on facilities that do not have physical toll

booths but that want to accommodate travelers who do not have electronic toll accounts

(i.e., drivers who do not typically use the toll facility).

Toll amounts are typically provided to the traveler on physical signage along the roadway. Tolls

for some facilities are static (i.e., they never change), some tolls vary by time of the day or day of 

the week, and other tolls vary based on mitigating demand to use the facility (i.e., 

high-occupancy toll (HOT) express lanes). Facilities with variable tolls should use physical 

signage to ensure that the proper cost to use the facility is displayed to the traveler. This signage 

is typically limited to displaying two or three toll amounts (to different exit points along the 

facility) to avoid overburdening the driver with information. In some instances, the travel 

times/speeds are displayed in advance of a toll facility to give the driver time to decide whether it 

is worth the cost of using the toll facility. Most toll agencies make tolling data publicly available 

via the toll agency’s website, but these data may not be easily accessible during a trip.

Other types of signage are also located along a freeway to provide information about navigating 

the roadway network (primarily green/white signage), regulatory information (white/black/red 

signage), and warning information (yellow/black signage). A lot of thought and effort goes into the 

placement of this signage to account for the variable needs of many roadway users.

In complex segments of the roadway network, roadway engineers should avoid overloading the 

driver with too much information and locate signage far enough upstream of various decision
188 

points along the roadway to ensure that drivers who need that information have enough time to

properly react to it, and this is true for toll information as well. If is common for signage along 

freeways to provide tolling information for express lanes. Because this signage can provide 

limited information (to reduce information overload to drivers), it may be difficult for the driver 

to ascertain the actual cost of the toll for their trip. Similarly challenging, existing route planning 

tools do not always have access to real-time toll information, leaving the traveler with unknowns.

Loop detector and video detection systems allow vehicle counts and speeds to be collected. Toll

facilities that utilize toll transponders and overhead detection gantries can detect the movement 

of vehicles that have transponders as they pass through the toll facility. The more frequent the

placements of the gantries, the more detailed information that can be discerned about movements

that occur on the roadway. 

JUSTIFICATION FOR CHANGES

Several aspects of the current conditions of the roadway environment could warrant the addition 

of technology to enable communication to and from mobile devices. These aspects are discussed 

in detail in the following subheaders. 

Driving Wayfinding

The placement and use of static signage and dynamic signage along roadways is typically 

governed by the MUTCD.

(10) Many States tailor the MUTCD to create a State-specific version, 

whereas some States use the Federal version. The concept of providing drivers with appropriate 

information about hazards and inefficiencies at strategic locations and times is known as positive 

guidance. The goal is to utilize knowledge rooted in human factors and traffic engineering to 

improve highway safety and operations. 

One of the biggest drawbacks of the MUTCD (and the use of static signs and DMSs in general) is 

that they are unable to account for the speed at which a traveler is moving when they encounter a 

sign.(10) The placement of these signs depends on the amount of time it takes a driver to cover a 

given distance based on an expected speed and acceleration of the vehicle. However, if the vehicle 

is moving at a speed that is greater than the speed limit, then the driver will have less time than the 

engineers intended to react to that sign. Alternatively, at slower speeds, there may be too much 

time, resulting in expectancy issues. Ideally, signage information is displayed to the driver at a time 

and location that corresponds to their current speed. Another drawback of static signage and 

DMSs is that drivers may have to read and interpret information that may apply to them.

Provision of Toll Facility Information and Payment 

Regulatory signs at managed lanes and toll facilities should address pricing, vehicle eligibility, 

hours of service, and possibly enforcement. However, the potential for information overload is 

greater with guidance signs, especially if a complex operational strategy is in place. The

information shown on these signs must account for the various conditions under which a driver 

could arrive to the facility. Toll agencies maintain a matrix of tolling information for every 

allowable combination of entry and exit points along the facility to use for determining what 

information to display to drivers at different locations along the facility. For example, in an 

express lane facility with multiple access and egress locations, the tolling agency should 
189 

determine which combinations of access and egress locations to provide tolling information. Due

to this limitation, the driver may not receive the data needed for their specific trip (with a specific

access/egress pair). Most tolling agencies provide the cost for the driver to use the next segment

as it is approached by the driver. Some drivers need to add the cost of these segments up as they 

drive along the corridor to determine the specific cost of their trip.

Driving trip planners are unable to leverage toll information for the following reasons: 

• Drivers have to slow down to make payments at physical toll booths, and physical toll

booths are expensive for tolling agencies to operate and maintain.

• Some drivers do not have electronic toll accounts—especially drivers who do not 

typically use the toll facility or are driving in an unfamiliar area.

Data Collection for Traffic Management 

Many current traffic detection technologies are location based. That is, these technologies can

detect vehicles at a location, and they have several other attributes such as detecting speed. The

collection of vehicle movement data along a broader stretch of roadway would allow for more

complex analyses to be performed and greatly enhance the ability of traffic management 

agencies to manage traffic along the roadway using any number of strategies at hand. 

Furthermore, the ability to use detection data to predict future conditions would be limited 

because of the real-time nature of the collection process. Although simulations (running in near

realtime) that use these data could provide a certain degree of predictive capability, it would be 

difficult to make assumptions regarding increases and decreases in demand that would also affect

future conditions. As drivers utilize trip planning services to determine the most efficient route to 

service their trip, it would be advantageous for management agencies to receive and utilize these

planned trip data to predict future conditions more effectively to proactively manage the roadway 

network. The traveler may be hesitant to share planned trip information but may be more open to

the idea if incentives are provided (in the form of a shorter trip time or as a discount for using toll

facilities).

DESCRIPTION OF DESIRED CHANGES

Examples of driver user needs are provided in table 23, followed by mobile device-based

applications that could address these needs.
190 

Table 23. Driver user needs. 

User Need 

ID Title Description

Driver UN1 Roadway Signage A driver needs spatially and temporally relevant

roadway signage information.

Driver UN2 Customized Travel

Information

A driver needs traveler information customized to a

predetermined route (i.e., does not need information

that does not pertain to them).

Driver UN3 Toll Information A driver needs tolling information for toll facilities that

could be used to get to their destination when using a 

personal vehicle.

Driver UN4 Travel Time

Comparison

A driver needs a method of knowing how much travel

time will be saved by using a toll facility.

Driver UN5 Toll Facility Payment A driver needs a method to pay for tolls.

Rolling Toll Account Registration and Toll Payment

As electronic toll collection increases in popularity (to reduce system inefficiencies caused by 

staffed toll plazas), there is an opportunity for mobile devices to facilitate payment on toll 

facilities. As a driver passes through a toll facility, they are either charged a one-time fee or they 

are detected when they enter and exit the facility and are charged based on the distance traveled 

upon exiting the facility. As the driver passes a payment location, electronic messages could be 

exchanged between the toll facility and the mobile device in the vehicle to provide the mobile 

device with the charge, and the mobile device could provide the toll facility with payment 

information so that the driver’s account can be charged. This process would require the driver to 

enter payment information into a mobile device that has been authorized to be used to make 

mobile payments. One potential benefit of using a mobile device to facilitate toll facility

payments would be that it could be standardized across toll systems that currently do not have 

compatible toll tag detection systems.

Tailored Roadway Signage 

The mobile device would be able to tailor the location and time at which signage information is

displayed to a driver based on the driver’s speed and location. It would be further able to reduce 

confusion that could be experienced by drivers by only displaying signage information relevant

to the driver based on their selected route, as determined by a trip planning service.

Provision of Toll Facility Information

This use case would allow a mobile device to present tailored information to the driver to ensure 

that only the travel time and tolling information relevant to a selected route (as determined by a 

trip planner) would be presented to the driver. Furthermore, a mobile device would allow all 

information to be arranged and displayed simultaneously to reduce the burden on the driver of 

remembering information placed periodically along the freeway.
191 

Capturing Traveler Decisions for Use in Traffic Management Activities.

Using data from CVs for traffic management is a growing area of interest among traffic 

managers to supplement traffic conditions data collected from other existing ITS equipment. 

Probe data would become more available as the number of vehicles and handheld mobile devices 

that can communicate these probe data increases. This increase in data availability would result 

in an expansion of access to high-quality, real-time, multimodal transportation data captured 

from CVs, mobile devices, and infrastructure methods for capturing decisions made by travelers 

while in the process of traveling. Furthermore, various wireless communications technologies 

can provide multiple methods for a mobile device to access multimodal trip planning services,

which would improve the ability for system managers to capture data contained in interactions

between travelers and a trip planning service.

Data captured from the mobile devices of drivers could be input to a process that transforms 

disaggregate data collected from all drivers using the travel planning service (along with other 

real-time and historic data sources) into an advanced prediction of future conditions. These data 

could be used to proactively manage the system using any number of strategies available to the 

traffic management agency, which may include, but would not be limited to, adjusting express 

lane tolls, implementing lane control, adjusting ramp meter timing, and adjusting a variable 

speed limit.

Priorities Among Changes 

This section prioritizes user proposed functionality presented in the previous subsection. This

prioritization would be typically done by classifying each possible change as essential, desirable,

or optional. The classification method used would be determined by each deploying agency. 

Functions related to safety or other high-priority needs would be considered as essential, whereas

desirable functions would provide enhanced functionality but would not be necessary for the 

system to meet user needs. Optional needs would be generally limited to needs that would be 

discretionary in nature. Prioritizing user needs would be a subjective practice and would vary 

from agency to agency and from region to region. 

Changes Considered But Not Included

This section identifies changes and new features considered but not included and the rationale for 

not including them. Not including certain features could be due to implementation difficulties, 

technology limitations, or other systems’ ability to adequately meet the needs of users. 

Consideration of changes that were considered but not included would vary from agency to 

agency and from region to region.

Assumptions and Constraints

This section lists assumptions and constraints that would (or could) limit how the system could 

be designed and implemented. The following examples describe common assumptions and 

constraints could affect the design of the proposed system:

• Communications, technology, hardware, or software availability. 

• Off-the-shelf technology procurement (as opposed to the development of a new device). 
192 

• Operational policies and constraints.

• Existing laws and regulations (e.g., governing the operations of motor vehicles,

pedestrians, and bicyclers on the roadways). 

PROPOSED OPERATING ENVIRONMENT

As discussed in previous chapters, sharing and using electronic messages with connected mobile 

devices can be described as systems that work together. For this concept, this environment 

includes a mobile device, a GNSS, a TMC, and a toll operations center.

Figure 29 illustrates a systems diagram for this concept. The interfaces, hardware, messages, and 

facilities and external systems that comprise this figure are discussed in detail in the proceeding

subsections.

Source: FHWA. 

Figure 29. Diagram. Mobile device driver system. 

Interfaces

The TMC would provide roadway signage information and the toll operations center would 

provide the toll matrix message to the mobile device. The mobile device would receive both 

messages before the traveler reaches the location where the information would be needed. The 

mobile device and the toll payment system would exchange payment messages. Payment

registration (with the toll payment system) would be completed before the traveler uses the tolled

facility, whereas the payment user ID would be exchanged as the traveler enters and exits the 

facility and could be collected intermittently as the traveler uses the facility.
193 

Hardware 

The following hardware would need to be provided to enable this concept:

• Mobile device—The mobile device would be a self-contained apparatus that wirelessly

sends and receives messages, receives data from its onboard sensors, has a processor to

execute functions, and has an HMI that allows it to receive input from and provide output 

to the pedestrian (audio/visual/haptic). The mobile device would receive highway signage 

information and toll information messages, and the mobile device would position itself in

the roadway environment to determine what signage would be around it or when it would 

be approaching a toll facility. If the traveler’s route is known, the mobile device could 

tailor information (signage and toll information) displayed to the traveler according to the 

route. A mobile device that uses a toll facility would send a payment information

message to RSE along the corridor so that the traveler can be charged for the trip taken

along the toll facility.

• RSE—The RSE would be capable of wireless communications with a mobile device 

(method not specified), would contain a processor to execute functions, and would be 

backhaul connected to a TMC. The RSE located intermittently in advance of and along a 

toll facility would receive toll data from the tolling management center and would 

generate and broadcast the toll information message. Other RSE along the roadway 

network would receive signage data from the TMC, would generate highway signage 

information messages, and broadcast it. The RSE would receive payment information 

messages and would forward them to the toll payment facility.

Messages

The following messages would be needed to enable this concept: 

• Toll information message—The toll information message would convey toll

information for a single toll facility or multiple connected toll facilities. The toll

information would consist of a matrix of tolls that would account for all possible travel

options between entrance and exit points. Various toll amounts would be provided for

different vehicle classes and special discounts would be available for toll tag-pass

holders. The message would also contain the name, location, and direction of the toll

facility access points, among other characteristics that would locate and identify the

entrance and/or exit point. The message would also contain the period over which the 

posted toll would be active, which would enable a tolling management agency to update 

the toll amount on actively managed facilities.

• Highway signage information message—The highway signage information message

would contain information about MUTCD-compliant signage that would be on overhead 

signs and on the roadside.(10) The message would not contain the geometry of the sign 

itself but would contain a code that represents each sign. These codes could correspond to 

the codes presented with each sign in the MUTCD.

(10) Information in the message would 

contain specific information for each sign such as a highway number, a speed limit value, 

an exit number, or a distance. In a location where multiple signs would be shown, 
194 

additional data would be needed to specify how signs are displayed with respect to one 

another. Such data could be appropriate to consider for inclusion in the SAE International

J2354 standard, which describes standardized medium-independent messages needed by 

information service providers for advanced traveler information systems.

(25)

• Payment account registration message—The payment account registration message 

would be sent from a mobile device to an agency’s payment system for the purpose of 

registering payment information and associating that payment information with a traveler. 

This message would contain the traveler’s payment account information (e.g., card/account 

number, name, billing address), agency payment identifier, and an account activation 

period. This message would be sent only when the mobile device would not have an active 

registration with the payment system for a given agency providing a service the traveler 

intends to use.

• Payment account confirmation message—The payment account confirmation message

would be sent to the mobile device after an agency’s payment system has determined

whether a valid method of payment has been provided (the registration was successful or

not). Information in this message would include the payment status, an account ID, and a 

date of expiration for the account activation period. This account ID would be used in all

future transactions between the mobile device and the payment service with which the 

mobile device would be registered until the end of the activation period (at which time,

the payment account must be reactivated).

• Payment user ID message—The payment user ID message would be sent from the 

mobile device to pay for services after a payment account has been registered. This

message would contain the intended payment system ID along with the travelers account 

ID. No payment information would be exchanged. 

• Payment user confirmation message—The payment user confirmation message would 

be sent in response to the payment user ID message, and it would contain the payment 

system ID, the account ID, and payment confirmation status.

Facilities and External Systems

The following external systems would be needed to enable this concept: 

• Toll management center—The toll management center would be responsible for 

managing the toll facility and would set tolls, which could be static, vary by time of 

day/day of week, or vary in realtime based on demand. Toll data would be sent to RSE in 

the vicinity of the toll facility. Toll information would need to be updated on a continuous 

basis to reflect real-time conditions.

• Toll payment facility—The toll payment facility would receive payment information

from RSE in the vicinity of toll facilities. This payment data would be used to charge the

traveler for a trip taken on the toll facility.
195 

• TMC—The TMC would receive signage inputs from traffic management staff and would 

forward this signage data to RSE near the actual location of the signage.

MODES OF OPERATION

Mobile devices are intended to complement existing methods of providing toll and signage 

information, and payment for utilizing a toll facility. Information and notifications provided to

the traveler are expected to improve the ability to make informed decisions and mobility of

mobile device users. Mobile devices are not intended to override existing methods of receiving

information or payment. If the mobile device-based system experiences nonnormal modes of 

operations, the mobile device user would have to rely on existing methods of receiving signage 

or tolling information and for making a payment to use the toll facility. (This situation could 

preclude the traveler from using the facility.) Various issues that could result in nonnormal

operations are provided in general context in chapter 8, Modes of Operation. 

USER CLASSES AND INVOLVED PERSONNEL

The primary user class would be the traveler (driver). The traveler would carry a mobile device 

in their personal vehicle to provide mobility benefits. The traveler would be responsible for 

processing roadway signage information, determining what information displayed on the signage 

would be applicable to them, and responding to this information as necessary. When presented

with the option to use a parallel toll facility, the traveler would need to know the requirements to

use the facility, the cost to use the facility, and the benefit of using the facility. If the traveler

uses the toll facility, the traveler would be the responsible for making a payment to use the 

facility. (This payment process could involve the traveler establishing an account before use.) 

SUPPORT ENVIRONMENT

The toll agency would be responsible for the following actions: 

• Determining and implementing tolls for a HOT facility or other tolled facility. 

• Maintaining communications equipment that allows for electronic toll collection. 

• Making real-time toll matrix data publicly available so that data can be used for trip 

planning purposes. 

• Managing the collection of tolls. 

The local transportation agency/TMC would be responsible for the following actions: 

• Maintaining and operating ITS/communications hardware on the roadside: 

o Traffic signal controller. 

o Roadside communications. 

• Managing intersection geometry data. 

• Maintaining roadway signage inventory. 
196 

OPERATIONAL SCENARIOS

The operational scenarios in this section intentionally contain details that are typically beyond 

the scope of what would be necessary for ConOps, such as including the functions carried out by 

each component, detailing the sending and receiving of messages, and revealing the content of 

those messages. This level of detail would be typically found in subsequent SE documentation. 

However, in this concept, this additional detail is included to provide the reader with additional 

context about how such a system could work and how messages can be used to enable the use 

case to underscore the theme of sharing electronic messages with mobile devices to satisfy the 

needs of different types of travelers.

Use Case 4—Scenario 1

Use Case 4—Scenario 1 describes a traveler riding in a motor vehicle while using a connected 

mobile device. This scenario is identified and titled “UC4-S1: Roadway Signage and Toll 

Facility” with the following characteristics:

• Short description—A traveler (transit user) would use a mobile device to receive 

notifications regarding roadway signage that would be tailored to a planned route. The 

mobile device would also provide information about parallel managed-lane facilities and 

would facilitate payment on an ad-hoc basis (i.e., would not require the traveler to 

preregister) if the traveler decides to use the facility.

• Scenario objective—To Demonstrate the ability of the mobile device to provide the 

following options: 

o Receive tailored roadway signage information. 

o Pay for use of toll facility. 

o Capture traveler decisions for use in traffic management activities. 

• Operational event(s)—The functioning-related events would take place in the following 

order: 

o The mobile device would receive roadway signage information as the vehicle moves 

along the roadway. 

o The mobile device would assess the traveler’s planned route to determine which 

roadway signage could be shown to the traveler. 

o The mobile device would provide information regarding parallel toll routes (e.g., toll 

amount, travel time, occupancy requirements) that would be specific to the traveler’s 

planned route. 

o The mobile device would provide payment information to the tolling payment system 

to ensure that the traveler could be billed for a trip taken to the toll facility. 

• Preconditions—A business traveler would return to an airport to catch a flight. They 

would a rental car and would return the car to a facility at the airport (i.e., the business 

traveler would not have the option of taking another mode). The traveler would have 

entered payment information when the mobile device was initialized.
197 

• Traveler actor role—The traveler would efficiently navigate the roadway with 

knowledge of alternative options. 

• Mobile device actor role—The mobile device would provide relevant signage 

information to the traveler (based on the location of the mobile device in the 

transportation environment) and would send and receive messages that would enable the 

traveler’s needs to be met.

• RSE role—The RSE would facilitate the provision of information to/from the mobile 

device. 

The scenario then describes key actions and the flow of events of six sources: traveler, mobile 

device, MMTP service, TMC, general, and RSE. Figure 30 and table 24 describe steps 1 through 

26 of this scenario, table 25 further describes steps 27 through 37 as detailed in figure 31, and 

table 26 describes steps 38–41. 

Source: FHWA. 

Figure 30. Diagram. Use Case 4—Scenario 1, steps 23–26.
198 

Table 24. Use Case 4—Scenario 1, steps 1–26. 

Source Step Key Action Comments

Traveler 1 Starts a driving trip from a meeting location to the 

airport. 

The traveler uses a trip planner to find a suitable driving 

route from their current location to the airport.

Traveler 2 Opens trip planning application on mobile device

and enters trip details.

The trip details include origin (automatically populated 

with current location), destination, preferred mode, and so 

forth.

Mobile 

device

3 Sends MMTP trip request message to MMTP 

service.

The MMTP trip request message contains the following 

content: 

• Trip ID: 1357. 

• Origin (lat/long or address). 

• In vehicle: no: 

• Destination (lat/long or address). 

• Preferences: 

o Mode: driving. 

o Accommodations: N/A. 

o Departure/arrival time: N/A. 

o Cost: N/A.

MMTP 

service

4 Receives trip request message. N/A

MMTP 

service

5 Evaluates potential options based on inputs and 

traveler preferences. 

N/A

MMTP 

service

6 Sends trip options information back to the TMC. If a publicly available communications network is used to 

facilitate the connection between the mobile device and 

the MMTP service, then the MTTP service can capture 

this information easily (in accordance with terms of use 

established for utilizing the network). Otherwise, this 

process will require an established relationship between 

the MMTP service and the TMC, or a driver 

incentivization through a reduction in toll, or another 

incentive. 
199 

Source Step Key Action Comments

MMTP 

service

7 Sends trip options information back to mobile 

device. 

The MMTP trip options information message contains the 

following content: 

• Trip ID: 1357. 

• Route ID 1: 

o Start location (lat/long or address). 

o End location (lat/long or address). 

o Polyline (of route). 

o Leg 1. 

• Mode: driving. 

• Service provider ID: N/A. 

• Vehicle ID: N/A. 

• Cost: N/A. 

• Payee ID: N/A. 

• Distance: 15 mi.

• Duration: 50 min. 

Mobile 

device

8 Receives trip options information from the 

MMTP service. 

N/A

Mobile 

device

9 Presents driving trip information to the traveler.

Prompts the traveler to confirm the route and 

begin navigation. 

N/A

Traveler 10 Confirms route by using mobile device. N/A

Mobile 

device

11 Begins to provide navigation instructions to the 

traveler. 

The mobile device is presumably in a location where it

can be easily seen and heard by the traveler, such as on a 

dash mount or windshield-mount device. The driver does 

not hold the mobile device in-hand while driving. 
200 

Source Step Key Action Comments

Mobile 

device

12 Sends route choice confirmation message to the 

TMC. 

The route choice confirmation message contains the 

following content: 

• Trip ID: 1357. 

• Route ID: 1.

TMC 13 Receives route choice data. The TMC uses route choice confirmation to predictively 

analyze future traffic conditions. The TMC can 

preemptively enable strategies at hand to proactively 

manage traffic along select corridors.

Note: The tolling agency and the traffic management 

agency would take the express lanes itinerary information 

and use it for management activities (e.g., adjust variable 

speed limit adjustment, ramp meter adjustment, 

implement integrated corridor management strategy, 

adjust lane control) that would be available to the 

managing agency. Archived data could be used to conduct 

long-term planning studies, to perform O/D studies, and to 

understand how driver behavior affects freeway 

throughput. 

Traveler 14 Travels along the selected driving route. N/A
201 

Source Step Key Action Comments

Mobile 

device

15 Receives roadway signage information as the 

traveler moves along the route. 

The roadway signage information contains the following 

content: 

• Sign. 

• Type. 

• MUTCD ID.

• Prominence.

• Applicable zone (polygon). 

• Advance notification zone (polygon). 

Note: To conserve bandwidth, the mobile device would 

receive information about signage only within a given

radius of the vehicle or within a given radius of the 

expected forward path of travel. 

Mobile 

device

16 Assesses the vehicle location and path of travel

with respect to the applicable time and locations 

of each sign to determine what signage is

applicable to the driver. 

The mobile device determines the relevant signage by 

assessing the selected route polyline (MMTP responses) 

and the applicable zone for signage (roadway signage 

information). 

Note: The applicable time and location for each sign 

would depend on the speed of the vehicle and the time of 

day in which it would be driving. For instance, certain

warning and guidance signage would be displayed to the 

driver at an earlier time and location for a driver moving 

at a higher rate of speed than for a driver moving at a 

lower rate of speed.

Mobile 

device

17 Displays relevant signage information to the 

driver.

The mobile device also displays signage that is not 

relevant to the driver, but that information is secondary in

importance to the signage pertaining to the driver’s

selected route. 
202 

Source Step Key Action Comments

Mobile 

device

18 Queries local roadway conditions. The mobile device intermittently checks conditions along 

the route to determine whether there is an alternative

option. 

General 19 Congestion starts to build along the route. N/A

Traveler 20 Approaches initial ingress point to a parallel

managed land facility.

The HOT lane requires payment for single-occupant 

vehicles. Tolls may vary based on traffic conditions in

general-purpose lanes.

RSE 21 Sends data about managed-lane facility. The RSE sends the managed-lane toll matrix message, 

which contains the following content: 

• Ingress location: 

o Lat/long: 38.641033, −77.287508. 

o Mile marker: 157. 

o Egress location: 1: 

• Lat/long: 38.652832, −77.281661. 

• Mile marker: 158. 

• Requirement: single occupant. 

• Cost: $1.00. 

• Express travel time: 20 min.

• General purpose lanes (GP) travel time: 35

min. 

o Egress location: 5: 

• Lat/long: 38.732394, −77.196360. 

• Mile marker: 166. 

• Requirement: single occupant. 

• Cost: $2.00. 

• Express travel time: 32 min.

• GP travel time: 46 min.
203 

Source Step Key Action Comments

RSE 21 Sends data about managed-lane facility. o Egress location: 10 (last exit): 

• Lat/long: 38.787950, −77.177165. 

• Mile marker: 170. 

• Requirement: single occupant. 

• Cost: $10.00. 

• Express travel time: 40 min.

• GP travel time: 60 min.

Note: Data would include toll and travel-time matrix 

(i.e., the toll and travel time for every ingress and egress 

combination.) 

Mobile 

device

22 Receives information about a managed-lane

facility. 

N/A

Mobile 

device

23 Alerts the driver that an express lane option is

available.

N/A

Mobile 

device

24 Provides a travel time estimate to get to the 

destination in the general-purpose lanes and in the

express lanes. 

N/A

Mobile 

device

25 Provides the amount of the toll to use the express

lanes from the traveler’s current location to the 

airport.

N/A

Traveler 26 Decides to take the express lane. The traveler decides that it would be worth the cost of the

toll to save time and get to the airport.

Note: This decision would be based on personal judgment. 
204 

Table 25. Use Case 4—Scenario 1, steps 27–37. 

Source Step Key Action Comments

Mobile 

device

27 Sends payment account registration

message to toll operations center.

The payment account registration message contains the following 

content: 

• Payment account information: 

o Account number: 1234567890123456. 

o Name: John Doe. 

o Payment billing address: 123 Main St.

• Payee ID: 444555666 (corresponds to toll payment system). 

• Account activation period: 1 d. 

Note: The traveler would have previously entered payment 

information into the mobile device when it was initialized. If multiple

payment options have been entered, the mobile device would prompt 

the traveler which payment method to use.

Toll

operations 

center

28 Receives payment account registration

message.

The toll operations center stores the payment account information

until the end of the account activation period.

Toll

operations 

center

29 Authorizes payment method. The toll operations center authorizes the payment method.
205 

Source Step Key Action Comments

Toll

operations 

center

30 Sends payment account registration

confirmation to mobile device. 

The payment account registration confirmation message contains the 

following content: 

• Payee ID: 444555666 (corresponds to toll payment system). 

• Payment status: authorized. 

• Account ID: 6F7G8H9I0J. 

• Account activation period: 1 d. 

Note: the payee ID and account ID would be used in the payment user

ID messages for all trips taken using facilities managed by the toll

agency during the account activation period (1 d). This process would 

limit the number of times account information would need to be 

exchanged. 

Mobile 

device

31 Sends an itinerary of the driver’s 

selection of the express lanes to the 

tolling agency and the traffic

management agency. 

N/A

Mobile 

device

32 Instructs the traveler to enter the 

express lanes at the next access

location. 

N/A

Traveler 33 Maneuvers to enter the express lanes. N/A

Mobile 

device

34 Notifies the traveler that they are

about to enter a tolled facility. 

Note: This would provide a traveler who may not be familiar with the

area one last opportunity to move back to the general-purpose lanes

(or to exit) to avoid inadvertently using the facility.

RSE 35 Detects the presence of the mobile 

device as the vehicle travels in the 

express lane. 

RSE would establish connectivity with the tolling agency. 

Mobile 

device

36 Sends payment user ID message to toll 

operations center. 

The payment account ID message contains the following content: 

• Payee ID: 444555666 (corresponds to toll payment system). 

• Account ID: 6F7G8H9I0J. 
206 

Source Step Key Action Comments

Toll

operations 

center

37 Sends payment user confirmation

message to mobile device. 

The payment user confirmation message contains the following 

content: 

• Payee ID: 444555666 (corresponds to toll payment system). 

• Account ID: 6F7G8H9I0J. 

• User status: confirmed. 

Source: FHWA. 

Figure 31. Diagram. Use Case 4—Scenario 1, steps 27–37. 
207 

Table 26. Use Case 4—Scenario 1, steps 38–41. 

Source Step Key Action Comments

Mobile 

device

38 Instructs the driver when they approach the egress

location for the express lane facility to continue to

stay on the route for the airport. 

N/A

Traveler 39 Maneuvers to exit the express lanes. N/A

Toll

operations 

center

40 No longer detects the presence of the mobile device 

and determines that the vehicle is no longer 

traveling in the express lane. 

N/A

Toll

operations 

center

41 Determines the total cost of the toll for the trip. The toll operations center determines the cumulative toll

to be $2.00. The traveler’s account will be charged. 

Note: Entering and/or exiting the facility at

nondesignated locations (as determined by the tolling

agency) could result in additional fees being assessed for 

improper use of the facility.

To complete this scenario, four characteristics are included, along with a system diagram to capturing the sources included in the 

scenario, as shown in figure 32. 
208 

The following characteristics complete Use Case 4—Scenario 1: 

• Postconditions—Traveler would receive toll facility information that would be 

customized for the trip they are taking: 

o Traveler would use toll facility and would pay (account would be generated on an adhoc basis, the traveler would not be required to have pre-established an account 

before using the toll facility). 

o Traveler would pay for use of parking facility. 

o TMC would receive information regarding the traveler’s planned route. This

information could be used to predict future traffic conditions and proactively apply 

traffic demand management strategies.

• Messages—The message types would include trip request messages, route options, 

selected route messages, toll lane detection messages, toll/travel time matrix messages, 

payment request messages, and payment information. 

• Traceability—The following user needs would apply to this scenario: 

o Driver UN1—Roadway Signage. 

o Driver UN2—Customized Travel Information. 

o Driver UN3—Toll Information. 

o Driver UN4—Travel Time Comparison. 

o Driver UN5—Toll Facility Payment. 

• Mobile device inputs summary—Inputs would include trip planner inputs (from the 

traveler), trip options information messages (from the MMTP), roadway signage 

information (from the TMC), and managed-lane toll matrix messages (from toll 

operations center).

• Mobile device outputs summary—Outputs would include trip request messages (to 

MMTP), route choice messages (to the TMC), roadway signage (to the driver), and toll

information (to the driver). 
209 

Source: FHWA. 

Figure 32. Diagram. Use Case 4 – Scenario 1, sources. 

211 

CHAPTER 12. CONCEPT IMPLEMENTATION

CHAPTER OVERVIEW

Implementing a mobile device information exchange capability involves more than technical 

knowledge and sound design to be successful. Leadership would be a critical aspect of the 

implementation and new technology applications (such as mobile device use) would benefit from 

the direction and support of a project champion and a technical working group. These positions 

would help organize and promote the system to build consensus among stakeholders. These 

positions would also provide the guidance to adjust the concepts and approaches that have been 

introduced and described throughout this document for local needs and conditions. SE, for 

instance, would be a framework process to guide stakeholders through a project and outreach and 

coordination to consider the local environment. Similarly, the use cases provided in this 

document are examples of what could be considered but may not be applicable to all locations. 

Supplementing this information with additional references could assist with planning, designing, 

or developing the ability to share electronic messages with mobile devices.

This chapter provides an overview of the following tactics that transportation agencies or service 

providers could implement to increase local application and improve project success:

• Identify local needs. 

• Establish a working group. 

• Identify a regional champion. 

• Integrate the system with existing systems.

CONSIDERATIONS FOR LOCAL AGENCIES

Concepts developed in chapters 8, 9, 10, and 11 consider several traveler needs to demonstrate 

the ability of a mobile device to enable the communication of information that helps travelers

make decisions before and during a trip. However, when developing concepts for a project or 

planning a study that supports sharing and using electronic messages with mobile 

device-carrying travelers, it would be important to consider the needs of local stakeholders, local

transportation infrastructure, local transportation systems as well as the constraints and enablers 

that would need to be captured and reflected in SE documentation. Local agencies could use the

concepts in chapters 8–11 as a starting point for developing SE documentation and could adapt 

the concepts, as necessary, to account for local needs and local conditions. 

Identify Local Needs

Outreach would be a crucial component to capturing local facets that would play a role in 

developing SE documentation. Both stakeholder engagement and technical working group 

meetings are types of outreach that could be performed. Systems engineers, who are responsible 

for developing documentation, would be present during stakeholder engagement and technical 

working group meetings to ensure that all input would be adequately captured throughout the SE 

process.
212 

To best capture the needs for the proposed, outreach would be conducted among potential users.

This outreach could involve one or more groups that would focus on defining the needs of 

different user classes (e.g., pedestrian, bicyclist, transit user, driver). Ideally, the needs that 

would be elicited from the focus groups would represent the needs of the entire user class. Each

stakeholder would bring a unique perspective—outreach would be performed to ensure that the 

needs elicited from all stakeholder feedback would be well-rounded. 

Establish a Working Group

A working group would be established to work through technical aspects of the proposed system.

Members of this group would ideally comprise stakeholders who would manage the system,

network components, managers of external systems that the group may interface with, and 

technical staff developing SE documentation. 

During the review of the any 

documentation, it would be important to

establish one or more review cycles to

allow for various stakeholders to provide 

input. Receiving feedback from

stakeholders would allow systems

engineers to refine content so that the

intent of stakeholders would be adequately

presented in the documentation. 

The technical working group would discuss detailed aspects of the system to meet specific needs 

of users by offering features that are applicable only to area users. Agencies that are considering 

the deployment of infrastructure to support mobile devices likely already have local

transportation systems in place that are planned to be leveraged. It would be important to

consider both the regional architecture and system architecture. Members of this group would be 

knowledgeable regarding the needs of users, the capabilities of existing systems, the abilities of 

existing systems to be modified, and the scope of improvements that could be made to enable 

communications with mobile devices.

Identify Regional Champion

More than one agency may be involved in deploying transportation technologies, especially in 

the regional context. Creating organization among these agencies would be an important factor in 

managing the project. Generally, there would be a lead agency organizing the efforts of the other

involved agencies to achieve the common goal of developing a mobile device-based system. The

lead agency would be generally accountable for the effectiveness of the deployed system. Once

the lead agency has been established, it would be important to determine what other supporting 

agencies need to be involved. Supporting agencies would provide information that would support 

the design and deployment of the system and could be responsible for the following actions: 

• Managing external systems that the deployed system would interface with TMC staff,

transit management staff, toll management staff, and shared-use device management 

staff. 

A technical working group should be established 

that is knowledgeable about the needs of users,

capabilities of existing systems, the ability of 

existing systems to be modified, and the scope 

of improvements that can be made to enable 

communications with mobile devices.
213 

• Managing existing and/or deployed system components (e.g., technology organization 

that manages hardware, backhaul communication, and network configuration/settings). 

• Representing users of the deployed system (i.e., advocacy organization, or focus group

representative). 

• Developing SE documentation. 

The efficiency with which a mobile 

device-based system could be successfully

deployed would be aided by other agency 

stakeholders being proponents of the 

proposed system and their willingness to

cooperate. As supporting agencies are identified, the lead agency would need to develop a 

management approach that would establish a consensus regarding the structure of the group and 

the responsibilities and procedures of each member. In a case where there would be more than 

one lead agency (e.g., neighboring jurisdictions partnering on a project), it would be important to

establish a management structure among the leading agencies to establish an internal

management structure and a method for interacting with other supporting agencies.

Integrate with Existing Systems

Enabling communications with a mobile device or other wirelessly connected device, such as a 

CV, is still an emerging concept in the transportation industry. A limited number of agencies

have experiences in deploying wireless communications networks that could be leveraged for 

(among other things) lessons learned and best practices. 

Many nuances to the deployment of such a system cannot be effectively captured in high-level

guidance. Agencies considering the deployment of a mobile device-based system could consider 

establishing a relationship with agencies that have previously successfully deployed similar

infrastructure. This relationship would provide guidance and advice when the deploying agency

experiences uncertainty about how to proceed with a design of the system or about how it would 

be implemented. Furthermore, coordinating with other agencies would encourage 

interoperability—whereby a mobile device (or other connected device) could use the same 

application in multiple environments (provided each environment has established connectivity 

with the same transportation services and external systems). SE documents developed by 

agencies with experience deploying similar systems could also be reviewed to provide additional 

guidance to inform the structure and concepts that would be included in a locally specific set of

SE documents. 

The efficiency with which a mobile 

device-based system can be successfully 

deployed may be aided by agency stakeholders 

being proponents of the proposed system and 

willing to cooperate.

215 

CHAPTER 13. SYSTEMS ISSUES TO CONSIDER

CHAPTER OVERVIEW

Implementing the capability for a TMS to share electronic messages with mobile devices should 

consider what may be needed to support developing, implementing, operating, and maintaining 

this capability or service. Agencies or service providers that operate the TMS would be 

encouraged to review and revise or develop operating policies, procedures, and management 

tools to ensure the information exchange would be not only functional but also secure. Managing 

information and user expectations are critical to maintaining public trust of the service and 

enabling technologies, which may involve raising the public’s awareness to increase 

understanding among users.

Agencies should also consider the operating and staffing impacts the new technologies and 

services could have on the organization in terms of number and type of staff required to operate 

and maintain the equipment. This chapter provides an overview of operational, development, and 

deployment issues agencies may consider when considering TMSs sharing electronic messages 

with mobile devices.

OPERATIONS CONSIDERATIONS

To satisfy the data needs of travelers, the 

deployed system should consider 

interfacing with other external systems to

enable data transmission between mobile

devices and these external systems.

Maintaining these interfaces would require 

coordination between the agency responsible for managing the deployed system and other 

external systems. 

As the services provided by external systems evolve, the inputs and outputs to these systems 

change to enable these evolving services. For the deployed system to take advantage of external 

system updates, it must be able to interface with the external system and process the data sent to 

and received from the external system. The agency responsible for managing the deployed 

system would be aware of changes to external interfaces to ensure that the system could be 

updated to support these interfaces (and the data that flow over them) as they update. 

One of the primary aspects of a deployed system would be that it establishes a path of

communication between a mobile device and an external system. An agency that would be 

responsible for a network over which data would be transmitted would also be responsible for 

determining what data can flow over the network and how those data would be handled. Some of 

the data described in the concept chapters of this report are considered personally identifiable 

information (PII). PII is considered to be any information that could be used to identify an 

individual. This information could include, but would not be limited to, origin information,

destination information, vehicle ID information, payment account information, or locations 

(waypoints) along a traveler’s route. Some of these data items are sensitive in nature, whereas

For the deployed system to leverage the 

functionality external systems, it should be 

able to interface with the external system and 

process the data sent to and received from the 

external system.
216 

other types of data must be corroborated with other information for a traveler’s identity to be at

risk.

As discussed in the concept chapters, the transmission of data between mobile devices and other 

systems over a publicly managed network could be leveraged for various types of advanced uses 

such as capturing traveler decisions for transit/traffic management purposes. Today these types 

of uses are commonly referred to “Smart City” uses. When these data are being captured for 

traffic or transit management activities, these transit and traffic agencies should carefully 

consider what data would be used and/or stored. These agencies would need to ensure that they 

adhere to internal policies and procedures regarding the use and storage of such data, including 

considering the following attributes:

• Usage policy: 

o What could data be used for? 

o Who would have access to what data?

• Storage: 

o Data could be filtered to obfuscate PII by being time- and or space-aggregated with 

other data. 

o How would information be encrypted? Stronger protections are necessary to transmit 

and store sensitive data.

• Data retention: 

o How long would each type of data be stored?

o Data that have had PII removed could be stored for longer periods. 

o PII that is no longer needed could be deleted. 

Although a single message may not be considered PII, it could be possible to reconstruct a trip 

from a group of messages that could lead to the identification of an individual and their 

whereabouts. Such circumstances exist when there are few vehicles on the roadway, or certain 

patterns exist in messages, allowing specialized pattern recognition software to distinguish 

between individuals in a group. The protection of PII would be crucial for maintaining the trust 

of a traveler who wishes to preserve their privacy.

Due the nature of data being transmitted to and from mobile devices over a publicly managed 

system, mobile device users should acknowledge the terms and conditions (or terms of use) to

ensure they would understand how their data could be used before exchanging information. 

ORGANIZATIONAL CONSIDERATIONS 

The addition of the mobile device-based system would result in operations modifications for 

agencies that own and maintain equipment, manage the data gathered, and manage and maintain 

the enabling TMSs. This system could include fiber maintenance to support the additional 

responsibilities of the fiber backhaul network upon which the system relies (agencies could 

consider contracting fiber maintenance, if necessary).
217 

CONSIDERATIONS DURING DEVELOPMENT

Considerations during development may include sustained stakeholder involvement and

acquiring the proper permits for deploying communications technology. The lead agency would 

continually reach out to supporting stakeholder agencies to develop and maintain agreement on 

the features to include as part of the final system and to ensure a continued commitment by these

agencies to provide support for external interfaces and internal system support. 

Furthermore, public outreach would be necessary to enlist travelers who are willing to install

equipment or software on their personal

mobile devices and the deploying agency 

that would procure and distribute mobile

devices to travelers or purchase a dedicated

mobile device. The procurement of 

construction services would not be able to 

start until the system design is complete. This design could involve, but would be not limited to, 

the installation of fiber backhaul, roadside devices, and other equipment and network 

configuration. 

If the system includes the deployment of wireless communication technology, the deploying 

agency determines whether a Federal Communications Commission (FCC) license must be 

obtained. FCC applications are location-specific and specific to certain communications media 

and vary, depending on the types of messages that would be broadcast. The process of obtaining 

these licenses (if required) could be time-consuming (depending on the scale of deployment) and 

may affect the deployment schedule.

Finally, establishing communications security is important. Wireless access points (and to a 

lesser extent unsecured physical access points) are potential entrance points for hackers to access

any number of other devices or systems on the network. Agencies may consider using 

cyber-threat intelligence capabilities that identify, protect, detect, respond, and recover from

potential threats to systems and devices connected to the network. Before testing the system and 

initiating operations, the deploying agency may consider procuring these communications 

security services to protect systems and devices connected to the network and to ensure the 

legitimacy of information, so that all information originates from a trustworthy source. 

The network would need to utilize cyber-threat 

intelligence systems that identify, protect, 

detect, respond, and recover from potential 

threats to systems and devices connected to 

the network. 

219 

CHAPTER 14. ANALYSIS OF MOBILE DEVICE-BASED SYSTEMS

CHAPTER OVERVIEW

Systems involving information exchange with mobile devices could provide new real-time

information, capabilities, and functions to the travel environment with increased interaction with

the system user. This chapter summarizes available improvements within the various categories

of traveler safety, traveler mobility, payment processing, and interoperability. The listed

improvements provide owner/operators with a sampling of possible concepts but are not be 

considered a comprehensive list.

As mobile device-based systems are designed and deployed, it would be important that 

owner/operators continually assess the system’s role and performance. These systems would 

facilitate the exchange of electronic messages and therefore may require users to obtain and use 

equipment that may not be readily available. Evaluating the ability of users to interact with the 

system, the potential limitations, and any alternatives to improve the success rate would be key 

issues to consider during its development and after deployment. To help with this assessment,

establishing key performance measures that provide quantitative measures could be used to track

and assess performance over time.

This chapter provides an overview of the following topics: 

• Summary of Improvements. 

• Disadvantages and Limitations. 

• Alternatives and Tradeoffs Considered. 

• Performance Monitoring, Evaluation, and Reporting. 

SUMMARY OF IMPROVEMENTS

This section describes the capabilities that would be afforded by the proposed system. This 

section addresses the benefits or advantages of sharing information with mobile devices over the 

previous way of performing the functionality. In addition to providing safety and mobility

benefits, the concepts discussed herein provide increased accessibility in the form of payment 

and interoperability of mobile devices in different environments: 

• Improved safety of mobile device-carrying travelers:

o Bicyclist street safety. 

o Pedestrian phase extension. 

• Improved mobility of mobile device-carrying travelers:

o Enhanced crosswalk wayfinding. 

o Enhanced transit wayfinding. 

o Constant checks on progress on a multimodal trip to assess progress and provide 

alternatives. 

o Connection protection. 
220 

• Payment facilitation: 

o Rolling payment account registration. 

o Transit payment. 

o Toll payment. 

o Payment for other system. 

• System-to-system and region to region interoperability: 

o Use a single device (mobile device) that allows the traveler to benefit. 

o Improve management capabilities. 

o Use a planned driving route and provide progress updates for use in traffic

management activities. 

o Use a planned transit route and provide progress updates for use in transit

management activities.

These types of improvements are only intended to provide examples of how mobile devices

could help travelers (using various modes) make decisions and represent only a fraction of the 

applications that could assist mobile device-carrying travelers.

Another goal of the system could be to improve the accessibility of transportation services or 

information to mobile device users. This improvement would be done by establishing 

communications infrastructure that would provide connectivity between mobile devices and 

transportation services or systems that provide data.

Some services and systems are currently available through a wireless cellular service provider. 

However, accessibility would be improved if there were a communications infrastructure that

could provide additional means of connectivity, whereby this infrastructure would not require the

mobile device user to pay to connect, promoting equal access to these services and systems.

Publicly managed networks established for the communication of transportation data could be 

used to provide free connectivity for transportation applications. 

An agency could deploy equipment that would provide a single point of connectivity to one or 

more transportation services (e.g., TMC, transit management center, third-party services).

Alternately, one or more wireless access points could be used along a physical communications 

backhaul to enhance mobile device connectivity. In areas where backhaul connectivity exists, 

agencies could use this existing backhaul connectivity to provide connectivity to mobile devices.

DISADVANTAGES AND LIMITATIONS

Regarding a mobile device-based system, the one limitation is that for a traveler to receive any 

benefit from the system, they would have to have a mobile device with the necessary 

communications capabilities (e.g., cellular). Prototypes and initial deployments could provide 

funding to procure mobile devices to distribute to travelers, but this process would not be a 

sustainable long-term approach. The availability of a device with the proper capabilities, and the 

public’s ability to readily purchase such a device (i.e., would not be cost prohibitive) would 

provide fewer limitations to adoption and participation. 
221 

Precursor research (sharing data between mobile devices, CVs and infrastructure) has resulted in

the generation of a prototype mobile device that requires the use of peripheral smartphone 

accessories that enable communications, specifically DSRC radios, that are not available on 

today’s smartphones or other types of mobile devices. Given recent FCC rulemaking, it is clear 

that DSRC does not have a future. Furthermore, it is unknown whether smartphone 

manufacturers will consider C-V2X technology in future generation phones. 

Ideally, the key to mobile device-based systems having a long-term goal of large-scale mobile 

device adoption may be to design a system that leverages off-the-shelf technology or uses 

technology that is already available or planned to be available. When an agency builds 

infrastructure and supporting software to enable functionality to support the needs of travelers, it

would present a low barrier to entry to maximize adoption and likelihood of success. Thus, 

considering the current state of technologies and emerging trends in the smartphone and mobile 

device markets is important when assessing the feasibility or pursuing a mobile device-based 

system. 

It is risky to design for the use of communications technologies that are not available or not 

planned to be available on off-the-shelf smartphones or mobile devices. A mobile device design 

that does not require the use of peripheral components (with a smartphone) would not be 

advisable, because this type of device would likely result in reluctance to adoption. Furthermore,

convincing smartphone manufacturers to integrate or enable certain technologies into the next 

generation of devices (that they were not already planning to integrate) would also be difficult.

ALTERNATIVES AND TRADEOFFS CONSIDERED

The use of mobile devices for 

vehicle-to-vehicle safety was not considered,

because many vehicle-based safety and

mobility applications are currently enabled

through CV technology. 

It would also not be the intent of a 

mobile device-based system to replace the 

means by which existing services are provided in the current system. However, it would be 

important to consider the current system to determine whether it would be potentially enough (or 

if it could be potentially modified) to implement a concept that has been developed. 

PERFORMANCE MONITORING, EVALUATION, AND REPORTING

Assessing operations would play a critical role in understanding the operating characteristics of

the mobile device-based system. To gauge whether a deployed mobile device-based system

achieves the deploying agency’s goals and objectives, performance measures would be 

developed. Deciding which type of performance measure to use would depend on a variety of 

factors, including data availability. Thus, it would be important to consider the ability to collect

data (from the system or from external sources) to derive a given performance measure when

considering which performance measures would be used to assess the mobile device-based

system.

It is important to consider the ability to collect 

data (from the system or from external 

sources) to derive a given performance 

measure when considering which performance 

measures would be used to assess the mobile 

device-based system.
222 

These measures could align to each deployed application to compare conditions before and after

deployment (i.e., a before-after analysis). Other performance measures would compare areas

where mobile device-based communications would be deployed compared to those that would 

not (i.e., a with-without analysis). The benefit of before-after comparisons would be that they 

could measure changes directly in the areas that would be improved from a baseline of current 

conditions. The benefit of with-without comparisons would be that they could be done at the

same time, which would mitigate the impact of external variables. Other more complex analyses

could be designed depending on the availability and complexity of the data that could be 

gathered. 

It would also be important to address confounding factors that could affect performance

measures. Controlling for confounding factors would improve the ability to isolate changes in the 

performance of the system that could be attributed to the integration of mobile device-based

communications. 
223 

REFERENCES

1. Pierce, B., R. Brooks, T. Timcho, R. Zimmer, C. Toth, S. Nallamothu, and J. Nu 

Rosenbohm. 2016. Sharing Data Between Mobile Devices, Connected Vehicles and 

Infrastructure—Task 3: Concept of Operations: Technical Memorandum—Final. Report 

No. FHWA-JPO-16-422. Washington, DC: Federal Highway Administration. 

2. Waggoner, J., B. Frey, S. Novosad, S. Johnson, V. Blue, D. Miller, and S. Bahler. 2016. 

Connected Vehicle Pilot Deployment Program Phase 1, Concept of operations (ConOps) 

—Tampa (THEA). Report No. FHWA-JPO-16-311. Washington, DC: Federal Highway 

Administration. 

3. Galgano, S., M. Talas, D. Benevelli, R. Rausch, S. Sim, K. Opie, M. Jensen, and C. 

Stanley. 2017. Connected Vehicle Pilot Deployment Program Phase 1, Concept of 

Operations (ConOps)—New York City. Report No. FHWA-JPO-16-299. Washington, 

DC: U.S. Department of Transportation Intelligent Transportation Systems Joint Program 

Office.

4. SAE International. 2016. Dedicated Short Range Communications (DSRC) Message Set 

Dictionary. J2735_201603. Warrendale, PA: SAE International.

5. European Telecommunications Standards Institute (ETSI). 2010. Intelligent 

Transportation Systems (ITS) Vehicular Communications Basic Set of Applications. TS 

102-637. Sophia-Antipolis, France: ETSI.

6. Google Transit APIs. 2022. “GTFS Realtime Overview” (web page). 

https://developers.google.com/transit/gtfs-realtime, last accessed February 18, 2022. 

7. National Transportation Communications for Intelligent Transportation System Protocol

(NTCIP), Actuated Signal Controller Working Group. 2019. Object Definitions for 

Actuated Signal Controllers (ASC) Interface. NTCIP 1202 v03A-SE01. Washington, DC: 

American Association of State Highway and Transportation Officials; Washington, DC: 

Institute of Transportation Engineers; Rosslyn, VA: National Electrical Manufacturers 

Association. https://www.ntcip.org/file/2019/07/NTCIP-1202v0328A-SE01.docx, last 

accessed November 3, 2022. 

8. FHWA. 2022. “V2X Hub” (web page). https://usdotcarma.atlassian.net/wiki/spaces/V2XH/overview, last accessed February 18, 2022. 

9. IEEE Connected and Autonomous Vehicles. 2016. Initial 3GPP Cellular V2X Standard 

Completed. New York, NY: Institute of Electrical and Electronics Engineers.

https://site.ieee.org/connected-vehicles/2016/09/26/initial-3gpp-cellular-v2x-standardcompleted/, last accessed September 26 2022. 
224 

10. FHWA. 2012. Manual on Uniform Traffic Control Devices. 2009 MUTCD with 

Revisions 1, 2, and 3 incorporated. Washington, DC: Federal Highway Administration. 

https://mutcd.fhwa.dot.gov/pdfs/2009r1r2r3/pdf_index.htm, last accessed November 3, 

2022. 

11. Llunenfeld, H., and G. J. Alexander. 1990. User’s Guide to Positive Guidance, 3rd ed. 

Washington, DC: Federal Highway Administration. 

12. Federal Transit Administration. 2019. “Metropolitan Transportation Plan (MTP)” (web 

page). https://www.transit.dot.gov/regulations-and-guidance/transportationplanning/metropolitan-transportation-plan-mtp, last accessed February 18, 2022. 

13. FHWA. 2022. “Organizing and Planning for Operations: Transportation Systems 

Management and Operations(TSMO) Plans” (web page). 

https://ops.fhwa.dot.gov/plan4ops/tsmo_plans.htm, last accessed February 18, 2022. 

14. FHWA. 2007. Systems Engineering for Intelligent Transportation Systems: An 

Introduction for Transporation Professionals. Report No. FHWA-HOP-07-069.

Washington, DC: Federal Highway Administration. 

15. FHWA. 2006. Regional ITS Architecture Guidance Document. Report No. FHWA-HOP06-112. Washington, DC: Federal Highway Administration. 

https://ops.fhwa.dot.gov/publications/regitsarchguide/, last accessed February 18, 2022. 

16. Agile Alliance. n.d. “What is Agile Software Development?” (web page).

https://www.agilealliance.org/agile101/, last accessed February 18, 2022. 

17. IEEE. 1998. IEEE Guide for Information Technology—System Definition—Concept of 

Operations (ConOps) Document. IEEE Std. 1362-1998. New York, NY: Institute of 

Electrical and Electronics Engineers. 

18. ANSI. 2018. Guide to the Preparation of Operational Concept Documents. ANSI/AIAA 

G-043B-2018. Washington, DC: American National Standards Institute. 

https://webstore.ansi.org/standards/aiaa/ansiaiaa043b2018, last accessed September 12, 

2022. 

19. Fox, J. 2022. “Guidelines for Creating an Effective Vision Zero Action Plan.” Vision 

Zero Network, June 21, 2022. https://visionzeronetwork.org/roadmapforaction/, last 

accessed September 12, 2022. 

20. National ITS Architecture Team. 2022. “Architecture Reference for Cooperative and 

Intelligent Transportation (ARC-IT)” (web page). https://www.arc-it.net/index.html, last 

accessed September 13, 2022. 

21. ISO/IEC/IEEE. 2018. Systems and Software Engineering—Life Cycle Processes—

Requirements Engineering. ISO/IEC/IEEE 29148:2018. Geneva, Switzerland: 

International Organization for Standardization. 
225 

22. USDOT. n.d. “Accessible Transportation Technologies Research Initiative (ATTRI)” 

(web page). https://www.its.dot.gov/research_archives/attri/index.htm, last accessed 

September 22, 2022. 

23. Giampapa, J. A., A. Steinfeld, E. Teves, M. B. Dias, and Z. Rubinstein. 2017. Accessible 

Transportation Technologies Research Initiative(ATTRI): State of the Practice Scan. 

Report No. CMU-RI-TR-17-15. Pittsburgh, PA: The Robotics Institute—Carnegie 

Mellon University. 

24. Pierce, B., E. Plapper, J. Rizek; and Battelle Memorial Institute. 2016. Accessible 

Transportation Technologies Research Initiative (ATTRI) User Needs Assessment: 

Stakeholder Engagement Report. Report No. FHWA-JPO-16-35. Washington, DC: 

Federal Highway Administration. 

https://ntlrepository.blob.core.windows.net/lib/60000/60100/60128/FHWA-JPO-16-

354.pdf, last accessed November 3, 2022.

25. SAE International. 2019. Message Sets for Advanced Traveler Information System. 

J2354_201906. Warrendale, PA: SAE International.
HRSO-50/03-23(WEB)E Recycled

Recyclable

Recommended citation: Federal Highway Administration,

Sharing and Using Connected Device Data to Improve Traveler 

Safety and Traffic Management—Concept of Operations, Use Cases, 

Traveler Information Needs, Messages, and Requirements

(Washington, DC: 2023) https://doi.org/10.21949/1521974