Point to Multi-Point Protocol (PMPP) Prepared by: NTCIP Steering Group - PDF

Please download to get full document.

View again

of 19
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report



Views: 33 | Pages: 19

Extension: PDF | Download: 0

Related documents
Point to Multi-Point Protocol (PMPP) Prepared by: NTCIP Steering Group May Draft March 1998 Table of Contents FOREWORD...i Section 1: GENERAL SCOPE Background Purpose
Point to Multi-Point Protocol (PMPP) Prepared by: NTCIP Steering Group May 1996 Draft March 1998 Table of Contents FOREWORD...i Section 1: GENERAL SCOPE Background Purpose of Document REFERENCES Normative References Other References Contact Information DEFINITIONS ABBREVIATIONS AND ACRONYMS Section 2: NTCIP PROTOCOL OVERVIEW GENERAL ASPECTS Protocol Background Point to Multi-Point Role Section 3: POINT TO MULTI-POINT PROTOCOL GENERAL ASPECTS POINT TO MULTI-POINT PROTOCOL DEFINITION Service Definition Protocol Definition Table of Figures FIGURE 3-1. OSI STACK AND NTCIP PROTOCOLS...1 FIGURE 3-2. PMPP FRAME STRUCTURE...2 FIGURE 3-3. SINGLE BYTE ADDRESS FIELD...3 FIGURE 3-4. TWO-BYTE ADDRESS FIELD...3 Draft March 1998 Page i FOREWORD The purpose of this document is to provide a definition of Point-to-Multi-Point Protocol (PMPP), one of the component standards of the National Transportation Communications for ITS Protocol (NTCIP). It is intended as a communications protocol standard for interconnecting transportation and traffic control equipment. NTCIP represents a suite of protocols and information management standards that apply to the entire industry. The PMPP addresses the need for a specific Data Link Layer protocol that is geared to the communications requirements of field devices such as traffic controllers, variable message signs, camera controllers, and other similar devices that share a common connection to their controller. It is, by design, implementable in current, state-of-the-art field devices that are part of traffic control or traffic management systems. The original effort in the development of NTCIP began with the NEMA traffic control equipment manufacturers desire to extend the TS-2 Standard for traffic control hardware to cover the more complex issues of systems interoperability and communications standards. The initial goal was to develop a common protocol and define a minimum set of control and status messages so that end users could intermix not only different manufacturers controllers and 170-type controllers, but also all other field-related devices. Currently, it is being extended to cover intra- and inter- traffic management and control center communications. The ultimate goal is to define standard protocols for all aspects of communications for transportation and traffic control networks that are needed for ITS. The figure below depicts the current NTCIP protocol suite family; other protocol suites will be added on an as needed basis. The shaded block indicates the focus of this document. PROFILES Class B Class A Class C Class E Application STMF STMF Telnet FTP SNMP Telnet FTP SNMP Presentation Null Null Null Null Session Null Null Null Null Transport Null UDP TCP TCP Network Null IP IP IP Data Link PMPP PMPP PMPP PPP Physical EIA 232E FSK EIA 232E FSK EIA 232E FSK EIA 232E In preparation of this Standards Publication, input of users and other interested parties is being sought and evaluated. Inquiries, comments, and proposed or recommended revisions should be submitted to: Attn: Alberto J. Santiago NTCIP Information /HSR-11 Turner-Fairbank Highway Research Ctr Georgetown Pike McLean, VA fax: (703) Draft March 1998 Page SCOPE Section 1 GENERAL The National Transportation Communications for ITS Protocol (NTCIP) establishes a common method of interconnecting Intelligent Transportation Systems (ITS) and traffic control equipment, establishes the protocol and procedures for establishing communications between ITS related components, defines procedures to develop and register a common set of messages related to controlling and managing an ITS, and defines a set of messages specifically related to current traffic control systems Background As transportation control equipment becomes more sophisticated, planners, users, and equipment manufacturers have recognized the need to establish system inter-operability and integration standards. Different agencies have defined protocols to work with their specific hardware but a problem arises when attempting to integrate additional or other existing hardware into a system. There is no common protocol with which the equipment can communicate. The various systems utilize different synchronizing techniques, data formats, and error-recovery schemes. If a national ITS program is to be implemented then communications standards and protocols must be established. The problem is exemplified by considering just the integration issues related to traffic signal controllers. Currently there is no standardized method to communicate with either National Electrical Manufacturers Association (NEMA) -type controllers or 170-type controllers. In systems that use a remote communications unit to interface with the input/output backpanel signals of the controllers, severe limitations are imposed on the capabilities of the system. Alternately, when systems from different manufacturers are integrated into the same central control system, the communications protocol to each system is different and manufacturer specific. Local controller units operating within the system normally have to be from the same manufacturer of the system. The integration problem is compounded when existing systems are tied into transportation management systems. Not only do these systems have to deal with traffic controllers, but they must also handle such devices as surveillance cameras, variable message signs, and other ITS-related hardware. Ideally, all of this equipment should be able to share the same communications channel. Industry-wide communications standards are needed not just for connectivity and interoperability reasons, but also to accommodate future technology growth. As the needs of ITS become clearer, the ability to transfer data throughout the system will become crucial. A communications standard must accommodate the presently recognized needs as well as the yet undefined needs of the future Purpose of Document The purpose of this document is to provide the information necessary to establish the Point to Multi- Point Protocol (PMPP). The PMPP is used in NTCIP systems at the Data Link Layer to manage the NTCIP protocol classes that can coexist on a common channel. The PMPP accomplishes this by accepting data received from the upper and lower layer protocols, resolving the protocol class and passing the data to the next appropriate protocol for further processing. Page 1-2 Draft March REFERENCES Normative References The following standards contain provisions that, through reference in this text, constitute provisions of this Standard. While end users of NTCIP do not need to obtain these documents, they do provide a complete understanding of the protocol. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most recent editions of the standards listed below. Contact information regarding the referenced standards is given at the end of this section. ISO/IEC 3309:1994, Information technology Telecommunications and information exchange between systems High-level data link control (HDLC) procedures Frame structure. ISO/IEC 4335:1994, Information technology Telecommunications and information exchange between systems High-level data link control (HDLC) procedures Elements of procedures. ISO/IEC 7809:1994, Information technology Telecommunications and information exchange between systems High-level data link control (HDLC) procedures Classes of procedures. ISO/IEC 11575, Information technology Telecommunications and information exchange between systems Protocol mapping for the OSI Data Link service Other References The following list of documents may also be helpful to the reader in gaining a full understanding of the NTCIP. ITU-T Recommendation X.210 ISO/IEC 10731, Information technology Open Systems Interconnection Conventions for the definition of OSI services. CCITT Recommendation X.213 (1992) ISO/IEC 8348:1992, Information technology Network service definition for Open Systems Interconnection. CCITT Recommendation X.200 (1988), Reference model of Open Systems Interconnection for CCITT Applications. ISO 7498:1984, Information processing systems Open Systems Interconnection Basic Reference Model. (The above pair of documents are basically the same in content and text. They will be superseded by a new edition to be published by end of the Summer At that time, there will only be one version in identical text format and the reference will then appear in above.) CCITT Recommendation X.212 (1988), Data Link service definition for Open Systems Interconnection for CCITT applications. ISO/IEC 8886:1992, Information technology Telecommunications and information exchange between systems Data link service definition for Open Systems Interconnection. Draft March 1998 Page Contact Information ISO/IEC Standards Members of the ISO maintain registers of currently valid ISO/IEC International Standards. For the United States of America, the member of ISO is the American National Standards Institute (ANSI), which may be contacted as follows: ANSI 11 West 42nd Street, 13th Floor New York, New York (212) ITU-T Recommendations The ITU-T Secretariat Bureau (ITU-TSB), formerly CCITT, maintains a list of the currently valid ITU- T Recommendations. The ITU-TSB may be contacted as follows: International Telecommunications Union Place des Nations CH-1211 Geneva 20 Switzerland DEFINITIONS These definitions define the nomenclature frequently used in regard to the RS-232 interfaces and modems. 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. authentication: The process whereby a message is associated with a particular originating entity. Basic Encoding Rules: The OSI language for describing transfer syntax. baud rate: The number of discrete signal events per second occurring on a communications channel. It is often referred to as 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. 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. data: Information before it is interpreted. data link layer: That portion of an OSI system responsible for transmission, framing, and error control over a single communications link. datagram: A self-contained unit of data transmitted independently of other datagrams. Page 1-4 Draft March 1998 Intelligent Transportation Systems: A major national initiative to improve information, communication and control technologies in order to improve the efficiency of surface transportation. International Organization for Standardization: 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 Internet, NSF/DARPA, Internet, or the Federal Research Internet. network: A collection of subnetworks connected by intermediate systems and populated by end systems. 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. network management: The technology used to manage in a network, usually referring to the management of networking specific devices such as routers. In the context of this document, refers to all devices including end systems that are present on the network or inter-network. Open Systems Interconnection: An international effort to facilitate communications among computers of different manufacture and technology. physical layer: That portion of an OSI system responsible for the electro-mechanical interface to the communications media. port number: Identifies an application-entity to a transport service in the Internet suite of protocols. The concept of port numbers is often present in OSI literature; however, post numbers are not inter-network standard, but exist as local network conventions only. protocol: A system of rules and procedures governing communications between two devices. File transfer protocols in your communications program refer to a set of rules governing how error checking will be performed on blocks of data. router: A level-3 (network layer) relay. subnet: A physical network within a network. transportation management: Short for the management of networks of transportation devices and the network itself. user data: Conceptually, the part of the protocol data unit used to transparently communicate information between the users of the protocol. Prefixed by the protocol control information. Draft March 1998 Page ABBREVIATIONS AND ACRONYMS ANSI American National Standards Institute ITU-T International Telecommunications Union, Telecommunications Sector BPS Bits per Second NEMA National Electrical Manufacturers Association CCITT International Telegraph and Telephone NSF National Science Foundation Consultative Committee DARPA Defense Advanced Research Projects Agency NTCIP National Transportation Communications for ITS Protocol DLSDU Data Link Service Data Unit OSI Open Systems Interconnection EIA Electronic Industries Association PMPP Point to Mulit-Point Protocol FCS Frame Check Sequence PPP Point-to-Point Protocol FHWA Federal Highway Administration SDU Service Data Unit FSK Frequency Shift Keying SNMP Simple Network Management Protocol HDLC High-level Data Link Control STMF Simple Transportation Management Framework IANA Internet Assigned Number Authority STMP Simple Transportation Management Protocol IEC International Electro-technical TCP Transmission Control Protocol Commission IETF International Engineering Task Force UCC Unbalanced Connectionless Class IP Internet Protocol UDP User Datagram Protocol IPI Initial Protocol Identifier UI Unnumbered Information ISO International Organization for UP Unnumbered Poll Standardization ITS Intelligent Transportation Systems Draft March 1998 Page 2-Error! Main Document Only.1 Section 2 NTCIP PROTOCOL OVERVIEW (Authorized Engineering Information) 2.1 GENERAL ASPECTS Protocol Background The effort to develop NTCIP began with the NEMA traffic control equipment manufacturers recognition for the need to extend the TS-2 Standard for traffic control hardware interchangeability to cover the more complex issues of systems interoperability and communications standards. As the discussions proceeded, the FHWA sponsored a Signal Manufacturers Symposium in May of The participants, who represented manufacturers and users, suggested that the NEMA Committee broaden the scope of its work to define a truly open system that includes not just NEMA-type controllers but 170- type controllers and other control-related equipment as well. They also wanted the NEMA Committee to consider how the protocol would tie into a transportation information network and be adaptable to different communications architectures. A subsequent NEMA Technical Committee meeting sought input from all interested parties and a number of suggestions were made to extend the NEMA protocol standard into a national, industry-wide open protocol standard. Subsequent meetings evolved into general industry forums with representatives from the user community, consultants, and 170-type equipment suppliers. Recognizing the industry-wide importance of this standard, the FHWA has lent support in developing standards for the ITS. To be open , NTCIP had to meet existing traffic control functional requirements, support traffic management communications, and lend itself to other, as yet undefined, application requirements of ITS. For a protocol to be open, the first axiom is that communications aspects must be distinctly separate from the application. Since none of the existing traffic control protocols met this criteria, it was felt that other industry standards had to be examined to see if they could serve as a model. To that end, NTCIP embraces features of several existing worldwide communications standards established by the International Organization for Standardization (ISO), the International Telecommunications Union, Telecommunications Sector (ITU-T; formerly CCITT), and the Internet Engineering Task Force (IETF). These standards map into the ISO Open Systems Interconnect Reference Model (OSI Model), which deals with how information can be passed in open systems. The above mentioned goals are realized by establishing a reference model and defining standards that can be used within this framework to support NTCIP requirements. These standards provide the mechanisms to transport information between traffic-control and/or ITS devices. In traffic signal systems they allow information to be passed from an arterial master directly connected to a traffic controller or from a central computer through several devices to a traffic controller. The information and associated procedures for transportation control purposes, on the other hand, is not the subject of any existing international standards. The openness of the protocol should not preclude the possibility of upgrading existing hardware to the standard. A significant, productive, installed base of signal systems is deployed, and a cost-effective evolution from these systems must be addressed in NTCIP. Specifically a class of operation shall be specified that will be implementable in current state-of-the-art hardware. This class of operation will operate with a reduced set of application messages. With its simplified protocol and functionality, it reduces overhead to a level compatible with the capabilities of current hardware. The functional complexity and therefore code size is on par with existing protocols. A device supporting this class of operation will be able to coexist in a system that implements the full NTCIP specification. Page 2-2 Draft March Point to Multi-Point Role The PMPP provides the functionality necessary to integrate different protocol classes over the existing Physical and Data Link layers, and provides access to the higher protocol layers for devices that support them. PMPP will be used to direct Class B traffic to either the Simple Transportation Management Protocol (STMP) or Simple Network Management Protocol (SNMP) in the application layer and directs Class A and Class C traffic to the appropriate Network Layer (IP) for processing. Going down in the stack, the PMPP will accept the user data from the STMP, SNMP and IP layer protocols, construct an appropriate HDLC frame including the proper initial protocol indicator (IPI) value, and pass the frame to the physical layer for transmission over the link. The IPI is directly analogous to the Protocol Identifier employed in the PPP and IP protocols, and follows the same rules as specified in PPP. It provides a mechanism to permit multiplexing messages generated by multiple protocols using a single physical channel. The IPI is an assigned number, which has been coordinated with IANA. 1 1 Pending. Draft March 1998 Page GENERAL ASPECTS Section 3 POINT TO MULTI-POINT PROTOCOL The Point to Multi-Point Protocol fits into the NTCIP suite of protocols as depicted in Figure 3-1. PROFILES Class B Class A Class C Class E Application STMF STMF Telnet FTP SNMP Telnet FTP SNMP Presentation Null Null Null Null Session Null Null Null Null Transport Null UDP TCP TCP Network Null IP IP IP Data Link PMPP PMPP PMPP PPP Physical EIA 232E FSK EIA 232E FSK EIA 232E FSK EIA 232E Figure 3-1. OSI Stack and N
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks