National Transportation Communications for ITS Protocol (NTCIP

National Transportation Communications for ITS Protocol (NTCIP
National Transportation
Communications for ITS Protocol
(NTCIP)
GUIDE
Prepared by
The NTCIP Joint Standards Committee
DRAFT
March 3, 1997
TABLE OF CONTENTS
INTRODUCTION.................................................................................................................................................I
ABOUT THIS DOCUMENT............................................................................................................................. II
CHAPTER 1: WHAT IS THE NTCIP? ............................................................................................................. 1
WHAT TRANSPORTATION MANAGEMENT SYSTEMS CAN USE THE NTCIP?...................................... 1
HOW THE NTCIP WAS DEVELOPED............................................................................................................ 2
CURRENT NTCIP ACTIVITIES AND HOW YOU CAN HELP....................................................................... 3
OTHER SOURCES OF INFORMATION ABOUT THE NTCIP........................................................................ 3
CHAPTER 2: HOW THE NTCIP MAY BE USED .......................................................................................... 1
WHY THE NTCIP SHOULD BE SPECIFIED IN ALL PURCHASES............................................................... 1
Avoid Early Obsolescence ............................................................................................................................ 1
Provide Choice of Vendor............................................................................................................................. 1
Provide Interjurisdictional Coordination ...................................................................................................... 2
Use One Communications Network for All Devices....................................................................................... 2
TYPES OF SYSTEMS SUPPORTED BY THE NTCIP ..................................................................................... 2
Types of Devices Supported .......................................................................................................................... 2
System Configurations Supported.................................................................................................................. 3
Types of Data Links Supported...................................................................................................................... 3
Types of Messaging Strategies Supported...................................................................................................... 4
Signal System Functions Supported............................................................................................................... 4
CHOOSING NTCIP OPTIONS ......................................................................................................................... 5
Protocol Profiles........................................................................................................................................... 5
Conformance Level....................................................................................................................................... 6
Optional Objects........................................................................................................................................... 6
Object Value Ranges..................................................................................................................................... 6
Physical Interface ......................................................................................................................................... 7
Maximum Address......................................................................................................................................... 7
Maximum Packet Size ................................................................................................................................... 7
DESIGNING SYSTEMS WITH THE NTCIP.................................................................................................... 7
Retrofitting Existing Systems with the NTCIP................................................................................................ 7
The NTCIP in New Systems........................................................................................................................... 8
Changes Over Time ...................................................................................................................................... 8
OTHER CONSIDERATIONS ........................................................................................................................... 9
Competition, Proprietary Interests, and Confidentiality ................................................................................ 9
Agency-Specified Features.......................................................................................................................... 10
Software and Hardware Implications of NTCIP Options ............................................................................. 11
Delivery Schedule....................................................................................................................................... 11
HOW TO INCLUDE THE NTCIP IN PROCUREMENT SPECIFICATIONS ................................................. 11
Checklist of Items to Consider .................................................................................................................... 12
Sample Language for Procurement Specifications....................................................................................... 12
FREQUENTLY ASKED QUESTIONS ........................................................................................................... 23
CHAPTER 3 SUMMARY TECHNICAL DESCRIPTION ................................................................................ 1
ABOUT THIS CHAPTER ................................................................................................................................. 1
THE NTCIP DATABASE ................................................................................................................................. 1
ENCODING THE NTCIP DATABASE FOR TRANSMISSION ....................................................................... 6
THE NTCIP AND THE ISO SEVEN-LAYER MODEL .................................................................................... 8
The Application Layer - Using STMF............................................................................................................ 8
The Presentation, Session, Transport, and Network Layers ......................................................................... 10
The Data Link Layer for Class B................................................................................................................. 10
The Physical Layer ..................................................................................................................................... 12
CALIFORNIA ASSEMBLY BILL 3418 AND NTCIP..................................................................................... 12
CREATION OF NEW MIB MODULES AND ADDING OBJECTS TO DRAFT MIBS .................................. 13
SUMMARY .................................................................................................................................................... 13
CHAPTER 4: SYSTEMS AND SOFTWARE DEVELOPERS GUIDE............................................................. 1
CENTRAL SYSTEM SOFTWARE IMPLEMENTATIONS................................................................................................ 2
Caltrans........................................................................................................................................................ 2
Washington State Department of Transportation........................................................................................... 3
FHWA........................................................................................................................................................... 3
NTCIP Exerciser........................................................................................................................................... 3
SIGNAL CONTROLLER.................................................................................................................................. 3
Caltrans........................................................................................................................................................ 3
FHWA........................................................................................................................................................... 4
VARIABLE MESSAGE SIGNS ................................................................................................................................. 4
WSDOT......................................................................................................................................................... 4
FHWA........................................................................................................................................................... 4
OTHER DEVICES ............................................................................................................................................ 4
I-95 Corridor ................................................................................................................................................ 5
RECOMMENDED REFERENCES .............................................................................................................................. 5
WORLD WIDE WEB........................................................................................................................................ 5
NTCIP JOINT STANDARDS COMMITTEE............................................................................................................... 5
CALTRANS ......................................................................................................................................................... 6
NEMA TECHNICAL COMMITTEE ......................................................................................................................... 6
ORGANIZATIONS PLANNING DEPLOYMENT OF NTCIP .......................................................................................... 6
BOOKS AND OTHER SOURCES .............................................................................................................................. 7
RFC DOCUMENTS .............................................................................................................................................. 7
COMMON DEVELOPMENT PITFALLS......................................................................................................... 8
Protocol-Related Issues ................................................................................................................................ 8
Bit and Byte Order........................................................................................................................................ 8
Extended Addresses ...................................................................................................................................... 8
Maximum Duration Between Successive Bytes .............................................................................................. 9
Response Time .............................................................................................................................................. 9
Control Byte ................................................................................................................................................. 9
Frame Handling.......................................................................................................................................... 10
CRC Algorithm ........................................................................................................................................... 11
Invalid Frame ............................................................................................................................................. 11
STMP Message Type Byte........................................................................................................................... 11
Length Values for Variable Message Fields ................................................................................................ 11
Carriers ...................................................................................................................................................... 12
Number of Devices on a Channel................................................................................................................ 12
MIB ISSUES ............................................................................................................................................... 12
NTCIP BYTE STREAM EXAMPLES ............................................................................................................ 12
Introduction................................................................................................................................................ 13
Definition of a Dynamic Object .................................................................................................................. 14
Formal Specification for Dynamic Objects.................................................................................................. 14
Configuration of Dynamic Objects.............................................................................................................. 14
Dynamic Object Definition (dynObjDef) ..................................................................................................... 14
Examples .................................................................................................................................................... 15
Configuring a Dynamic Object.................................................................................................................................15
STMP Set Request from NEMA ..............................................................................................................................18
STMP Set Response from NEMA ............................................................................................................................20
STMP Set Request from Root ..................................................................................................................................20
STMP Set Response From Root...............................................................................................................................21
STMP Dynamic Object Get Request ........................................................................................................................21
Explanation of the Event Log...................................................................................................................................21
STMP Dynamic Object Get Response......................................................................................................................23
STMP Dynamic Object Get-Next Request ...............................................................................................................23
STMP Dynamic Object Set Request-No Reply .........................................................................................................24
STMP Dynamic Object Error Response ...................................................................................................................24
Other Nondynamic Examples...................................................................................................................... 25
STMP Get Request from NEMA..............................................................................................................................25
STMP Get Response from NEMA ...........................................................................................................................26
STMP Get-Next Request from NEMA .....................................................................................................................26
Conclusion.................................................................................................................................................. 27
CHAPTER 5 PROCEDURES FOR MAINTAINING AND MODIFING THE STANDARD........................... 1
APPENDIX A ACRONYMS................................................................................................................................ 1
APPENDIX B - GLOSSARY............................................................................................................................... 6
APPENDIX C - RECOMMENDED ASC OBJECT RANGES ............ ERROR! BOOKMARK NOT DEFINED.
APPENDIX D - ITE ARTICLE......................................................................................................................... 18
Introduction
This document is a starting point for learning about the National Transportation Communications for ITS Protocol
(NTCIP). This document is not a part of the NTCIP standard: it provides an overview and explanation of the NTCIP and
guidance to those using the NTCIP. It is not necessary to first read the formal NTCIP standards documents, nor to have
the standards documents as a reference. Information about the formal standards and other documents and sources of
information related to the NTCIP are found later in this document.
The NTCIP is a family of standard communications protocols used for data transmission within and between Intelligent
Transportation Systems, (ITS). The standard covers both the "how" and "what" of data communications, that is, both the
transmission rules and the format and meaning of standardized messages transmitted using those rules. Where possible,
the NTCIP is based on existing standards in the telecommunications and computer industries.
The NTCIP aims to do for transportation systems what the Internet has done for communications between generalpurpose computers: it will help enable interoperability and interchangeability between devices and between systems from
different manufacturers. It can provide more choice, more flexibility, and the ability to coordinate the operation of
adjacent devices and systems.
The NTCIP family of protocols is continually expanding to address additional needs. The initial standard provides
protocols for real-time communications between a master or computer and such field devices as traffic signal controllers,
environmental sensor stations, dynamic message signs, highway advisory radio, closed - circuit television cameras, and
freeway ramp meters. Work is under way on additional protocols for applications such as computer-to-computer or
center-to-center data exchange, communications within transit management systems, and communications with and
between moving vehicles. The NTCIP and related standards are intended to eventually provide a comprehensive family of
communications protocols covering all ITS applications.
ABOUT THIS DOCUMENT
The document is divided into chapters, each of which deals with a different topic and is directed at a different audience. It
is recommended that the reader review Chapter 1 first; then the reader should move directly to whichever chapter deals
with the topic of interest. Each chapter stands alone− it is not necessary to read preceding chapters.
The chapters are as follows:
Chapter 1 - What Is the NTCIP? This chapter is intended for all readers and provides a brief description of the
NTCIP.
Chapter 2 - How the NTCIP May Be Used . This chapter explains what devices and situations the initial NTCIP
standard may be used for, the benefits of using it, and advice on how to write procurement specifications for systems
incorporating the NTCIP standard. Chapter 2 is intended for people responsible for purchasing or specifying ITSrelated equipment and systems (e.g., transportation engineers in public agencies that own or operate ITS systems or
who work as consultants for those agencies would benefit from reading this chapter).
Chapter 3 - Summary Technical Description. This chapter is intended for engineers and technicians who want to
understand how the NTCIP works without having to read all the detailed specifications that comprise the formal
standards documents. It describes the structure of the NTCIP including the different classes of protocols, the
different layers of the protocol stack, the message frame format, dynamic messages, the way in which devices and
---------------------------------------------------------------------------------------------------------------i
Revision 2-March 3, 1997 Draft
device specific messages are referenced using registered path names following the Internet's addressing structure,
and how data elements are defined using Abstract Syntax Notation. It also contains answers to frequently asked
questions concerning the technical details of the standard.
Chapter 4 - System and Software Developers Guide. This chapter is intended for system and software developers
responsible for implementing transportation management systems using the NTCIP. It contains "tips and traps"
advice for software developers and sample source code.
Chapter 5 - Procedures for Maintaining and Modifying the Standard. This chapter is not written at this time. The
standard maintenance procedures are still in development. A supplement to this document will be published when
the procedure is finalized. The supplement will explain the process for having new ideas reviewed and accepted for
inclusion in future versions of the standard.
Appendix A - Acronyms
Appendix B - Glossary
Appendix C - NTCIP Articles Appearing in the Institute of Transportation Engineers (ITE) Journal
This document is updated from time to time to reflect the latest version of the NTCIP and the current version of each
available document related to the NTCIP. To see whether this is the current version of this document, check the NTCIP
home page on the World Wide Web at
http://www.ntcip.org.
---------------------------------------------------------------------------------------------------------------ii
Revision 2-March 3, 1997 Draft
Chapter 1: What Is the NTCIP?
The National Transportation Communications for ITS Protocol (NTCIP) is a standard for transmitting data and messages
between electronic devices used in Intelligent Transportation System, (ITS). An example of such a system is a computer
at city hall monitoring and directing the operation of microprocessor-based controllers (effectively roadside computers) at
traffic signals in a city. The computer regularly sends instructions to the traffic signal controllers to change timings as
traffic conditions change and, the controllers send traffic flow and status information to the computer. In another
example, two transit management systems (computers) exchange real-time information about the location of transit
vehicles bound for a shared timed-transfer center, so each system knows instantly whether one vehicle is running
significantly behind schedule and is unable to make the scheduled transfer time. Passengers can also be notified
automatically, and the local traffic management center can be automatically requested to provide priority for the delayed
transit vehicle at traffic signals.
A communications protocol is a set of rules for how messages are coded and transmitted between electronic devices. The
equipment at each end of a data transmission must use the same protocol to successfully communicate. It is a bit like
human languages that have an alphabet, vocabulary, and grammar used by everyone speaking that language.
Before the NTCIP was developed, each vendor of electronic devices and software used in transportation management
systems adopted a different protocol for data communications. This made it very difficult to mix equipment and software
from different vendors in the same system and to communicate between systems operated by adjacent agencies. The
NTCIP provides a common standard that can be used by all vendors and systems developers.
WHAT TRANSPORTATION MANAGEMENT SYSTEMS CAN USE THE NTCIP?
The NTCIP is comprehensive and flexible; it actually defines several different protocols. For example, it provides a
protocol that can be used with traditional equipment and communications infrastructures and others that are designed for
use with new and emerging technologies. The NTCIP will eventually cover most types of devices and systems used in
ITS, including systems for managing traffic and transit operations, traveler information, and multimodal systems
integration.
Initially, traffic signal management systems are a major application for the NTCIP. The NTCIP can be used with all types
of traffic signal controllers, including National Electrical Manufacturers Association (NEMA) controllers, the Model 170
controller and variations thereon, and the Model 2070 and similar advanced controllers. The NTCIP can be used in all
types of signal systems, including central control (second-by-second control), two-level distributed systems (no field
masters), and three-level distributed systems (closed-loop systems with field masters). The current version of the NTCIP
supports communications between controllers and field masters or computers. Field controllers can operate traffic signals,
dynamic message signs, closed-circuit television cameras, ramp meters, environmental sensors, and other devices.
The initial NTCIP protocol development effort focused on a standard for traditional direct communications between a
master and multiple field devices sharing a communications cable or channel and low-speed communications such as
1,200 baud. This is the most common type of system used today. A standard protocol suited to this application ("Class
B") was developed and has been published by NEMA. Standard messages ("objects") that can be transmitted using the
Class B protocol are being defined for the following field devices:
• Global objects (common to all devices and will be published early in 1997)
• Actuated signal controllers (object set is defined and will be published early in 1997)
---------------------------------------------------------------------------------------------------------------1
Revision 2-March 3, 1997 Draft
•
•
•
•
•
•
Dynamic message signs (publication expected in mid)
Environmental sensor stations (publication expected in mid)
Highway advisory radio (publication expected in mid)
Freeway ramp meters (publication expected in mid)
Video camera control (publication expected later in 1997)
Traffic sensor stations (publication expected later in 1997).
In addition to the Class B protocol, other protocols are being developed as follows:
•
•
•
•
Class A
Class B
Class C
Class E
-
similar to Class B but able to be routed through intermediate devices
basic protocol for use on low bandwidth communications channels
similar to Class A but able to transfer files efficiently
designed for center-to-center data exchange.
The Class A and C protocols provide features not available in the Class B protocol, but the added functionality also adds
overhead that increases the message delivery time significantly unless higher bandwidth channels are used. Class B is a
"stripped down" protocol that provides basic services for multiple devices on a low-bandwidth channel. The same
messages can be sent using any of the Class A, B, or C protocols, but both ends of the transmission must support the same
protocol. A device may support multiple protocols.
Chapter 2 more fully describes the different applications of the NTCIP, the benefits of using this standard, and guidelines
for including NTCIP in procurement specifications. The technical details of the different protocols are described fully in
Chapter 3.
HOW THE NTCIP WAS DEVELOPED
In 1992, in response to frequent requests for standardization from the users of traffic signal controllers, NEMA began
discussions on the development of a common communications protocol for traffic signal systems. To encourage and
broaden the process, the Federal Highway Administration (FHWA) sponsored a symposium in May 1993 to bring users
from around the country together with manufacturers and software developers for both NEMA and Model 170 controllers.
Over the next two and a half years, a NEMA working committee, with representatives from all types of traffic signal
controller and signal system developers, held open meetings every few months to produce in December 1995 the first
version of the NTCIP. That version defined a standard protocol for traffic signal systems.
In February 1995, FHWA convened another symposium to review progress and to discuss further development of the
NTCIP. The meeting revealed widespread support for the NTCIP and a desire to extend its scope to cover transportation
management devices other than traffic signals. An NTCIP steering committee was established with representatives of
users, designers, and developers of all types of ITS and including members from the public, private, and academic sectors.
The committee convened in May 1995 and met every 6 weeks or so.
In a further effort to speed the development of ITS standards, FHWA in late 1995 solicited proposals from standards
development organizations interested in contracting with the Federal Government to develop ITS standards. Five
organizations were selected to receive up to $5 million of initial funding. In September 1996, a consortium comprising of
the American Association of State Highway Transportation Officials, ITE, and NEMA was awarded funds to jointly plan,
oversee, and execute further development of the NTCIP. The NTCIP steering committee was renamed the NTCIP Joint
Standards Committee and expanded to include six representatives from each of the three organizations.
---------------------------------------------------------------------------------------------------------------2
Revision 2-March 3, 1997 Draft
Activities undertaken by the NTCIP Joint Standards Committee include the following:
• Planning and overseeing further development of the NTCIP
• Forming working groups to develop additional elements of the NTCIP
• Guiding the use of FHWA funds for contract services in support of the NTCIP
• Guiding the development of a "protocol exerciser" for testing NTCIP implementations
• Coordinating with related ITS and communications standards development efforts in the United States and
internationally
• Writing this NTCIP guide
• Other outreach and promotional activities, including ITE Journal articles, the NTCIP web site, and various
presentations and demonstrations.
CURRENT NTCIP ACTIVITIES AND HOW YOU CAN HELP
The NTCIP is continually being enhanced and expanded. Work is under way to add protocols or standard message
definitions for more field devices, transit facilities, and center-to-center data exchange. Most of this work is performed by
volunteers from the ITS community. Assistance and input is needed and welcomed from everyone.
The following are some ways that you can help advance the NTCIP:
• Contact the NTCIP Joint Standards Committee chairman, Ed Seymour (phone: 972-994-0433, fax: 972994-0522, e-mail: [email protected]) if you want to join a working group developing any of the NTCIP elements.
• If you just want to review and comment on documents prepared by a working group, monitor the activities of
each group via the NTCIP Web site (http://www.ntcip.org) and download or ask for documents available for
review.
• Use the NTCIP in projects and provide feedback on implementation experience.
• Specify that all new equipment and systems be NTCIP compatible, even if not needed immediately, so that the
population of devices in the field will be compatible as quickly as possible.
OTHER SOURCES OF INFORMATION ABOUT THE NTCIP
The following are some further sources of information about the NTCIP:
• The Class B protocol technical specifications have been published by NEMA as documents TS 3.2 (National
Transportation Communications for ITS Protocol - Simple Transportation Management Framework) and TS
---------------------------------------------------------------------------------------------------------------3
Revision 2-March 3, 1997 Draft
3.3 (National Transportation Communications for ITS Protocol Class B Profile). These documents and an
overview document (TS 3.1) are available from NEMA at 703-841-3200.
• The NTCIP home page on the World Wide Web (http://www.ntcip.org) provides historical and current
information about the standards development activities, including downloadable files of technical papers and
draft standards for review.
• The “Standards Activities” column in the ITE Journal provides highlights of NTCIP activities.
• The NTCIP coordinator at NEMA in Arlington, Virginia, is Bruce Schopp, and he is available to answer
questions or refer you to others who can help. Contact him by telephone at 703-841-3231, fax at 703-841-3331,
or e-mail at ([email protected]).
---------------------------------------------------------------------------------------------------------------4
Revision 2-March 3, 1997 Draft
Chapter 2: How the NTCIP May be Used
This chapter is intended for those responsible for the procurement of ITS equipment, including traffic signals and other
transportation management systems. It describes how the National Transportation Communications for ITS Protocol
(NTCIP) benefits users, the different types of transportation management systems that the NTCIP supports, how to choose
between the various options available in the NTCIP, issues to consider in system design, how to incorporate the NTCIP in
specifications for equipment procurement contracts, answers to questions frequently asked by users, and sources of further
information for users.
This document is updated from time to time to reflect changes in the NTCIP. To see whether this is the current version of
this document, check the NTCIP home page on the World Wide Web at http://www.ntcip.org or contact the NTCIP
coordinator, Bruce Schopp, at NEMA (phone 703-841-3231, fax 703-841-3331, e-mail: [email protected]).
WHY THE NTCIP SHOULD BE SPECIFIED IN ALL PURCHASES
The NTCIP offers increased flexibility and choice for agencies operating transportation management systems. It removes
barriers to interjurisdictional coordination and allows equipment of different types and manufacturers to be mixed on the
same communications line. For these reasons, operating agencies will benefit from specifying that the NTCIP be included
in all future purchases and upgrades, even if the NTCIP is not planned to be used initially.
Avoid Early Obsolescence
Even though it may not be practical to retrofit NTCIP support in some old equipment, most vendors will offer NTCIP
support in current and future products. It is possible to operate a mixture of NTCIP and non-NTCIP devices in the same
system, although not on the same communications line. Alternatively, equipment may continue to use a current protocol
even though it also supports NTCIP. In either case, an operating agency can ensure that its equipment remains useful and
compatible long into the future by requiring NTCIP support in all future purchases and upgrades of transportation
management systems, including purchases of individual masters and controllers for any type of traffic control, monitoring,
or traveler information device.
Buying a field device, such as a signal controller or sign controller, or a field master or central control system that has no
software available to support the NTCIP, is like buying an incompatible computer that has no software available to access
the Internet. Even if purchasers do not use the Internet now, they surely will during the lifetime of the computer.
Provide Choice of Vendor
Once an agency has a master or computer system that includes support for the NTCIP, it can purchase field devices or
software from any manufacturer offering NTCIP-compatible products, and they will communicate with that master. Only
products from the same vendor will be able to fully use the features within the master or controller that are manufacturer
specific, but basic functionality will be available regardless of the manufacturer.
To gain the full benefit of a particular manufacturer's unique features, and for other reasons such as ease of maintenance,
many agencies will likely continue to standardize on a single vendor. However, the NTCIP will make it easier for such an
agency to gradually change its controllers and other field devices from one vendor to another in the future as part of a
switch to a new vendor for the entire system.
---------------------------------------------------------------------------------------------------------------1
Revision 2-March 3, 1997 Draft
Provide Interjurisdictional Coordination
In traffic signal systems in particular, it will be very useful for an agency to be able to communicate with and implement,
at least, basic monitoring and signal coordination functions for adjacent controllers that are owned by other agencies and
may be from a different vendor. Furthermore, such "foreign" controllers can be added on to an existing communications
channel and mixed with different types of controllers on the same line.
Future enhancements to the NTCIP will address system-to-system links. This will solve the problem of two masters
needing to communicate with each other for the purpose of coordination and monitoring of devices operated by adjacent
jurisdictions.
Use One Communications Network for All Devices
The NTCIP also allows a master to communicate with a mixture of device types on the same communications channel.
For example, with the addition of appropriate application software in the master, a variable message sign could be
installed near a signalized intersection, and the master could communicate with the sign controller using the
communications channel already in place for the traffic signal controller. The communications network is usually the
most expensive component of a transportation management system. The NTCIP ensures maximum flexibility in future
use of that major investment.
TYPES OF SYSTEMS SUPPORTED BY THE NTCIP
Types of Devices Supported
The NTCIP defines a family of general-purpose protocols that support all types of devices used in transportation
management systems. The initial NTCIP standard also defines device-specific application-level objects, or messages, for
traffic signals. Work is underway to add object definitions for dynamic message signs, closed-circuit television (CCTV)
camera control, ramp meters, vehicle detection/count stations, highway advisory radio, environmental sensors, and other
devices.
The underlying layers of the basic communications protocols in the NTCIP can support communications for almost any
type of field device. The standard also includes a set of objects, or messages, specific to each type of device. For example,
CCTV camera control requires a message such as "Pan right x degrees," which is not needed for other devices. Messages
that are common to most device types, such as "Set date and time," have been placed in a set of global messages. The
device type-specific messages, combined with the global messages and the underlying layers of the NTCIP (which are also
common to all devices), define a complete protocol for each device.
---------------------------------------------------------------------------------------------------------------2
Revision 2-March 3, 1997 Draft
Since all devices use the same fundamental protocol, different types
of devices can be mixed on the same communications channel. For
example, a variable message sign could be inserted between two
different types of traffic signals in a daisychain of devices on the
same communications line, as illustrated in Figure 1. Furthermore,
communications software developed for one type of device can be
used with little change for other devices.
The NTCIP is independent of the hardware used. For example, the
NTCIP can be used directly with any type of traffic signal controller.
It does not matter if the signal controller follows the National
Electrical Manufacturers Association (NEMA) TS-1 standard, TS-2
standard, the Model 170 standard, the Model 2070 standard, or no
standard at all, so long as its software implements typical North
American phasing and timing logic. Some different messages
would need to be defined for controllers that embody European,
Australian, or Japanese controller logic. Additional messages can
be defined by a controller or software vendor to address any features
unique to that vendor.
System Configurations Supported
Figure 2.1 Communications with
Different Devices
One of the fundamental principles of the NTCIP is that it is
independent of the way in which a transportation management
system is configured. For example, the NTCIP can be used in any
of the typical traffic signal system configurations, including these:
• Central control (e.g., Urban Traffic Control System (UTCS))
• Two-level distributed control (e.g., interconnected time base without field masters)
• Three-level distributed control (e.g., typical "closed-loop" systems).
The initial version of the NTCIP assumes that all field devices will communicate with a master of some kind. That master
may be a central computer, a field master, or another field device (e.g., a device controller that acts as a master as well as a
local controller). Future extensions to the NTCIP will add support for intermediate management stations and for
contention-based peer-to-peer communications in which devices can report an event or exception at any time without
having to wait to be polled.
Types of Data Links Supported
The NTCIP can be used over almost any type of direct communications link. Examples of different types of
communications media that could be used include twisted pair, coaxial cable, optical fiber, and radio (e.g., narrow band,
spread spectrum, microwave). It does not matter whether the communications media is agency owned, leased, or dial-up.
Any data transmission rate could be used, from say 300 bits per second to many megabits per second, if the devices
support those speeds. It does not matter whether the communications configuration uses concentrating hubs or
multiplexers to combine multiple channels on trunk links.
---------------------------------------------------------------------------------------------------------------3
Revision 2-March 3, 1997 Draft
The only requirement is that the time of transmission, and any turnaround delay time in transmission devices such as
modems, be reasonably small and consistent. The protocol is based on polling, and the master cannot wait indefinitely for
a response message. If the time between when the last byte of a message leaves the master and the first byte of the
response arrives at the master is too long (e.g., half a second), it will not be possible to poll many devices on the same
channel within 1 or 2 seconds, which is a typical polling cycle for many traffic signal systems.
The NTCIP can be used with both half- and full-duplex circuits.
As discussed below, the NTCIP Class B protocol is designed for use with slower communications links, such as 1,200
baud. However, it involves some more overhead than most of the proprietary protocols in use today, and it may not be
possible to maintain the same polling cycle time with the same number of controllers per channel and the same baud rate.
Types of Messaging Strategies Supported
The initial version of the NTCIP is based exclusively on polling as a messaging strategy. This messaging strategy is used
almost universally in the industry today. Polling involves the masters sending a request message addressed to a particular
device, and that devices sending back a response message. The field device can speak only when spoken to.
The NTCIP also allows the master to broadcast messages to all field devices on a channel simultaneously. The protocol
includes support for future "trap" messages, which are event-driven messages sent by the field device at the next poll.
This will enable a field device to report unusual events and faults when they occur without having to send complete status
information at every poll.
The NTCIP allows the use of "dynamic" messages that may combine several shorter messages for efficient
communications. This enables a system to use custom combinations of data in messages, smaller messages with less
overhead, and messages suited to particular needs, while still using standard message components and still allowing
communication with any NTCIP- compliant device. Dynamic messages can be as short as 8 bytes, including the opening
and closing flags. Poll-only messages from the master can be as small as 6 bytes.
Planned enhancements to the NTCIP include support for peer-to-peer communications and an event-driven messaging
strategy as an alternative to polling. Peer-to-peer options within the NTCIP would be used for communications between
computers (e.g., computers in different traffic management centers) on a wide area network, for direct communications
between local controllers, and for event-driven communications between computers and field devices. Applications for
these capabilities include data exchange and coordination between jurisdictions, traffic signals that interact locally to
optimize coordination without having to use a common background cycle length, and the ability to economically use
commercial switched-packet networks for communications between a computer and field devices.
Signal System Functions Supported
The initial version of the NTCIP provides messages directly supporting the most common functions and features of traffic
signal systems, including the following:
•
•
•
•
•
Setting controller clocks
Uploading traffic volumes and occupancy
Instructing controllers to change to a particular coordination pattern
Monitoring such signal status as phase color, phase demand, and detector status
Monitoring the controller for faults and alarm conditions
---------------------------------------------------------------------------------------------------------------4
Revision 2-March 3, 1997 Draft
• Checking and changing settings in the controller database.
These and other supported functions cover most of the features common to modern traffic signal systems, including
dynamic map displays of groups of signals and dynamic graphic displays of individual intersections.
Most controller software incorporates some unique features and parameters. Some of these may require special messages
to be defined. This can be done by the software or controller vendor using a standard procedure defined within the NTCIP
and described below. This enables the standard to evolve and accommodate innovation and advances in traffic control
systems.
CHOOSING NTCIP OPTIONS
The NTCIP has been designed to be very flexible, so as to support the wide variety of current and future configurations
and features of modern transportation management systems. The NTCIP incorporates several options that a system
designer can choose from.
Protocol Profiles
The NTCIP will soon define two alternative protocol "profiles" suitable for field devices as described in the Institute of
Transportation Engineers papers appended to this document. A system designer will be able to specify that equipment or
software support Class A Profile, the Class B Profile, or both.
The Class B profile defines a simple connectionless protocol that is very efficient in terms of minimum overhead, but can
be used only for point-to-multipoint communications. The Class A profile is an enhanced connectionless protocol that
supports full network addressing and message routing, and therefore can be used in any network configuration.
Class A enables messages to be routed via intermediate devices, such as a field master or communications hub. Class B
requires the communicating devices to be directly connected with no intermediate devices (although other devices can
share the same communications channel). The added flexibility of Class A comes at the price of extra overhead that
increases the transmission time. In general, Class A is intended for high-speed communications links where message
routing is needed such as between a computer and next-generation controllers (e.g., the Model 2070 controller) via a
communications hub, or for low-speed indirect communications links where frequent real-time transmissions are not
needed. Figure 2 illustrates an application.
---------------------------------------------------------------------------------------------------------------5
Revision 2-March 3, 1997 Draft
The Class B profile is intended for typical low-speed (e.g., 1,200
to 4,800 baud) direct communications with the current
generation of field controllers. A master that supports both
profiles can communicate on the same communications channel
with controllers that use either profile. Therefore, it is generally
useful for masters to support both profiles. A field master or
communications hub may also communicate with controllers
using Class B and with a central computer using Class A.
The contents of the messages sent are the same regardless of
whether the Class A or Class B profile is used. They are just
different ways of transmitting the same information.
Conformance Level
There are two conformance levels to choose between, regardless
of which class profile is used. A system designer must specify
one or the other. Conformance Level 1 is a subset of Level 2.
The difference between the two conformance levels is that Level
2 adds support for the Simple Network Management Protocol,
including global Internet objects.
Figure 2.2
Example of Class A
Communications
Conformance Level 1 provides basic functionality suitable for
most applications. Conformance Level 2, which is a superset of
Level 1, provides exactly the same functionality as Level 1 and
adds the option to use additional security features such as
passwords and multilevel access control for individual messages.
If such additional features are used, the message transmission
time will be increased and is, therefore, usually not practical for
use with low-speed communications links.
Optional Objects
The NTCIP defines groups of objects (messages) that are optional and can be included or excluded from a procurement
specification. It is generally advisable to require support for all optional objects, even if not needed initially. However,
prospective vendors should be consulted to ensure that specification of such objects will not incur significant additional
cost or delay.
Object Value Ranges
The NTCIP does not specify the range of valid values for each object. This can be left to the vendor, but the range for
some objects, such as phase yellow time, may be important for failsafe operation. A suggested value range for objects has
been provided as an appendix to this Guide. This appendix may be referenced in a procurement specification.
Modification to specific object ranges can be included in the specification if needed.
---------------------------------------------------------------------------------------------------------------6
Revision 2-March 3, 1997 Draft
Physical Interface
The NTCIP requires either RS-232 or FSK modem for the interface to the physical communications link. Additional
interfaces may also be provided as needed. An RS-232 interface provides maximum flexibility, including the use of an
external FSK modem. An internal FSK modem avoids the need for an external modem but may preclude the use of other
transmission schemes, unless the device also has an RS-232 port. The important thing is that compatible modems or
other transmission equipment are provided at both ends of each communications link.
Maximum Address
The NTCIP specifies that at least 62 devices are addressable on one communications channel. This is normally sufficient.
However, the system designer may specify a larger number if needed. Use of a larger number will add 1 more byte to all
messages and increase message transmission time a little. In practice, polling cycle time considerations usually limit the
practical maximum number of devices on a channel to considerably less than 62.
Maximum Packet Size
The NTCIP specifies that the device support packet sizes of up to 515 bytes. This is normally sufficient. However, the
system designer may specify a larger maximum packet size if needed. Use of larger packets will increase the time that the
system needs to allow for message transmission.
DESIGNING SYSTEMS WITH THE NTCIP
Retrofitting Existing Systems with the NTCIP
It may not be feasible to modify old versions of controllers or controller software to make them NTCIP compatible. If such
controllers or software cannot be upgraded or replaced, traffic control systems that continue to make use of older
equipment or older software versions will likely have to continue using the protocols unique to communications with those
devices. However, current version controllers and software within the system can be modified to use the NTCIP, and all
future versions should be NTCIP compatible.
NTCIP-compliant traffic signal controllers satisfy the requirements of California's AB 3418 legislation, which requires a
standard protocol in all new and upgraded controllers. However, the AB 3418 protocol does not provide NTCIP
compliance and provides only very limited functionality. The AB 3418 protocol is a small subset of the NTCIP.
NTCIP and non-NTCIP devices cannot be mixed on the same communications channel. Therefore all devices sharing a
channel must be upgraded simultaneously. A master that communicates with both NTCIP and non-NTCIP devices will
need to use a different communications port for NTCIP devices and for non-NTCIP devices, and will need to support both
protocols. In traditional closed-loop signal systems, the most likely and simplest solution is to limit each field master to
one protocol. Only field masters with NTCIP-compatible controllers would be upgraded to support NTCIP. This avoids
the need for field masters to simultaneously support two protocols on two separate ports.
In closed-loop traffic signal systems, the central computer could communicate with field masters using a different protocol
than that used by the field master to communicate with controllers. The central computer could also use different
protocols to communicate with different field masters, even using the same communications port, assuming that
communications are with only one field master at a time. As with the controller and the field master, the central computer
---------------------------------------------------------------------------------------------------------------7
Revision 2-March 3, 1997 Draft
software will need to be modified to add support for the NTCIP protocol if the NTCIP is to be used for communications
with field masters.
Any upgrade of an existing system to add support for the NTCIP is probably best designed in consultation with the system
vendor. Each vendor will likely adopt an upgrade strategy that is most efficient for the majority of its customers. If a
particular customer wants a unique arrangement, that customer will probably have to pay the full cost of the software
modifications, whereas the cost of the general solution will be spread among many customers.
One approach to the introduction of the NTCIP is to operate two totally separate systems-one NTCIP and one nonNTCIP-during a transition period. Field devices can gradually be switched over from one to the other as they are
replaced or their software is upgraded. This may be the only choice if the current system is quite old and upgrading it for
NTCIP is not practical. Such a transition would logically be done as part of a general system upgrade.
Even if a system continues to use a proprietary protocol, new controllers and masters, or new software packages, it should
include NTCIP support as an option. Some vendors will support both their existing protocols and the NTCIP in the same
software package. Others will require a change of software to switch from one protocol to the other. Regardless of how it
is done, the owning agency should ensure that NTCIP support is available for future use even if it is not needed
immediately. This will maximize the useful life of the new equipment and enable introduction of the NTCIP at any time
in the future without further upgrades. It also maximizes options and competition when choosing new equipment, since
different vendors' equipment can be mixed if needed.
As discussed above, the NTCIP Class B protocol may involve more overhead than the existing proprietary protocol, and it
may not be possible to maintain the same polling cycle time with the same number of controllers per channel and the
same baud rate. This issue can be critical for signal systems, such as UTCS, that use second-by-second central control,
and may require use of a higher baud rate or additional communications channels. Two masters, or one master
supporting both the proprietary protocol and the NTCIP can be used to gradually transition to an all-NTCIP system as
controllers (and communications equipment, if necessary) are upgraded over time.
The NTCIP in New Systems
An agency that is able to "start from scratch" with all new controllers, or all new software, can implement the NTCIP for
an entire system very easily. It is then unnecessary to accommodate a mixture of NTCIP and non-NTCIP devices. From
an operating agency's point of view, it is only necessary to specify the NTCIP options to be used for communications in the
new system.
One of the powerful features of the NTCIP standard is the ability for a master to communicate with different types of
controllers or controller software packages. This feature is often needed when one or two controllers within a group of
closely spaced signals is owned by a different jurisdiction. Even if one agency is implementing a totally new system, it
may still have a need to communicate with different controllers owned by another agency. Therefore, even if a new
system is designed to use the Class A profile for all communications, the master should still have the ability to use Class B
communications for other agencies' controllers.
Changes Over Time
Competition between controller and software vendors leads to innovation and unique features and functions. The vendors
respond to customer feedback and continually improve their product to better meet user needs. The NTCIP recognizes
that such innovation is desirable and must be accommodated within the communications standard. Hence the NTCIP
provides for manufacturer-specific management information base (MIB) modules, which can be created by a vendor (or
---------------------------------------------------------------------------------------------------------------8
Revision 2-March 3, 1997 Draft
an agency) at any time to define new features and the associated unique messages. MIB modules are described in detail in
another chapter. An agency wanting additional features may define its own MIB module and include it in the
specifications for new equipment or software.
These additional MIB modules are extensions to the NTCIP. Agencies purchasing new equipment or software should
specify that all manufacturer-specific MIB modules be supplied on a disk so that support for the additional features can be
implemented in the management system. Over time, as multiple vendors come to offer effectively the same feature, many
such innovations will become "standard" and no longer offer a competitive edge to one supplier. Then the feature can be
added to the set of standard messages within NTCIP rather than remaining manufacturer specific.
Additional MIB modules are one way in which the NTCIP will be continually enhanced over time. Agencies may want to
upgrade their systems from time to time to take advantage of such enhancements. Another source of change in the
NTCIP over time will be the addition of more protocol profiles, which will tend to address specialty applications and will
have less impact on existing systems. The profiles will be of interest to agencies starting new systems, linking with
adjacent agency systems, or wishing to use commercial communications networks.
Current controller and master software will have to be modified to support the NTCIP. Most vendors of traffic signal
systems (and many vendors of others devices such as CCTV camera controllers and variable message signs) have
indicated an intent to make those software modifications, at least for future product versions. The cost of software
modification will be small on a per unit basis. Most vendors are expected to continue to offer their current proprietary
protocol as an alternative to NTCIP, or for use in mixed systems, at least for several more years. However, vendors will
not want to support two different protocols indefinitely and may drop the old protocol from future products. To avoid
being left with an unsupported and incompatible communications protocol, users can ensure that all future purchases
include support for the NTCIP and that proprietary protocols are replaced with the NTCIP as soon as possible.
OTHER CONSIDERATIONS
Competition, Proprietary Interests, and Confidentiality
Agencies responsible for traffic management are best served if they can choose between multiple competing vendors for
all elements of traffic management systems. Vendors will always compete on the basis of price and support, but
competition in system functionality is also desirable to continually advance the state of the art through innovation. A
vendor will not invest in research and development of new functions if the results cannot be kept proprietary to that
company to ensure that a marketing advantage accrues from the development effort.
As discussed above, the NTCIP allows for manufacturer-specific MIB modules to address the need for proprietary
features. It is unrealistic to expect vendors to openly publish documentation, including MIBs, that reveal the workings of
proprietary developments. A procurement specification that requires disclosure of proprietary MIB modules to
competitors may result in either no conforming proposals or significantly higher priced proposals.
As already noted, it may be reasonable to require disclosure of proprietary MIB modules to a systems integrator. However,
the procuring agency needs to provide assurance that the information will be kept confidential by all involved parties and
that it will not be used except as allowed for in the contract.
If an agency is concerned about the "one-supplier" limitation of proprietary features, it can always choose to limit its
system to use only nonproprietary NTCIP elements (except for some necessary manufacturer-specific information). This
---------------------------------------------------------------------------------------------------------------9
Revision 2-March 3, 1997 Draft
can be done in either of two ways. The first option is for the agency to specify use of only the current NTCIP standard
objects, with no unnecessary manufacturer-specific extensions allowed. This will ensure that equipment from all vendors
complying with the NTCIP will be compatible and usable in the system without modification. However, this fails to take
advantage of any extended functionality, and may exclude some systems that use proprietary features in such a way that
they cannot be "switched off" to revert to a generic standard NTCIP implementation.
The second option is to allow vendors to offer the NTCIP standard objects plus any nonstandard objects the vendor is able
and willing to provide open documentation for, including MIB modules that can be given to any vendor to facilitate
integration of other vendor's equipment. This option will likely result in the availability of additional features and
functionality on which the user may become dependent. However, full use of those features with third-party equipment
may not be feasible without some additional systems integration effort and, therefore, cost. This option may also exclude
some systems that use proprietary features in such a way that they cannot be "switched off" to limit the operation to only
those features for which the vendor is prepared to reveal documentation to competitors.
Agency-Specified Features
An operating agency may choose to develop its own extensions to the NTCIP and require that vendor proposals include
support for these extensions. Unless the agency represents a large market in itself, or other agencies adopt the same
extensions, the number of vendors able and willing to add the additional features may be severely limited, and the system
cost (initial and maintenance) may be significantly increased by the need to add and support such custom features.
Agency-specific extensions may be necessary for totally new and unique features developed and implemented within an
agency. Agency-specific extensions are not recommended for minor features or as custom replacements for NTCIP
standard objects, the only purpose of which is to implement the standard feature in a "better" way.
It is conceivable that a group of customers (preferably with the cooperation of vendors) could collaborate to define a set of
NTCIP extensions (experimental MIB modules), which they all include in their standard specifications. Such extensions
may become a de facto standard by virtue of the market represented by those customers and would likely quickly be added
to the NTCIP standard objects.
Such a process may be used as a way to expedite updates to the NTCIP standard without having to wait for the formal
NTCIP revision procedures. However, it will be successful in this regard only if a broad cross-section of customers and
vendors are included in the development of the experimental MIB modules. Development of significant numbers of
specific extensions by individual large agencies or a limited group of agencies will probably result in the proliferation of
multiple "standards" and will defeat the basic intent of the NTCIP.
Any attempt by agencies to specify NTCIP extensions must also take into account the time required for vendors to develop
the custom features as well as the level of support that can be expected in the future if the extension does not become a part
of the NTCIP standard. An agency may find itself with a unique version of software that is no longer actively supported,
is supported only at additional cost, and is likely to not be available from other vendors. The feature is also likely to not be
available in systems operated by neighboring agencies with which shared communications may be desirable in the future.
In general, agencies are encouraged to work together and with vendors to cooperatively evolve the NTCIP to address the
needs of everyone. This process will inevitably involve compromise but in the long run will ensure an enduring and
effective standard, the benefits of which will outweigh any short-term limitations.
---------------------------------------------------------------------------------------------------------------10
Revision 2-March 3, 1997 Draft
Software and Hardware Implications of NTCIP Options
The NTCIP is primarily a software specification. It defines the functions and objects that need to be provided or supported
by software used in data communications. It is possible to develop software (for a particular device) that supports all of the
above-discussed NTCIP options within one software package in such a way that the end user can choose between the
options for any particular application. This obviously gives the user the most flexibility.
However, some of the above options are useful only if the rest of the system design also supports them. This includes
system configuration, hardware, and software in other devices. A system procurement specification that requires full
support for all of the NTCIP options may result in an unnecessarily expensive system. Even if a particular option will be
needed in the future, it may be better procured as part of a future system upgrade rather than in the initial system
procurement.
Delivery Schedule
It takes time for vendors to modify software packages to add support for the NTCIP. Once a version of the NTCIP is
released and becomes available, vendors must write software, test it, debug it, and integrate with other system components.
These procedures may take up to 12 months or more for complex systems. Vendors may also have to wait until several
proposed enhancements are combined in a single software upgrade. Delivery schedules included in procurement
specifications need to take this process into account. This does not necessarily mean that procurements need to be held up
while waiting for NTCIP software to be completed. It is often possible to operate systems using a previous version of
communications software while waiting for the new version. Many systems may not even implement the new NTCIP
version when it is ready, but only make it available for future use when needed.
In any case, discussions with prospective vendors can reveal what schedule is reasonable for delivery of an NTCIP version
of software. A procurement contract can specify that the system operate with older software initially and that the new
version be installed and made operational by some future date. A payment retainer should be held to ensure compliance.
If the agency has no current need for the NTCIP version of the software, but wants to have an NTCIP compatible system
for future use and compatibility with future equipment, then the new software need only be supplied and demonstrated to
be functional without actually being put into use. It is even possible to have software supplied on a ROM chip or on disk
but not actually installed, except temporarily for testing and demonstration purposes.
As updates are made to the NTCIP over time, agencies may choose to upgrade their software to incorporate the latest
version or wait until a future upgrade if those additional features are not needed right away. A long-term contract may
require use of the "most recent available version of the NTCIP.” It is not practical to require a vendor to supply software
compatible with the "current version of the NTCIP," since the standard may be updated at any time and the vendor
requires a reasonable amount of time to implement the changes.
HOW TO INCLUDE THE NTCIP IN PROCUREMENT SPECIFICATIONS
The following guidelines apply to all types of procurement contracts and solicitations, including bidding, competitive
proposals, and sole-source negotiations.
---------------------------------------------------------------------------------------------------------------11
Revision 2-March 3, 1997 Draft
Checklist of Items to Consider
The following are items to be considered in preparing a specification for procurement or upgrade of a traffic management
system or any component of such a system:
• Which devices require NTCIP support to be included at this time (e.g., signal controllers, sign controllers,
camera controllers, field masters, central computers)?
• Which of the NTCIP options discussed in are to be selected?
• What delivery schedule is reasonable for the NTCIP components?
• What experimental MIB modules are needed?
Sample Language for Procurement Specifications
In the following sample language templates, optional and alternative items are shown in a list. Dates and other items to
be replaced by actual values are indicated as such. Some sentences or the entire paragraph may need to be repeated for
different devices.
Sample Procurement Specification Text:
SECTION 1:
The
• field device
and/or
• controller
and/or
• field master
and/or
• central computer
software shall comply with the referenced National Transportation Communications for ITS Protocol
(NTCIP) Standards
• when installed
or
• prior to DATE.
The software shall comply with the versions of the relevant NTCIP standards that are current at the
date of this document, or a later version.
The software shall comply with NEMA TS 3.2 the Simple Transportation Management Framework,
and shall meet the requirements for Compliance Level
• 1
or
• 2.
---------------------------------------------------------------------------------------------------------------12
Revision 2-March 3, 1997 Draft
The software shall comply with NEMA TS 3.3 the Class B Profile, and shall include an
• EIA/TIA 232-E
and/or
• FSK modem
interface for NTCIP based communications.
(NOTE: Other classes are under development and will be available in the future but they are not yet
considered in these procurement specification samples)
SECTION 2:
The software shall implement all mandatory objects of all mandatory conformance groups as defined
in
• Gobal Object Definitions, NEMA TS 3.4
and
• Actuated Signal Controller Object Definitions, NEMA TS 3.5
or
• Dynamic Message Sign Object Definitions, NEMA TS 3.6
(NOTE: The following sentences are optional within any one specification)
The software shall also implement all mandatory objects of the following optional conformance
groups as defined in
• Global Object Definitions, NEMA TS 3.4
* Reports
* PMPP objects [These need updating]
* STMP objects
and/or
• Actuated Signal Controller Object Definitions, NEMA TS 3.5
* Generic
* General
[These need updating]
* Phase
* Detector
* Unit
* Coordination
* TimeBase
* Preempt
* Miscellaneous
* Ring
* Channel
* VehicleOverlap
* Report
* TS2 (if desired)
---------------------------------------------------------------------------------------------------------------13
Revision 2-March 3, 1997 Draft
or
• Dynamic Message Sign Object Definitions, NEMA TS 3.6
* <To be determined>.
The software shall also implement the following optional objects as defined in the
•
Global Object Definitions, NEMA TS3.4
* <To be determined>
and/or (NOTE: pick only objects from one of the following two Standards)
• Actuated Signal Controller Object Definitions, NEMA TS 3.5
* phaseCarsBeforeReduction
* preemptControlTable
* ringControlTable
* eventClassTableor
• the Dynamic Message Sign Object Definitions, NEMA TS 3.6
* <To be determined>
SECTION 3:
All objects required by these procurement specifications shall support all values within its
standardized range, unless otherwise approved by the PROJECT ENGINEER. The standardized range is
defined by a size, range, or enumerated listing indicated in the object’s SYNTAX field and/or through
descriptive text in the object’s DESCRIPTION field of the relevant standard. The following provides the
current listing of known variances for this project.
TABLE 2.1 OBJECT RANGE VALUES FOR ACTUATED SIGNAL CONTROLLERS
OBJECT
MINIMUM PROJECT
REQUIREMENTS
TS 3.4-1996
maxTimeBaseScheduleEntries
15
maxDayPlans
15
maxDayPlanEvents
15
maxEventLogConfigs
15
eventConfigMode
2,3, and 4
maxEventLogSize
255
maxEventClasses
7
maxGroupAddress
1
TS 3.5-1996
maPhases
8
phaseMinimumGreen
1-255 seconds
phaseMaximum1
1-255 seconds
phaseMaximum2
1-255 seconds
---------------------------------------------------------------------------------------------------------------14
Revision 2-March 3, 1997 Draft
phaseYellowChange
phaseOptions
phaseConcurrency
maxVehicleDetectors
vehicleDetectorOptions
vehicleDetectorDelay
maxPedestrianDetectors
unitControl
maxAlarmGroups
maxSpecialFunctionOutputs
coordCorrectionMode
maxPatterns
patternCycleTime
patternOffsetTime
maxSplits
splitMode
maxTimebaseAscActions
maxPreempts
preemptControl
preemptDelay
maxRings
maxSequences
maxChannels
maxOverlaps
overlapType
overlapTrailYellow
3.0 - 5.0 seconds
Must support editing of bits
0,5,6,7,8,10
Must support standard 8
phase, dual-ring
configuration
24
Must support editing of bits
0, 1, 2, 4, 5, 7
0-255.0
4
Must support editing of bits
2, 5, and 6
0
0
2
8
30-255 seconds
0-254 seconds
3
2
15
6
Must support editing of bits
0 and 2
0-600 seconds
2
3
8
4
2
3.0 - 5.0 seconds
TABLE 2.2 OBJECT RANGE VALUES FOR VARIABLE MESSAGE SIGNS
OBJECT
MINIMUM PROJECT
REQUIREMENTS
TS 3.4-1996
maxTimeBaseScheduleEntries
7
maxDayPlans
7
maxDayPlanEvents
7
maxEventLogConfigs
15
eventConfigMode
2,3, and 4
---------------------------------------------------------------------------------------------------------------15
Revision 2-March 3, 1997 Draft
maxEventLogSize
maxEventClasses
maxGroupAddress
TS 3.6 Pending-1997
numFonts
maxFontCharacters
defaultBackgroundColor
defaultForegroundColor
defaultJustificationLine
defaultJustificationPage
dmsNumPermanentMsg
dmsMaxChangableMsg
dmsMaxVolatileMsg
Volatile Memory
dmsControlMode
numActionTableEntries
maxAuxDigital
maxAuxAnalog
auxPortDirection
255
7
1
1
255
0
Must support at least one of
2, 7, 40, or 41
2, 3
2, 3
0
0
15
5 KB
2, 4, and 5
15
1
1
may support only a single
value
(Note: Add a list of objects and value ranges for any objects for which a different range is required)
The software shall be supplied with full documentation, including a
• 3.5in. floppy disk(s)
and/or
• CD-ROM
containing ASCII versions of the following MIB files in ASN.1 format:
• the relevant version of each official NEMA Standard MIB Module referenced by the device
functionality
and
• if the device does not support the full range of any given object within a NEMA Standard MIB
Module, a manufacturer specific version of the official NEMA Standard MIB Module with the
supported range indicated in ASN.1 format in the SYNTAX field of the OBJECT-TYPE
macro. The filename of this file shall be the same as the standard MIB filename with the
extension “.man”.
Additionally, the software shall
• not support any objects not standardized and approved by NEMA
or
• be supplied with full documentation, including
---------------------------------------------------------------------------------------------------------------16
Revision 2-March 3, 1997 Draft
* 3.5in. floppy disk(s)
and/or
* CD-ROM
containing ASCII versions of any and all manufacturer-specific objects supported by the
device in ASN.1 format in a manufacturer-specific MIB with accurate and meaningful
DESCRIPTION fields and supported ranges indicated in the SYNTAX field of the OBJECTTYPE macros.
The Manufacturer shall
• not place any restrictions as to the passage of any and all of this documentation to any third
party.
or
• allow the use of any and all of this documentation by any party authorized by the Purchasing
Jurisdiction for systems integration purposes at any time initially or in the future, regardless of
what parties are involved in the systems integration effort.
Draft versions of the actuated signal controller (ASC) and dynamic message sign (DMS) MIB modules as
well as other information can be obtained from the NTCIP Web site at http://www.ntcip.org.
Using the above template, the following are examples of specifications clauses for specific procurements.
Example 1 - Purchase of Traffic Signal Controllers for Use in an Existing Signal System
The controller software shall comply with the referenced National Transportation Communications
for ITS Protocol (NTCIP) Standards prior to June 1, 1997. The software shall comply with the
versions of the relevant NTCIP standards that are current at the date of this document, or a later
version.
The software shall comply with NEMA TS 3.2 the Simple Transportation Management Framework,
and shall meet the requirements for Compliance Level 1. The software shall comply with NEMA TS
3.3 the Class B profile, and shall include both an EIA/TIA 232-E and an FSK modem interface for
NTCIP based communications.
The software shall implement all mandatory objects of all mandatory Conformance Groups as
defined in Actuated Signal Controller Object Definitions, NEMA TS 3.5.
The software shall also implement all mandatory objects of the following optional Conformance
Groups as defined in
•
Global Object Definitions, NEMA TS 3.4:
* Reports
* PMPP objects
* STMP objects
---------------------------------------------------------------------------------------------------------------17
Revision 2-March 3, 1997 Draft
and in
• Actuated Signal Controller Object Definitions, NEMA TS 3.5
* Generic
* General
* Phase
* Detector
* Unit
* Coordination
* TimeBase
* Preempt
* Miscellaneous
* Ring
* Channel
* VehicleOverlap
* Report
The software shall also implement the following optional objects as defined in the Actuated
Signal Controller Object Definitions, NEMA TS 3.5
* ringControlTable
All objects required by these procurement specifications shall support all values within its
standardized range, unless otherwise approved by the PROJECT ENGINEER. The standardized range is
defined by a size, range, or enumerated listing indicated in the object’s SYNTAX field and/or through
descriptive text in the object’s DESCRIPTION field of the relevant standard. The following provides the
current listing of known variances for this project.
TABLE 2.3 OBJECT RANGE VALUES FOR ACTUATED SIGNAL CONTROLLERS
OBJECT
MINIMUM PROJECT
REQUIREMENTS
TS 3.4-1996
maxTimeBaseScheduleEntries
15
maxDayPlans
15
maxDayPlanEvents
15
maxEventLogConfigs
15
eventConfigMode
2,3, and 4
maxEventLogSize
255
maxEventClasses
7
maxGroupAddress
1
TS 3.5-1996
maPhases
8
phaseMinimumGreen
1-255 seconds
phaseMaximum1
1-255 seconds
phaseMaximum2
1-255 seconds
phaseYellowChange
3.0 - 5.0 seconds
---------------------------------------------------------------------------------------------------------------18
Revision 2-March 3, 1997 Draft
phaseOptions
phaseConcurrency
maxVehicleDetectors
vehicleDetectorOptions
vehicleDetectorDelay
maxPedestrianDetectors
unitControl
maxAlarmGroups
maxSpecialFunctionOutputs
coordCorrectionMode
maxPatterns
patternCycleTime
patternOffsetTime
maxSplits
splitMode
maxTimebaseAscActions
maxPreempts
preemptControl
preemptDelay
maxRings
maxSequences
maxChannels
maxOverlaps
overlapType
overlapTrailYellow
Must support editing of bits
0,5,6,7,8,10
Must support standard 8
phase, dual-ring
configuration
24
Must support editing of bits
0, 1, 2, 4, 5, 7
0-255.0
4
Must support editing of bits
2, 5, and 6
0
0
2
8
30-255 seconds
0-254 seconds
3
2
15
6
Must support editing of bits
0 and 2
0-600 seconds
2
3
8
4
2
3.0 - 5.0 seconds
.
The software shall be supplied with full documentation, including 3.5in. floppy disk(s) containing
ASCII versions of the following MIB files in ASN.1 format:
•
The relevant version of each official NEMA Standard MIB Module referenced by the device
functionality
•
If the device does not support the full range of any given object within a NEMA Standard MIB
Module, a manufacturer specific version of the official NEMA Standard MIB Module with the
---------------------------------------------------------------------------------------------------------------19
Revision 2-March 3, 1997 Draft
supported range indicated in ASN.1 format in the SYNTAX field of the OBJECT-TYPE macro.
The filename of this file shall be the same as the standard MIB filename with the extension
“.man”.
•
Any and all manufacturer-specific objects supported by the software shall be documented in
ASN.1 format in a manufacturer specific MIB with accurate and meaningful DESCRIPTION
fields and supported ranges indicated in the SYNTAX fields of the OBJECT-TYPE macros.
The Manufacturer shall allow the use of any and all of this documentation by any party authorized by
the Purchasing Jurisdiction for systems integration purposes at any time initially or in the future,
regardless of what parties are involved in the systems integration effort.
Example 2 - Purchase of a New Closed Loop Signal System
The controller, field master and central computer software shall comply with the referenced National
Transportation Communications for ITS Protocol (NTCIP) Standards prior to December 31, 1997.
The software shall comply with the versions of the relevant NTCIP standards that are current at the
date of this document, or a later version.
The software shall comply with NEMA TS 3.2, the Simple Transportation Management Framework,
and shall meet the requirements for Compliance Level 1.
The software shall comply with NEMA TS 3.3, the Class B Profile, and shall include an EIA/TIA 232E interface for NTCIP based communications.
The software shall implement all mandatory objects of all mandatory Conformance Groups as
defined in Actuated Signal Controller Object Definitions, NEMA TS 3.5.
The software shall also implement all mandatory objects of the following optional Conformance
Groups as defined in
• Global Object Definitions, NEMA TS 3.4:
* Reports
* PMPP objects
* STMP objects
and in
• Actuated Signal Controller Object Definitions, NEMA TS 3.5
* Generic
* General
* Phase
* Detector
* Unit
* Coordination
* TimeBase
* Preempt
---------------------------------------------------------------------------------------------------------------20
Revision 2-March 3, 1997 Draft
*
*
*
*
*
Miscellaneous
Ring
Channel
VehicleOverlap
Report
The software shall also implement the following optional objects as defined in the Actuated Signal
Controller Object Definitions, NEMA TS 3.5
*
*
*
*
ringControlTable
phaseCarsBeforeReduction
ringControlTable
eventClassTable
All objects required by these procurement specifications shall support all values within its
standardized range, unless otherwise approved by the PROJECT ENGINEER. The standardized range is
defined by a size, range, or enumerated listing indicated in the object’s SYNTAX field and/or through
descriptive text in the object’s DESCRIPTION field of the relevant standard. The following provides the
current listing of known variances for this project.
TABLE 2.4 OBJECT RANGE VALUES FOR ACTUATED SIGNAL CONTROLLERS
OBJECT
MINIMUM PROJECT
REQUIREMENTS
TS 3.4-1996
maxTimeBaseScheduleEntries
15
maxDayPlans
15
maxDayPlanEvents
15
maxEventLogConfigs
15
eventConfigMode
2,3, and 4
maxEventLogSize
255
maxEventClasses
7
maxGroupAddress
1
TS 3.5-1996
maPhases
8
phaseMinimumGreen
1-255 seconds
phaseMaximum1
1-255 seconds
phaseMaximum2
1-255 seconds
phaseYellowChange
3.0 - 5.0 seconds
phaseOptions
Must support editing of bits
0,5,6,7,8,10
phaseConcurrency
Must support standard 8
phase, dual-ring
configuration
---------------------------------------------------------------------------------------------------------------21
Revision 2-March 3, 1997 Draft
maxVehicleDetectors
vehicleDetectorOptions
vehicleDetectorDelay
maxPedestrianDetectors
unitControl
maxAlarmGroups
maxSpecialFunctionOutputs
coordCorrectionMode
maxPatterns
patternCycleTime
patternOffsetTime
maxSplits
splitMode
maxTimebaseAscActions
maxPreempts
preemptControl
preemptDelay
maxRings
maxSequences
maxChannels
maxOverlaps
overlapType
overlapTrailYellow
24
Must support editing of bits
0, 1, 2, 4, 5, 7
0-255.0
4
Must support editing of bits
2, 5, and 6
0
0
2
8
30-255 seconds
0-254 seconds
3
2
15
6
Must support editing of bits
0 and 2
0-600 seconds
2
3
8
4
2
3.0 - 5.0 seconds
The software shall be supplied with full documentation, including 3.5in. floppy disk(s) containing
ASCII versions of the following MIB files in ASN.1 format:
•
The relevant version of each official NEMA Standard MIB Module referenced by the device
functionality
•
If the device does not support the full range of any given object within a NEMA Standard MIB
Module, a manufacturer specific version of the official NEMA Standard MIB Module with the
supported range indicated in ASN.1 format in the SYNTAX field of the OBJECT-TYPE macro.
The filename of this file shall be the same as the standard MIB filename with the extension
“.man”.
•
Any and all manufacturer-specific objects supported by the software shall be documented in
ASN.1 format in a manufacturer specific MIB with accurate and meaningful DESCRIPTION
fields and supported ranges indicated in the SYNTAX fields of the OBJECT-TYPE macros.
---------------------------------------------------------------------------------------------------------------22
Revision 2-March 3, 1997 Draft
The Manufacturer shall allow the use of any and all of this documentation by any party authorized by
the Purchasing Jurisdiction for systems integration purposes at any time initially or in the future,
regardless of what parties are involved in the systems integration effort.
These are examples only, and are not meant to imply that this wording will be the most appropriate for all
purchases of controllers and closed-loop systems. Each agency should consider its own needs and
conditions and choose wording accordingly. It is often beneficial to discuss proposed wording with
prospective vendors before finalizing the specifications.
An NTCIP Exerciser is being developed by the Federal Highway Administration to enable both
manufacturers and purchasers to test equipment for correct operation of the NTCIP standard. This is a
software package that operates on a personal computer and emulates either a master or controller as
needed. It enables test messages to be sent and both the sent and received messages to be captured and
analysed. Deliberate errors can be introduced to test error handling. For information about the exerciser,
visit the NTCIP Web page at http://www.ntcip.org.
FREQUENTLY ASKED QUESTIONS
My system works fine. Why do I need the NTCIP?
The industry is expected to migrate to the NTCIP as the standard and only protocol used in controllers,
field masters, and central computers for communications with all ITS field devices. This will take several
years, but when it is complete, it will be difficult to purchase new equipment without the NTCIP and may
be difficult to purchase equipment that supports your current proprietary protocol. The sooner you get
NTCIP equipment installed, the sooner you will be able to make the switch and avoid being left with an
obsolete system. Purchasing equipment now with both your current protocol and the NTCIP ensures that
you are prepared for the future switch to the NTCIP and minimizes the cost and difficulty of changing out
software or equipment in the future.
I am purchasing only one or two new controllers per year on average, and they must operate with my
current field masters that do not use the NTCIP. How can I make use of the NTCIP?
You probably can not make use of the NTCIP immediately. You would need to have an NTCIPcompatible master as well as controllers. As you purchase new controllers, be sure to specify that they
have software that includes the NTCIP protocol in addition to your system's current protocol. That way,
you will not have to upgrade those controllers in the future when you upgrade to NTCIP field masters.
---------------------------------------------------------------------------------------------------------------23
Revision 2-March 3, 1997 Draft
My system supplier says that it will offer an NTCIP version of the controller soon, but that it may be
2 years before it has an NTCIP version of the master. Should I ask for the NTCIP in the controllers
now even though the master can not make use of it?
You should require that new controllers be retrofitted with the NTCIP version of the software as soon as it
is available. The new software must also support your system's current protocol. As soon as the NTCIP
version of the master software is available, you can switch over to use of the NTCIP and need no longer
worry about two protocols. If you are purchasing a new master in the mean time, it is wise to specify that
the supplier retrofit the NTCIP software as soon as it is available.
---------------------------------------------------------------------------------------------------------------24
Revision 2-March 3, 1997 Draft
CHAPTER 3 Summary Technical Description
ABOUT THIS CHAPTER
This chapter will provide the reader with a basic understanding of how NTCIP uses a get/set paradigm to manage
object-oriented databases in transportation devices. NTCIP follows the standard ISO seven-layer model. The top
layer is called the application layer and is the interface between the communication protocol and the device
database.
Each NTCIP profile defines the seven layers in a different way to meet the requirements served by each profile.
There are several communications profiles currently approved and others under development. The simplest profile
is Class B and targets point-to-multipoint communications over low-speed links using modems and copper wires.
The more advanced profiles include TCP/IP (Internet protocol) and target TMC-to-TMC communications. Many
of the profiles define identical layers. For instance, Class A and Class B both use a modified version of the Simple
Network Management Protocol (SNMP) for the application layer and implementation of High-level Data Link
Control (HDLC, ISO 3309) for the data link layer. This chapter explains how the different layers defined in the
Class B profile make up a Class B message.
One of the major differences in the NTCIP approach is the use of a standardized database. NTCIP databases are
defined using Abstract Syntax Notation One (ASN.1). NTCIP manages the database using SNMP as the
application layer. Transport of the SNMP messages are carried out using lower layers of the protocol. The
database becomes the interface layer between the application and the application layer of the protocol stack.
The reader is warned not to rely on this interpretation of the NTCIP for development purposes. A system or device
developer will need to review the NTCIP, Basic Encoding Rules (BER), HDLC, and SNMP documents. Also, only
the NTCIP Class B profile is described because all other NTCIP profiles are currently in draft form.
This document is updated from time to time to reflect changes in NTCIP. To check whether this is the current
version of this document, access the NTCIP home page on the World Wide Web at http:www.ntcip.org or contact
Al Santiago at fax (703) 285-2264.
THE NTCIP DATABASE
Transportation devices need to store and communicate constants, parameters, and collected data. Examples
include minimum cycle time for a traffic signal, text for a variable message sign, vehicles per hour for a count
station, and current wind speed from a weather station.
NTCIP is intended for many types of transportation devices, each with different database requirements. NTCIP
relies on the SNMP approach to database management. SNMP uses an industry-standard get/set paradigm to read
and write data in a database. Data elements in the database are called “managed objects” or just “objects” for
short. The database is a group of related objects and is called a “management information base” or MIB. The
entity that manages the MIB within a device is called an agent. The concept is that a management application
---------------------------------------------------------------------------------------------------------------1
Revision 2-March 3, 1997 Draft
sends messages to the agent to fetch or modify the values of objects stored within the MIB. When MIB values
change, the transportation device responds as defined in its programming. The agent works at the application
layer in the protocol, but is itself not the application. The agent does not care whether the MIB represents a traffic
controller or variable message sign or any other device.
An object is a single instance of data. Once an object is defined, it must be transported as a whole. As an example,
an object may define the current time, say 12:15:30. Since this object is defined as hours, minutes and seconds, it
can not be used to transport just seconds. Alternatively, time could be defined as three separate objects, one each
for hours, minutes, and seconds. It is important to note that a system could contain both of these object definitions
for time. It may be convenient to have access to different forms of the same data in the same MIB but it is not very
efficient, since extra objects require more computer memory. Thus, if access to seconds is needed, the current time
should be defined as three objects. It is also important to note that even if time of day was defined as three integer
values, all three could still be transmitted in a single SNMP message.
To standardize some of the commonly needed objects, the NTCIP defines a global objects MIB module. The global
MIB module contains definitions of commonly needed objects that are basic to the NTCIP, such as the name and
versions of the MIBs supported by an agent.
A MIB and its objects are defined using ASN.1. "Abstract syntax" means that the manner used to define the data
is independent of the procedure for encoding the data into binary form. The MIB is a text document that can be
read by a human and compiled by computer. A management application must have a copy of the MIB employed by
the managed agent. The MIB is transferred to a management application via a text file on a floppy disk. This is
usually performed when the device is first installed. However, other methods could be used for MIB transfer.
Example 1:
Consider a traffic control device that includes one or more MIBs. The management application will need access
to the number, names and versions of the MIBs contained within the device.
Note: An octet is a fancy word for byte. It is a byte with exactly eight bits.
The global objects MIB (NEMA TS 3.4) defines an object called “globNumMib.” Below is the ASN.1 definition of
this object.
2.2.1 [globNumMib]
globNumMib OBJECT-TYPE
SYNTAX
Ubyte (1..255)
ACCESS
read-only
STATUS
mandatory
DESCRIPTION “The number of MIBs supported by a device.”
::={globCfg 1}
The object represents the number of MIBs contained or supported by the agent for a NTCIP device. This may not
seem to useful, but this number is required to access the actual list of names stored in other objects within the
global MIB.. The first line is the tag or name identification for the object. The SYNTAX line defines the variable
type. In this example, the type is Ubyte, (which is one unsigned byte that represents a number from 1 to 255. The
STATUS line defines whether or not an agent’s MIB must include this object. A device does not have to include
or support optional objects to be considered compliant with NTCIP. This object is mandatory; if the device is to
---------------------------------------------------------------------------------------------------------------2
Revision 2-March 3, 1997 Draft
be compliant, it must include this object. The DESCRIPTION line provides a human-readable description of the
object. The last line indicates that the root node of this object is globCfg 1; globCfg is defined above in the MIB
as belonging to a specific node. The macro definitions allow the MIB object identifiers to be referenced from a
node defined in the top of the MIB file.
Table 1 lists some common ASN.1 terms used for object definitions. Since this is an incomplete list, refer to ISO
8824 and the NTCIP documents for more information. The NTCIP also defines additional limitations to ASN.1.
These limitations are defined in a section called the NEMA Structure and Identification of Management
Information (NEMA_SMI). The NEMA_SMI is not a MIB but is added to all NTCIP MIBs. Another section,
called the Transportation Management Information Base (TMIB), is the parent of all NTCIP MIB modules. TMIB
defines some common variable types from the ASN.1 primitives. For example, ASN.1 defines an integer as a
number between positive and negative infinity. TMIB refines this by defining a new type called a byte. A byte is
an integer with a range of +127 to -127, and is exactly one octet (a byte with eight bits) in length. These
definitions and others are defined using the ASN.1 macro language.
TABLE 3.1
SOME COMMON ASN.1 TERMS FOR OBJECT DEFINITION
ASN.1 Tag
Description
Some Options
OBJECT-TYPE
Alphanumeric string that names
the object
SYNTAX
Object data type
BYTE - (-127..127)
UBYTE - (0..255)
SHORT - (-32782..32782)
USHORT - (0..65535)
LONG - (+/-2147483647)
ULONG - (0..4294967295)
Octet string - a string of bytes, such
as ASCII text
ACCESS
Determines read/write
capabilities
Read - Object can be read
Write - Object can be changed
No access - Object cannot be read or
written
STATUS
Determines whether this object is
required.
Mandatory - All MIBs of this type
must include this object.
Obsolete - The object has been deleted
or replaced and agents are not required
to implement it.
Optional - Not required.
Deprecated - A status of deprecated
implies that the object is being
discouraged, and in future releases of
the standard may be marked obsolete.
---------------------------------------------------------------------------------------------------------------3
Revision 2-March 3, 1997 Draft
DESCRIPTION
Explanation of what the object
represents and how to interpret it
Anything you want to write to describe
object
The ASN.1 macro language is very powerful in that new object syntax can be created by modifying or combining
basic (primitive) data types. The equivalent of a one dimensional array can be defined using the SEQUENCE
operator. Default values and ranges for objects can also be defined in the MIB. ASN.1 is a language rich with
operators, macros, and tags. Very complex data structures can be created with ASN.1.
The MIB objects are related by device type (e.g., a traffic controller [asc] MIB or a variable message sign [vms]
MIB). These device MIBs are called modules of the larger TMIB. NTCIP has draft MIB modules for actuated
traffic controllers, variable message signs, closed circuit television control (CCTV) and highway advisory radio
(HAR). MIBs for many other devices are being developed. It is desirable to use standard wherever possible, but as
new device features require additional objects, new versions of a MIB can be created. NTCIP also supports
proprietary and experimental MIBs. Experimental MIBs are kept under a separate node and users know that the
MIB is subject to changes. Proprietary MIBs can exist under nodes owned by others (i.e., not under NEMA 1203).
Objects in the MIB are arranged in a tree structure, and objects are named by the path along the branches of the
tree to the object. The path starts at the trunk of the tree, and a node identifier is added at each branch until the
object is reached. The node identifiers are integers and are separated by a dot or decimal point. NTCIP uses the
tree structure defined by ISO and CCITT. An entire MIB module will hang off this global name tree. Below is a
diagram showing the tree structure from its root to the NEMA node. All NTCIP MIB modules will be attached to
the NEMA node.
---------------------------------------------------------------------------------------------------------------4
Revision 2-March 3, 1997 Draft
Figure 3.1 Tree Structure of MIB Objects (Source: NEMA Standards Publication TS 3.2 )
All objects in the NEMA NTCIP MIB modules will start with 1.3.6.1.4.1.1206 or
(iso.org.dod.internet.private.enterprises.nema). NEMA has further divided the 1206 node into four subgroups.
Figure 3.2 NEMA 1206 Node and Subgroups (Source: NEMA Standards Publication TS 3.2)
---------------------------------------------------------------------------------------------------------------5
Revision 2-March 3, 1997 Draft
Everything below the transportation node constitutes the TMIB. Within the TMIB there are protocol, device, and
dynamic object groups. The device group has subtrees for each of the supported devices: asc, ramp, vms, camera,
sensors, and global objects. More branches will be added as new devices are included in NTCIP.
Example 2:
Consider our global object in example 1. Notice the 2.2.1 preceding the object identifier; this is the subidentifier
from the globCfg node. Below is the header information from the global MIB.
nema OBJECT IDENTIFIER ::= {iso org(3) dod(6) 1 private(4) enterprises(1) 1206}
transportation OBJECT IDENTIFIER ::= {nema 4}
devices OBJECT IDENTIFIER ::= {transportation 4}
global OBJECT IDENTIFIER ::= {devices 6}
globCfg OBJECT IDENTIFIER :: = {global 1}
globMgmt OBJECT IDENTIFIER ::= {global 2}
globSTMP OBJECT IDENTIFIER ::= {global 3}
globPMPP OBJECT IDENTIFIER ::= {global 4}
The path would be 1.3.6.1.4.1.1206.4.4.6.1.2.2.1 or (iso.org.dod.internet.private.enterprises.nema.
transportation.devices.global.globCfg.2.2.1).
Do not be concerned with the 14-node identifier above: NTCIP can trim the number of bytes that need to be
transmitted. This reduction can be accomplished by setting a reference point below the ISO node. Later we will
discuss identifying objects from the NEMA node, thus deleting 7 nodes and using dynamic objects to predefine
object identifiers.
The databases for NTCIP devices are defined using ASN.1, which provides a standard method for object definition,
organization, and identification. We have examined how to define an object and identify the path to the object
using this standard. Next, we examine how the object identifier or path and the value of the object are encoded
into binary data for transmission.
ENCODING THE NTCIP DATABASE FOR TRANSMISSION
To transmit an object we need to encode the object’s identifier, data type, length, and value. This is commonly
referred to as TLV for (type, length, value). NTCIP uses a standard set of rules for encoding called, BER (ISO
8825, CCITT X.209). NTCIP also defines a set of Packed Encoding Rules (PER) contained in the Simple
Transportation Management Protocol (STMP) as defined in the Simple Transportation Management Framework
(STMF). PER is used exclusively with the dynamic objects defined by the STMP. The object identifiers can be
coded from the root node (ISO) using SNMP, or the NEMA node if using STMP. The method used is specified in
the STMF message type so that the receiving party can properly decode the message.
Example 3:
Using the object from example 1, we need to encode the object identifier, data type, and value.
OBJECT IDENTIFIER
TYPE
LENGTH
VALUE
1.3.6.1.4.1.1206.4.4.6.1.2.2.1
Ubyte
1
5 (for example, say the device has five MIBs)
---------------------------------------------------------------------------------------------------------------6
Revision 2-March 3, 1997 Draft
Assuming SNMP and using the encoding rules for OBJECT IDENTIFIER, the first two components are combined
using the formula (40X)+Y to form the first subidentifier. Each subsequent component forms the next
subidentifier. Each subidentifier is encoded as a non-negative integer using as few seven bit blocks as possible.
The blocks are packed into octets, with the first bit of each octet set to a 1 except for the last octet of each
subidentifier.
BER encodes INTEGER using Two’s complement representation with the minimum number of octets.
Note that [xx] represents a number in hexadecimal format.
{1.3.6.1.4.1.1206.4.4.6.1.2.2.1}
TABLE 3.2
OBJECT COMPONENT, SUBIDENTIFIER AND OCTET SEQUENCE HEX
Component
1.3
6
1
4
1
1206
Subidentifier
43
6
1
4
1
1206
4
4
6
1
2
2
1
4
4
6
1
2
2
1
Octet Sequence Hex
[2B]
[06]
[01]
[04]
[01]
10010110110 bin
[89][36]
[04]
[04]
[06]
[01]
[02]
[02]
[01]
Adding the OBJECT IDENTIFIER type of [06] and a length of [0E] or (14 decimal) yields the following byte
sequence:
[06][0C][2B][06][01][04][01][89][36][04][04][06][01][02][02][01]
If we started from the NEMA node we would trim this to:
[06][07][04][04][06][01][02][02][01]
Next, lets encode the data value, which is 5. From the definition statement we get a byte sequence of:
[05]
BER encodes Ubyte as an integer using the most significant bit as a sign bit. INTEGER has a type code of [02].
---------------------------------------------------------------------------------------------------------------7
Revision 2-March 3, 1997 Draft
Our object value with a type of [02] and a length of [01] would become:
[02][01][05]
The combined byte sequence for {Object ID} and {Object Value} using STMP is:
{[06][07][04][04][06][01][02][02][01] }{ [02][01][05] }
PER is a subset of BER and can only be used with dynamic objects. Since both the manager and the agent know
which objects are defined in the dynamic object, no object identifier is required. Also, the data type is known, so
the type field of the TLV is not encoded. For fixed-length objects, length is known and is also not encoded. Using
PER, the dynamic object could be read with one byte in the message, and the reply would only have a one byte
value.
Example 3 examined only two data types that can be encoded with BER. BER contains encoding rules for all
ASN.1 types and contains several optional methods for encoding, so that the same data could be encoded in more
than one way. NTCIP limits some of the data types allowed to somewhat simplify encoding. See the STMF
document for more information.
THE NTCIP AND THE ISO SEVEN-LAYER MODEL
The various NTCIP profiles define each of the seven layers differently: for example, Class C is designed to support
file transfers. File transfers are supported by adding Internet File Transfer Protocol (FTP) to the application layer.
Since FTP requires virtual connections, the transport layer is based on Transmission Control Protocol (TCP).
These two changes add the file transfer function to NTCIP by changing two layers in the existing Class A profile
definition.
The Application Layer - Using STMF
We have created an object using ASN.1, placed it in a tree structure, gave it a real value, and finally encoded the
object and its value using BER. To transport the object from one device to another will require some sort of
protocol. NTCIP uses STMP for this purpose. STMP is a modified version of the SNMP standard used on the
Internet. STMP adds 13 dynamically defined objects. The dynamic objects are defined at run time and can contain
any of the objects in an agent’s MIB. The benefit is that the object identifiers and type codes need only be
transmitted once. Example 3 showed that object identifiers present a lot of overhead bytes. Using dynamic objects
and PER, the example object data could have been transmitted in just one byte for the application layer.
STMP uses a get/set/trap paradigm. The table below lists the STMP message types, purposes and originators. The
managing application initiates all communications by sending a request. The is commonly referred to as polling.
If required, the agent will send an acknowledgment depending on the request type.
TABLE 3.3
Message Type
Get Request
STMP MESSAGE TYPE, PURPOSE, AND ORIGINATOR
Purpose
Contains a list of objects, the agent is to return the
values
Originator
Management
Application
---------------------------------------------------------------------------------------------------------------8
Revision 2-March 3, 1997 Draft
Set Request
Set Request - No Reply
Get Response
Set Response
Trap Response
Get Error Response
Set Error Response
Contains a list of objects and values, the agent is to set
the values in its MIB per this message
Contains a list of objects and values, the agent is to set
the values in its MIB per this message
Agent response to a Get request
Agent response to a Set request
Agent response if a Trap condition is met.
Agent indicates that there was an error in the request
Agent indicates that there was an error
Management
Application
Management
Application
Agent Application
Agent Application
Agent Application
Agent Application
Agent Application
All STMP messages begin with an octet that identifies the protocol data unit (PDU) format, message type, and
object identifier. Error responses also contain an octet error code and an octet index. Refer to the NEMA NTCIP
STMF documents for a description or the possible error codes.
TABLE 3.4
Bit
7
6-4
Contents
PDU Format
0
1
Message Type
000
001
010
011
100
101
110
111
3-0
Object ID
0000
0001-1101
1110
1111
STMP MESSAGE BIT, CONTENTS AND DESCRIPTION
Description
Reserved (not STMP)
Standard STMP format
This value indicates that a Get request is contained in the packet.
This value indicates that a Set request is contained in the packet.
This value indicates that a Set request requiring no reply is contained in the
packet.
This value indicates that a Trap response is contained in the packet.
This value indicates that a response to a Get request is contained in the packet
(positive ACK).
This value indicates that a response to a Set request is contained in the packet
(positive ACK).
This value indicates that an error response to a Get request is contained in the
packet.
This value indicates that an error response to a Set request is contained in the
packet.
NEMA node used as root.
ID of STMP "dynamic object."
Absolute root used.
Reserved.
The STMP PDU message has the following format:
[Type octet][Message Data]
Example 4:
---------------------------------------------------------------------------------------------------------------9
Revision 2-March 3, 1997 Draft
Using our object from example 3 and assuming STMP. To read the value of the globNumMib object:
Manager sends Get request [80]:
STMP
[80]
Object ID
[06][07][04][04][06][01][02][02][01]
Object Value
[02][00]
The agent would respond with a Get reply. Assuming there was no error, the PDU would contain
[C0][02][01][05].
The Presentation, Session, Transport, and Network Layers
The NTCIP Class B profile does not use these layers. Class A uses User Datagram Protocol (UDP) as the transport
layer, and IP as the network layer. In the case of Class A, it is the network layer that performs the routing
function. Class A also supports the concept of ports, which are commonly used to target data to a specific
application layer. This permits one port to support FTP and another to support SNMP. Thus, using Class A, the
same device with the same address can support multiple application layers and even multiple applications. The
cost of the added functionality of Class A is extra octets in each message.
The Data Link Layer for Class B
The STMP or SNMP message must exist in a network that possibly carries messages to and from multiple agents.
Since NTCIP data links can be shared, a destination address must be added to the messages. Data must be
protected from possible corruption during transmission. To insure accurate delivery of a message, NTCIP relies on
HDLC. For Class A, B, and C profiles, the STMP message is encapsulated in the an HDLC frame. Class A wraps
the STMP message with Internet UDP. UDP adds its own addressing and checksum to the message. The UDP
packet is then inserted in the HDLC frame for transmission. The Class A profile allows routing of messages,
whereas Class B is limited to point-to-point transmissions.
FLAG
Figure 3.3
ADDRESS
CONTROL
INFORMATION FCS
FLAG
HDLC Frame Structure (Source: NEMA Standards Publication TS 3.3)
The opening and closing flags are one octet with a value of [7F]. The address field contains the target address and
has variable length of one to two octets. The control is one octet and identifies the frame type as
command/response, unnumbered information, or unnumbered poll. The information field contains the STMP
message being transmitted. The FCS field (frame check sequence) field is a two-octet cyclic redundancy check
(CRC). The last field is the closing flag described earlier.
---------------------------------------------------------------------------------------------------------------10
Revision 2-March 3, 1997 Draft
Class B profile is basically the HDLC frame with an initial protocol identifier (IPI). The IPI is one or two octets
that identifies the information as Class B. The IPI is the first one or two octets in the information field. Values for
the IPI(s) are constant and are defined in the class profiles.
The figure below details the three layers used in a Class B transmission. The application layer is defined as STMP,
the Network is NTCIP Class B, and the data link layer is HDLC. The hardware layer is defined as EIA 232 and is
not shown.
Fo
o rmat + Type + Object Id Object Data
Application Layer
Network Layer
Data Link Layer
Figure 3.4
IPI
FLAG
ADDRESS
CONTROL
Upper Layer PDU data
INFORMATION FCS
FLAG
Class B Transmission Layers (Source: NEMA Standards Publication TS 3.3)
In an HDLC frame, the flag fields are kept unique by replacing all [7F] octets contained in the frame. The
replacement is referred to as byte stuffing. Octets with a value of [7E] are replaced with [7D][5E]; likewise [7D]
are replaced with [7D][5D]. In this way a reception of a [7E] identifies the beginning or ending of an HDLC
frame.
Example 5:
To use Class B profile to send our Get globNumMib message to the agent, we place our previous data packet into
the Class B frame. Assuming that the agent has an address of 2. The entire 19-byte frame is shown below:
Flag
Address [09]
Control [C0]
IPI
STMP
FCS
Flag
[7E]
[C0]
[80] [06][07][04][04][06][01][02][02][01]
[02][00]
(2 bytes)
[7E]
---------------------------------------------------------------------------------------------------------------11
Revision 2-March 3, 1997 Draft
Note that the address in Example 5 is not [02] but rather [09]. NTCIP uses an extensible address that varies from
one to two octets. In the first octet, the low-order bit is used as a signal that the next octet also contains address
information. The next bit is used as a flag to indicate that this address is a global address. Global addressing
permits broadcasting information, such as the current time of day, to all devices at once.
The Physical Layer
NTCIP Classes A, B, C, and E all define EIA 232 or frequency shift key (FSK) transmission as the physical layer.
In the case of FSK only 1,200 bps is defined. EIA 232 could transmit data at much higher rates, such as 38,400
bps, using another transport, such as fiber-optic modems. FSK is defined to support existing copper wire
communication infrastructure.
CALIFORNIA ASSEMBLY BILL 3418 AND NTCIP
The State of California passed a law that requires all traffic controllers to use a standard protocol. AB 3418 is
based on NTCIP, but relies on a set of predefined dynamic objects. AB 3418 “hard-codes” the “dynamic” objects.
The AB 3418 MIB is fixed, dynamic message number 1 contains the information in Table 3.5. The Controller ID
response is returned when a Get request for dynamic object number 1 is sent to the agent. This approach is easy to
implement but limits future expansion. Upward compatibility fails as soon as one object needs to be redefined.
However, AB 3418 can coexist on NTCIP-based networks and can be supported by NTCIP Class B. An NTCIP
Class B signal controller can be programmed to completely emulate AB 3418.
TABLE 3.5
Byte
GET CONTROLLER RESPONSE (SOURCE: CALTRANS AB3418).
Value
(Hex)
Description
01
C1
"GET CONTROLLER ID RESPONSE - No Error" Message
Type
02
LENGTH
Number of bytes in message bytes 3 to (N+9)
03
LENGTH
Number of bytes in manufacturer's ID
NAME
ASCII string with manufacturer's ID
m
LENGTH
Number of bytes in model ID
m+1 to N-1
MODEL
ASCII string with model ID
9
Number of bytes in protocol revision ID
"AB3418 V1"
ASCII string with protocol revision ID
4 to m-1
N
N+1 to N+9
---------------------------------------------------------------------------------------------------------------12
Revision 2-March 3, 1997 Draft
CREATION OF NEW MIB MODULES AND ADDING OBJECTS TO DRAFT
MIBS
NEMA has done a great job in defining an open and expandable protocol. NTCIP permits completely open
database definitions without precluding completely proprietary (closed) ones. NTCIP will serve both open and
closed databases on the same network. Users are encouraged to review the existing MIB object definitions before
attempting to add new ones.
The creation of a new MIB module can be quite easy. This is especially true if the device to be supported already
has a list of defined requirements and database. Start by rewriting the existing database using ASN.1. Next,
define the necessary objects for the device and attempt to organize them in a subtree. Obtain from NEMA, a root
node for the subtree under the NEMA experimental node. Seek comments from NEMA, manufacturers, and users
of similar devices. In the early stages of NTCIP development, it may be sufficient to list the needed objects by
name and proposed data types (submit them to the Joint NTCIP Standards Committee for further development).
Above all, try to use the existing object definitions as much as possible; this will further compatibility between
devices.
SUMMARY
Transportation devices, like any other computer device, require databases. If the device will share its data with
other devices, a communication protocol is required. NTCIP fulfills both of these requirements. NTCIP uses
ASN.1 to define and organize data objects into a database called a MIB. BER is used to encode the object
identifiers and their values into a binary form usable by computers. NTCIP relies on STMP to transport objects to
and from the MIB contained in a transportation device. The Class B profile adds an IPI byte to the STMP message
and wraps the message in HDLC frame. The benefit of STMP over SNMP is a reduction in the overhead required
to identify and transport objects. STMP also supports 13 dynamic objects. These dynamic objects further reduce
overhead by saving a list of MIB objects and their types in a new dynamic object that can be referenced by a single
byte.
References
1.
NEMA Standards and Publications TS 3.1, Draft Proposed Standard National Transportation
Communications for ITS Protocol - NTCIP - Overview, National Electrical Manufacturers Association, 1996
2.
NEMA Standards and Publications TS 3.2, Draft Proposed Standard National Transportation
Communications for ITS Protocol - Simple Transportation Management Framework, National Electrical
Manufacturers Association, 1996
3.
NEMA Standards and Publications TS 3.3, Draft Proposed Standard National Transportation
Communications for ITS Protocol - NTCIP - Class B Profile, National Electrical Manufacturers Association, 1996
4.
Stallings, William. SNMP, SNMPv2 and CMIP, The Practical Guide to Network Management Standards,
Addison-Wesley Publishing Company, Inc., 1993 (ISBN 0-201-63331-0).
---------------------------------------------------------------------------------------------------------------13
Revision 2-March 3, 1997 Draft
Chapter 4: Systems and Software Developers Guide
As of this writing, most of the practical experience with the National Transportation
Communications for ITS Protocol (NTCIP) has been based on draft versions of the
standard and other documents that were designed to provide a stepping stone to full
NTCIP implementation. Specifically, the documents to which software has been
developed include the following:
• AB3418. The California legislature passed legislation (Assembly Bill 3418) requiring
all signal controllers purchased in the state after January 1, 1996, to be compliant
with a standardized protocol. The legislation delegated the creation of the technical
standard to Caltrans. As a result, Caltrans worked with the developers of the
NTCIP to develop a protocol that would (1) be ready by the mandated deadline and
(2) be as consistent as possible with the future NTCIP standard. The resulting
protocol from this effort is referred to as the AB3418.
• VMS E1. In order to demonstrate the progress which had been made in the
development of the NTCIP, the Federal Highway Administration (FHWA) and the
NTCIP Steering Group decided to develop a demonstration system to be exhibited
at the 1996 Transportation Research Board (TRB) Annual Convention. One of the
goals established for this demonstration was to demonstrate how the NTCIP could
be used to control various ITS devices on the same communications circuit. As
such, both traffic signals and variable message signs were included in the
demonstration. The signals used the AB3418 protocol described above and the
Variable Message Sign (VMSs) used the VMS E1, a protocol developed along the
same guidelines as the AB3418, but customized for VMS control.
• VMS E1.2. One of the other goals of the TRB demonstration was to show the
flexibility of the protocol to be enhanced to support such features as routing. Two
of the VMSs were designed to also support the VMS E1.2 protocol. This protocol
corresponds to the NTCIP Class A Profile and includes Internet Protocol and User
Datagram Protocol headers. The inclusion of these headers allow the packets to be
routed over complex computer networks (e.g., the source and destination computers
do not have to be directly connected, instead they can be connected through a series
of computers which will pass the data back and forth).
• TMC E1.2. Yet another goal of the demonstration was to show that the NTCIP effort
includes communications at the center-to-center level. As such, the demonstration
included a “local” TMC and a “remote” TMC. Communications between these
computers were defined by the TMC E1.2 protocol, another protocol developed
---------------------------------------------------------------------------------------------------------------1
Revision 2-March 3, 1997 Draft
along the guidelines set by AB3418 and conforming to a Class A Profile packet
structure.
Software for the NTCIP is being developed by a number of organizations. The full
NTCIP family is described by a number of documents, including the following
•
•
•
•
•
•
•
•
•
•
•
TS-3.1 - NTCIP Overview
TS-3.2 - Simple Transportation Management Protocol
TS-3.3 - Class B Profile
TS-3.4 - Global Object Definitions
TS-3.5 - Actuated Controller Unit Object Definitions
TS-3.6 - Variable Message Sign Object Definitions (Draft)
TS-3.x - Class A Profile (Draft)
TS-3.x - Class C Profile (Draft)
TS-3.x - Class E Profile (Draft)
TS-3.x - Highway Advisory Radio Object Definitions (Draft)
TS-3.x - Point-to-Multipoint Protocol (Draft)
The remainder of this chapter provides details relating to the various software sources
that are currently available in the public domain.
Central System Software Implementations
There are four basic prototype implementations of central system styled software.
None of these packages were designed to operate a real system; rather, they are
designed to provide tools to the industry to test equipment submitted as being
compliant to a specific protocol.
Caltrans
Caltrans has developed a Protocol Exerciser to test device support of the AB3418
protocol. This exerciser can be configured to act as a “central system” (i.e., it fulfills the
role as the manager of the communications channel). The software allows a user to
send down a single message at a time and will provide an analysis of the response
received from the attached device. It supports all of the AB3418 messages, and as such
is designed for signal controllers.
---------------------------------------------------------------------------------------------------------------2
Revision 2-March 3, 1997 Draft
Washington State Department of Transportation
The Washington State Department of Transportation (WSDOT) has also developed a
central system emulator; however, the department’s software is designed to test VMS’s
support of the VMS E1 protocol. It is similar to the Caltrans Exerciser in that it allows
users to send messages to a sign and it provides an analysis of the received response.
FHWA
The FHWA funded the development of the TRB demonstration system, which includes
a prototype central system that provides control of up to 10 traffic signals and four
VMSs. The traffic signals must support AB3418, and the VMSs must support VMS E1
and/or VMS E1.2. The central system includes the background point-to-multipoint
polling as included in the Class B Profile. Finally, it also includes support of center-tocenter communications conforming to the TMC E1.2.
NTCIP Exerciser
The FHWA is currently funding the development of the NTCIP Exerciser software.
This software package will be able to read in any properly formatted management
information base (MIB) from a floppy disk and support the exchange of fully compliant
NTCIP messages under the direction of the operator. The package will eventually
support the creation of macros to enable the user to perform a number of operations
sequentially and to record the results. Initial versions will only support Class B
communications, but future versions will support Class A as well.
SIGNAL CONTROLLER
There have also been efforts in the industry to develop device simulators, which
provide a sample device for new central system software to be tested against.
Caltrans
The previously mentioned Protocol Exerciser that Caltrans developed can also be
configured to simulate a signal controller at a specific drop address. This emulator
supports all of the messages defined in the AB3418 protocol and responds
appropriately; it also provides full error checking as required by the AB3418.
---------------------------------------------------------------------------------------------------------------3
Revision 2-March 3, 1997 Draft
FHWA
As a part of the effort to prepare the TRB Demonstration, the Caltrans software was
modified such that it could be configured to respond to any drop address (i.e., it can be
configured to simulate 63 controllers simultaneously). This was useful in verifying the
operations of the central system controlling multiple devices in a fast polling cycle.
The software was also enhanced in order to support the background point-tomultipoint polling.
Variable Message Signs
Software packages to support VMSs have also been produced by the various
development efforts.
WSDOT
In addition to the prototype VMS control system, WSDOT developed a VMS simulator
program. Their program supports the VMS E1 protocol and provides the appropriate
responses. The software can optionally be used to control one of the physical signs
used in the TRB demonstration. This is accomplished by the software translating the
messages to the proprietary protocol defined by the VMS.
FHWA
As a part of the TRB Demonstration, the FHWA funded the development of a DOSbased VMS controller that supports both the VMS E1 and VMS E1.2 protocols (i.e., both
Class A and Class B). Optionally, the software can be used to control a physical VMS
through translating messages to a proprietary protocol. Two versions of this software
were developed in order to control signs from two different manufactures for the
demonstration.
OTHER DEVICES
In addition to the above software packages, other efforts are under way to produce
simulators for other devices.
---------------------------------------------------------------------------------------------------------------4
Revision 2-March 3, 1997 Draft
I-95 Corridor
Work is underway to develop a HAR simulator and a VMS simulator. These will be
developed as conformance tools for the field deployments that are under way along the
I-95 Corridor.
Recommended References
There is a wide variety of publications available that relate to the NTCIP. This section
lists some of the resource materials that have been used in the development process, as
well as the location of developed materials
WORLD WIDE WEB
A wide range of documentation is available on the World Wide Web NTCIP Home
Page located at: http://www.ntcip.org
The site currently includes such items as these:
• NTCIP Class Profile documents
• NTCIP object definitions for a variety of devices
• Various white papers written during the development of the initial standards
• FHWA-sponsored software packages (e.g., NTCIP demonstration and NTCIP
Exerciser).
NTCIP Joint Standards Committee
In addition, there are articles in the December 1995, January 1996, and April 1996 issues
of the ITE Journal. Future issues of the ITE Journal will include additional NTCIP
articles, as well as a bimonthly NTCIP update section, which will provide the most
recent information regarding the NTCIP development.
---------------------------------------------------------------------------------------------------------------5
Revision 2-March 3, 1997 Draft
The NTCIP Joint Standards Committee is also attending a variety of major industry
conferences and giving presentations describing various aspects of the NTCIP. Finally,
the NTCIP demonstration is being given at various conferences.
Caltrans
Caltrans also has a home page that can be reached from a link on the above referenced
page. This site includes the following:
• Standard Communications Protocol for Traffic Signals in California,
and Implementation Requirements, August 15, 1995
Specification
• Standard Communications Protocol for Traffic Signals in California, Protocol
Exerciser Manual, Version 1.0, August 15, 1995
• Full text of Assembly Bill No. AB3418 and a number of AB 3418 Committee
publications can be found on the AB3418 Home Page for downloading.
NEMA Technical Committee
The most recent versions of the NEMA Standards can be obtained from:
National Electrical Manufacturers Association
1300 N. 17th St.
Rosslyn, Virginia 22209
703-841-3200
703-841-3300 fax
Organizations Planning Deployment of NTCIP
In addition to the above sources of information, other agencies are planning NTCIP
deployments, and it is the hope of the Joint Standards Committee that the various
deploying agencies will work together to share information. Here is a partial list of
agencies considering the use of the NTCIP:
• Dade County, Florida
---------------------------------------------------------------------------------------------------------------6
Revision 2-March 3, 1997 Draft
•
•
•
•
•
•
•
•
•
•
•
I-95 Corridor Coalition
Irvine, California
La Mesa, California
Las Vegas Area Computer Traffic Systems
Los Angeles, California
Richardson, Texas
Santa Clara, California
State of California
State of Florida
State of Washington
State of Virginia.
Books and Other Sources
During the development of the standards and prototypes, a number of books were
consulted; including the following:
• Stevens, W. R., TCP/IP Illustrated, Volume 1, The Protocols: Reading, Massachusetts:
Addison Wesley Publishing Co. 1994
• Wright, G. R. and Stevens, W. R., TCP/IP Illustrated, Volume 2, The Implementation,
Reading, Massachusetts: Addison Wesley Publishing Co. 1995
• International Technical Support Center Raleigh N. C., TCP/IP Tutorial and Technical
Overview, Document Number GG24-3376-01, IBM Corp, Armonk, N.Y.: June 5, 1990,
2nd Edition
• Rose, M. T., The Open Book, Englewood Cliffs, N.J.: Prentice Hall, 1990
• Stallings, W., SNMP, SNMPv2, and CMIP The Practical Guide to Network Management
Standards, Reading, Massachusetts: Addison Wesley Publishing Co. 1993
RFC Documents
Another important source of information is the Internet. Electronic copies of RFC
documents may be obtained using “anonymous FTP” to the host nic.ddn.mil or
ds.internic.net. Printed copies are available from
DDN Network Information Center
14200 Park Meadow Drive
---------------------------------------------------------------------------------------------------------------7
Revision 2-March 3, 1997 Draft
Suite 200
Chantilly, VA 22021
(800) 365-3642
(703) 802-4535
COMMON DEVELOPMENT PITFALLS
During the development of the NTCIP demonstration, a number of issues arose in
trying to get the various components to interoperate. These issues are documented
here to provide future implementers and integraters information for their design
consideration.
Protocol-Related Issues
A number of the problems discovered during the integration work related to invalid
interpretation of the specifications, especially relating to those clauses that reference
other specifications without providing significant detail. In order to minimize the
number of these conflicts in the future, a discussion of some of these issues is provided
below.
Bit and Byte Order
Bit and byte order in a computer are not necessarily the same as the bit and byte order
on the transmission medium. The transmission order varies in accordance with the
guidelines of international standards. Implementations should ensure that the
representation of the most and least significant bits and bytes in the computer
accurately reflect what is sent and received on the transmission medium.
Extended Addresses
There has been some confusion about how large a high-level data link control (HDLC)
address must be supported. NTCIP devices are required to support one-and two-byte
HDLC addresses. All addresses are odd; if the first byte of an address is even, then the
address is multibyte.
---------------------------------------------------------------------------------------------------------------8
Revision 2-March 3, 1997 Draft
Maximum Duration Between Successive Bytes
Many existing field devices expect incoming messages to be a series of bytes with
minimal delay between the bytes. They will time out as an end of message when a byte
is not received in 15 ms for 1,200-bps communications. This means that consecutive
messages must be separated by about 30 ms at 1,200 bps. With the simultaneous use of
soft carrier turnoff this gap must be increased by the soft carrier turnoff time. At higher
transmission rates these times are proportionally reduced.
Because of the desire for full-duplex communications, Class B NTCIP devices should be
designed to support much greater durations between successive bytes as suggested in
the Class B Profile. In short, the only distinguishing limit of a message is the 0x7E flag.
Response Time
The public domain code that is available was developed using DOS and Windows; in
both cases the serial port interrupt is only checked every 50 ms. Thus, these systems do
not perform quite as well as desired; however, this was not an issue for the
demonstration.
A real product should use a serial port driver to achieve the desired performance. The
desired performance is system dependent and is stored in the T2 object. Typically, this
value should be in the range of 20 ms. If the data link layer of the secondary (remote
device) has not received a response from the upper layers just prior to the T2 timer
expiring, it should send an empty frame (assuming the poll bit was set). The secondary
may not respond after the T2 timer expires.
Control Byte
The NTCIP includes support for three control byte values. A primary can transmit an
unnumbered poll (0x33), an unnumbered information command with the poll bit set
(0x13), or an unnumbered information command without the poll bit set (0x03). The
secondary always responds with unnumbered information response with the final bit
set (0x13). (Note that these values are presented according to Internet encoding rules.)
---------------------------------------------------------------------------------------------------------------9
Revision 2-March 3, 1997 Draft
Frame Handling
The primary may constantly poll each device in order to determine whether it has any
information to report. If the primary station has information to transmit with this poll
(e.g., a request), it encapsulates this data in an unnumbered information command with
the poll bit set. If there is not any information to send, it sends an “empty” frame of six
bytes called an unnumbered poll frame. If the primary station has information to send,
but does not want to give the opportunity for the receiving device to respond (e.g., a
broadcast), it sends the data in an unnumbered information frame without the poll bit
set.
When a secondary station receives an unnumbered information frame with the poll bit
set or an unnumbered poll, it responds with an unnumbered information frame with
the final bit set. If the secondary has any data to send with this frame, it is
encapsulated within the frame. If the secondary does not have any data to send, it
should send an empty frame.
When a secondary station receives an information command without the poll bit set
(e.g. a broadcast message), it does not respond.
It should be further noted that these rules only deal with the data link layer. For
example, a central system may send a broadcast message without a poll at the data link
layer, while requesting a response at the application layer. The remote device would
prepare a response at the application layer that would then be stored in the device’s
data link layer. This response could only be sent out after the device has received a
frame with the poll bit set.
For example, if dynamic object 1 had been defined to be the time object, central could
send the following byte stream:
Flag Addr Ctrl IPI STMP ----SET Time---- CRC Flag
7E FF 03 C1 91 31 E6 E7 00 XX XX 7E
The address indicates that it is received by everyone and the control byte prevents
anyone from responding on the wire; however, the STMP byte is a SET with response.
Thus, all of the devices generate responses at the application layer and they are sent to
the data link layer to be transmitted. Then, the data link layer waits until permission is
granted for the device to speak (e.g., an unnumbered poll frame). In this way, a central
system can broadcast the time and then go back and ensure that all the devices received
the message.
---------------------------------------------------------------------------------------------------------------10
Revision 2-March 3, 1997 Draft
If the secondary has a pending response waiting at the data link layer, it should send
the response immediately upon receiving a frame with the poll bit set. If the incoming
frame contains information, the information should be processed. This might entail
producing a new response that will be sent to the data link layer, where it will reside
until the next poll is received.
A device is responsible for storing one response frame at the data link layer. If a
second response is generated before the first is sent, the first response should be
overwritten.
CRC Algorithm
Examples of how to code the cyclical redundancy check (CRC) algorithm can be found
in the AB3418 code and the FHWA code used the demonstration.
Invalid Frame
When a device receives an invalid frame it should just discard the frame. Invalid
frames include those with invalid CRCs, invalid initial protocol identifiers, etc. Devices
should not provide any response to invalid frames.
STMP Message Type Byte
To see how the STMP Message Type Byte is coded and used, see NEMA Standards
Publication TS 3.2, National Transportation Communications for ITS Protocol, Simple
Transportation Management Framework, page 5-1.
Length Values for Variable Message Fields
The exact meaning of this field (i.e., which bytes are included in the count) has led to
some confusion. The count value does not include the count byte in the count (i.e., the
count starts the byte after the count byte).
---------------------------------------------------------------------------------------------------------------11
Revision 2-March 3, 1997 Draft
Carriers
It is very important that secondary stations on multidrop lines turn off their modem
carriers when not sending data. After responding to a poll, the carrier must be removed
from the line so that other stations may respond.
Systems Integration
In addition to those issues raised about the interpretation of the specifications, there
were also issues over how systems should be designed and what should be required in
procurement specifications to achieve the goal of systems interoperability. This section
provides some guidance on how to approach these issues.
Number of Devices on a Channel
The maximum number of reliable field devices on a single modem channel is limited
by the input impedance of the transmission output circuit in the field device modems.
Each of these outputs is a load on the field device transmission line. A practical upper
limit is somewhere around 15 field devices for the current technology 202 modems.
Advanced 202 modems can be used that will isolate the individual transmission circuits
unless the modem is actively transmitting. In a system with only four to seven field
devices per channel this consideration can be neglected.
MIB ISSUES
All NTCIP procurements should specify that the manufacturers/developers must
provide the devices' MIB module(s) to the purchasing agency, with rights to distribute
to their agents (e.g., those persons acting on behalf of the agency). The MIBs should be
provided in ASCII format on the medium of the procuring agency's choice. The MIBs
should include all Simple Network Management Protocol (SNMP)/Simple
Transportation Management Protocol (STMP) objects that the device(s) support.
NTCIP BYTE STREAM EXAMPLES
One of the challenges of the NTCIP is to be flexible enough to not only lend itself to
other, yet undefined, application requirements of ITS, but also to meet the demands on
the communication requirements of the existing traffic control devices. One such
demand is the fact that many existing traffic control systems have very limited
---------------------------------------------------------------------------------------------------------------12
Revision 2-March 3, 1997 Draft
bandwidth. To resolve this problem, the architects of the NTCIP have developed and
standardized NEMA TS 3.2 - Simple Transportation Management Framework (STMF)
and NEMA TS 3.3 Class B Profile. These documents provide a very efficient
standardized methodology by which to exchange data.
Unfortunately, there is a potential with any new standard that different people may
interpret the standard differently. This section is aimed at providing one interpretation
of how to use these specifications in order to exchange data. The section does not form
a specification in any sense, but can be used as a guide to determine where there may
be inconsistencies in interpretations of the specification documents and may increase
the potential of having consistent interpretations throughout the transportation
community. If differences are discovered through this process, they should be raised
with the NTCIP Joint Standards Committee. Over time, this section will be updated to
reflect the resolution of any such differences and thus can become an even more
definitive example.
Agencies implementing equipment claiming to be NTCIP compliant are encouraged to
interact with agencies and individuals involved in the NTCIP development to
maximize the benefits gained through sample field deployments.
Introduction
STMF specifies multiple formats that may be used in exchanging NTCIP data,
including these:
•
•
•
•
SNMP
STMP from the root node
STMP from the NEMA node
STMP dynamic objects.
Books describing SNMP are readily available from technical bookstores; therefore, this
section is limited to describing the various STMP encodings. The approach taken to
demonstrate the various encodings is to present a sample process to configure the
dynamic object definition table (which can not be done using dynamic objects) and then
retrieving and setting the values referenced by the dynamic objects.
The examples used in this section are based on object definitions as defined in NEMA
TS 3.4 - Global Object Definitions and the dynamic object definition table objects as
defined in the STMF.
---------------------------------------------------------------------------------------------------------------13
Revision 2-March 3, 1997 Draft
Definition of a Dynamic Object
Before presenting the example, it is useful to provide a background on what dynamic
objects are. A dynamic object is conceptualized as an aggregate of related managed
objects that can be operated on as a group. The goal is to minimize the bandwidth
requirements when communicating frequently requested sets of objects between a
management station and remote devices. Dynamic objects are designed to be defined
at run time to provide the management station with flexibility in how it communicates
with an agent.
For this purpose a node has been assigned under the protocols node called the dynamic
object management (dynObjMgmt) with OBJECT IDENTIFIER ::= {protocols 3}. The
dynObjMgmt subtree contains two nodes, dynObjDef and dynObjData.. Details of the
node assignments from the transportation node can be found in Section 4.2 of the
STMF.
Formal Specification for Dynamic Objects
Dynamic objects are formally specified in Sections 4 and 5 of the STMF. Section 4.2
identifies the position of dynamic objects in the International Organization for
Standardization tree.
Section 4.2 defines the rules for the creation and management of dynamic objects.
These rules will be applied in the subsequent sections of this section.
Configuration of Dynamic Objects
We will briefly examine the configuration of dynamic objects as specified in section 4.2
of the standard.
Dynamic Object Definition (dynObjDef)
The standard defines a table under the dynObjDef node, which is used to describe
which objects are contained within each dynamic object and in which order the
individual object appear within each dynamic object.
Each row (entry) in the table identifies a specific object, in which dynamic object it
resides, and its position (order) within the dynamic object. The dynamic object
definition table with sample data is shown below:
---------------------------------------------------------------------------------------------------------------14
Revision 2-March 3, 1997 Draft
dnObjNumber
dynObjIndex
1
1
dynObjVariabl
e
1.3.6.1.4.1.1206.
4.2.6.3.4.3
(eventLogID)
dynObjOwner
NTCIP Guide
Example
dynObjStatus
1
(Valid)
The table is explained in the standard and a summary follows:
The dynObjNumber identifies with which of the 13 dynamic objects this
row of the table is associated.
The dynObjIndex identifies the order in which the associated variable will
be located in the specified dynamic object.
The dynObjVariable is the object identifier and instance information of the
subject data.
The dynObjOwner is used to indicate the owner of this dynamic object.
The management station may optionally set the dynObjOwner to any value
it desires.
The dynObjStatus indicates whether the row is valid, invalid, or under
creation ; the values are explained in detail in section 4.1.4 of the
standard.
Examples
The following clauses provide sample encodings of the various message types that may
be sent according to the STMP.
Configuring a Dynamic Object
As an example, we will define dynamic object 1 as consisting of three objects defined in
NEMA TS 3.4 - Global Object Definitions. These objects were taken from one of the
three virtual tables needed to define the event log mechanism. These objects are
described in detail below after presenting the location of these objects under the global
tree:
eventLogTable ::= 1.3.6.1.4.1.1206.4.2.6.3.4
---------------------------------------------------------------------------------------------------------------15
Revision 2-March 3, 1997 Draft
Three of the objects under the iso (1) org (3) dod (6) internet (1) private (4) enterprises (1)
nema (1206) transportation (4) devices (2) global (6) globalReport (3) eventLogTable (4)
eventLogEntry(1) node are defined as follows:
eventLogClass
OBJECT-TYPE
SYNTAX
INTEGER (0..65535)
ACCESS
read-write
STATUS
mandatory
DESCRIPTION
“This object contains the event configuration ID (from the eventLogConfig Table) that
caused this table entry. It indicates the row in the eventLogConfig table responsible for
this event entry. If this object is set to zero (0) then the associated row (in the eventLog
Table) is cleared and the following rows shall be renumbered to maintain a sequential
eventNumber sequence.”
::= {eventLogEntry 3}
eventLogTime OBJECT-TYPE
SYNTAX
INTEGER (0..4228250625)
ACCESS
read-only
STATUS
mandatory
DESCRIPTION
“The time that the event occurred in seconds since the epoch of 00:00:00 (midnight)
January 1, 1970 per the device’s globalTime object. If the device does not have valid
date and time information, then this shall be the time in seconds since the device is
powered up.”
::= {eventLogEntry 4}
eventLogValue
OBJECT-TYPE
SYNTAX
OPAQUE
ACCESS
read-only
STATUS
mandatory
DESCRIPTION
“The value of this object is dt to the value pointed to bt the eventConfigConpareOID of
the associated eventLogID whn the event was logged. Its length is variable.”
::= {eventLogEntry 5}
Thus the OID for the three objects are:
• 1.3.6.1.4.1.1206 4.2.6.3.4.3 (eventLogID)
---------------------------------------------------------------------------------------------------------------16
Revision 2-March 3, 1997 Draft
• 1.3.6.1.4.1.1206 4.2.6.3.4.4 (eventLogTimel)
• 1.3.6.1.4.1.1206.4.2.6.3.4.5 (eventLogValue)
Assuming that we are working with an STMP-compliant device that supports these
three objects, we can aggregate the three objects into a dynamic object following the
procedure outlined in STMF.
The virtual representation of the dynObjDef object table that is about to be created is
shown below:
dynObjNumbe
r
1
dynObjIndex
1
dynObjVariabl
e
eventLogID
1
2
eventLogTime
1
3
eventLogValue
dynObjOwner
dynObjStatus
NTCIP Guide
Example
NTCIP Guide
Example
NTCIP Guide
Example
1
1
1
For the purposes of this example we will set the value of the dynObjOwner to
NTCIP Guide Example for each row.
The setup of the dynamic object table involves a row by row configuration of the table.
This is achieved by sending set request command(s) to the agent, appropriately setting
the values in the table. During the process of setting these values, the dynObjStatus
entry for each row is set to the value “createRequest (2)”.
According to Section 5.2.1.4 of the Standard, the Information Field shall contain the
VarBindList. This is defined as
SEQUENCE OF
SEQUENCE{
name ObjectName,
value ObjectSyntax
}
The concept of VarBindList is further explained below.
---------------------------------------------------------------------------------------------------------------17
Revision 2-March 3, 1997 Draft
A variable represents an instance of a managed object. A variable binding, or VarBind,
refers to the pairing of the name of the variable (including the instance, or index, of the
variable) and its value. A list of, called a SEQUENCE OF, such VarBinds or pairs is
defined as a VarBindList. This concept is reflected in the following encoding which
represents the initial set up of a dynamic object table.
The byte stream has been modified according to the rules in 5.1.2 of the Standard. Rule
(d) states that the OBJECT IDENTIFIER fields shall be interpreted as in 5.1.1.3. This
means that if the Object ID Field of the PDU Header Field is 0 (nema node), then the
stream is modified and encoded as indicated below. If the object ID Field of the PDU
Header Field was 14 (0xE) then the objects would have to be specified from the ISO
node (the struck-out bytes would be added, and the length values would be adjusted
accordingly).
STMP Set Request from NEMA
90
STMP SET
REQUEST from NEMA
30 81 D2
Sequence (0x30)
with length defined in 1 byte (0x81)
and the length value is 210 bytes (0xD2)
30 14
Sequence of 20 bytes (0x14) (name-value pair)
06 08
OID of length = 8 bytes (0x08) follow
04 01 03 01 01 03
OID of dynObjVariable (1.3.6.1.4.1.1206.4.1.3.1.1.3)
from the nema node
01 01
Index (dynObjNumber, dynObjIndex)
06 08
OID of length = 8 bytes (0x08) follow
04 02 06 03 04 03
OID of eventLogID (1.3.6.1.4.1.1206 4.2.6.3.4.3)
from the NEMA node
03 01
index for eventLogClass=3 and
eventLogNumber=1
30 1F
Sequence of 31 bytes (0x1F) (name-value pair)
06 08
OID of length = 8 bytes (0x08)
04 01 03 01 01 04
OID of dynObjOwner (1.3.6.1.4.1.1206.4.1.3.1.1.4)
01 01
from nema node and index
04 13
The value which is an Octet string of 19 bytes
follow
4E 54 43 49 50 20 47 75 69 64 65 20 45 78
Value of dynObjOwner = NTCIP Guide Example
61 6D 70 6C 65
30 0D
Sequence of 13 bytes (0x0D) (name-value pair)
06 08
OID of length = 8 bytes (0x08) follow
04 01 03 01 01 05
OID of dynObjStatus (1.3.6.1.4.1.1206.4.1.3.1.1.5)
01 01
and index
---------------------------------------------------------------------------------------------------------------18
Revision 2-March 3, 1997 Draft
02 01 02
30 14
06 08
04 01 03 01 01 03 01 02
06 08
04 02 06 03.04.04 03 01
30 1F
06 08
04 01 03 01 01 04 01 02
04 13
4E 54 43 49 50 20 47 75 69 64 65 20 45 78
61 6D 70 6C 65
30 0D
06 08
04 01 03 01 01 05 01 02
02 01 02
30 12
06 06
04 01 03 01 01 03 01 03
06 06
04 02 06 03 04 05 03 01
30 1F
06 08
04 01 03 01 01 04 01 03
04 13
4E 54 43 49 50 20 47 75 69 64 65 20 45 78
61 6D 70 6C 65
30 0D
06 08
04 01 03 01 01 05 01 03
02 01 02
Value of dynObjStatus (Integer= 02, Length =1,
Value =2 [Create Request])
Sequence of 20 bytes (0x14) (name-value pair)
OID of length = 8 bytes (0x08) follow
OID of dynObjVariable from NEMA and index
OID of length = 6 bytes follow
OID of eventLogTime from NEMA and index
Sequence of 31 bytes (0x1F) (name-value pair)
OID of length = 6 bytes (0x06) follow
OID of dynObjOwner from NEMA and index
The value which is an Octet string of 19 bytes
follow
Value of dynObjOwner = NTCIP Guide Example
Sequence of 13 bytes (0x0D) (name-value pair)
OID of length = 8 bytes (0x08) follow
OID of dynObjStatus from NEMA and index
Value of dynObjStatus (Integer= 02, Length =1,
Value =2 [Create Request])
Sequence of 18 bytes (0x12) (name-value pair)
OID of length = 8 bytes (0x08) follow
OID of dynObjVariable from nema and index
OID of length = 8 bytes follow
OID of eventLogValue from NEMA and index
Sequence of 31 bytes (0x1F) (name-value pair)
OID of length = 8 bytes (0x08) follow
OID of dynObjOwner from nema and index
The value which is an Octet string of 19 bytes
follow
Value of dynObjOwner = NTCIP Guide Example
Sequence of 13 bytes (0x0D) (name-value pair)
OID of length = 8 bytes (0x08) follow
OID of dynObjStatus from nema and index
Value of dynObjStatus (Integer= 02, Length =1,
Value =2 [Create Request])
The complete Class B Profile encoding of this message is as shown below (encoded as
an unnumbered information frame with the poll bit set):
7E YY 13 C1 90 30 81 D2 30 14 06 08 04 01 03 01 01 03 01 01 06 08 04 02 06 03 04 03 03 01
30 1F 06 08 04 01 03 01 01 04 01 01 04 13 4E 54 43 49 50 20 47 75 69 64 65 20 45 78 61 6D
70 6C 65 30 0D 06 08 04 01 03 01 01 05 01 01 02 01 02 30 14 06 08 04 01 03 01 01 03 01 02
06 08 04 02 06 03 04 04 03 01 30 1F 06 08 04 01 03 01 01 04 01 02 04 13 4E 54 43 49 50 20 47
75 69 64 65 20 45 78 61 6D 70 6C 65 30 0D 06 08 04 01 03 01 01 05 01 02 02 01 02 30 14 06
---------------------------------------------------------------------------------------------------------------19
Revision 2-March 3, 1997 Draft
08 04 01 03 01 01 03 01 03 06 08 04 02 06 03 04 05 03 01 30 1F 06 08 04 01 03 01 01 04 01 03
04 13 4E 54 43 49 50 20 47 75 69 64 65 20 45 78 61 6D 70 6C 65 30 0D 06 08 04 01 03 01 01
05 01 03 02 01 02 XX XX 7E
XX XX = CRC for stream
YY = Address to which the message is to be sent
STMP Set Response from NEMA
Assuming that the receiving device sucessfully received the data packet, it should
respond with an STMP Set Response with encoding from the same reference node (in
this example from NEMA). The encoding will be as follows:
D0
STMP SET RESPONSE from NEMA
The complete Class B Profile encoding of the data packet is as shown below:
7E YY 13 C1 D0 XX XX 7E
XX XX = CRC for frame
YY = device address
STMP Set Request from Root
The final step is to activate the table as a dynamic object, and this is done by setting the
dynObjStatus for each row to valid (1). This operation could be (and likely would be)
done with encoding from the NEMA node, but this example encodes it from the root
node for explanatory purposes. The encoding will then be as follows:
9E
30 42
30 14
Length
06 0F
2B 06 01 04 01 89 36 04 01 03 01 01 05
01 01
02 01 01
30 14
06 0F
2B 06 01 04 01 89 36 04 01 03 01 01 05
STMP SET Request from Root
Sequence of 66 bytes (0x42) bytes
Sequence of 20 bytes (0x14) (Pair: OID
and its value follow
OID of length = 15 bytes (0x0F) follow
OID of dynObjStatus from root node
Index
Value of dynObjStatus (Integer= 02,
=1, Value = 1 [Valid])
Sequence of 20 bytes
OID of length = 15 bytes follow
OID of dynObjStatus from root
---------------------------------------------------------------------------------------------------------------20
Revision 2-March 3, 1997 Draft
01 02
02 01 01
30 14
06 0F
2B 06 01 04 01 89 36 04 01 03 01 01 05
01 03
02 01 01
Index
Value of dynObjStatus
Sequence of 20 bytes
OID of length = 15 bytes
OID of dynObjStatus from root node
Index
Value of dynObjStatus
STMP Set Response From Root
Again, the receiving device would indicate that it sucessfully received the data packet.
The encoding will be as follows:
DE
STMP SET RESPONSE from Root
Once the dynamic object table structure is created with the above sequence of
operations, the management station can efficiently GET and SET the values referenced
by the associated dynamic object whenever the need arises.
STMP Dynamic Object Get Request
A GET request for the data referenced by the dynamic object can be performed in just 1
byte of application layer encoding as follows:
Get
dynamic
object. #1
81
The resulting Class B Profile byte stream (including header and footer information) will
look as follows:
7E YY 13 C1 81 XX XX 7E
Explanation of the Event Log
In the example detailed above, dynamic object 1 consists of data from the event log table. Thus, in order
to understand what will be returned from a get request for this dynamic object, one must first
understand the event log.
---------------------------------------------------------------------------------------------------------------21
Revision 2-March 3, 1997 Draft
The contents of the event log are defined in the event log configuration table as
depicted below. The user configures this table to define which events should be logged
in the event log table.
ID
Class
INTEGER INTEGER
Mode
Compare
Enum
INTEGER INTEGER
Value
Compare
Value 2
Compare
OID
OID
Log OID
OID
Config
Action
Enum
Each defined event has a unique ID to distinguish the event. Whenever this event occurs, it is recorded
in the event log table under the class identified in the configuration table. Events are defined based on
certain conditions becoming true. The mode variable identifies the type of event (e.g., on-change, when
equal to, exceeds, etc) and the compare values indicate the values to use in the comparison defined in
the mode (e.g., when exceeds compare value). The compare OID field references the variable to use in
the comparison (e.g., when temperature exceeds compare value). The Log OID references the variable
that should be logged when the event becomes true (e.g., when temperature exceeds compare value log
the status of the fans). Finally, the configuration action variable identifies whether this event should be
logged or whether it is disabled (other options may be added in the future, such as returning a trap
when the condition occurs).
For the purpose of this example, it is assumed that there is a entry in the event
configuration table as follows:
ID
Class
Mode
Compare
Value
Compare
Value 2
Compare OID
Log OID
17
3
onchange
0
0
phaseStatus
GroupGreens.
1
phaseStatus
GroupGreens.1
Config
Action
log
The phaseStatusGroupGreens (from TS 3.5) object indicates which of the phases are
currently active within a particular phase group. The first phase group (identified by
the “.1” index extension) indicates the status of the first eight phases. Thus, whenever
the green status of any of the first eight phases change, the new value of the
phaseStatusGroupGreen.1 object is recorded in the Class 3 section of the log. The log
entry is denoted as event ID 17. Note that for the on-change mode, the values of
compare value and compare value2 are irrelevant.
The amount of space allocated to the Class 3 events is determined by the event class
table. Assuming that this number is non-zero, the object referenced in our dynamic
object (i.e., Class 3 Number 1) is valid.
---------------------------------------------------------------------------------------------------------------22
Revision 2-March 3, 1997 Draft
The event log table is defined as follows with a sample entry:
Class
3
Number
1
ID
17
Time
00:00:00 6/1/96
Value
34
The class indicates the class of the event as identified in the event configuration table.
The number indicates which entry in the table (within a given Class). The ID identifies
the event ID as specified in the event configuration table. The time is a time stamp of
when the event occured, in this case at midnight, the morning of June 1, 1996. The
value records the value of the object referenced by the associated log OID field in the
event configuration table, in this case it records the value of phaseGroupGreenStatus.1
as of midnight on June 1, 1996. The value 34 represents phases 2 and 6 as being green.
With this background of the event log, and the above assumptions regarding the
“current” values, we can now present the response to the above get request.
STMP Dynamic Object Get Response
For the dynamic object 1 get request above, the corresponding get response byte stream
will be as follows:
C1
11
31 AF 88 00
01
22
GET RESPONSE for Dynamic Object number 1
Event Configuration ID number 17 (= 0x11 hex)
833587200 seconds since 00:00:00 1/1/70
Variable is one byte in length (This field is
required
because OPAQUEs are variable length)
phases 2 and 6 were green when event was
recorded
The resulting Class B byte stream will look as follows:
7E YY 13 C1 C1 11 31 AF 88 00 01 22 XX XX 7E
STMP Dynamic Object Get-Next Request
According to subsection 5.1.1.2 (message type field), a get-next request shall be sent
from a manager to an agent to request the value of the next object in lexigraphic order.
This can be applicable in a case where more than one dynamic object structure has been
defined in a device. For example if dynamic objects 1, 4 and 5 are defined in a device,
---------------------------------------------------------------------------------------------------------------23
Revision 2-March 3, 1997 Draft
a get-next request for dynamic object 1, as indicated below, would retrieve the data
referenced by dynamic object 4 with similar encoding as before.
Get-next
dynamic
object next
to number
1
B1
STMP Dynamic Object Set Request-No Reply
If the user wanted to send a message to set the objects referenced by dynamic object 1,
but did not want to receive a confirmation of the response, it would send the following
byte stream (using the same values as before).
A1
Number 1
11
31 AF 88 00
01
22
Set Request-No Reply for dynamic object
Event Configuration ID number 17 (= 0x11 hex)
833587200 seconds
A one byte value follows
Phases 2 and 6 are green
The remote device would process such a request if possible, but would not respond (at
the application layer) under any condition. This operation may be desired if the
management station is concerned about overwriting traps or other pending responses.
STMP Dynamic Object Error Response
You may have noticed that the above example contained an error. Both the event log
time and event log value parameters are “read only” and thus may not be set. In the
above example, this error would not be reported because the request indicated no
reply. However, if the message had been a set request instead of a set request-no reply
(e.g., a PDU Header field of 0x91 instead of 0xA1), the following error would be
returned:
E1
04
02
Error Response for Dynamic Object 1
the first error encountered was a readOnly
Error
this error was encountered on the second item
in the packet
---------------------------------------------------------------------------------------------------------------24
Revision 2-March 3, 1997 Draft
Note: According to subsection 5.2.1.5 (Error responses) the agent will return an error status and
index number only. There is no need for the agent to return the information contained in the set
request since the manager retains the last request transmitted to an agent in order to determine
what part of the request caused the error.
Because this error response provides valuable information, the use of set request-no
reply should be used with great caution.
Other Nondynamic Examples
The following examples provide a contrast between the bandwidth consumption of the
dynamic objects given above and non-dynamic objects as shown below.
STMP Get Request from NEMA
a get request for the objects defined in the above dynamic object 1 would be
represented as follows:
80
30 24
30 0A
06 08
04 02 06 03 04 03
03 01
30 0A
06 08
04 02 06 03 04 04 03 01
30 0A
06 08
04 02 06 03 04 05 03 01
GET REQUEST from the NEMA node
Sequence of 36 bytes (VarBindList) follows
Sequence of 10 bytes follows
OID of length = 8 bytes follows
OID of eventLogID from NEMA node
Index
Note: No value according to rule 5.1.2 (a)
Sequence of 10 bytes follows
OID of length = 8 bytes follows
OID & index of eventLogTime from NEMA
node
Sequence of 10 bytes follows
OID of length = 8 bytes follows
OID of eventLogValue from NEMA node
Notice the difference in overhead between the get request for a dynamic object and the
same request for the objects treated as nondynamic objects. In this example, the
complete Class B frame for the dynamic object would be 8 bytes and the frame for nondynamic objects would be 45 bytes (a savings of over 82 percent!). This differential
would be even greater for more complex dynamic objects. For a process that is
frequently repeated, the dynamic object option provides a significant advantage in
reducing bandwidth requirements.
---------------------------------------------------------------------------------------------------------------25
Revision 2-March 3, 1997 Draft
STMP Get Response from NEMA
The corresponding get response would be encoded as follows:
C0
30 30
30 0D
06 08
04 02 06 03 04 03 03 01
02 01 11
30 10
06 08
04 02 06 03 04 04 03 01
02 04 31 AF 88 00
30 0D
06 08
04 02 06 03 04 05 03 01
44 01 22
GET RESPONSE from NEMA node used as
root)
Sequence of 48 bytes (VarBindList) follows
Sequence of 13 bytes follows
OID of length = 8 bytes follows
OID and Index of eventLogID from NEMA
node
Value return (INTEGER=2, length=1,
value=17)
Sequence of 16 bytes follows
OID of length = 8 bytes follows
OID and Index of eventLogTime from NEMA
node
Value return (INTEGER=2, length=4, value=
833587200 seconds)
Sequence of 13 bytes follows
OID of length = 8 bytes follows
OID of eventLogValue from NEMA node
Value return (OPAQUE=0x44, length=1,
value=0x22)
In this case, the Class B frame response using nondynamic objects would be 58 bytes
long versus 15 bytes for the dynamic object (a savings of almost 75 percent!) Once
again, this savings becomes even more pronounced for more complex dynamic objects.
STMP Get-Next Request from NEMA
A get-next request can be used to retrieve instances of sequential nondynamic objects.
The object retrieved is the next object in lexicographic order. For tabular objects, this
would be the next sequential entry of the same parameter. Examples of this are
provided below.
B0
30 0A
06 08
04 02 06 03 04 05 03 01
GET Next Request from NEMA
Sequence of 10 bytes
Object Identifier of 8 bytes
OID and index of eventLogValue.3.1
---------------------------------------------------------------------------------------------------------------26
Revision 2-March 3, 1997 Draft
Assuming that there was a second entry of the same ID recorded at 00:00:20 on June 1,
1996, and that the recorded green phases were four and eight, the response would be
C0
30 0D
06 08
04 02 06 03 04 05 03 02
02 01 88
GET Response from NEMA
Sequence of 13 Bytes
OID of 8 bytes
eventLogValue for Class 3 Number 2
INTEGER=2, Length=1, Value=0x88
The Get-Next Request can also be used to get a sequence of items as follows:
B0
30 24
30 0A
06 08
04 02 06 03 04 03 03 01
30 0A
06 08 04 02 06 03 04 04 03 01
30 0A
06 08 04 02 06 03 04 05 03 01
Get Next Request from NEMA
Sequence of 36 bytes
Sequence of 10 bytes
OID of 8 bytes
OID and Index of eventLogID.3.1
Sequence of 10 bytes
TLV of OID & index of eventLogTime.3.1
Sequence of 10 bytes
TLV of OID & index of eventLogValue.3.1
And the response would be:
C0
30 30
30 0D
06 08
04 02 06 03 04 03 03 02
02 01 11
30 10
06 08 04 02 06 03 04 04 03 02
02 04 31 AF 88 14
30 0D
06 08 04 02 06 03 04 05 03 02
02 01 88
Get Response from NEMA
Sequence of 48 bytes
Sequence of 13 bytes
OID of 8 bytes
OID & index of eventLogID.3.2
INTEGER of 1 byte = 17
Sequence of 16 bytes
TLV of OID & index of eventLogTime.3.2
INTEGER of 4 bytes = 00:00:20 6/1/96
Sequence of 13 bytes
TLV of OID & index of eventLofValue.3.2
INTEGER of 1 byte = 0x88
Conclusion
There is considerable reduction in overhead once a group of objects have been defined
as a dynamic object.
---------------------------------------------------------------------------------------------------------------27
Revision 2-March 3, 1997 Draft
Dynamic object implementation will be most useful for retrieving objects that need
frequent polling (e.g., traffic data in signal controllers). This means that once the
dynamic object table has been created, the dynamic values of the objects can be
frequently polled with minimal overhead
---------------------------------------------------------------------------------------------------------------28
Revision 2-March 3, 1997 Draft
Chapter 5 Procedures for Maintaining and Modifying
the Standard
---------------------------------------------------------------------------------------------------------------1
Revision 2-March 3, 1997 Draft
Appendix A Acronyms
Abbreviation
/Acronym
Definition
AASHTO
American Association of State Highway and Transportation
Officials
ANSI
American National Standards Institute
ASCII
American Standard Code for Information Interchange
ASN.1
Abstract Syntax Notation One
ATIS
Advanced Traveler Information System
ATMS
Advanced Traffic Management System
AVI
Automatic Vehicle Identification
AVL
Automatic Vehicle Location
bps
bits per second
CCITT
Consultative Committee for International Telegraphy and
Telephony, now known as ITU-T
CCTV
closed-circuit television
CLNS
connectionless-mode network service
CLS
closed-loop system
CONS
connection-oriented network service
CRC
cyclical redundancy check
DCE
Data Circuit Terminating Equipment
DLSAP
Data Link Service Access Point
---------------------------------------------------------------------------------------------------------------1
Revision 2-March 3, 1997 Draft
Abbreviation
/Acronym
Definition
DLSDU
Data Link Service Data Unit
DTE
Data Temminal Equipment
DTR
Data Terminal Ready
EBCDIC
Extended Binary Coded Decimal Interchange Code
EIA
Electronic Industries Association
FCS
Frame Check Sequence (see Cyclic Redundancy Check)
FHWA
Federal Highway Administration
FSK
Frequency Shift Keying
FTP
File Transfer Protocol
HAR
Highway Advisory Radio
HDLC
High-Level Data Link Control
IAB
Internet Activities Board
IANA
Internet Assigned Numbers Authority
IEC
International Electro-technical Commission
IETF
lnternet Engineering Task Force
IP
Internet Protocol
IPI
Initial Protocol Identifier
ISO
International Organization for Standardization
ISTEA
Intermodal Surface Transportation Efficiency Act of 1991
ITE
Institute of Transportation Engineers
---------------------------------------------------------------------------------------------------------------2
Revision 2-March 3, 1997 Draft
Abbreviation
/Acronym
Definition
ITIIS
International Traveler Information Interchange Standard
ITS
Intelligent Transportation Systems
ITU-T
International Telecommunications Union, Telecommunications
Sector
LAN
Local Area Network
LLC
Logical Link Control
LSB
Least Significant Bit
MIB
Management Information Base
MSB
Most Significant Bit
NEMA
National Electrical Manufacturers Association
NSDU
Network Service Data Unit
NTCIP
National Transportation Communication for ITS Protocol
NVT
Network Virtual Terminal
OSI
Open Systems Interconnection
PDU
Protocol Data Unit
PER
Packed Encoding Rules
PICS
Protocol Implementation Conformance Statement
PMPP
Point-to-Multi Point Protocol
PPP
Point-to-Point Protocol
RFC
Request for Comments
---------------------------------------------------------------------------------------------------------------3
Revision 2-March 3, 1997 Draft
Abbreviation
/Acronym
Definition
RM-OSI
Reference Model OSI
SAP
Service Access Point
SDU
Service Data Unit
SMI
Structure of Management Information
SNMP
Simple Network Management Protocol
SNMPv2
Simple Network Management Protocol version 2
STMF
Simple Transportation Management Framework
STMI
Structure and Identification of Transportation Management
Information
STMP
Simple Transportation Management Protocol
TCIP
Transit Communications Interface Protocol
TCP
Transmission Control Protocol
TCP/IP
Transmission Control Protocol/Internet Protocol
TIA
Telecommunications Industries Association
TLV
Tag, Length, Value
TMC
Transportation Management Center
TMC E1
Transportation Management Experimental Protocol Version 1
TMC E1.2
Transportation Management Experimental Protocol Version 2
TMIB
Transportation MIB
TMS
Transportation Management Systems
---------------------------------------------------------------------------------------------------------------4
Revision 2-March 3, 1997 Draft
Abbreviation
/Acronym
Definition
TOC
Transportation Operation Center
UCC
Unbalanced Connectionless Class
UDP
User Datagram Protocol
UI
Unnumbered Information (Frame)
VMS E1
Variable Message Sign Experimental Protocol Version 1.0
VMS E1.2
Variable Message Sign Experimental Protocol Version 1.2
WAN
Wide Area Network
---------------------------------------------------------------------------------------------------------------5
Revision 2-March 3, 1997 Draft
Appendix B - Glossary
Term/Abbreviation Definition
Acronym
agent
An STMF entity that receives commands and transmits responses
to the received commands.
ANSI
American National Standards Institute, a standardization group
that develops or adopts standards for the United States.
application services
The services collectively offered by the upper four layers of the
OSI model.
Applications
Programmer
Interface (API)
A set of calling conventions defining how a service is invoked
through a software package.
ASCII
American Standard Code for Information Interchange. A 7-bit
binary code representation of letters, numbers, and special
characters. It is universally supported in computer data transfer.
ASN.1
Abstract Syntax Notation One, a formal language for describing
information to be processed by computer, an ISO standard.
asynchronous
Data transmission in which the actual data is preceded by a start
bit and followed by a stop bit since the time between transmitted
characters varies. Compare with Synchronous.
authentication
The process whereby a message is associated with a particular
originating entity.
authorization
The process whereby an access policy determines whether an
entity is allowed to perform an operation.
---------------------------------------------------------------------------------------------------------------6
Revision 2-March 3, 1997 Draft
Term/Abbreviation Definition
Acronym
bandwidth
The range of frequencies that can be used for transmitting
information on a channel, equal to the difference in Hertz (Hz)
between the highest and lowest frequencies available on that
channel. Indicates the transmission-carrying capacity of a
channel.
Basic
Encoding The OSl language for describing transfer syntax.
Rules (BER)
Baud Rate
The number of discrete signal events per second occurring on a
communications channel. It is often interchanged with bits per
second (bps), which is technically inaccurate but widely
accepted.
bit
Binary digit. A single basic computer signal consisting of a value
of 0 or 1, off or on.
Bit error rate (BER)
The number of bits transmitted incorrectly.
In digital
applications it is the ratio of bits received in error to bits sent.
bps
Bits per second, transmission rate (speed) of data
bridge
A means for connecting two networks at the data link layer.
broadcast address
An address referring to all stations on a medium.
byte
A group of bits acted upon as a group, which may have a
readable ASCII value as a letter or number or some other coded
meaning to the computer. it is commonly used to refer to 8-bit
groups.
(AB3418) California A bill that requires all new or upgraded traffic signal controllers
Assembly Bill No. installed in California after January 1, 1996, to incorporate a
3418
standard communications protocol. Caltrans has published this
specification for developers.
---------------------------------------------------------------------------------------------------------------7
Revision 2-March 3, 1997 Draft
Term/Abbreviation Definition
Acronym
carrier
A continuous frequency capable of being either modulated or
impressed with another information-carrying signal. Carriers are
generated and maintained by modems via the transmission lines
of the telephone companies.
checksum
An arithmetic sum used to verify data integrity.
Class A Profile
“A”dvanced Field Communications - Designed for more
complicated networks, Class A comunications provides for
Routing of messages and has 35 bytes of overhead per frame.
However, Class A has the same data link layer limitations as
Class B Communications.
Class B Profile
“B”asic Field Communications - Designed for the existing field
environment, such as multidrop lines, low speed (1,200 bps), it
has 8 bytes of overhead per frame, provides basic NTCIP
functionality, supports multiple manufacturers, and supports
multiple device types.
Class C Profile
“C”onnection-Oriented Communications - This type of
communications provides for connections and sequencing and
allows for File Transfers. However, it has 47 bytes of overhead
per frame.
Class D Profile
“D”ial-Up Communications - Class D will provide for security
for dial-up connections, utilize point-to-point design, and will
probably use dial-back features.
Class E Profile
Center-to-Center “E”xchange - Class E will be 100% Internet
Community Standard, and designed for high bandwidth pointto-point connections. It will allow both File transfers and SNMP
operations.
---------------------------------------------------------------------------------------------------------------8
Revision 2-March 3, 1997 Draft
Term/Abbreviation Definition
Acronym
Cyclical
Redundancy Check
Cyclical Redundancy Check. An error-detection technique
consisting of a cyclic algorithm performed on each “block” of
data at the sending and receiving end of the transmission. As
each block is received, the CRC value is checked against the CRC
value sent along with the block.
data
Information before it is interpreted.
data dictionary
An organized listing of all data elements that are essential to the
system, with precise, definitions so that both the user and the
system developer will have a common understanding of input,
output, components of storage, and intermediate calculations.
data flow
The description of information movement and the transforms
that are applied as the data moves from input to output.
Data Link Layer
Layer 2 of the OSI Reference Model; it is responsible for
transmission, framing, and error control over a single
communications link.
datagram
A self-contained unit of data transmitted independently of other
datagrams.
DTE
Data Terminal Equipment. The device that is the originator or
destination of the data sent by a modem. (An EIA/TIA - 232 - E
signal)
DTR
Data Terminal Ready. A signal generated by most modems
indicating a connection between the DTE (computer) and the
modem. When DTR is high, the computer is connected. (An
EIA/TIA - 232 - E signal)
EIA/TIA-232-E
Electronic Industries Association/Telecommunications Industries
Association specification that defines the serial port on a PC.
end-to-end services
The services collectively offered by the lower three layers of the
OSI model.
---------------------------------------------------------------------------------------------------------------9
Revision 2-March 3, 1997 Draft
Term/Abbreviation Definition
Acronym
flow control
A mechanism that compensates for differences in the flow of data
to and output from a modem or computer. Either hardware or
software can be used for this control to prevent data loss.
Hardware flow control using the modem makes use of a buffer to
store data to be sent and data received. Flow control is necessary
if the communications port is locked at a higher rate than the
connection rate.
FSK modem
interface
Typical method of traffic control system communications, phone
line, or twisted wire based.
full duplex
Signal flow in both directions at the same time. It is sometimes
used to refer to the suppression of on-line local echo and
allowing the remote system to provide a remote echo.
gateway
A router and translater between protocols; also, (imprecise usage)
an entity responsible for complex topology mappings.
half duplex
Signal flow in both directions, but only one way at a time. It is
sometimes used to refer to activation of local echo which causes a
copy of sent data to be displayed on the sending display.
HDLC
Generalized network approach: high-level data link control
Highway Advisory
Radio (HAR)
Low-powered AM or FM stations that broadcast brief messages
to standard car radios from small transmitters placed near
highways.
host
(Internet usage) an endsystem.
IETF
lnternet Engineering Task Force, a group chartered by the IAB to
develop certain RFCs for standardization .
indirect routing
The process of sending a network message to a router for
forwarding.
---------------------------------------------------------------------------------------------------------------10
Revision 2-March 3, 1997 Draft
Term/Abbreviation Definition
Acronym
infrastructure
This refers to all fixed components to a transportation system
such as rights of way, tracks, equipment, stations, parking/parkn-ride lots, signalization equipment, maintenance facilities.
Intelligent
Transportation
Systems (ITS)
A major national initiative to improve information,
communication, and control technologies in order to improve the
efficiency of surface transportation. Technological innovations
that apply direct communications and information processing to
improve the efficiency and safety of surface transportation
systems.
These include on-board navigation for vehicles,
emergency communications systems, electronic toll/fare
collections, traffic management centers, etc.
intermediate
system
A network device performing functions from the lower three
layers of the OSI model. Intermediate systems are commonly
thought of as routing data for end systems.
Intermodal Surface
Transportation
Efficiency Act of
1991 (ISTEA)
Federal authorizing legislation for highways, transit, and other
surface transportation programs.
Established intermodal
objectives for national transportation system to achieve efficiency,
air quality, and environmental quality.
intermodalism
The use and coordination of more than one mode of
transportation.
International
Organization for
Standardization
(ISO)
An international standards organization. ANSI is the primary
interface to ISO within the United States. Often thought to be
International Standards Organization because of the usage ISO
for short.
Internet
A large collection of connected networks, primarily in the United
States, running the Internet suite of protocols. Sometimes referred
to as the DARPA Intemet, NSF/DARPA, Intemet, or the Federal
Research Intemet.
---------------------------------------------------------------------------------------------------------------11
Revision 2-March 3, 1997 Draft
Term/Abbreviation Definition
Acronym
Internet
(IP)
Protocol The network protocol offering a connection less mode network
service in the Internet suite of protocols.
Internet suite of
protocols
A collection of computer-communication protocols originally
developed under DARPA sponsorship.
IP address
A 32-bit quantity used to represent a point of attachment in an
internet. An Internet Protocol Address.
lAB
Internet Activities Board, group in charge of authorizing RFCs
for the purpose of standardizing Internet operations.
IANA
Internet Assigned Numbers Authority, group in charge of
assigning Internet addresses.
Local Area
Network (LAN)
Any one of a number of technologies providing high speed, lowlatency transfer and being limited in geographic size.
Management
Information Base
(MIB)
A collection of objects defined using Abstract Syntax Notation
One (ASN.1) that can be accessed via a network management
protocol. (See Structure of Management Information.)
manager
The entity that sends commands to entries and processes their
responses.
maximum
transmission unit
The largest amount of user data that can be sent in a single frame
on a particular medium.
network
A collection of subnetworks connected by intermediate systems
and populated by end systems.
network identifier
That portion of an IP address corresponding to a network in an
internet.
Network Layer
That portion of an OSI system responsible for data transfer across
the network, independent of both the media comprising the
underlying subnetworks and the topology of those subnetworks.
---------------------------------------------------------------------------------------------------------------12
Revision 2-March 3, 1997 Draft
Term/Abbreviation Definition
Acronym
network
management
The technology used to manage a network. Usually referring to
the management of networking specific devices such as routers.
In the context of the NTCIP, refers to all devices including end
systems that are present on the network or inter network.
NTCIP
National Transportation Communication for ITS Protocol,
communications protocol under development. The development
effort is being spearheaded by FHWA, NEMA, and the NTCIP
Joint Standards Committee.
NTCIP Home Page
Site on the World Wide Web where one may obtain the latest
NTCIP information. The address is
http://www.ntcip.org
NTCIP
Group
Steering A public/private advisory group composed of ITS experts that
guides the development of the NTCIP.
object
A representation of a data element that is managed.
object identifier
A unique name (identifier) that is associated with each type of
object in a MIB. This is a defined ASN.1 type.
OBJECT-TYPE
The macro defined in RFC-1212 which is the format used to
define SNMP objects. In STMF, the OBJECT-TYPE macro
consists of five fields:
• Object Name
• Syntax
• Description
• Access
• Status.
Open Systems
Interconnection
(OSI)
An international effort to facilitate communications among
computers of different manufacture and technology.
---------------------------------------------------------------------------------------------------------------13
Revision 2-March 3, 1997 Draft
Term/Abbreviation Definition
Acronym
parity
A simple error detection method used in both communications
and computer memory checking to determine character validity.
PER
Packed Encoding Rules, a variation of BER developed for use on
low bandwidth communications links, specified in NEMA TS3.2.
physical address
The address of a physical interface.
Physical Layer
That portion of an OSI system responsible for the electromechanical interface to the communications media.
Point-to-Point
Protocol (PPP)
Transmission of data between two and only two stations on a
point to point link.
Point-to-MultiTransmission of data between multiple stations or nodes (i.e., one
Point
Protocol primary and multiple secondaries).
(PMPP)
port number
Identifies an application-entry to a transport service in the
Internet suite of protocols. The concept of ports are often present
in OSI literature, however, ports are not Internet standard, but
exists as local network conventions only.
Presentation Layer
That portion of an OSI system responsible for adding structure to
the units of data that are exchanged.
primary
A node on a link which controls the polling to and from
secondary nodes on that link and controls the communications
from the secondary nodes on that link.
profile
The defined protocol at each of the seven OSI layers.
protocol
A formal set of conventions governing the format and relative
timing of message exchange between two communicating
processes. A system of rules and procedures governing
communications between two devices.
---------------------------------------------------------------------------------------------------------------14
Revision 2-March 3, 1997 Draft
Term/Abbreviation Definition
Acronym
Protocol Data Unit A part of transmitted data that contains information used by the
(PDU)
protocol at a particular layer in the OSI stack.
proxy agent
A device which receives and responds to network management
commands on behalf of another entity.
RFC
Request for Comments, the name given to correspondence and
standards by the IAB.
router
A level 3 (network layer) relay
secondary
A node on a link that is controlled by the primary node in terms
of polling and communications.
service primitive
An artifact modeling how a service is requested or accepted by a
user
Session Layer
That portion of an OSI system responsible for adding control
mechanisms to the data exchange.
Simple
Transportation
Management
Framework (STMF)
Simple Transportation Management Framework, describes the
organization of the information within devices and the methods
of retrieving or modifying any informaiton within the device.
STMF also explains how to generate and utilize computer
readable information organization descriptions.
Simple
Transportation
Management
Protocol (STMP)
Simple Transportation Management Protocol, a variation of
SNMP developed by NEMA to address low bandwidth
communication links and real time device monitoring.
SMI
Structure of Management Information, a definition of how to
create management objects and a hierarchical (tree like)
definition of nodes where management objects will be attached
for unique identification.
---------------------------------------------------------------------------------------------------------------15
Revision 2-March 3, 1997 Draft
Term/Abbreviation Definition
Acronym
SNMP
Simple Network Management Protocol, a communications
protocol developed by the IETF, used for configuration and
monitoring of network devices.
SNMPv2
Simple Network Management Protocol version 2, recent
modification of SNMP that is undergoing evaluation by the
Internet community.
socket
A pairing of IP address and a port number
TCIP
Transit Communications Interface Protocol – A subset of NTCIP
protocols which are specific to the transit community.
TCP/IP
Transmission Control Protocol/Internet Protocol
addressing both the network and transport layers)
TLV
Tag, Length, Value - the form used in SNMP encoding.
Traffic
Management
Experimental
Protocol (TMC E1)
Based on the AB3418, TMC E1 is a specified protocol that allows
basic communication messages to be sent between TMCs on the
same communications channel.
(protocol
An enhancement of TMC E1, TMC E1.2 is a specified protocol
Traffic
that allows basic communication messages to be sent between
Management
multiple TMCs using IP for routing services.
Experimental
Protocol
(TMC
E1.2)
The transport protocol offering a connection-oriented transport
Transmission
Control
Protocol service in the Internet suite of protocols.
(TCP)
Transport Layer
That portion of an OSI system responsible for reliability and
multiplexing of data transfer across the network (over and above
that provided by the network layer) to the level required by the
application.
---------------------------------------------------------------------------------------------------------------16
Revision 2-March 3, 1997 Draft
Term/Abbreviation Definition
Acronym
transport-stack
The combination of protocols, at the transport layer and below,
used in a given context.
user data
Conceptually, the part of a protocol data unit used to
transparently communicate information between the users of the
protocol. Prefixed by the protocol control information.
User
Datagram The transport protocol offering a connectionless mode transport
Protocol (UDP)
service in the Internet suite of protocols.
Variable Message
Sign Experimental
Protocol Version 1.0
(VMS E1)
Based on AB3418, a specified protocol that allows basic
communication messages to be sent to and from multiple VMS on
the same communications channel, even if the signs are from
different manufacturers.
Variable Message An enhancement of VMS E1, a specified protocol that allows the
Sign Experimental VMS messages to be routed using the IP protocol.
Protocol Version 1.2
(VMS E1.2)
Wide
Area Any one of a number of technologies that provide geographically
Network (WAN)
distant transfer.
---------------------------------------------------------------------------------------------------------------17
Revision 2-March 3, 1997 Draft
APPENDIX C - NTCIP Articles Appearing in the
Institute of Transportation Engineers (ITE)
Articles are available from:
The Institute of Transportation Engineers
525 School St., S.W., Suite 410
Washington, D.C. 20024
(202) 554-8050
---------------------------------------------------------------------------------------------------------------18
Revision 2-March 3, 1997 Draft
---------------------------------------------------------------------------------------------------------------19
Revision 2-March 3, 1997 Draft
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement