U.S. DOT Guidance on C2F Communications Standards

The U.S. Department of Transportation (U.S. DOT) offers the following guidance regarding NTCIP C2F standards.

Information-Level Standards

Both SNMP and STMP utilize BER. SFMP was designed to decrease the overhead consumed by data identification by utilizing NTCIP's OER (NTCIP 1102), which provides more efficient encoding than SNMP's BER. OER addresses the specific needs of certain applications-layer protocols used by the transportation community. In contrast with other sets of encoding rules, OER delimits data elements on octet (byte-level) boundaries at the cost of additional bandwidth.

Although not the focus of this advisory, dialogue (message sequences), data definition, and object definition standards should be used instead of proprietary data definitions (and custom dialogues) or object definitions to support interoperability between centers built by different vendors. Dialogue and message standards are defined in ITS Standards such as Global Object Definitions, Object Definitions for DMS, Object Definitions for ESS, and Data Element Definitions for TSS, which may be covered in future advisories.

Applications-Level Standards

Applications-Level C2F communications standards provide three closely related Applications-Level protocol choices for C2F communications: SNMP, STMP, and SFMP. The protocols differ with respect to the level of complexity to implement them and the types of services offered. The best protocol for a deployment depends on the relative importance of the following three requirements: simplicity, flexibility, and efficiency. At this time, STMP and SFMP are available on a limited number of ITS Information-Level standards. Another way of thinking about the trade-offs between SNMP, STMP, and SFMP is depicted in Figure 2.

Figure 2. C2F Protocols

Stacks based on SNMP provide a simple but bandwidth-intensive protocol for C2F applications on the basis of the Internet protocol Internet Standard IAB STD 15 RFC 1157 of the same name (SNMP). This protocol is suitable only for networks with high bandwidth or low volumes of messages. SNMP has gained widespread acceptance as a method of managing TCP/IP networks, including individual network devices and devices in aggregate. SNMP is applicable to any TCP/IP network as well as other types of networks. SNMP defines a client-server relationship. The client program, or network manager, makes virtual connections to a server program, or SNMP agent, which executes on a remote network device and serves information to the manager regarding the device's status. The database, which is controlled by the SNMP agent, is referred to as the SNMP Management Information Base (MIB) and is a standard set of statistical and control values. Through the use of private MIB variables, SNMP agents can be tailored to a myriad of specific devices, such as network bridges, gateways, and routers.

The SFMP and STMP protocols, defined in NTCIP 1103 Transportation Management Protocol (TMP), were designed to extend the Internet-standard SNMP to transportation, while being compatible with SNMP, to address limited bandwidth communications links that require SNMP for configuration. The TMP standard must be used in conjunction with the NTCIP global object definitions (NTCIP 1201) and one of the NTCIP information profiles, which provide the glossary of common object definitions used by multiple NTCIP traffic control devices and the content for a particular device, respectively. SFMP addresses the need for a bandwidth-efficient protocol for low-end field devices, such as closed circuit camera controllers.

STMP allows C2F messages to be sent efficiently using dynamic composite objects. STMP works in the same way as SNMP and uses the same data elements. Therefore, any management system that implements STMP can also communicate with a device that supports only SNMP. When combined with an efficient encoding scheme, STMP is a more bandwidth-efficient but more processor-intensive solution than SNMP. Occasional messages requiring additional security can be sent using SNMP. The use of dynamic objects enables users to define custom messages that comprise any number of individual data elements. Stacks based on this protocol are suitable for networks with low bandwidth and high volumes of messages, including traffic signal systems where a central computer is directly connected to field devices, precluding the need to route the information through some other device such as an on-street master in a closed-loop system. STMP should be considered essential for traffic signal systems operating over traditional media, but other devices may not need it. However, as a function of SNMP and STMP, devices can send a message to the management system only when requested to do so by the system.

SFMP was designed to decrease the overhead consumed by data identification by utilizing NTCIP's Octet Encoding Rules (OER) (NTCIP 1102) that provide more efficient encoding than SNMP's BER. OER addresses the specific needs of certain application-layer protocols used by the transportation community. In contrast with other sets of encoding rules, OER delimits data elements on octet (byte-level) boundaries at the cost of additional bandwidth.

Together, the three options of SNMP, STMP, and SFMP, known as the TMP suite of protocols, provide a solution to use any of the three choices within a transportation environment depending on the data-exchange requirements for a device. Table 1 summarizes the services offered by and the implementation requirements of each Applications-Level profile.

NTCIP 2302 Trivial File Transfer Protocol (TFTP) and NTCIP 2303 File Transfer Protocol (FTP), commonly used protocols in the Internet industry, can be used for exchanging large files. TFTP was designed for applications where field devices may not support full file and directory services. Field devices that support full file and directory services can use FTP.

Transport-Level Standards

The Transport-Level option essentially consists of a choice between the use of routable and nonroutable protocols. The NTCIP 2201 Transportation Transport Protocol (T2, formerly know as NULL protocol) at the Transport Level is used in nonroutable environments, such as field devices directly connected to a central system, without going through a logical network. For networked environments, an additional choice is required between connection-oriented and connectionless protocols. The Transmission Control Protocol (TCP) is a connection-oriented protocol that is used in conjunction with the Internet working protocol known simply as Internet Protocol (IP). The User Datagram Protocol (UDP) is a connectionless protocol that is also used in conjunction with the Internet Protocol (IP).

Internet (TCP/IP and UDP/IP) Transport Profile (NTCIP 2202) defines an NTCIP Transport-Level profile using Internet standards relating to TCP/IP and UDP/IP. If the TCP/UDP IP transport standards are implemented, then support for message routing through intermediate communications hubs or fieldmasters is inherently included. However, a particular implementation of a C2F protocol stack may not provide support for such immediate or future options unless this is specifically requested at the time of procurement.

The intended environment of the T2 Profile is one in which flow control and error recovery are the responsibility of the subnetwork and information exchanges occur in a non-network system, where there is only a single subnetwork. The only remaining function applicable to the T2 Profile is application multiplexing. The relationship of the T2 Profile to the other layers of the OSI Model is that it serves as a link in transforming the interface information at the Applications-Transport boundary to that at the Transport-Subnetwork boundary.

Subnetwork-Level Standards

The Subnetwork Level presents a series of network protocols: PPP, PMPP, asynchronous transfer mode/synchronous optical network (ATM/SONET), and Ethernet. Devices using the same subnetwork protocol can share the same communications line with other devices. It does not matter whether such devices are from different manufacturers or are totally different devices; for example, a traffic signal and a DMS could share a line. Each device is assigned an address that is unique on that line or channel. The management system can communicate with any of the devices at any time by sending a message addressed to that device.

NTCIP 2101 PMPP Using RS-232 Subnetwork Profile provides a simple data-exchange tool that uses a connectionless delivery mechanism. The NTCIP 2101 standard is applicable to transportation-related devices that must operate in a typical primary or secondary configuration where one device is the designated primary device while one or more other devices are connected to a single channel and are acting as secondary devices. A secondary device will not transmit unless explicitly allowed to do so by a primary device. When using PMPP, the management system can communicate with only one of the devices on the line or channel at a time. This protocol is based on three ISO standards; ISO 3309, ISO 4335, and ISO 7809. NTCIP 2101 does not require a particular Transport Profile or Applications Profile. At the data-link layer, PMPP is used to provide error detection, link activation and deactivation control, and notification.

This NTCIP 2101 subnetwork profile defines not only the physical and data-link-layer protocols but also the interface between the data-link-layer and higher-layer protocols. It provides a mechanism to permit "multiplexing" messages generated by multiple protocols using a single physical channel.

The RS-232 (now referred to as EIA/TIA 232) interface at the physical layer can serve as the interconnection method directly or can act as an interface to other technologies. The direct interface is applicable when a transportation device is relatively close to the management station. Distance limitations can be eliminated by leveraging fiber-optic connections. Alternatively, the EIA/TIA 232 interface can serve as the interface to external modems.

NTCIP 2102 PMPP Using FSK Modem Subnetwork Profile is very similar to 2101 and is used to manage connected devices that coexist on a common channel. It supports a variety of upper-layer protocols over a common physical implementation using FSK modem technology.

NTCIP 2103 PPP Over RS-232 Subnetwork Profile defines an NTCIP Subnetwork Profile for one-to-one communications using a serial or PPP over RS-232 or dial-up modem communications links. This profile leverages the industry-standardized Internet-based PPP protocol, which is a proven Internet protocol for system deployment.

Ethernet subnetwork profile (NTCIP 2104) defines an NTCIP Subnetwork Profile for Ethernet. Specifically, it calls for use of the IEEE LLC and MAC protocols over a 10Base5, 10Base2, 10BaseT, or 10BaseF physical interface. This profile leverages the previously standardized Internet-based Ethernet protocol, which is a proven protocol for system deployment.

U.S. DOT Guidance Summary

In specifying the protocol stack, the systems designer must chose the combination of protocols that will help users meet operational requirements. It is advisable that systems designers assess the throughput and bandwidth requirements necessary to fulfill the operational requirements for the system. This step must occur after the Information Level functional requirements, dialogues, and objects have been selected. The systems designer can then determine, via a bandwidth analysis and architecture tradeoff process, the most cost-effective method to send and receive data and, if necessary, modify the Information Level functional requirements, dialogues, and objects. Additional information about applying the systems-engineering process in selecting ITS standards can be found on the ITS Standards website.

Agencies with nonstandardized legacy version controllers or controller software in place may consider retrofitting or migrating to standardized solutions when performing system upgrades. System upgrades provide a good opportunity for gradually switching field devices from one system to another as they are replaced or their software is upgraded. One approach to the introduction of NTCIP in a C2F system is to operate two separate systems—one NTCIP and one non-NTCIP—during a transition period. This may be the only choice if the current system is quite old and upgrading the entire system at once is not practical. For example, a central system with current field devices that cannot be updated could be expanded to run NTCIP protocols on some communications channels while the older equipment is maintained on others.

back to top

C2F Standards Framework

|

C2F in Use