NOTICE

The United States Government does not endorse products or manufacturers.

Trademarks or manufacturers’ names appear herein only because they are

considered essential to the objective of this document.

Dear Reader,

We have scanned the country and brought together the collective

wisdom and expertise of transportation professionals implementing

Intelligent Transportation Systems (ITS) projects across the United States.

This information will prove helpful as you set out to plan, design, and

deploy ITS in your communities.

This document is one in a series of products designed to help you

provide ITS solutions that meet your local and regional transportation

needs. The series contains a variety of formats to communicate with

people at various levels within your organization and among your

community stakeholders:

• Benefits Brochures let experienced community leaders explain in their

own words how specific ITS technologies have benefited their areas;

• Cross-Cutting Studies examine various ITS approaches that can be

taken to meet your community’s goals;

• Case Studies provide in-depth coverage of specific approaches taken

in real-life communities across the United States; and

• Implementation Guides serve as “how to” manuals to assist your

project staff in the technical details of implementing ITS.

ITS has matured to the point that you are not alone as you move toward

deployment. We have gained experience and are committed to

providing our state and local partners with the knowledge they need to

lead their communities into the next century.

The inside back cover contains details on the documents in this series,

as well as sources to obtain additional information. We hope you find

these documents useful tools for making important transportation

infrastructure decisions.

Christine M. Johnson Edward L. Thomas

Program Manager, Operations Associate Administrator for

Director, ITS Joint Program Office Research, Demonstration and

Federal Highway Administration Innovation

Federal Transit Administration
Executive Summary 2

Introduction 4

Needs Assessment 5

Requirements Analysis 7

Regional ITS Architecture 15

Telecommunications Architecture 21

Major Issue Areas 23

Distributed vs. Centralized 25

Outsourcing vs. Staffing 29

Lease vs. Own 31

Technical Alternatives 38

Competitive Access Providers 43

Conclusion 46

References 47

1
2

Telecommunication resources impact almost every activity of the public’s

daily lives. This pervasive influence is likely to increase as dependence on

information technology continues to grow. ITS, where technology is

applied to improve the effectiveness of transportation, are particularly

impacted in many ways by telecommunications issues.

Telecommunications infrastructure is an important factor in enabling an

ITS to function. It ties together and moves data between the major

elements of an ITS, including roadside equipment, vehicles, the vehicle

operator, and central operations facilities such as transportation

management centers (TMC). Telecommunications is equally critical to

creating optimal value, by integrating the individual elements over

telecommunications lines (and through the use of standards) to

command the resources and provide the information needed to improve

overall transportation efficiency. Telecommunications infrastructure can

also be the single most expensive part of ITS, both in implementation

and in operations/maintenance. Thus, arriving at the telecommunications solution that best suits the agency in support of the ITS

program, whether local, regional, or statewide, is a very high priority.

Arriving at the telecommunications solution best suited to the agency’s

needs is, in many cases, one of the most intimidating undertakings

performed by a transportation agency. The skills required to understand

the options, and how those options compare to one another, are not

found in the educational background of most transportation agency

personnel. This is further complicated by the rapid pace of change in

telecommunications, driven by technology, by deregulation, and by new

business paradigms such as the exchange of access to right-of-way for

telecommunications resources. Relationships with telecommunications

consultants, vendors, and service providers are relatively new to these

agencies, if they exist at all. The significant need for informed assistance

is addressed by this document in two ways: what processes work best,

and what factors should be considered in making telecommunications

decisions.

The first critical process in addressing any system-related need is to

understand the requirements. In telecommunications, the requirements

are often extensive. This document discusses methods and experience in

analyzing telecommunications requirements in order to determine an

optimal solution. Three processes—a thorough and structured

requirements analysis, use of a regional ITS architecture, and

development of a telecommunications architecture—are discussed.

This document discusses processes and decisions which can be applied in

making important telecommunications choices for the specific needs of

ITS. Although the processes and decisions are applicable far outside the

field of transportation, their application will only be discussed within the

context of transportation and from a transportation perspective.
3

The latter portion of the document discusses five critical decision areas

facing agencies in need of telecommunications services:

• Should the systems and the network services be distributed or

centralized?

• Should network support be staffed internal to the agency or

outsourced?

• How can the agency meaningfully compare leased vs. owned network

options?

• How can primary network technical alternatives be compared?

• What factors should be addressed when considering acquiring

telecommunications services from a competitive access provider?

Where possible, example situations from agency ITS programs have been

described. We would like to express our appreciation to the

Departments of Transportation (DOT) of the states of California, Georgia,

Maryland, Michigan, Minnesota, Missouri, New York, Texas, Virginia, and

Wisconsin, for providing examples of successful practices in ITS

telecommunications for this document.

Our analysis of the telecommunications experiences of the states

reviewed for this study, as well as issues and concerns that have arisen in

supporting ITS deployment in other states has brought several points

into focus:

• There are many complex choices to be made in selecting the

telecommunications solution to support ITS implementation. The

telecommunications solution is critically important, both because of

the essential technical function it provides to the system, and because

of its significant financial impact on total system implementation and

operations/maintenance cost and resources.

• The typical public agency will benefit greatly from access to qualified

professional telecommunications consulting assistance in performing

technical and business analyses and developing system design.

• There are ITS telecommunications examples we can learn from, such

as the experiences of the states studied for this report. It should be

recognized that the factors involved in the decisions made by these

agencies continue to change, and that their decisions might be

different if they were making the decisions under current conditions.

• Effective techniques to use in addressing the telecommunications

design issues include development of a regional ITS architecture and

an ITS telecommunications architecture.

• A careful systematic requirements analysis is essential in obtaining the

telecommunications solution best suited to an agency’s needs.
4

In many ITS implementations, the telecommunications solution was

arrived at without the kind of rigorous examination that would have

accompanied similarly significant and complex technical/business

choices. The purpose of this document is to present several of the best

techniques which can be used to explore telecommunications

alternatives, and to determine which one or ones are acceptable, and

possibly optimal, for a specific agency and program.

The intended audience for this document includes both the public and

private sectors. The primary objectives are to raise the awareness of and

provide a tool for public agencies responsible for transportation

programs including or supporting ITS. This includes agencies involved in

several phases of the ITS program life cycle, but is focused on those

agencies performing program planning and design. The document is

also expected to be of value to the traditional traffic and transportation

consulting community which may be assisting such agencies.

The document begins by focusing on performing an effective needs

assessment before selecting a telecommunications solution. Three

elements in the needs assessment phase are addressed:

• Requirements analysis

• The use of a state or regional ITS architecture in defining

telecommunications needs

• Development of a telecommunications architecture

For each item, the document provides a definition and justification, and

then describes how the process may be performed. Where possible,

examples from actual cases are included.

The second section of the document addresses several of the key

technical issues which arise in selecting telecommunications solutions.

These include:

• Distributed vs. centralized

• Outsourcing vs. staffing

• Lease vs. own

• Technical alternatives

• Competitive Access Providers

The approach to each issue is similar; defining the choice, demonstrating

possible approaches, discussing relevant issues, and providing real

examples where possible.
5

Understanding the need to be met is the most fundamental step before

undertaking design, procurement, and implementation. Typically this

involves gathering information from a variety of sources, such as the

stakeholders in all life cycle phases of the eventual system. The process

may involve looking ahead for a significant period, in order to understand

how the chosen solution can meet present needs, and can evolve to meet

future ones. It always includes defining what issues are critical: is the

decision to be driven by cost, capability, reliability, or other factors?

This document will address three possible activities within the overall

needs assessment: requirements analysis, the use of a state or regional

ITS architecture in determining needs, and the development of a

telecommunications architecture. While the first of these three is

relatively common, the other two are, respectively, rare and almost

unknown.

How have states traditionally chosen telecommunications

solutions?

Many factors must be considered in deciding upon the right telecommunications solution for an ITS program. Requirements analysis, a

process commonly encountered in engineering programs, is well suited to

telecommunications. Requirements analysis includes formal definition of

requirements, as well as development of alternative solutions and

comparative analysis of the alternatives.

Requirements analysis is a common practice in the civil engineering field

when building highway or mass transit infrastructure, and is often

standard operating procedure in state DOTs. Often, a civil engineering

project is years in planning before it ever reaches design. The method

used in such projects is quite similar to the one used by the Maryland

State Highway Administration (Maryland SHA) to choose their

telecommunications solution: requirements and costs are carefully

analyzed for several alternatives before a final decision is made on a

particular option.

DOT’s have done relatively few comparable telecommunications

requirements analyses, however, because historically there were few

options from which to choose. In the history of traffic signal systems, for

example, prior to deregulation typically the only alternatives available to

an agency were the use of purchased services through dialup or leased

lines, or the implementation of an agency-owned and –operated cable

plant of twisted pair or coaxial cable. Often the decision of which route

to take was based on:

• Budget considerations

• The approach taken by neighboring jurisdictions

• A direction set by higher levels within the agency

• Pre-existing agreements with telecommunications service providers.

A requirements

analysis is a

hierarchical, iterative

process for deriving

and describing the full

set of needs to be

satisfied by a product,

system, or service

provider.
6

Many such decisions were developed from a relatively narrow

perspective. Often they were based upon an internal perspective only

(no broad stakeholder assessment), or upon the needs of only one project

at a time. Thus the elements contributing to an ability to grow and

evolve, and to achieve significant integration were not recognized.

Requirements analysis is a common activity of transportation agencies. It

involves the definition of needs: what things the eventual solution must

do or provide/produce. It is equally important for product– or system–

related projects as it is for service-related ones. Our objective is to

address how accepted requirements analysis techniques should be

applied to effectively address the specifics of the complex and critical

telecommunications solution choice.

What is a Requirements Analysis?

A requirements analysis is a hierarchical, iterative process for deriving and

describing the full set of needs to be satisfied by a product, system, or

service provider. It typically begins by defining, or using pre-defined,

program level goals and objectives. These goals and objectives are the

bases for the derivation of high-level or generalized requirements, which

can then be decomposed further into lower-level technical requirements.

Thus, each requirement is traceable to its parent, and thereby to the

higher level need it fulfills.

At the lowest level, requirements must be objectively measurable, along

all relevant parameters. Only in this manner can they be of use in

determining if the specified technical approach is appropriate. Thus, if

delivery of a specified amount of power is the requirement, it must be

measurable both in terms of units of energy and in terms of time.

Requirements at the lowest level should not overlap because there is the

risk of duplication and resultant inefficiency.

The requirements analysis should also ensure that all requirements are

captured, understood, and agreed upon. As will be discussed later,

reaching full consensus among stakeholders about the requirements is an

essential element in determining the optimal solution.

Why do a Requirements Analysis?

The Maryland SHA Chesapeake Highway Advisories Routing Traffic

(CHART) program reported the logic behind its rigorous requirements

definition process. Maryland SHA saw telecommunications requirements

analysis as similar to the situation where design, engineering, and

construction of new roadways and bridges cannot begin until careful

planning identifies why they are needed, who they will serve, and where

they will be. Only then can the road be adequately designed based on

the nature of the traffic and the volume of vehicles expected to travel

over it. Likewise, an efficient telecommunications network for CHART

Without identifying

detailed telecommunications requirements

by consensus on

functional objectives,

there is no basis for a

technical solution

other than its

technological appeal.
7

could not be implemented without knowledge of why it was needed,

who would be served, and how it would be used by the CHART program.

Only then could the technical characteristics of the data, video, and voice

traffic be identified with any certainty.

Without identifying detailed telecommunications requirements by

consensus on functional objectives, there is no basis for a technical

solution other than its technological appeal. Therefore the risk is high

that the solution employed will not meet the functional program

requirements, and may have to be revised at significant cost. This is

similar to a case where a road or bridge is under-designed and must be

rebuilt because volumes or vehicle types were poorly understood prior to

design. Maryland SHA wanted to avoid this.

How to do a Requirements Analysis

Step 1: Identify ITS Program Goals, Objectives, and Requirements

Since the telecommunications network is intended to support an

intelligent transportation system, requirements analysis for ITS

telecommunications cannot begin without the formulation of ITS goals

and objectives by the ITS stakeholders.

As will be described in a later section on the use of a regional ITS

architecture, such an architecture can serve as an important source of

information about telecommunications requirements. The telecommunications requirements and the ITS systems and services they support

must also be consistent with the regional ITS architecture if one has been

developed. Information is available on how architecture consistency is

defined and can be demonstrated via the USDOT ITS Joint Program

Office’s web site, at http://www.its.dot.gov.

There may be a variety of existing resources to help understand

requirements, among them:

• ITS Early Deployment Plans

• High Level Statewide, Regional, or Project ITS Architectures

• Statewide ITS Strategic Plan

• Regional and Statewide Transportation Strategy and Plan

• Feasibility Studies

• Preliminary Engineering Studies

• Conceptual Design Analyses

• Transportation Improvement Program

• Statewide Transportation Improvement Plan.

How to do a

Requirements

Analysis

Step 1–

Identify ITS

Program Goals,

Objectives, and

Requirements

Step 2–

Derive Technical

Requirements

Step 3–

Document

Requirements

Step 4–

Validate

Requirements

Step 5–

Manage

Requirements

Types of

Requirements:

• Functional

• Operational

• Performance
Step 2. Derive Technical Requirements

For convenience, the telecommunications requirements are categorized

by requirement types. Requirement types to be considered include

functional, operational, and performance requirements.

Functional requirements identify what is to be done. A sample functional

requirement might be that the network must carry incident information

from the traffic management system to the traveler information system.

Operational requirements identify who or what performs the function,

where the function is performed, how many perform the function, and

when it is performed. A sample operational requirement might be that

the system should provide notice of freeway incidents to up to five local

law enforcement and emergency service providers within 30 seconds of

incident confirmation.

Performance requirements quantify measures such as how much, how often,

or how fast. A sample performance requirement might be that the network

must be able to provide up to five full-motion, full-color video images at 30

frames per second at all times, within 15 seconds of a request.

Requirements must be analyzed and translated into terms that telecommunications engineers can use to derive technical architectures. Video;

data; voice; local area network (LAN); reliability, maintainability, and

availability (RMA); and security are recommended architectural

components that should be derived from the program-level requirements.

With regard to video, the initial definition of requirements should identify

the number and locations of the closed circuit television (CCTV) devices,

video quality and motion requirements, and the locations of some, but not

necessarily all, of the consumers of video. From an analysis of each class of

situation in which the system will be applied (using case analysis), the

following telecommunications requirements can be derived: the location of

all consumers of video; the number of images to be viewed simultaneously

at each location; all locations that will select and control the video; the

maximum number of images to be transmitted between any two facilities;

and the directionality of video. The video data rate (kilobits per second or

megabits per second [Kbps or Mbps] per image) can be derived from the

program-level video quality and motion requirements.

With regard to data, program-level requirements should identify those

device types that will be polled for status and/or data, those that will

automatically transmit data at pre-specified intervals, and those that will

transmit data on an exception basis only. Through analysis, these

requirements can be decomposed into derived telecommunications

performance requirements: identifying polling frequency; fixed data

transmission frequency (where applicable); average and maximum

exception-based frequencies (where applicable); format and size of the

status and data messages for each device type; and the maximum

allowable time to transmit each message. The message size and timing

8
requirements can be further decomposed into transmission rates (Kbps,

Mbps) per message. Requirements should also identify who (which

location) will control the traveler information devices.

In Maryland, Maryland SHA desired to ensure that there was no bias for

or against any solution, equipment, or acquisition method, so

requirements were described by the nature of the traffic that the network

would have to support. This included serial data from the ITS devices and

field controllers, LAN data, voice, and video traffic.

Important requirements were derived for each type. Examples of the

detailed requirements are device message sizes and formats, frequency of

transmission, polling interval for low-speed devices, image and motion

quality, transmission delay, number of simultaneously viewable images,

and camera selection and control constraints for CCTV. Overall reliability,

maintainability, and availability requirements for the network backbone

were also derived during this step from information obtained about ITS

device failure rates and the ability to respond to outages on the road

systems during peak travel times.

Step 3. Document Requirements

Each program-level and derived telecommunications requirement should

be assigned to the appropriate requirement type (e.g., functional,

operational, etc.). For each type of requirement, each high-level

requirement should be assigned a unique identifier. A simple numbering

scheme will generally be sufficient. Each requirement statement should

be as concise as possible, and unambiguous. By convention, requirement

statements are drafted using the verb “shall.” A given requirement

statement can be subdivided into two or more clearly identified parts.

Also, a requirement statement can reference a table or tables that contain

detailed information. This is normally done to reduce the size and

complexity of the requirement statement. Any requirement that was

derived from a high-level requirement should retain the identifier of the

parent as part if its identifier.

Step 4. Validate Requirements

After the requirements have been assembled, it is necessary first to

analyze and compare them to ensure that neither conflicts nor gaps exist.

Each requirement is also reviewed for measurability.

The requirements should be presented to the stakeholders, initially in

writing, and then preferably in a group forum type of working session.

Leading up to the presentation, it may be useful to perform some

requirements “outreach” in order for key participants and their

organizations to fully understand and have considered the requirements

before arriving at the discussion forum. In this process, these participants

should be afforded the opportunity to ask questions “off the record”

which they may not feel comfortable asking in front of the group as a

whole. In this way, these issues can later be brought before the

assembled group in a non-confrontational manner.

9
In the presentation, the requirements are described and explained,

relating the requirement to the purpose (goal or objective) it supports,

but not linking it to any specific stakeholder. Implications of each

requirement should be presented as well, in order to gain a full

understanding of the requirement, and to stimulate consideration of

whether each should be modified to alter its impact on cost, risk,

reliability, or any other important decision-making criterion.

It is necessary for someone at an appropriate level of responsibility at

each stakeholder organization to indicate approval and to “take

ownership” of the requirements. This process may require additional

meetings or discussions if all key individuals are not able to attend a

single meeting. It is also important to recognize that there may be

multiple separate elements within each stakeholder organization whose

opinions are not uniform. It is preferable that these elements meet

beforehand to resolve internal differences of opinion. Reaching

consensus will be facilitated if each stakeholder organization “deputizes”

an individual to speak for its interests and with the authority of the

organization (or that their common supervisor be available to do so).

Step 5. Manage Requirements

The resultant requirements document is a “living” document and should

be managed in a controlled manner. Although the information may be

made available online, the document or database itself should be

carefully secured as would be any other contractual or design document.

The requirements database should be managed under the same

configuration management program as is used for other critical

information. Thus, each change made to the database would be logged,

described, the requestor noted, and the reason for the request described.

Changes would only be made after formal review and approval of the

configuration control board, representing the official views of each of the

stakeholder organizations. If there is a constant flow of changes, the

board may be required to meet on a regularly scheduled basis. Typically,

some form of change control notice is issued in advance of a board

meeting, along with the information necessary to hold a meaningful

discussion. Following the reaching of consensus, a signature sheet is

passed, on which each organization’s assent is noted. Notice of the

change is then distributed, likely to a broader audience than just the

change board.

Hiring A Consultant Team With Industry-Specific Network

Design Experience

ITS telecommunications is one of the most expensive components of ITS

programs and may rival medium to large civil engineering projects in

cost. It, therefore, makes sense to perform the same kind of up-front

planning and analysis that is performed for civil engineering projects.

Like transportation, the telecommunications industry is huge and

complex with an entirely different set of technical disciplines that DOTs

10

It is necessary for

someone at an

appropriate level of

responsibility at each

stakeholder organization to indicate

approval and to “take

ownership” of the

requirements.

It is extremely

important that DOTs

arm themselves with

appropriate telecommunications

expertise and

experience to

adequately play in

this arena.
may not be familiar with. This should be recognized up front and

planned for either by retaining appropriate in-house staff or contracting

with a firm experienced with a range of technical disciplines in this

industry. It is extremely important that DOTs arm themselves with

appropriate telecommunications expertise and experience to adequately

play in this arena. Not to do so heightens the risk of making unwise cost

and design decisions.

Maryland SHA recognized that it did not have the resident expertise in

building and maintaining a large telecommunications infrastructure to

make a decision of the desired level of quality. Thus, it turned to a

systems integration firm to perform the study. The systems engineering

division of a major aerospace/defense firm was retained under

subcontract to an engineering firm with which the state already had a

flexible contract mechanism. The aerospace/defense firm had specific

expertise and experience in analyzing and building large complex

networks. The analysis developed technical options based on functional

and performance requirements. It compared the costs of those options

(including owning versus leasing) over a ten-year life cycle; the

appropriate length of the life cycle for use in the analysis is itself an early

and important decision. The telecommunications analysis lasted nine

months and consisted of three phases:

1) functional and performance requirements analysis and validation

2) development of various network options

3) the costing of those options.

The Virginia DOT has found itself, several times, faced with developing

plans for network implementation or evaluating alternative approaches

recommended by firms already under contract. In these cases, the state

has made use of systems firms with significant aerospace/defense

backgrounds already under contract to perform the analyses. In one

instance, a major contractor, having recently won the contract to perform

a significant expansion of the regional advanced traffic management

system (ATMS) and the telecommunications network supporting it, came

forward with a variety of alternatives to the recently bid plans and

specifications. Virginia DOT relied upon the systems consultant hired to

perform inspection and independent validation and verification to

investigate available alternatives in detail, and analyze the implications.

In a later situation, Virginia DOT recognized the need to create a regional

network, unifying existing network elements and providing expansion

capability to support significant growth. Virginia DOT used the same firm

previously retained to assemble the primary requirements and to develop

the network concept. Virginia DOT then had an additional systems firm

with significant aerospace/defense background which was also under an

existing flexible contract to perform detailed analyses of the technical

alternatives.

11

The appropriate length

of the life cycle for use

in the analysis is itself

an early and important

decision.
The technique used to hire a telecommunications consultant is similar to

that used by most agencies to hire consultants for other purposes, with a

few important exceptions. Because relatively few telecommunications

consultants have highway experience and if qualification-based selection

is used, then experience outside of the transportation trade should be

carefully considered. This may include work for other types of

government agencies (and even foreign governments), and for the

private sector. In cases of the latter, not all information may be subject to

disclosure regarding an assignment, potentially including the name of the

client. In many industries this information is extremely proprietary, and

consultants are prohibited in their contracts from divulging the client’s

name. Thus, for example, if an agency were to use the Architect-Engineer

and Related Services Questionnaire (SF254) and Architect-Engineer and

Related Services Questionnaire for Specific Projects (SF255) forms as the

primary method for collecting information from bidders, these forms may

prove to be inadequate. These forms do not contain staffing or project

categories necessary for a complete description of telecommunications

experience and capability.

As with hiring any other consultant, the agency should be sure to require

relevant experience. If the requirements are limited to the wide area

network, then only that type of experience is necessary. If the analysis is

to include both local and wide area networks, both types of experience

should be sought. Typically, experience with switches and multiplexers is

also appropriate to specify. Often, both technical expertise and

telecommunications contracting expertise is needed. Although

experience with local providers and conditions is helpful, it is a far lesser

concern than having the appropriate technical expertise.

It may be difficult to retain a qualified telecommunications consultant

under existing agency overhead and profit ceilings. This is because most

telecommunications consultants serve the private sector, where such

ceilings do not exist. If this is the case, the agency should seek methods

to pay prevailing telecommunications consulting rates.

Of utmost importance is retaining a telecommunications consultant that

is independent and objective. This almost always excludes firms that sell

or install telecommunications equipment. The agency will need to decide

whether this also excludes firms providing the requirements analysis from

proposing on the detailed design of the system, or whether there is

sufficient benefit from efficiencies in carryover of the needs understanding

and client relationship to leave this option open.

What Were The Lessons Learned From An Example

Telecommunications Requirements Analysis?

The Maryland SHA performed an extensive formal telecommunications

requirements definition and analysis of alternatives in the early stages of

its ITS planning. They hired a consulting firm with specialized

telecommunications expertise to provide a requirements analysis process,

12

Often both technical

expertise and telecommunications

contracting expertise

is needed.

Of utmost importance

is retaining a

telecommunications

consultant that is

independent and

objective.
to supply advice in development and analysis of the requirements, and

later to identify options that would meet requirements. This experience

serves as an excellent case study providing lessons learned in the

requirements analysis process.

Designing a network is a complicated undertaking and requires a skill set

not readily available in Maryland SHA.

Maryland SHA recognized it did not internally have the appropriate

expertise and experience in determining all of the requirements and in

identifying and comparing financial and technical alternatives for largescale networks. The agency also recognized that this expertise was not

readily available through its traditional transportation engineering

consulting community. Thus, they hired a firm experienced in both

telecommunications and systems integration. This firm worked in concert

with Maryland SHA’s internal transportation engineering staff and

transportation engineering consultants to Maryland SHA on the analysis.

Virginia DOT found the same experience in planning and implementing a

large telecommunications network to support its traffic signal system in

Northern Virginia. From both technical and contractual perspectives,

Virginia DOT found its own knowledge and experience less than it desired.

To remedy this, it hired two retirees from the local phone company, one

with central office (switching and networking) experience, and the other

with field installation experience, to supplement its existing in-depth

understanding of transportation/traffic engineering and traffic signal

systems.

How a network is designed is a critical determinant of the total cost.

The goal of the Maryland SHA requirements analysis was to define the

most cost-effective and technologically viable option based on defined

functional and performance requirements. Its formal definition and

documentation of requirements provide a method of assuring that any

proposed solution could provide at least the basic telecommunications

capability it needed. Without the information developed during the

requirements definition, SHA would not have been able to perform the

financial and technical analyses that it used to assist in determining its

eventual telecommunications solution.

Different network designs may meet the same requirements, but may have

widely varying costs, both for implementation and for operations/

maintenance. Maryland SHA analyzed the financial implications of each of

the requirements-based design options it considered. Through

performing this analysis, Maryland SHA was able to develop a network

configuration which dramatically reduced the total cost by:

• Minimizing the number of times that the network had to cross long

distance zone boundaries

• Minimizing the bandwidth consumed by typically bandwidth-intensive

video transmissions

13

There may be several

network designs that

meet requirements,

but each alternative

can have widely

varying costs,

particularly when

using leased services.
• Utilizing the intelligence of its field devices to reduce the volume of

data transmitted

• Making optimal use of the communications infrastructure it already

owned and used.

The timeframe assumed in the analysis can drive the decision.

Based on its prior experience, Maryland’s analysis assumed that the

accumulation of long-term lease charges would be higher than the

capital costs of building a fiber optic network over time. Therefore, it was

unexpected that the least expensive leased option was half the cost of the

full build option for the ten-year analysis period which they had chosen.

In Maryland SHA’s opinion, ten years was an appropriate network life

cycle since it was long enough to consider factors such as technical

obsolescence of current generational fiber optic equipment, but short

enough to assume that the value of leased bandwidth remained

unchanged for each year. Since many factors—including the rapid

evolution of technology, the ability to upgrade the network significantly

without replacing it, and the end-of-life “residual value” of the system—

are important in choosing a life cycle length for analysis, great care is

warranted in selecting this value. Some “sensitivity analysis,” comparing

results when the life cycle length is varied from the chosen value, is

appropriate in order to assure that the assumptions have not

predetermined the final network solution.

Risk can be minimized.

By undertaking the analysis, Maryland SHA reduced two important risks:

1) that the agency would build a network that would not meet its needs,

and 2) that the agency could not capitalize on technology and

competitive changes that may yield lower telecommunications costs

during the life of the network. By understanding

and documenting its requirements, particularly by

identifying who needed access to the information

and how much bandwidth was required to

provide acceptable access, Maryland SHA could

build a network that adequately addressed these

requirements. Without understanding its

requirements, Maryland SHA ran the risk of

building a network that would be costly to

change or redesign in order to take advantage of

technology improvements or to serve additional

agency needs that arose after it was

implemented.

Technology trends, the passage of the Telecommunications Act of 1996, and the unfolding of a

deregulated environment have generally resulted

in overall lower costs of equipment and services.

Maryland’s telecommunications consultant

recommended that Maryland SHA keep a

watchful eye on specific technologies (e.g.,

14

Maryland State Highway Administration

Summary Lessons Learned

• Designing a network is a complicated

undertaking and requires a skill set not

readily available in Maryland SHA.

• How a network is designed is a critical

determinant of the total cost.

• The timeframe assumed in the analysis

can drive the decision.

• Risks can be minimized.
Digital Subscriber Line technologies) that could reduce ongoing charges.

It also recommended that Maryland SHA not pursue long-term leases but

rather only three-year leases so that Maryland SHA could capitalize on

telecommunications reform. If lower costs did not materialize, the

agency could still pursue a build option or renegotiate with providers for

better prices.

What is a Regional ITS Architecture? What is it not?

A regional ITS architecture can provide significant value in helping to

define telecommunications requirements. By identifying types, volumes,

sources, and users of transportation information, the regional ITS

architecture helps in understanding connectivity and bandwidth

requirements, as well as the nature (periodic, continuous, random) of the

communication flow.

A regional ITS architecture progresses from defining the highest level of

needs to the specifics of data elements and data flows, and the standards

which may be applicable to methods used to implement these flows. For

the purposes of this document, a regional architecture can be viewed as

ranging from a single municipality or rural area to statewide scope. It is

not limited to urban environs, and may include both urban and rural

components, and the means for their integration for comprehensive

regional transportation management.

A key component in every step of regional ITS architecture development

is that inputs be gathered from a full range of stakeholders. Equally

important is that consensus be achieved between the key stakeholders on

the outcome of the architecture. Often this involves both public and

private sectors, representation from multiple modes, and participants

from many different components of the transportation environment such

as law enforcement and towing services. As it progresses into greater

detail, the architecture will:

• Inventory the existing transportation resources and systems which will

need to be served by the telecommunications network, and which

may provide telecommunications capability supporting transportation

needs

• Gather needs as viewed by the stakeholders, including their priorities

• Discuss their respective roles and responsibilities in transportation

management

• Identify resources operated by them

• Define opportunities for sharing of information between them.

This process should identify many opportunities for partnerships, publicpublic, public-private, and private-private. Sharing of roles, and taking

advantage of resources owned or activities already performed by agencies

can result in both increased performance and decreased total cost. Thus,

15

A key component in

every step of regional

ITS architecture

development is that

inputs be gathered

from a full range of

stakeholders.

Equally important is

that consensus be

achieved between the

key stakeholders on

the outcome of the

architecture.
the regional ITS architecture development process assists in creating both

technical and institutional infrastructure supporting future ITS

deployment.

The architecture development begins by identifying ITS user services

(originally defined in the National ITS Program Plan) which satisfy the

user needs outlined in the transportation planning process. In the

architecture, high level user services are further subdivided into user

service requirements, more clearly identifying the specific services

required to address the region’s transportation needs.

At this point a preliminary concept of operations is drafted. It adds a

“how we are going to do it” to the “what we are going to do” that was

described in the user services analysis. Its focus is on roles,

responsibilities, and resources. The concept of operations is an excellent

point at which to clarify roles and responsibilities of each of the

stakeholder participants, and to initiate discussion of how the

stakeholders and their systems will interact in the broader transportation

management context.

Once the specific user services are defined, a logical architecture can be

constructed. The logical architecture performs a structured

decomposition of the identified user services into the functional processes

necessary to deliver these services. The logical architecture also provides

the relationships between the functional processes, by identifying the

information which each process uses, stores, or generates, and the

information which moves between the processes. Thus, it provides a

clearly defined specification for each process, a data flow diagram of the

information moving between processes, and a data dictionary of the data

elements themselves.

This information is of significant value in telecommunications analysis.

Once the locations and means of processing are identified further along

the systems engineering process, this information will allow the

calculation of data access points and bandwidth needs.

The physical architecture is the next step. It begins by identifying the

physical entities where functions may be performed. These entities

would include such facilities as a traffic operations center, a freeway

management center, or a transit operations center.

The physical architecture proceeds further to identify the subsystems

which belong within each physical entity. Typically these divisions are

clear, based upon the roles, responsibilities, and jurisdictions which either

existed previously or which were defined in the concept of operations. It

also identifies interfaces between the subsystems, as well as internal and

external physical interfaces.

16

The logical

architecture also

provides the

relationships between

the functional

processes, by

identifying the

information which

each process uses,

stores, or generates,

and the information

which moves between

the processes.

The Concept of

Operations Answers:

• What are we going

to do?

• How are we going

to do it?
The physical architecture allocates the processes identified in the logical

architecture into the subsystems. The basis for this allocation is that

subsystems:

• Group tightly coupled functions

• Group tightly synchronized functions

• Group performance/security/safety critical functions

• Align with cost allocations

• Align with deployment options

• Align with market segments.

The subsystems are aggregated (and later integrated) as needed for

actual deployment. A tool which may assist in this process is the use of

market packages. Market packages contain multiple, related equipment

packages from one or more subsystems. They are defined to make them

more easily related to actual ITS infrastructure elements, such as an

incident management program or an electronic fare payment system.

For example, the transit vehicle tracking market package contains both

the transit center tracking and dispatch, and the on-board trip

monitoring equipment packages. Market packages, and the relationships

between market packages, considerably simplify the preparation of an

implementation strategy.

The architecture identifies the interconnections between subsystems, and

may identify the standards which are appropriate for these

interconnections. Where subsystems exist in different systems or different

centers, telecommunications is also required to accomplish the

interconnection.

Subsystems are composed of equipment packages, which in turn contain

one or more processes derived in the logical architecture. Thus, the

information flow data derived in the logical architecture step can be

related to the interconnections identified in the physical architecture step,

providing a relatively complete picture of the telecommunications needed

to support the regional ITS implementation. The result is a complete

picture of the information flows between subsystems, and between

systems and the facilities in which they are located and operated.

Another characteristic of the architecture interconnection analysis is that

it recognizes the nature of the telecommunications, i.e., whether they are

random (voice), steady state (constant polling or sensor data), or bursty

(pre-processed and locally stored for later transmission). The physical

architecture contains a telecommunications “layer” which can assist in

modeling the telecommunications needs for the systems to be deployed.

17

The information flow

data derived in the

logical architecture

step can be related to

the interconnections

identified in the

physical architecture

step, providing a

relatively complete

picture of the

telecommunications

needed to support the

regional ITS

implementation.
The most useful tool in developing a regional ITS architecture is the

National ITS Architecture. The National ITS Architecture (available online

and on CD-ROM) provides an exhaustive list of the elements at each step

in the process, from which those appropriate to the region’s architecture

can be selected. This provides the foundation from which the necessary

regional customization can be accomplished. Sources for access to the

National ITS Architecture are provided later in this document.

An ITS architecture is not a system design or a complete

telecommunications architecture, although it provides important

information for use in each. It does not define where (physically) the

required functions are performed, or how they are implemented. An

architecture is technology independent, although it should reflect the

needs and capabilities of pre-existing ITS infrastructure.

USDOT has developed a product, entitled “Turbo Architecture”, to assist

in rapid, efficient, and thorough development of a regional ITS

architecture. Information on obtaining the Turbo Architecture tool,

training, assistance, and documentation will be available through the

USDOT ITS Joint Program Office’s web site at http://www.its.dot.gov.

What is the value of a Regional ITS Architecture in defining

telecommunications requirements?

The most important contribution of a regional ITS architecture in

defining telecommunications requirements is that when taken to its most

detailed level, it identifies the information to be communicated between

external elements and the ITS systems/subsystems, and between the ITS

systems/subsystems themselves. Thus, it provides the foundation for

determining the telecommunications capacity and access points

required in the eventual network(s). The material contained in the

National ITS Architecture goes further, indicating the most common

general telecom-munications categories between systems, although this

information is subject to revision under the rapid evolution of

telecommunications technology and the deregulatory institutional

environment.

Unfortunately, due to the relative newness of ITS architecture

development, we were unable to identify at the time of this study any

agency which had applied this approach. Thus, most agency

telecommunications decisions have been made without the benefits of

the information a regional ITS architecture provides. Lacking this

information, there are several likely problems:

• The network may be sized too small to meet the eventual demands

• The network configuration may not match the user’s needs

• An approach may be adopted which results in significant additional

cost to be expanded to meet the full set of requirements.

The most important

contribution of a

regional ITS

architecture in

defining telecommunications

requirements is that

when taken to its

most detailed level, it

identifies the

information to be

communicated

between external

elements and the ITS

systems/subsystems,

and between the ITS

systems/subsystems

themselves.

18
How is a Regional ITS Architecture developed?

In addition to the highly summarized description above, readers

interested in information on the development of an ITS architecture are

referred to the USDOT courses and training materials described below.

USDOT is also preparing a scope of services which agencies will be able

to use to procure the services of a consultant to assist in preparation of a

regional ITS architecture.

19

Communication Relationships within the National ITS Architecture
References on developing an ITS architecture

A series of case studies of the preparation of regional ITS architectures

noted below has been developed by the Volpe National Transportation

Systems Center, and are available via the USDOT Electronic Document

Library (EDL) at http://www.its.dot.gov/welcome.htm—or from Federal

Highway Administration Devision Offices and Resource Centers.

• The New York - New Jersey - Connecticut Region

Building a Framework for Regional ITS Integration

Publication number FHWA-OP-99-021; EDL number 9643

• The Gary-Chicago-Milwaukee ITS Priority Corridor

Building a Framework for Tri-State ITS Corridor Integration

Publication number FHWA-OP-99-022; EDL number 9644

• The Houston ITS Priority Corridor

Building a Framework for Regional ITS Integration

Publication number FHWA-OP-99-023; EDL number 964

• The Southern California ITS Priority Corridor

Building a Framework for Regional ITS Integration

Publication number FHWA-OP-99-024; EDL number 9646

• Arizona’s Rural Statewide ITS Architecture

Building a Framework for Statewide ITS Integration

Publication number FHWA-OP-99-025; EDL number 9647

• Developing a Regional ITS Architecture: A Cross-Cutting Study

Building a Framework for Regional ITS Integration

Publication number FHWA-OP-99-026; EDL number 9649

• Electronic Credentialing for Commercial Vehicle Operations

Building a Framework for ITS/CVO Integration

Publication number FHWA-OP-99-027; EDL number 9650

The reader interested in ITS architecture training is directed to the web

site for the National Highway Institute (http://www.nhi.fhwa.dot.gov)

and the National Transit Institute (http://policy.rutgers.edu/nti) where

the most recently available related course material can be found.

Resources available on these web sites include courses on the application

of the systems engineering process and the use of the National ITS

Systems Architecture in planning, design, implementation, and

operations/maintenance of ITS facilities. The course catalog is available at

http://pcb.volpe.dot.gov/98catalg.htm.

The National ITS Architecture documents, including the full details of the

“sausage” connectivity diagram on page 19, are available online at

http://www.odetics.com/itsarch and through ITS America’s web site at

http://www.itsa.org. It is also available on CD-ROM from USDOT’s

Federal Highway Administration Resource Centers and from the ITS Joint

Program Office.

20
21

What is a telecommunications ITS architecture? What is it not?

A telecommunications ITS architecture describes the points of need for

telecommunications service, and the nature of their need (bandwidth and

type of service). On top of this “needs map” the telecommunications ITS

architecture overlays the network topology, thus identifying both the

network routing, and the points of interconnection (nodes). As with an

ITS architecture, it is not a system design; it does not identify the specific

devices or the technologies, although it may identify standards that are

appropriate.

How is a telecommunications ITS architecture useful in defining

telecommunications requirements?

The telecommunications architecture provides a picture of the

geographic distribution of the needs, the size and type of the needs, and

a view of the layout of the network.

The telecommunications ITS architecture:

• Provides a comprehensive view of the telecommunications needs for

the project or regional ITS program

• Assists in understanding both budgeting and project scheduling

requirements by illustrating the geographic layout of the system

• Provides information to those wishing to determine suitability of

specific equipment to the system’s needs

• Assists the implementing agency in understanding where multiple,

dispersed needs may be cost effectively combined and projectized

• Provides information to those that may benefit from interconnecting

to the ITS telecommunications network, or with whom the ITS

program desires to interconnect

• Provides a comprehensive view of the ITS telecommunications

network for other agencies who may wish to take advantage of the

network’s resources in order to accomplish their non-ITS missions

• Provides view of the network to assist in planning for network growth

and evolution.

How is a telecommunications ITS architecture developed?

A telecommunications architecture represents the combination of

information from several efforts. The map of devices needing

telecommunications support is often developed as part of an ITS

architecture preparation, or may have been assembled in preparation of

an ITS Early Deployment Plan or other similar document. The probable

“build-out” plan, representing likely additions to the field equipment, is

also likely the outcome of a significant planning effort.

The telecommunications architecture

provides a picture of

the geographic

distribution of the

needs, the size and

type of the needs, and

a view of the layout

of the network.
The telecommunications architecture represents imposition of an overall

network topology upon the map of the network needs and analysis. It

then becomes possible to derive the functions which need to be

provided, such as multiplexing, switching, and media conversion.

Example of telecommunications ITS architecture

A relatively thorough telecommunications ITS architecture has been

developed by the Southern California ITS Showcase. The Showcase

includes 17 projects distributed across 4 California Department of

Transportation (Caltrans) Districts. Systems from well over a dozen

agencies are included in or interconnected with the Showcase. Each

system converses with its peers through a “seed” which performs

translation. Seeds are connected to a regional “kernel” which provides

routing, network management, security (in addition to firewalls), and

other shared network services. Kernels, in turn, are interconnected via

the Showcase’s primary network connections.

22

Telecommunications Architecture for the Southern California

Priority Corridor ITS Showcase
23

Each District also contains a TMC co-owned and operated by Caltrans

and the California Highway Patrol (CHP). The TMCs are also

interconnected via the state’s wide area network. Each district’s own

network, providing connectivity to its sensors, displays, and other traffic

management and traveler information field devices, is also unique,

representing differences in age, budget, and technical and management

philosophies at their respective dates of development.

The ITS implementing agency faces a multitude of complex decisions in

the design and implementation of its telecommunications network.

Several of these key decisions, each with a long term impact on the

agency, its network, and its systems, are discussed below.

For many years, there have been widely divergent opinions on the

optimal level of distribution for traffic control systems, varying from

centrally controlled uniform traffic control systems (UTCS) to fully

detector-actuated systems with totally local control. Consistent with this

distribution of processing and control is a significant change in the type

and volume of telecommunications workload. In the classic centrally

controlled system, the network must support constant

telecommunications between many endpoints and the central computer,

constantly moving both data and control. In the fully distributed system

the reverse is true; control is totally localized, with information and

control messages transmitted only when major faults are detected or

when special needs exist for changes to the field devices. Typically these

changes are made via dialup; telecommunications linkages only exist

when needed.

Characterizing distributed and centralized systems

Distributed systems rely more extensively on processing resources near

the equipment being operated. The field processor is relatively complex,

typically running installed software. It typically has a fair amount of local

solid state memory. The local processor is also typically supported by

power conditioning or a modest battery backup so that it can tolerate

modest power fluctuations and failures. It may contain a display and

means for local debugging such as a keyboard connection, but it contains

at least a keypad. Telecommunications with the central facility is less

frequent. Telecommunications with the central facility may occur:

• Not at all

• Regularly but infrequently

• Only when malfunction is detected

• Only when the central facility desires to check on field system status

• Only when the central facility desires to make a change in the field

system operation.

Distributed systems

rely more extensively

on processing

resources near the

equipment being

operated.
In centralized systems, field devices are in constant telecommunications

with the central facility. Local processing power may be minimal, only

enough to carry out the commands issued by the central facility.

Typically the local processor has relatively little memory, and may depend

totally upon firmware for its local instruction set. The default mode of

operation in cases of telecommunications failure or failure of the central

facility is relatively basic, such as fixed time. Telecommunications to the

central facility is typically intensive, including system status, operational

condition, command confirmations, and sensor data which have received

little or no processing. Similarly, telecommunications from the central

facility typically includes a regular flow of commands and constant polls

requesting either sensor data or status checks.

Examples of distributed and centralized systems

Centralized – TransGuide

The TransGuide ATMS monitors and manages freeway traffic in the

greater San Antonio, Texas area. Designed in the early 1990s, it utilizes

relatively simple field controllers for detector monitoring. Network

In centralized

systems, field devices

are in constant telecommunications with

the central facility.

Local processing

power may be

minimal, only

enough to carry out

the commands issued

by the central facility.

24

TransGuide Architecture
architecture was fully redundant using diverse routing, point-to-point, and

all-digital, with over 1 million feet of single mode fiber optic cable run for

the first 26 centerline miles of system. Fiber trunks were run from the

control center to fiber hubs, which then further divided services to

multiple telecommunications cabinets. Data, control commands, and

voice were transmitted at modest speeds. These signals were combined

into higher speed streams, which were further combined with digitized

video signals to make a single signal on each fiber. At the control center

end, each of the fiber signals were demultiplexed, with data routed

through further demultiplexers and intelligent analyzers, and video routed

through a digital switch to monitors and large scale displays.

Primary computing took place on a fault tolerant minicomputer, originally

coupled to X-Windows terminals and later to true workstations.

Telecommunications was constant, with a steady stream of status polls

generated by the central computer and transmitted to each field device,

with status responses returned by the field devices. Status polls were

generated both regularly and on demand.

Data from detectors were partially pre-processed in the field, both

accomplishing data reduction and smoothing irregularities. Smoothed

data were returned frequently to the control facility but were captured by

intelligent analyzers which passed only further aggregated data and

nonstandard condition data to the central computer.

Distributed – Minnesota Virtual Traffic Operations Centers

Minnesota is in the process of implementing a series of “virtual

transportation operations centers” for small/medium urban areas with

significant surrounding rural regions. Each center will consist of servers

and workstations, located at the facilities of the individual agencies whose

functions they support, networked together for sharing information.

There will be no central facility or central support staff for the center. An

example of linked remote centers would be the interconnection of the

traffic signal computer(s) at the city DOT and the county department of

public works, with pavement and road weather sensor information at the

state DOT district office, and video signals from shared CCTV cameras on

major routes and at common trouble zones. A logical extension of this

concept would be to integrate into this system the output from any local

“smart work zone” type of system which may be in operation. The

potential exists for the integration of transit information as well. The

overall system will be linked to state DOT headquarters for use in

integrating traveler information on a regional and a statewide basis.

In this environment, information is shared liberally, and displays are

integrated to some extent using a geographic information system

representation. Initially, control is not shared, retaining pre-existing

jurisdictional boundaries and responsibilities.

25
Strengths and weaknesses of distributed and centralized

telecommunications systems

Distributed systems:

• Reduce the cost of telecommunications and processing by

transmitting less information, and by taking advantage of low cost

field processing resources

• Are less vulnerable to a single point of failure such as a control center

outage

• May be made to be centrally manageable under emergency or other

relevant conditions

• Result in reduced dedicated staffing by making system operation one

of a number of responsibilities of the “operations staff” at each

agency’s location.

Centralized systems offer:

• Ease of management through use of centralized management tools

• Ease of access for repair and modification since most processing and

switching devices are centrally located

• The opportunity to share the cost of more capable resources such as

large scale video displays or switches

• Easier ability to take a corridor or regional approach, since extensive

information is available centrally for processing in this manner.

Interfaces between different technologies

A primary difference in centralized and decentralized implementations is

in the interfaces between the devices that are interconnected. Using an

advance traffic management system as an example, devices such as

vehicle detectors, closed circuit television cameras, dynamic message

signs, and highway advisory radio transmitters are considered “field

devices.” These devices interact with “central equipment”, such as a

traffic management computer system, which may be located in a TMC.

The interaction is via a telecommunication network. If the computing

intelligence is highly centralized, then large volumes of raw, unprocessed

data would typically be transmitted over the network from the field

devices (especially detectors) to the center where they would be

processed by the computer. Similarly, with minimal intelligence in the

display devices such as the dynamic message sign, the central computer

would issue simple commands to the sign as well as commands to verify

that the commands were executed successfully, and would “poll” the

sign frequently to assess its operational status. This environment places

heavy demands upon the telecommunications network to carry volumes

of data and commands, and network failures typically make the system

essentially non-functional.

26
A primary difference

in centralized and

decentralized

implementations is in

the interfaces

between the systems

and technologies that

are interconnected.

In a distributed environment, the detectors would filter and analyze their

raw data, providing only summary or exception data over the network to

the center. Similarly, the dynamic message sign would have significant selfdiagnostic capability, would require only minimal direction, and would

automatically report only deviations from normal operation. This

environment requires much less capacity in the telecommunications

network, and may be able to operate with some effectiveness even if the

field devices are disconnected from the control center. An example of this

type of operation can be found in the fog warning system operating in the

Northern California approaches to the Rocky Mountains. In this system,

visibility sensors trigger standard messages to be displayed on dynamic

message signs, and cancel the messages when visibility returns to

acceptable levels, without intervention from the regional transportation

management center. The primary differences in interfaces include:

• The interface may move a little or a lot of information, depending upon

the ability of the field devices to pre-process the information, and upon

the level of field system intelligence and the degree of decision-making

authority allocated to the field system.

• The interface may or may not allow control capability to be moved

from one center to another. Although sharing of information between

centers is increasingly common, the ability to share control or to

transfer control from one facility to another can be significantly more

complicated, both institutionally and technically.

• The interfaces between systems must exist at many levels. Physical

medium, network protocol, and application programs must be

compatible in order for the systems to successfully exchange

information or interoperate. The objective of many of the early ITS

standards being developed is to support multiple alternatives for some

basic telecommunications decisions, such as the physical transmission

medium in order to accommodate existing infrastructure, and in order

to maintain a vigorously competitive marketplace.

• The interfaces may create either peer-to-peer (the devices work

cooperatively) or master/slave (one device controls the other)

relationships between the systems that are interconnected.

• Interfaces are the logical locations for the use of standards. When no

standards exist, the interfaces are often accomplished with proprietary

or closed systems, severely limiting the system owner’s ability to

expand or access the system without the assistance of the system

vendor.

• The interface may have impact on one or more of the systems that are

interconnected. This is particularly true when connecting multiple

legacy systems or legacy systems with newer ones. The interface may

have to serve as a “translator” into the native language of the legacy

system, requiring storage and processing power for the translation.

Further, the legacy system may have limits on the rate at which it can

accept, process, and acknowledge data and commands, thus forcing

the interface and the partner systems to wait on it.

27
28

An important consideration in making lease versus own and technology

decisions is how the agency will operate and maintain the

telecommunications infrastructure. This applies to both local and wide

area networks, and to the devices which connect the two. In this section,

several of the primary determinants in making the decision as to whether

to use agency staff or contractor personnel to perform network operation

and maintenance, or whether to contract for telecommunications services

rather than to own the network, are discussed.

Skills Required

Most agencies find it challenging to hire and retain personnel with the

skills required to operate and maintain a wide area network. These skills

often have to cover more than one technology. In multi-technology

implementations such as Detroit, where microwave, fiber optics, and

both coaxial cable and twisted pair copper are used, the skill set needed

is quite broad, and includes skills often found in both engineer and

technician job categories.

Certain skills are likely to be vendor-specific, particularly when dealing

with the particular switches and multiplexers deployed in the system.

This also applies to the particular tools which the agency has procured for

monitoring and managing its system, and for its maintenance. As an

example, a good working knowledge of the operation of one model of

fiber optic cable fusion splicer does not guarantee competency or

successful results with another brand.

This vendor-specificity also applies to dealing with the

telecommunications partners to whose systems the agency’s network may

be interfaced. An understanding of the signal system and controllers

which a network supports is critical to properly designing and

maintaining the system. This becomes even more complex if the system

is poorly documented, if vendor support is no longer available, or if the

system (such as the routing occurring at a central office) is indeterminate

(changes with time).

Skills relevant to ITS telecommunications are in extremely high demand in

the private sector. The agency desiring to hire personnel with these skills

is likely to find that agency salary and benefit limits and career paths

make it very difficult to successfully compete with the private sector for

these personnel, or to retain such personnel if the agency is able to hire

them. The primary competitors for such personnel include the Regional

Bell Operating Companies, equipment vendors, major corporations, and

engineering and consulting firms.

Most agencies find it

challenging to hire

and retain personnel

with the skills

required to operate

and maintain a wide

area network.

Skills relevant to ITS

telecommunications

are in extremely high

demand in the private

sector.
Procurement

In the procurement of telecommunications support services, the scope of

services must be both specific and complete. The RFP should specify all

of the services desired, under what conditions they must be performed

(i.e. 24 hours per day, 365 days per year), and what resources will be

provided or are required. Typically this will include both operations and

maintenance, and the maintenance will include both preventive and

emergency maintenance. The agency will need to determine if additional

services, such as network planning, design, and installation are required

for network modifications or expansions.

The specific qualifications required need to be clearly identified. In most

cases, this will include the particular equipment and tools which the

agency is planning to procure or has procured. Special considerations

may be required based on the installation itself (overhead, in tunnels,

underwater). As in other service procurements, the agency will be

looking for successful service experience that most closely resembles its

own needs. This may be challenging, as many providers may not have

experience working in a roadside or traffic environment, and thus may

need the assistance of a traffic control subcontractor or the agency’s

maintenance department traffic control capability.

The agency should specify a structure for the bidder’s pricing or rates. It

is likely that the contractor will uncover unsuspected conditions or such

conditions will emerge from network modification or expansion. Thus,

factors influencing the cost to the contractor of delivering acceptable

service may be outside the contractor’s control. The maintenance

contractor for the INFORM ITS system on Long Island was allowed a

specified number of weeks to identify such circumstances which could be

considered exceptions to its financial responsibility for repair.

Perhaps the most important step in the selection process is determining

the criteria for selection. The agency may need to carefully consider

upon what basis or bases the selection decision should be made. Often

price is the default; however this can lead to significant difficulties in

achieving acceptable service levels. Appropriate consideration of

qualification, experience, key personnel, and price is more likely to result

in a satisfactory result.

29

The most important

step in the selection

process is the criteria

for selection.
30

Contracting

Length of contract is a significant determinant in price and level of

satisfaction. Contractors will price more aggressively for longer contract

periods, unless economic times are highly unpredictable. The contractor

is also likely to be more productive over a longer period, as it will have

longer to overcome any learning curve. The agency will need, however,

to leave itself the ability to terminate the contract at appropriate times for

poor service. A commonly used contract structure is to have a “base”

period with multiple option years that can be exercised successively.

The type of contract itself determines the degree of sharing of risk, as in

all services contracts. The agency may desire to limit its financial risk, and

may opt for a fixed price contract. This is only recommended if the

network to be maintained is in good shape and is well documented, or

contractors will levy a significant risk penalty in their prices. The agency

will experience the maximum flexibility from a cost-plus type of contract,

where it is able to specify the types and levels of service on a reasonably

real-time basis. As is widely recognized, however, the agency’s financial

liability is open-ended, which may be inconsistent with its budgetary

policy.

The agency will want to consider how easy it is to amend the contract.

As the network is likely to grow over the duration of the contract, and

may change in nature with the replacement of various network devices,

contract terms may need to be adjusted to reflect realistic work

requirements. Complex and lengthy amendment processes, or processes

that artificially limit the number of amendments, may make it difficult for

the agency to procure the services it requires as the needs change.

As in many service contracting situations, the location of the contractor’s

staff can greatly influence their ability to deliver services and interact with

the agency effectively. Milwaukee’s MONITOR system has recently begun

contracting for full-time service positions, to be delivered on site at the

MONITOR offices. Thus, the contractor’s personnel are immediately

available to respond to short-term MONITOR needs.

Pay and benefits

Due to the extreme demand in both commercial and public sectors for

telecommunications professionals, compensation for quality personnel is

commonly higher than for similarly trained and experienced staff in civil

engineering. Market rates vary widely, based on local supply and

demand. Rates also reflect both the extent of education within and

beyond the degree program, and the extent and relevance of experience.

Agencies considering hiring telecommunications staff should consult

market surveys available to their personnel departments, and possibly

trade journals which regularly carry regionally based salary comparisons.

The type of contract

itself determines the

degree of sharing of

risk
In making a lease vs. own decision, the agency must consider both

financial and technical implications of its choice. The agency should

understand both the quantifiable considerations and the risks which are

assumed with each option, many of which will be impossible to quantify,

but which will impact the long term operation and growth of the region’s

ITS program.

How to conduct the financial analysis comparing leasing

versus owning

The essence of the lease versus own financial analysis is to identify all

forms of cost to be experienced during the analysis period, and the time

at which each cost will be incurred. This includes all elements of the

system life cycle, including planning, design, installation, testing,

operations, and maintenance. In order to perform this analysis, the

agency will need to fully understand its networking needs, and to have

designed multiple networking scenarios. Maryland found that its

preliminary leased network was not financially optimized, and thus

revised the design in order to optimize it while still meeting performance

goals. Similarly, it compared a totally new owned network to one using

some of its existing resources.

Some costs are “fixed,” and should not be considered in the analysis.

They include costs which are present in either scenario, such as the cost

of certain agency personnel and perhaps the costs of equipment to

interface the wide area network to the local area network.

Some more difficult decisions must be made in order to equitably

compare options. Typically the most challenging decision is determining

the required quality of video signal transmitted through the system. As

video often represents the greatest bandwidth demand on an ITS

network, all network options should represent essentially equivalent

qualities of video service. A similar decision will need to be made

regarding the need for each classification of device to be online full-time,

or whether dialup service is acceptable. This is particularly true for

relatively static devices, such as changeable message signs, ramp meters,

and signal systems which operate primarily under local rather than central

control. Without full time connectivity, however, the transportation

management center responsible for these devices may be unaware for an

extended period of the failure of a device, or of traffic problems which are

created by suboptimal operation of the device, such as queueing onto an

arterial caused by a mistimed ramp meter.

Some factors will be difficult to value in the analysis, such as the ease and

speed of expansion of the network. Unless such factors can be quantified

in the price quotations of competing vendors, they will receive only

qualitative consideration.

31

The essence of the

lease versus own

financial analysis is

to identify all forms

of cost to be

experienced during

the analysis period,

and the time at which

each cost will be

incurred.
32

The period used in calculating the present value is important. In

determining the time period of calculation, analysts need to recognize

not only how many years the network is expected to be in operation, but

also when it may be “built out” or expanded to cover a larger area or

provide greater capacity. Since up-front expenditures are most heavily

weighted in a present value calculation, and are also the greatest portion

of the investment in an owned network, the timing and length of

payments for leased services can greatly influence the outcome in

comparing leasing and owning. This timing difference is somewhat

reduced in importance if the lease payments are made in advance in

recognition for lower overall rates, such as was done by Virginia DOT in

Northern Virginia.

Some assumptions may need to be made for changes in the cost of

telecommunications services. Most long-term telecommunications

contracts are subject to renegotiation as options for expansion or other

changes are exercised. Since telecommunications services are generally

decreasing in cost, the agency may encounter conditions under which

the cost of leased services may decline. The opposite may be

experienced if an agency uses a service which its local carrier decides to

deemphasize. An example of this is when carriers decided to stop

making relatively inexpensive “unloaded” (not in use) analog lines

available, driving users of this service to considerably more expensive

telecommunication alternatives. A carrier may also “economically

motivate” users away from a less profitable service by dramatically

increasing its service price, perhaps forcing users into more expensive

alternative services.

A factor complicating the choice of present value calculation period is the

difference in lifetime and residual value of the different elements of the

system. Although some elements, such as proprietary electronics that

cannot be upgraded, may have a limited lifetime and little residual value,

the conduit itself may last for many years and in some cases has been

known to appreciate in value.

As a result of their own analysis, Maryland SHA decided not to build a

fully owned private fiber optic network, but rather a hybrid network

infrastructure relying predominantly on leased services while also

pursuing resource sharing initiatives. By opting not to build its own fiber

optic network, Maryland SHA expects to save $72 million. This decision

was based primarily on cost in the ten-year lifetime but also on identified

technical solutions that could fulfill defined business objectives and

mitigate the agency’s risk from rapid technology and telecommunications

industry change. While the lease versus build issue was an important

theme of the analysis, other critical system factors came to light that

affected decisions for ITS telecommunications and diminished the lease

versus build issue. The lease versus build question simply became two

options of the many that Maryland SHA considered which could fulfill

Maryland SHA’s ITS requirements.
In the development of this document, no comparable analysis was

identified which led to an agency deciding to build and operate its own

network. Numerous factors exist which could, however, lead to such a

decision. For example, many agencies have relatively generous capital

budgets that can be applied to fund construction of an agency-owned

system, but find it very difficult to obtain the operations funds that would

be used to pay for network leases. Under such circumstances, a decision

by the agency to build and operate a network rather than to lease

services may be quite logical.

A comparable decision to own rather than to lease may occur if the

agency is able to trade an asset, such as access to right of way, to a

contractor who would then provide a network which would be owned

and possibly operated by the agency. This alternative, if executed

correctly, can be extremely attractive both financially and in terms of the

capacity and connectivity received. Ideally, the agency may be able to

avoid paying both implementation and operations/maintenance costs. In

an agreement by the Missouri DOT, the state was able to arrange for

connectivity statewide in a single contract, avoiding an estimated $40

million implementation cost. Even in situations where service is acquired

for less than total geographic coverage, use of such an arrangement to

link sub-networks across local access transport area (LATA) or long

distance boundaries can result in major long-term savings. Individuals

interested in more information about shared resource programs should

investigate the Federal Highway Administration (FHWA) and American

Association of State Highway Transportation Officials (AASHTO) reports

on this topic cited in the References section of this document and the

December 1999 opinion of the Federal Communications Commission

regarding Minnesota’s shared resource program.

As with any long-term contracting situation, the specifics of the shared

resource agreement are critical to the success of the arrangement. Since

communications has a significant impact on both implementation and

operation cost, and on operational procedures, a careful and wellplanned approach to the negotiation of such arrangements, utilizing

specialized expertise where appropriate, is necessary.

When comparing leasing and ownership, agencies should consider the

level of risk they experience in justifying an ongoing operations cost when

compared to the cost of a capital acquisition. In some agencies, lease

fees are paid from relatively scarce operations funding, which must be

justified anew each year. Thus, the agency faces the risk of either having

to reduce system operation if operations funding is cut, or of having to

sacrifice other operations activity in order to continue funding the lease.

Capital funds, on the other hand, are dedicated once allocated, although

agencies must also consider that even an owned network will require a

lesser amount of operations and maintenance funding.

33

Agencies should

consider the level of

risk they experience

in justifying an

ongoing operations

cost when compared

to the cost of a

capital acquisition

when comparing

leasing and

ownership.
34

Technical impacts of leasing

The technical impacts of leasing are brought about primarily because the

network user does not know or have control of the following factors,

which also may change without the user’s knowledge:

• Network switching

• Network routing over long distances, including repeated amplification

of the signal

• Multiplexing and demultiplexing of signals

• Termination devices at network endpoints.

The first three of these actions can result in signal degradation, either

through loss of signal strength or through introduction of noise or other

signals into the primary signal stream. The last impact reflects the fact

that the signal may be delivered in a manner specified by the carrier from

its central office and through points of presence (POPs), rather than in a

manner most compatible with the end-use device.

The diversity of impacts, as well as the complexity of the analysis of these

impacts, further supports the importance of retaining appropriate

consulting experts while making the lease/build decision. An effective

consultant will assist the agency in understanding the issues and can

analyze their impact on meeting the agency’s objectives and supporting

its systems.

The use of dialup services (a subset of leased services) on an ITS system

can be significant as well. Typically in dialup systems, only periodic

communication is established with the field devices, perhaps only on an

as-needed basis. The agency faces the risk that either the field device or

the communication circuit will malfunction between calls, and will be

found to be nonfunctional only when it is needed.

The agency should also consider the complications of integrating a leased

network with an owned network. The devices at the interface will often

be a point of contention with the carrier when discussing system

problems.

It may be difficult to use diagnostic tools successfully past the point of

demarcation between the owned and leased systems. This extends

further to a general difficulty in diagnosing leased networks using digital

services, because the network may be periodically reconfigured by the

service carrier, and the signals likely undergo extensive multiplexing and

demulitplexing between end nodes.

Certain commonly leased telecommunication architectures are inherently

vulnerable to failure. A prime example is the “multidrop” network

architecture, where many slower devices are fed from a single higher

speed line. The transition point between a slower device and a higher

Certain commonly

leased telecommunication architectures

are inherently

vulnerable to failure.
speed line is called a “drop.” In such an architecture, a single cut in the

“backbone” will take all “upstream” drops offline. Similarly, a malfunction

in one drop which causes it to transmit constantly can effectively block the

ability to sustain communications with any other drops on the line.

The impacts of leasing on network maintenance have been discussed

earlier.

Procurement and contracting of leased and owned systems

Procurement

Procurement of either owned or leased telecommunications services can be

complex for the transportation agency. In the case of an owned system,

the capital required to implement the telecommunications system may

exceed half of the total ITS system implementation cost, thus making it the

largest and potentially the most important single system within the ITS

deployment. If services are procured instead of acquiring a system, the

service cost may be quite significant in comparison to the total operation

and support cost of the remainder of the ITS infrastructure. In either case,

the design must be sufficiently flexible to address technical evolution as well

as significant system expansion and alteration over an extended number of

years. As telecommunications is the single element which enables most of

the infrastructure to operate in an optimally effective manner, and which

allows centrally controlled equipment to receive necessary commands, it is

likely the most critical element to proper system operation. Thus, the

investment made and the relationships established in the

telecommunications procurement phase of the ITS deployment represent

some of the most important decisions in the region’s ITS program.

In the case of an owned system:

• The agency will often find itself procuring items with which it has little

experience, and therefore has few pre-existing standards and

specifications. This is another area where the use of a proven

telecommunications consultant can be of significant value to the

agency.

• Existing specifications and standard plan details (such as grounding,

cable burial depth, conduit schedule and sealing, manholes/pull boxes,

cabinet size and placement, power supply, and overload suppression)

may be inappropriate, having been developed often for illumination, or

for use in dialup or leased line situations, rather than for current

telecommunications cable and equipment.

• Standard documentation, training, testing, spares, and system support

procurement clauses may also be inappropriate for the

telecommunications system.

• The telecommunications system represents a broad variety of perhaps

separately procured or pre-existing devices which must interact

successfully at many levels. A failure at any interface may totally prevent

functioning, and may impact many additional devices further “down

35

...the service cost may

be quite significant in

comparison to the

total operation and

support cost of the

remainder of the ITS

infrastructure.
36

the line.” Thus, full and absolute proven compatibility is essential to

assure success.

• Common practices of dividing major projects into multiple

procurements may also create significant challenges in properly

assigning responsibility for difficulties in bringing the system online.

In Atlanta, in preparation for the 1996 Olympic Games, 10 contracts

were bid to install cable, and separate contracts were then let for

equipment installation and systems integration. Some contractors

had finished their work months (or years) ahead of the system

acceptance which would eventually prove that their portion of the

system worked correctly.

• Methods of measuring completion of work and of assigning value for

payment may also be inappropriate where trenching represents the

greatest cost, but where a few switching devices represent the most

critical functionality.

• A basic assumption in most public procurements, that price should be

the single determining factor, may need to be challenged. As

telecommunications devices vary widely in capability and quality, and

may be offered with a multitude of features and options, a “best

value” approach may lead to more satisfactory results.

In the case of a leased system:

• The agency should define requirements in such a way that it may be

possible to solicit both from the local phone company and from

competitive access providers. Requirements should be defined

exhaustively, including acceptable levels of service and responsiveness

to outages. Responsibility and interaction in response to network

problems or failures should be clearly identified. Penalties for outages

should also be quantified.

• The contract length and ease of modification should be considered in

order to receive the best pricing possible, and to simplify contract

administration as the network grows and needs change.

• The selection criteria should be defined in such a way that the local

phone company is not excluded from the competition, but that all

relevant service factors are considered in making the selection.

• The agency should consider how the network is specified, i.e., between

which points. The procurement should also consider whether a hybrid

configuration, which takes advantage of existing agency

telecommunications infrastructure or of existing agency bulk leased

telecommunications services, offers a more economical solution.

• The agency should investigate other existing state contracts to

determine whether superior terms are already available under an

existing contract. The DOT should consider, however, how it will

effectively interact with the contract-holding agency, which may have

little understanding of the transportation agency’s unique

telecommunications needs.

As telecommunications devices vary

widely in capability

and quality, and may

be offered with a

multitude of features

and options, a “best

value” approach may

lead to more

satisfactory results.
• The Request for Proposal (RFP) should specify how the contract will or

will not respond to changes in telecommunications tariffs and to

market prices for comparable services during its lifetime.

Contracting

• When contracting for telecommunications service, the agency should

consider how it will exercise the necessary leverage over the provider

in order to ensure the level of responsiveness that is desired or

needed. Any single procurement will likely represent only a small

portion of the business the agency or state does with its primary

carrier, and that will be only a small portion of the carrier’s total

business. Thus, the agency project manager may find that he or she

has little leverage to get the carrier to perform as desired. This can

include situations where the quality of service does not meet specified

standards, where the system is in need of diagnosis and repair, or

where the agency would like the system expanded or reconfigured.

• The agency may find that diagnosing telecommunications problems is

challenging when moving through the public network. Ordinary

diagnostic tools may find inconsistent or unusable results due to the

variety of switching and cable installations between endpoints, and

the practice that the route may be different each time the call is

routed, or the circuit brought up or down.

• The agency may find that the carrier’s installation specifications are

quite different from its own, particularly regarding cable burial depth,

trench fill, conduit composition and schedule (or lack of conduit),

inspection of the installation, etc. An agency imposing specifications

different from the carrier’s may encounter resistance or elevated cost.

• Often ITS field equipment is placed at intersections or along the

roadside. Most commercial carriers use street addresses to identify

network installation points. The lack of formal street addresses in

some geographic areas may complicate the carrier’s network planning

and installation, at additional cost to the agency.

• If the agency procures services at tariffs normally associated with

standard business, government, or consumer service, the network

user’s repair response time and reliability requirements may not be

met by what the carrier delivers. In ordinary consumer service and for

many economically attractive tarriffs, the carrier does not guarantee

either response time to a problem call or the period within which a

repair will be made. Typically carriers provide a guaranteed response

time only at a higher fee level.

• The carrier contract needs to be carefully crafted to support

expansion of the network and extension of the contract. Expansion

may include a longer network, more access points, alternative services

such as frame relay or asynchronous transfer mode (ATM), and

additional total bandwidth.

37

When contracting for

telecommunications

service, the agency

should consider how

it will exercise the

necessary leverage

over the provider in

order to ensure the

level of responsiveness that is desired or

needed.
38

• The agency must be aware of the potential for escalation in the

leasing rates between contracts. Most agencies find it difficult to

transition from leased service to owned service even when lease costs

increase unexpectedly. Typically the agency is not in a position to

terminate operation of some or all of its system while arrangements

are made for an alternate carrier or while an owned system is installed

if the current carrier decides to greatly increase prices.

• Agencies face similar challenges when expanding a network across

local access transport area lines, thus moving from “local” to “long

distance” or distance-based fee structure. In such cases, the cost for a

relatively short extension of the network can be much greater than

had been experienced for much of the network thus far.

Choosing the technology or technologies to be implemented in an ITS

telecommunications system is a complex and far-reaching decision. It

may have a large impact on both initial and long-term costs, and will

affect the performance and cost of the system throughout its lifetime.

Many choices abound, often mixed within a single solution. An

intelligent transportation system contains devices varying from having

little telecommunications need to having a very great need, from near to

remotely distant, and from easily accessible to very difficult to reach.

Thus, the telecommunications technology decisions are of critical

importance and deserve to be considered carefully before setting them as

part of the program’s course.

What are the technology choices?

Telecommunications technology alternatives abound, each with its own

set of distinct features. Media technologies are typically divided into two

categories: wireline and wireless. In an ITS context, wireline typically

includes:

• Twisted pair copper

• Coaxial cable

• Fiber optic (multimode and single mode).

Commonly considered wireless alternatives include, but are not limited to:

• Microwave

• Cellular (digital and analog)

• Cellular digital packet data (CDPD)

• Spread spectrum

• Digital and trunked radio systems.

The technology or

technologies to be

implemented in an

ITS telecommunications system may

have a large impact

on both initial and

long-term costs, and

will affect the performance and cost of

the system

throughout its

lifetime.
In concert and consistent with the media choice are decisions on

approaches to the other telecommunications “layers.” Alternatives such

as ATM, frame relay, digital subscriber line, and switched multimegabit

data service (SMDS) also greatly influence the capability and flexibility of

the telecommunications solution, as well as the cost and time to

implement and operate it.

How are the choices made?

There are a great many factors to consider when choosing the right

telecommunications technology. The choice should reflect a long term

perspective, as the cost and effort necessary to replace a system are

significant, and system shortcomings may significantly reduce the

effectiveness of a much larger investment in control center systems and

field equipment. Some of the factors considered in decisions examined

for this study include:

• How easy will it be to interface with the existing ITS

telecommunications infrastructure?

• How reliable is it in operation?

• How easy is it to maintain, and will it require additional maintenance

skills (or will existing personnel be able to maintain it)?

• Does it offer the capacity to meet our current needs?

• Is it capable of expanding to meet our growth needs, both in total

capacity and in terms of geographic distribution of the

telecommunications need?

• What are the implementation costs, total life cycle costs, and available

budget?

• How long will it take to implement, and is this consistent with our

other project plans/needs/priorities?

• Will we be able to operate and maintain the eventual network,

considering both staffing and skills constraints?

The recommended technique begins as this document does, with

understanding all aspects of the requirements. This includes a complete

assessment of the existing telecommunications infrastructure, and a

decision whether the implementation is to be added to the existing

network, or whether it will presently or eventually replace the network.

As an example of the latter choice, the Virginia DOT concluded that it

would leave systems inside the I-495 Washington, D.C. Beltway on an

aging coaxial cable system while implementing a fiber optic-based system

on I-95 and I-66 outside the Beltway, in order to remain within the limits

of the Virginia DOT district’s capital budget.

39

The recommended

technique begins with

understanding all

aspects of the

requirements.
40

Once requirements have been defined, each technology must be

evaluated. The evaluation factors, such as those above, need to be

determined and accepted by key stakeholders. Similarly, the way each

factor will be evaluated and its level of criticality must be decided. Some

factors may become go/no-go items, such as whether the technology

offers adequate capacity for the current need. Other factors may be

evaluated on a continuous scale, such as the cost to implement and the

total life cycle cost. Other factors may be evaluated on limited relative

scales, such as high/medium/low or a scale of 1-5, based on probability

assessments, such as whether the DOT can retain personnel qualified to

operate and maintain the system.

Examples of several technology alternatives

Virginia DOT Hampton Roads – twisted pair to fiber

Virginia DOT has had an operational ATMS in Northern Virginia for over

20 years. Virginia DOT’s second venture into ATMS came in the early

1990s with the implementation of the first phase of the ATMS for the

Suffolk District, in the Hampton Roads area centered around Virginia

Beach. Due to the inexperience of the DOT and its consultant with

telecommunications technology, as well as a relatively modest budget for

the project, the initial design included telecommunications over copper

twisted pair, using repeaters to boost signals over longer portions of the

network.

Due to the competitive bidding process, it was not possible for bidders to

propose alternate approaches during the bid period. The successful

bidder, an electrical contractor, immediately approached Virginia DOT

following its selection. It proposed conversion of a significant portion of

the network to fiber optic cable, using a mix of multimode and single

mode cabling, which would be coupled to the copper and coaxial cable

connections of the field devices at telecommunications hubs. They

presented Virginia DOT with a number of justifications including:

• The implementation could be done for essentially the same budget.

• The fiber optic system could be expanded more easily in capacity,

length, and number of connections than would be possible with the

copper network.

• Signal quality on the fiber optic network would likely be, and remain,

superior to the specified copper network, as it was not dependent

upon repeaters.

• Management tools were available which would make the fiber optic

network as easily manageable as the copper network.

• There was less likelihood of degradation of signal and network

performance over time due to cable corrosion.

Virginia DOT accepted the contractor’s proposal and has continued to

expand the system, whose fourth construction program was underway

in 1999.

The evaluation

factors need to be

determined and

accepted by key

stakeholders.
Detroit – fiber/microwave

In the 1990s, Michigan DOT faced a complex situation in deciding upon

the telecommunications network to support expansion of the ATMS for

the greater Detroit area. The existing system, implemented on M10—the

Lodge Freeway—depended upon a coaxial telecommunications cable

network whose age was creating significant problems for Michigan DOT’s

maintenance unit. Michigan DOT faced an ongoing challenge in

retaining an adequate staff to repair the system, and had little success in

recruiting personnel with appropriate qualifications. Additionally, few

spare parts were available for the system, so Michigan DOT found itself

often fabricating its own spares, at significant expense.

Michigan DOT had decided to greatly expand the ATMS, from its existing

30 plus centerline miles to 180 centerline miles. This expansion was to

take place at the same time that a great deal of road reconstruction was

to be undertaken, including I-94 linking Detroit to its airport. Due to this

reconstruction, cable-based telecommunications was unattractive, since

any cable installed prior to the road work was likely to be damaged by

the road work. Furthermore, the possibility of bringing field equipment

online early, to aid in traffic management during construction, also was

attractive. Michigan DOT’s budget for the 150 centerline mile expansion

was limited, and considerably less than would have been necessary for

installation of most cable-based options. Michigan DOT chose a “light

infrastructure” type of approach, with vehicle detectors only every two

miles, rather than at more common 0.3 or 0.5 mile spacing.

The result of these factors was a decision to implement a hybrid network.

The base of the network is a high-capacity, fully redundant self-healing

fiber optic ring. From this ring extend terrestrial microwave spokes to

hub locations from which telecommunications to field devices is carried

over copper cables.

Minnesota – twisted pair to hybrid fiber/twisted pair

In the Twin Cities area, Minnesota DOT has had an operational ATMS for

nearly 30 years. In 1991, Minnesota DOT recognized that its semidistributed system using coaxial cable for video and twisted pair for data

and command would be challenged to expand to the size and

complexity foreseen for the region’s ITS program. Minnesota DOT

commissioned a systems integrator-led team to analyze the current

situation and alternatives, and to make a recommendation. The system

needed to support:

• Ramp metering

• Vehicle detectors

• Changeable message signs

• Lane control signals

• Gate control

• Highway advisory radio.

41
42

The study considered an alternative delivery mechanism as well as leased

services, and the following technical alternatives:

• Broadband coaxial cable

• Fiber optic cable

• Copper twisted pair

• Terrestrial microwave

• Digital radio

• Cellular telephone and trunked radio.

A further phase of the study investigated alternate telecommunications

topologies (see sidebar for illustrations), including:

• Point-to-point

• Tree

• Nodal

• Ring

• Mesh.

A matrix was created, analyzing each technology in each topology for the

intended needs. The consultant’s recommendation was based on

consideration of the following, which are not in order of priority:

• Total life cycle cost

• Cost of installation

• Quality of service

• Adherence to industry standards

• Ability to deliver at least 100% excess capacity

• Ability to pre-install surplus media which would later be available for

system expansion or provision of other services

• Ability to be joined or integrated with the existing system, and

particularly the coaxial video cable

• Ability to service field equipment at increased distances from the

control center

• Overall level of reliability.

Each of these decisions occurred several years ago. Additional

alternatives, such as digital subscriber line now exist, in a considerably

less regulated telecommunications environment, which might lead each

agency to a different conclusion if the decision were now being

undertaken.

Point-to-Point

Tree

Nodal

Ring

Mesh

Network Topology

Examples
In the deregulated telecommunications environment, agencies have a

much wider and more varied choice for telecommunications services.

Whereas previously there would have been a single long distance service

provider, there are now many, offering different services, prices, and

business arrangements. Concurrent with the deregulation, however,

have appeared additional fees for services previously delivered as part of

the overall service package. In this section the process for selecting a

competitive access provider (CAP) and some of the considerations of

receiving services from a CAP are discussed.

Process for making the choice to use a CAP

As was noted in the previous section on making a choice of technology,

the first step in considering whether to contract with a CAP is to fully

understand and document the requirements. This forms the basis for

issuance of an RFP or invitation for bid (IFB), depending upon the chosen

contracting mechanism.

Also as found in the process for choosing a technology, the agency needs

to decide upon what basis its decision will be made. Several of the

factors to consider are:

• The first and most obvious reason to choose a CAP is because it offers

a lower price. Pricing may be structured quite differently than the

local phone company, with varying levels of discount or premium

based on either incremental or total utilization, type of service, time

of day, and LATA or long distance boundaries.

• The agency needs to be assured that it will receive an acceptable

quality of service. This may be measured in terms of bit error rate,

reliability, or other relevant factor.

• The agency should consider the ability it will have to modify the

contract for growth. Almost all areas are in only the initial stages of

ITS deployment, and few have begun to explore their options for

interconnection and integration with systems from neighboring

jurisdictions. The ability to achieve these is necessary in the

contractual agreement.

• The ability of the CAP to successfully and effectively diagnose and

remedy problems, preferably without significant technical

involvement by the agency, is important. One measure often

employed is the CAP’s guaranteed response time to remedy

problems.

• Since cross-provider interconnects represent situations where cost is

incurred and where responsibility becomes disputed when addressing

service problems, the number of access interconnects to get from the

TMC to its field equipment should be considered.

43

The agency needs to

decide upon what

basis its decision will

be made.
44

• It is necessary to consider exactly what the CAP has offered, since

there may be significant differences in the capabilities of various CAPs.

Some may be able to offer dark fiber or unloaded twisted pairs, while

others may be restricted to specific types of service, such as

Integrated Services Digital Network (ISDN), fractional T1, ATM, frame

relay, or other specific services.

• As is discussed in the following section, not all CAPs are well founded,

solidly backed businesses. The agency should consider the business

stability of the various CAPs from whom it has received bids, in order

to guage the risk it faces of unsatisfactory operations by the selected

CAP.

The implications of choosing a CAP

When contracting with a CAP, a number of implications need to be

considered. Access fees charged by the local phone company will be a

part of the financial equation, even if they are “invisible” to the network

end user. The structure and size of access fees continue to evolve,

changing the cost experienced by the CAP.

It is highly likely that there will be a need to interconnect with the local

phone company’s network. This is particularly true where the agency

desires to integrate voice, data, and video. With advances in computer

integrated telephony (CIT) and voice over Internet protocol (VOIP), this

becomes considerably more likely. The form of the interconnect, and

how responsibility is delineated for tracing problems that span the

interconnect, should be considered in making the CAP decision.

In the deregulated environment, the assets necessary to become a CAP

can be relatively small, and thus the barrier to market entry is low. The

result is that smaller firms, relatively poorly staffed and poorly capitalized,

can enter the market essentially as resellers of services purchased in bulk.

The long-term business stability in the region of such firms is

questionable, as they may be unable to create a significant price

advantage, and may have trouble making the marketing investment

necessary to build a significant business base. Thus, the agency may find

itself with a long-term contract with a firm no longer in business in the

region, instead receiving service from a firm that has assumed the

operation.

In the same vein, the agency may want to investigate the extent of the

local manpower resources of the CAP. Although the cost of a service

outage to the CAP may be relatively minor, the public relations problems

such an outage may cause to the agency may be much greater. Being

assured that the CAP has adequate skilled local manpower to diagnose

and remedy any outage can be an important component of making the

sourcing decision.
45

Examples of CAP provided systems

In the early days of the ITS program in Houston, the Texas DOT identified

a need to provide telecommunications at minimal cost between its area

telecommunications hubs and the interim (pre-TranStar) TMC. Texas

DOT identified a local carrier which had fiber optic cable run, primarily

overhead, along various routes in the metro area. Upon investigation,

Texas DOT found that the carrier had additional capacity available on the

fiber and was interested in realizing some revenue in exchange for this

unused capacity. Texas DOT was able to arrange to carry some of its

signals over the available fiber, in those areas where the fiber had been

run, at significantly less cost than would have been experienced either for

equivalent leased services, or for the installation of an agency-owned

network along the affected routes.
Our analysis of the telecommunications experiences of the states

reviewed for this study, as well as issues and concerns that have arisen in

supporting ITS deployment in other states has brought several points

into focus:

• There are many complex choices to be made in selecting the

telecommunications solution to support ITS implementation. The

telecommunications solution is critically important, both because of

the essential technical function it provides to the system, and because

of its significant financial impact on total system implementation and

operations/maintenance cost and resources.

• The typical public agency will benefit greatly from access to qualified

professional telecommunications consulting assistance in performing

technical and business analyses and developing system design.

• There are ITS telecommunications examples we can learn from, such

as the experiences of the states studied for this report. It should be

recognized that the factors involved in the decisions made by these

agencies continue to change, and that their decisions might be

different if they were making the decisions under current conditions.

• Effective techniques to use in addressing the telecommunications

design issues include development of a regional ITS architecture and

an ITS telecommunications architecture.

• A careful systematic requirements analysis is essential in obtaining the

best ITS telecommunications solution best suited to an agency’s

needs.

46
AASHTO, “Guidance on Sharing Freeway and Highway Rights-of-Way for

Telecommunications,” Washington, D.C., 1996

Federal Highway Administration, “Case Study for Contracting for

Communications Services for the Northern Virginia Traffic Signal

System,” Washington, D.C., 1999

Federal Highway Administration, “Longitudinal Utility Accommodation:

Case Studies for Trading Access to Freeway ROW for Wireline

Telecommunications,” Washington, D.C., 1996

Federal Highway Administration, “Shared Resources; Sharing Right-ofWay for Telecommunications,” Washington, D.C., 1996

Federal Highway Administration, “Shared Resources: Sharing Right-ofWay for Telecommunications Guidance on Legal and Institutional Issues,”

Washington, D.C., 1996

Federal Highway Administration, “Wireless Shared Resources: Sharing

Right-of-Way for Wireless Telecommunications,” Washington, D.C., 1997

ITS Cooperative Deployment Network, “ DSL Technologies for

Transportation Applications A Discussion with Keith Biesecker of Mitretek

Systems,” Washington, D.C., 1999

Minnesota DOT, “Communications Study for Minnesota Department of

Transportation Traffic Management System,” St. Paul, MN, 1991

Southern California Priority Corridor ITS Showcase, “Southern California

Priority Corridor Intermodal Transportation Management and

Information System (SHOWCASE) Scoping and Design Final

Implementation Plan,” Los Angeles, CA, 1997

Texas DOT, “TransGuide Design Guide,” San Antonio, TX (No date)

USDOT ITS Joint Program Office, “A Case for Intelligent Transportation

Systems (ITS) Telecommunications Analysis,” Washington, D.C., 1997

USDOT ITS Joint Program Office, “ITS Telecommunications: Public or

Private? A Cost Tradeoff Methodology Guide,” Washington, D.C., 1997

USDOT ITS Joint Program Office, “Telecommunications in Transportation:

A Summary of Key Issues,” Washington, D.C., 1997

USDOT, “The National Architecture for ITS: A Framework for

Integrated Transportation into the 21st Century, Version 2.0”

Washington, D.C., 1999

Virginia DOT, “Analysis of Bell Atlantic SONET Communications and

Video Services Proposal,” Richmond, VA, 1998

Virginia DOT, “Northern Virginia Signal System Communications

Scalability Analysis,” Richmond, VA, 1997

47
Federal Highway Administration Resource Centers

Federal Transit Administration Regional Offices

For further information, contact:

Eastern Resource Center

10 S. Howard Street

Suite 4000 – HRC-EA

Baltimore, MD 21201

Telephone 410-962-0093

Southern Resource Center

61 Forsyth Street, SW

Suite 17T26 – HRC-SO

Atlanta, GA 30303-3104

Telephone 404-562-3570

Midwestern Resource Center

19900 Governors Highway

Suite 301 – HRC-MW

Olympia Fields, IL 60461-1021

Telephone 708-283-3510

Western Resource Center

201 Mission Street

Suite 2100 – HRC-WE

San Francisco, CA 94105

Telephone 415-744-3102

Region 1

Volpe National Transportation Systems Center

Kendall Square

55 Broadway, Suite 920

Cambridge, MA 02142-1093

Telephone 617-494-2055

Region 2

Alexander Hamilton Federal Building

1 Bowling Green, Room 429

New York, NY 10004

Telephone 212-668-2170

Region 3

1760 Market Street, Suite 500

Philadelphia, PA 19103-4124

Telephone 215-656-7100

Region 4

Atlanta Federal Center

61 Forsyth Street, SW

Suite 17T50

Atlanta, GA 30303-3104

Telephone 404-562-3500

Region 5

200 West Adams Street

24th Floor, Suite 2410

Chicago, IL 60606-5232

Telephone 312-353-2789

Region 6

819 Taylor Street

Room 8A36

Fort Worth, TX 76102

Telephone 817-978-0550

Region 7

901 Locust Street, Suite 40

Kansas City, MO 64106

Telephone 816-329-3920

Region 8

Columbine Place

216 16th Street, Suite 650

Denver, CO 80202-5120

Telephone 303-844-3242

Region 9

201 Mission Street, Suite 2210

San Francisco, CA 94105-1831

Telephone 415-744-3133

Region 10

Jackson Federal Building

915 Second Avenue, Suite 3142

Seattle, WA 98174-1002

Telephone 206-220-7954
THIS DOCUMENT IS ONE IN A SERIES OF PRODUCTS THAT

ADDRESS ITS I SSUES PERTINENT TO A VARIETY OF AUDIENCES

FOR A CURRENT LISTING OF AVAILABLE DOCUMENTS, PLEASE VISIT OUR WEB SITE AT:

www.its.dot.gov

ELECTED AND APPOINTED OFFICIALS • SENIOR DECISION MAKERS

TRANSPORTATION MANAGERS • TECHNICAL EXPERTS

Representing:

STATES • CITIES • COUNTIES • TRANSIT PROPERTIES • TOLL AUTHORITIES

EMERGENCY SERVICE PROVIDERS • METROPOLITAN PLANNING ORGANIZATIONS

ADDITIONAL TRANSPORTATION STAKEHOLDERS

• COMMERCIAL VEHICLE OPERATIONS

• EMERGENCY SERVICES

• ENABLING TECHNOLOGIES

• EMISSIONS MANAGEMENT

• FREEWAY AND ARTERIAL MANAGEMENT

ITS Topics Addressed in This Series:

• PLANNING AND INTEGRATION

• REAL-TIME TRAVELER INFORMATION

• TRANSIT, TOLL, AND RAIL MANAGEMENT

• WEATHER INFORMATION FOR TRAVELERS

AND MAINTENANCE
INTELLIGENT TRANSPORTATION SYSTEMS

U.S. Department of Transportation

400 7th Street, SW

Washington, DC 20590

Federal Transit Administration

Room 9402,TRI-10

Phone: (202) 366-4991

Facsimile: (202) 366-3765

Federal Highway Administration

Room 3416, HOIT-1

Phone: (202) 366-0722

Facsimile: (202) 493-2027

FHWA-JPO-99-023 EDL # 11488 FTA -TRI-11-00-02

“Telecommunications analysis is undertaken prior to

implementing a large communications infrastructure not

only because of the cost, but also to avoid building a

network that will not meet operational needs.... In each

case, the agency made or changed previous decisions

based on the information and recommendations

presented in the analyses.”

—Maryland Department of Transportation