National Academies Press: OpenBook

Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report (1996)

Chapter: A.1.5 Communication Networks and Protocols

« Previous: A.1.4 Computer Considerations in Communication
Page 204
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 204
Page 205
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 205
Page 206
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 206
Page 207
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 207
Page 208
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 208
Page 209
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 209
Page 210
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 210
Page 211
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 211
Page 212
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 212
Page 213
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 213
Page 214
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 214
Page 215
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 215
Page 216
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 216
Page 217
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 217
Page 218
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 218
Page 219
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 219
Page 220
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 220
Page 221
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 221
Page 222
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 222
Page 223
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 223
Page 224
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 224
Page 225
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 225
Page 226
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 226
Page 227
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 227
Page 228
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 228
Page 229
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 229
Page 230
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 230
Page 231
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 231
Page 232
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 232
Page 233
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 233
Page 234
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 234
Page 235
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 235
Page 236
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 236
Page 237
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 237
Page 238
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 238
Page 239
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 239
Page 240
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 240
Page 241
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 241
Page 242
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 242
Page 243
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 243
Page 244
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 244
Page 245
Suggested Citation:"A.1.5 Communication Networks and Protocols." Transportation Research Board. 1996. Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report. Washington, DC: The National Academies Press. doi: 10.17226/6338.
×
Page 245

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

A.~.5 Communication Networks and Protocols Traditionally, communications networks have been based on two general techniques: 1) Circuit switched for voice, video, etc., signals which require controlled delay time from source to destination and exact ordering of transmission data. These networks are implemented by He telecommunications industry. Technologies include TI, SONET, and related multiplexing, cross-connect, etc., products. These networks are isochronous meaning "equal delay." 2) Packet switched for data (especially E-mail, computer networks, Internet access, etc.) which can tolerate random (but reasonable) time delays and resulting occasional out-of-order packet reception. These networks are implemented by the computer, LANJ~AN/WAN, data services (e.g., Compuserve, AOL, etc.) industries. Current ITS-related systems have been implemented using equipment and technologies of bow techniques: I) Field infrastructures typically employ circuit switched techniques, with simple end-to-end protocols to support real-tune requirements. 2) TOC computer networks employ packet-switched techniques (e.g., L`ANS) to interconnect large screen displays, workstations, printers, servers, etc. A clear industry trend has been an evolution of these techniques to support transport of multimedia voice, data, and video over He public telecotnmunicabons network and LAN/MANIWAN packet networks. This section will discuss the network protocols and systems that are available to support He emerging ITS multimedia requirements. L:~ - c2~t N~3-51. P~2F~Re~n A1-196

A.~.5.1 Packet Networks, OS! Stack, and Standards In the 19SOs and 1960s as computers emerged and were commercialized, We need for interconnected computer networks also emerged to share data In the early 1970s, more formal computer networks and products began emerging. Researchers quickly discovered that data networks had different characteristics Ran He widely deployed c~rcuit-switched voice networks and required different methodologies. The solution was He packet network which partitioned longer data messages at the source into smaller packets, transmitted He packets over He communication network, and reassembled the packets back to the ong~nal data message at He destination. This concept is illustrated in Figure A.~.S.~-~. Much effort has been focused on "Store and Forward" (sometimes denoted "Hold") packet networks. The unique characteristics and factors of the data networks Hat favor packet technology include: 1) Random interarrival times of source data 2) Random message lengths (pnor to packetization). 3) CaB (or connection) setup for short bursty data messages creates significant inefficiencies in c~rcu~t-sw~tched networks which are best suited for voice cans urge durations of minutes as opposed to fractions of seconds. Packet technologies handle this more efficiently. 4) Data networks can accommodate random delays of packet reception at He destination and can handle out-of-order reception sequences if Hey occur. 5) Modern digital error detection and correction technologies can be efficiently applied as required at bow He packet and message level. L::\NCHRP`Phase2. ~NCHRP3-51e Phase2FmalReport A1-197

,-: o ·o a) o a) a) i ~ D cn a) >a D · - a' cn cn a' a' D U) 1 or) Cat D a) cn E: In · _ · - a) Q O I-\ ·-~196 /L o a) 01 ~ ~ .6 1 1 O 1 ' no" o o In' a) o A i\ ~ I, ~ 1 C) · _ cn 1 1 Q I ~ FEZ \ o J L: J To r ~ z o y ~: o 3 z ~ Y ~C C! 3 er: o ~o ~n tY .

6) Network performance, in terms of average delay and throughput, is better in packet networks. The performance of a packet network is typ~caRy measured in terms of average throughput and delay. Models based on "Queuing Theory" are available to simulate the performance of packet networks. Figure A.~.5.~-2 illustrates how packet links and networks generally perform by plotting average delay versus percent throughput capacity. As We figure illustrates, if a network is lightly loaded, Me average delay is largely fixed and a function of propagation time and processing delays. But, as the load approaches 80-90% of capacity, Me delay detenorates rapidly. Thus, network managers strive to maintain percent link and network loading wed below 80-90% capacity by: I) Simulations in network design to predict performance. (Computer s~mulabon tools exist.) 2) Use of network management to collect statistics on actual network and link loadings during actual operation. 3) Plan rather than react to Increase capacity before problems emerge. In 1983, the International Standards Organization aso' released the Open Systems Interconnect fOS ~ Reference Mode! (often caned the OST Stack) Mat is shown in the block diagram in Figure A.~.5.~-3. The OST reference mode! is for packet networks generally performing Me functions described In Table A.~.5.~-~. Much like ITS-related systems today, Me private and public packet networks (e.g., LANIMAN/WAN, X.25, and Intemet data networks) of Me 83 era were experiencing problems urge multivendor interoperability and modulanty to support multiple physical media and multiple application layers. The 7-layer OS] reference mode! provides a methodology to address these problems by applying Me following principles: I) Each layer should perform well defined functions Mat are reasonably cohesive (i.e., naturally related). L::`NCHRP`Phasc2rp ~NCHRP3-51 · Phace2FmalReport Al-199 1

- - >- a) . - a' or a) Q o LO . _ U) o CL _' U) o lo o o 00 rat . -1 - +, O ·_ ~ cn A\ ~ U) 0 au CO '-! O ~ A ~ O CL o o lo lo - O in \ in 1 ~ D cn Q D as Anew by 3 fir lo IL at, - o In lo: lo: lo: >a ~ -, ° ,,, £

~E.~ E - ,, O ~= ~tL Al ~_ ~He O ~E X I i | | | | i . ~ W ~A, ~ ~ 9lUC ~ con ~E ' o' , , 3 ~O cut _ _O ~O l O ' O. 8 =- E am ~I, ~ ' O ' ~ ' °~_ cat °Ji =1 . it, ~ ~Age ~- WO l O. = ' -= ' ~o i,, o ·_ ~'A ~ ~ ~ ~ ~ a) O ~ E. [_ Oos , I ~, ~ 0 ,_ ~_ Z 1 1 1 1 1 1 1 _. 1 1 1 1 1 1 1 I I I I ~1 ~ ~%_ 1 1 . ~ 1 1 1 1 1 1 ~, 1 1 1 1 1 1 1 - _ ~ ~. , ~ W j j j j jj j ~ ce ~ I=°1oIol-=cI-=cI=5 e~ c ~ ~ ~ ~ ~ ~ co c~ c o

- ' ca ~ ~ - 0 5? c#o Q cent CD x al o ._ 3 _ U. ~ _ J In O O - o o Q C1S E - ; a, Cal - a, ._ - ._ CO LL X _ ~ o _ 3 ~ a, a, Cal ~ ' 0 ~ I,` 0 CtS c a) a) · ~ CO ~ E ~ r a) Q . ~.0= c, `, Q at: O _ 1 1M 2 o 2 · ~ ~ 8 ~ ~ , ~ ~ o ~ ~ g · · · ~ ·~. 1 11 2 ~ ~Q~ ~ == ~oh ~ z c: CO ~CO Cal O C~ ~t c~ a) 1 ~ ~ O _ m ·. 1- 1 1. 1. ~ o Q cn ~ C~ s- Ct ~ =: ,= Ce 0 ~.O S S ~ Q rL · ~ ~ ·.. .O cn s Q <: m u, cn cn co _ 1 1 J J I I o ._ ._ cn a CO ~ 0 C o ~ - o U) - U) CtS 0 o ~ ~ ._ ~ Q cD Ct ~ a,- _ ~ CtS .= C' O C~ S Q Q c~ o - Cd L) - Q Q ~0 - e~ C o o ~: o

2) The functionality of We layers should be sufficiently self contained so that information flow across the interface to other layers is reasonably minimized. 3) The functions of each layer should be conceived to support development of international standards for the layer. These standards define services provided by each layer as well as protocols for the Interfaces between layers. 4) The resulting standards for each layer should define services, functions, and interfaces to adjacent layers but not dictate how they must be implemented in hardware or software. 5) The stack should be modular so each layer may be changed without affecting adjacent layers and interfaces. Thus, new operational requirements can be accommodated as weD as advances in architecture, communication, hardware, software, and related technologies. 6) It should be possible to bypass (or consolidate) a layer when not needed. As examples, many implemented protocol stacks consolidate layers 5 Trough 7 as done in NEMA's NTCIP ITS protocol stack. The OS] stack is not a communication protocol standard, but a reference model standard to facilitate consistent, modular, and flexible protocol standards development. Although each layer is often referred to as a protocol, application protocol stacks, or profiles, such as NEMA's NICIP Signal System protocol, require definitions of Be individual layer protocols, services, and interfaces. With the OST reference model, Me assignment of funchonality to individual layers has achieved significantly better standardization. However, of necessity, some variability still exists for a variety of reasons. These include: I) Technology improvements (e.g., x.25 to frame relay, TCP/IP., etch 2) Different applications requirements (e.g., LAN versus MAN versus WAN). L:~h~.~t NC~ 3-51 · Pee 2 Fee Re"n A1-203

3) Implementation requirements (e.g., high speed LAN versus lower speed Internet protocols). 4) Complexity of (even supple) protocols makes nerd standardization bow undesirable and virtually impossible. 5) Different preferences, interpretations, arid priorities of the individual standards defining organizations. Thus, a protocol stack requires Me integration of public standard protocols (e.g., TCP/IP) and application-specific protocols (e.g., NTCIP) and the definition/ selection of many required ~mplementabon profiles and parameters. In Figure A.~.5.~-3, a communication infrastructure is identified Nat includes (I) the physical layer, (2) He link layer, and (3) We network layer. This cormnunicabon infrastructure is He distnbuted communication public and/or private infrastructure of a packet network. End users/equipment are physically located at He required source or destination of data and are provided end-to-end communication services by the communications infrastructure consisting of mediums, modes, hubs, terminals, etc. Commercial public communication services (and private networks) provide protocols for the lower Free layers only. Layers ~ Croup 7 are provided in end user equipment such as field equipment terminals and network/TOC communication servers and related equipment. ITS-related field communication infrastructure has not traditionalRy employed OSI-based standard protocols; however, NTCIP initiates an evolution within ITS toward this goal. Many public protocol standards are suitable for 11 S-related applications. Figure A.~.5.~-4 presents an overview of currently deployed or anticipated LAN/WAN standards with potential AS application. This figure illustrates the various OSI layers addressed by He standards. Users implementing a complete application stack must define and implement undefined higher and lower layers. ITS systems have many options and choices that include: :`NCHRP`Phasc2~pr NCHRP3-51e Phase2FmalRepoIt A1-204

f l Q) au ~ u) c:) ~ Q O CL) C~ ~ C~ ~ ~C C~ Q C~ - r, _ · ~n U) ~ ~ o `~ _ kE 0 >, ~ a 11 ~ _` cn L~ .C l~ O Q) -~ ~ o `_ C3_~ - I I ~ ~ 0 ° ° _ ~ U' _ ~ C: _ ~ ~ . .~ C'-m U) 6) Q J O y g~ . ~ - U) ·- O O ° _% Q ' O c' o 00 ~ O `_ C Q _Q) 0' Q ct' ._ J Q) ~ C~ O . O O 3 ._ ~ I' Z _ 1 1 . 1 mm · 0= _ C~ o~ CD O -T-- '~ I < . I ---1---- C~ I I ~ --- 1 --- J ~ 1 C_ _ Q) m 0 ~' ~J <: :5 J ~) I _' · a' _ a, c =) ~ C) {' ~ - ~ .c C) J oo O l_ ~ s ~ O > ~ cn _ I C] CL 1 o7 1 ·{,o, 1 c~ 1 I ~ I 1 1 1 1 [L I CL 1 1 ~n tn_ ~ .° · ~o ~ ~ . > C~ CN ~ Ln r~ c~ ~ 0 C ·< er ~ > > N ___ - > ~hJ ~ D cn a' ._ au _ o ~n 0 a' ~O ._ ~c cn ._ cn 1 .' I J `_ Z C - cn a) o C Q Q) C a) _ ,_ ~ C' ~ C ~ C~ J ~ ~ ._ ._ _ ~ - ~ Q, <t, `_ _ =~ ~ :D .~-o ~n >, >%z x c e: ~n o I O 1 o ~c cn ._ _ ._ _ u) _ c dIC -= O z ~ l - c ~ c) a' ~ c~ ~ o c .c Q ~ c' ~ tn _ U) {y ° o CL" C ·- ~ ~ C ~ a' ·'' c) 1 ^, Z c Lf) U] I X Q ~ _ 3 Q Q Q Q c C~ - _ a 0 ~ ~· ~ _ ~ C ~ ~) a 0 cn C cO ~n ~ a) J ~ C c' .= . 'Cn~ J J J ~ - ~ . cn cn ~ m 0 ~ ~ ~ C) CD <<mI o - - o - ~: L,J

I) The LAN 802.x standards only define the physical and link layers as LANs have tradidonaBy provided only shared bus, point-to-point, links of a few hundred meters. Higher layers have traditionally been implemented in Network Operating Systems (NOS), TCP/IP, etc. 2) TCP/IP are intemetworking protocols for MAN/WAN applications and only address He transport (TCP or 4~) layer and network (IT' or 3rd) layer. Typically, the employed lower layers are HDLC win dialup modems or, more recently, ISDN circuits. These are integrated in LAN systems (e.g., 802.x). 3) ElA-232, 422, 485, X.2l, etc., are physical (~) layer only protocols and multivendor interoperability requires specification of at least link (2) and often network (3) and higher layer protocols. 4) X.25 is a legacy protocol (70s, 80s) stack for layers 1, 2, and 3 that was conceived for networks interconnected by error-proof lower quality links. Thus, each layer of He protocol stack has significant overhead for error protection/control which makes X.25 unsuitable for higher speed links. TCP/IP addressed this problem by minimizing layers I, 2, and 3 error checking overheads and performing much of these functions in layer 4 ~CP) which is resident only in end user equipment and not the network infrastructure. Modern communication links are less error prone and can operate efficiency win these overhead error control functions on He periphery of the communications infrastructure. Lower overhead in layers I, 2, and 3 of He infrastructure is essential for higher link bit rates. 5) SONET and the T} hierarchy are physical (~) layer protocols that were developed to accommodate high speed transmission for the telephone industry. Bow public arid private Implementations have been extensively used for MAN/WAN intemetworkir~g of LAN networks. These win be discussed in more detail in Section A.1.2.3. 6) ATM is a telephone switching technology to support "On Demand" multimedia voice, data (LAN), and video. Standards are embryonic (1995) win many gaps and emerging end user products. Eventually, as standards and products evolve, ATM should prove cost-effective and valuable for lids applications. :\NCHR~Phasc:.'p ~NCHRP 3-51 · Phase 2 Anal Report A1-206

The elements of a packet network infrastructure exclusive of end user equipment typically consist of: 1) hubs andlor nodes, 2) repeaters, 3) bridges, 4) routers, and 5) gateways. Hubs and nodes have slightly different meanings depending on Me application. In private telephone applications (e.g., T1, SONET), nodes are typically Be first level of network infrastructure connection or multiplexing to which end user equipment (e.g., signal controDer) connects. In larger networks, hubs are typicalRy a hiker level of backbone infrastructure multiplexing and provide high data rate links to TOCs. In LANs, hubs are the infrastructure connection point for Be TWP-based 10 BaseT, etc., LANs, and nodes loosely denote any network connection (device). Figure A.~.S.~-S frustrates the funchon~ty of Be rem~g packet network elements. A repeater works at the physical (~) layer on bits usually to amplify a signal for greater distance. A bridge works at Be link (2) layer and converts one link layer protocol (e.g., Ethernet) to another link layer protocol (e.g., token nng) and assumes Cat both protocols use the same network (3) layer. A router works at the network (3) layer and converts from one network protocol (e.g., X.25) to another network protocol (e.g., IP). The two protocols must employ compatible transport (4) layers. L:\NCHRP\Phase2~rpt NCHRP3-51e Phase2FinalReport A1-207

/ l L I 1- 1 1 1' ~1 , 1~ ~ ~1 1 ~ _ 1 1 ~ 1 1 1 1 1 1 I I I T -ad- I I r . . . . _ -r l - l I ~ 1 1 1 1 - 1 1 1 1 1 1 1 1 0 . m 1 1 1 1 1 1 1 1 1 1- 1 1 1 1 ~ 1 1; 0 ~ J ~ ~- a' ~ 1 1 ----- 1 1~ I I r 1 LO ~or) Cod O O ~I . ~Q) ° Q O .C Q at <( Q U) ~Z O ._ ~ =<( a) ,. O ~ can Jim LO Cod X · _ ~ a' o _ ~ id_ 1 ' a) a) id_ llJ ~ O a) ~ ~ ~ Q (D Q ~ o o ~ z - - cn z y o 3 ao r . . ~ J ~ m~ ~ _ I ' ~ ~ ·_ a) cn Q a' \ T l L-I ~ .. y ~: - CL

A brouter or '`br~dge-router" is a combination bridge and router. LANs only provide OSI physical (1) and link (2) layer services as the early LEAN standards employed point-to-point, shared bus topology (e.g. Ethernet) wad no real "store-and-forward" function. As a brouter example, when internetworking to over L~ANs is desired, routers and bridging functions are often combined in brouters to include network (3) layer services (e.g., TCP/IP). A gateway is a network element that interconnects very dissimilar application protocol stacks. This can involve unpacketing all seven (sometimes less) layers of one protocol and repacketing into the equivalent layers of the other protocol. The processing can include address, data, error, control, etc., tasks. Gateways are usually only employed in WANs as significant processing is often required and achievable ~roughputs are typically low. LAN, MAN, and WAN, common packet network capabilities, are presented in Table A.~.5.~-2. A.~.5.2 NTCIP Protocol Suite NTCIP, or National Transportation Control/ITS Communication Protocol, is a standard for transportation applications. The NTCIP standards suite is being developed in the NTCIP Subcommittee of Me 'transportation Management System and Control Section Committee" of National Electrical Manufacturers Association (NEMA). NEMA redefined its membership criteria to encompass 11 S-related public and private stakeholder participation. The NTCIP Subcommittee began development in September, 1993 with participation and contribution by NEMA Controller Manufacturers; System Integrators and Consultants; 170 Software Developers; and national, state, and local public jurisdictional users. The original motivating goal was to evolve the deployed, proprietary, non-standard, legacy signal systems to open standards-based signal systems, in order to achieve multivendor interoperability, including mode] 170, NEMA, etc., systems. As rRs's multimodal and integrated service goals continue to crystalize, Nl CIP goals also have expanded to support these requirements (as presented in Table A.~.5.2-~. L~NCHRmPhase2.rp ~NCHRP 3-51 · Phase 2 Fmal Report A1-209

1 1 a E 0 0 0 ; 0 0 _ ·O Q E ._ z ?; ~ ~0 ~0 0 0 _ o o a, cn ._ ce ._ . Q _ a) ~ ~ CO Ct ~ a) . - o ~ CtS Ct ~ - (D a O ~ Z _ C, 't; ·0 O oS- _ ~ ~ L) Qo ~ ~ _ _ cn z - w - J C~ . - 53 t.O _ Q Q ~ n Q E C~ 0 ct ~ ~ 0 ~ O ~ ctO' ~ . = - Q ~ O ~ 1 ~ o ., C) ~ Z ~ Z _ CL LL ~ ~ cn co cn ~= s=] ·_ C: O ~ CO ~ O _ o 0 O ~ mmO 1 1 cn o 3 z et - o ,o ~Z 0 ce ~, _ u, cn Ce a, ~ Q .~ C 5 CO ~ ~ - cn c,8 0 '- ~ · ._ a) ~ ° 3 a, ~ ~ O-= 8 {D Q o ._ ._ Q Q ~: C cn 0 5? C#O ~C Q c~s o ct c~ z

The long term goal of 11 S is to support local, regional, state, and national (and eventually international) interjuu~sdictional communication networking as depicted Figure A.~.5.2-~. An NTCIP standard overview is presented in Table A.~.5.2-2. Table A.~.5.2-1 NTCIP Goals r I Support Evolution to National ITS Common Framework · Current 1200 bps, FSK modems on local multidrop . Advanced Mediums - Wireless, fiber, high speed modems · Local, Regional, State and Nationwide Interjurisdictional Communication · Provide Interoperability & Integration Guidelines and Standards Support interoperability with commercial standards applicable to ITS Provide ITS-specific protocol stacks and layer protocols where required Promote Competitive Procurement · Initial procurement . Upgrades and expansions Promote Multiple Application Integration on Common Communication Infrastructure . Traffic Control · Video Surveillance . · VMS Freeway Management Transit · CVO . Etc. The Installed base of ITS-related systems are dominated by a large number of signal systems employing 4-10 multidrop, 1200 bps, mode] 400 modems over private Twisted Wire Pair (TWP) infrastructure. Thus, NTCIP must support a natural cost-effec~ve evolution that integrates these systems, but supports: I) More advanced, higher speed commun~cabon technologies; 2) Broader base of ITS applications; and 3) Local, regional, state, and national networking. L \NCHRP Phase2.rp' NCHRP 3-51 · Phase 2 Fmal Report A1-21 1

"I o c, o · ~ - e~s ·~ l -a/ o ~\ ~ / ~s ~- |6 o~ \ ~ ~ - In TO cAt. ~ ~ u, aces In IL ~ $. o ~ - ce At ~ - Q Q , o ·_ z In - - o ._ O a) O Q ~ . .~) D I iL cn a Q ~ cn ~ O: o ~ ~ <: C.) I o ._ ._ cn ._ 3 C, ~o ~ o ~ ._ o ~ .> CO ._ Ct5 - _~ U) .O ~ ~ - o _ _ _ ._ C~, o , ~ ~ '~o q) o ° C, o - o CO [L O - z O - o - o O ~ ~ S S ~ a (D ~ cn ~ CL ll

Table A.~.5.2-2 NTCIP Standard Overview Follows ISO Open System Interconnected (OSI) Reference Model (7 Layers) Patterned after established standards > High-level Data Link Control (IdDLC) (layer 2) procedures standardized by ISO / IEC TCP/IP (layers 3 and 4) standards Two classes of operation Class A - Extensive capacity Class B - (NTCIP LITE) - reduced protocol for operation on installed base of 1200 bps, FSK modems in multidrop configuration Class C - Connection oriented services · Class E - High speed connection oriented services I SmallTransportationManagementProtocol(STMP)-networkmanagement l Flexibility in configuration, plus other benefits ~ More flexible OSI stack to accommodate evolution Class B Operation The OST reference mode] (Figure A.~.5.~-3) provides a framework to achieve this requirement. Figure A.~.5.2-2 presents the OSI protocol stack profiles that Me NEMA NTCIP subcommittee is `developing. ~ the left column is the NEMA Class B protocol Mat supports Me legacy second by-second, mode] 400, modems circuits Mat are widely deployed,. These multidrop circuits at 1200 bps have limited throughput capacity which requires Mat Me Class B protocol stack and application layer message set be miliiniized. The NEMA Class B stack is presented in Figure A.~.5.2-3 and illustrates Me me zation: I) No transport layer all. 2) A single byte ~Pl) is allocated at Me network layer (3) Mat identifies Class B. but provides no network addressing or over functions. 3) The link layer (2) has 5 bytes (plus layer 3 and higher information) consisting of an open flag, address byte, control byte, and 2 cyclic redundancy control (i.e., error detection) bytes. L;\NCHRP~rp' NCHRP3-51 · Phase2FmalRepoIt A1-213

hi In - ~ co o ~ ~ A -I ~. E23 ._ - Co s Q - U ~ l _zi Cat o1~ 1~1 ° =° ~ - O ~ CO ~CO Cat ~ V' =< ~TIC ~iC to ~·0 Q ARC G) ~Z

o o o o In - ~ · - Q - cn a, _, m U) a) _, _ _ a) U' a) Ct In CO a) CO Q o ._ c 1 a) Ct o i_ _, CO C' Q Q a: - ~0 A CO \ ~ a) ct a) ~ CtS CM - A_ En A_ ._ m CO i_ a) ~3 . . - ..~ a, CO a 1 ~- CL o , ~ a) - cn - ~ I ~=. in ~ At- ` ~E - C iLW 1 1

Thus, six bytes of protocol overhead are required. As comparison, Figure A.~.5.2-4 presents an example historical signal system message format that is not based on Me OSI stack concept and integrates (i.e., is not modular) the lindc layer, network layer, and application layer. Thlls, in addition to employing proprietary protocols and message sets, historical signal system protocols are not well suited to muldapplication communication infrastructures, efficient data sharing, multimedia network, or integration of modern network management capabilities. Conversely, open OSI-based protocol standards require greater overhead Can tightly tailored proprietary protocols. The NTC1r Class B protocol is a compromise between: I) Subset of the full featured OST protocol stack as Implemented in most communication standards (e.g., X.25, TCP/~, etc.~. 2) A subset of the application message set that includes He minimum functionality required to support control or monitoring functions on a second-by-second or over poking rate as required. 3) Throughput limited multidrop, 1200 bps modem, TWP circuits. 4) Penodic suspension of Class B operation replaced by more full featured Class A operations for non-control/monitonng functions such as down loads, etc. at reasonable times (e.g., non peak, night, emergency data, etc.~. 5) A very mitral network layer (3) is implemented with no network addressing capability. Thus, only primarylsecondaIy link level addressing (8 bits) is available (e.g., master/slave polling). L.\NCHRP`Phase2.rp ~NCHRP3-51a Phase2FmalReport A1-216

- ~ ~ - - - ~ us an e ~Q o _ ~ U ~ ·_ S" in in ~ 3 - o ~ O ._ Z - C] . e" ~ E o [L _ E E a V V _) ~ Ed o e e e_ Cot _ ° O ~ V eie ~ _ i~ E E ~ G E _ o G ~ G _ 2 a ~ G _ m ~ 54§ ~c~ ~ Va!~= ~c~ _ _ _ G G G.,- O G G ,, _ Cl Q O) S O a a: Q G 5 O O O = O ° O G o G L 113 cr ~ N ~ ~ ~0 = m ~ u' c' ~ ~ 0 c' m 0 1 m Z C' N o U) 1~ ~ ~ N _ Q _ N ~U) (D V, e~ C~ C ~ O C~ O . 4 - g ~ ·_ _ _ _ ~ O z o . Ct O .O Ct C) ._ _ ~ C ~ ~ 8 1 0 1 ._ _ ._ ~S _ r' 4 - ~ ~z E o y n 0 ~L 3 53 Z ~ 0 .O ,= ~: ~ ~ F' 3 ~ 4_ ~ '~ e,.s oo ce C: ~ Ir ~ E ~ _ . m _ _ ~: ~ ~ ~ _ . _ = G ~ _ ~ _ ~ _ . m ~ IL ~° = g N O N ':~;~r ~ ~ E~ = ~ = = = _= 25 _ = _ ~ _ = _ = G _ CC ~ _ ~ _ ~ _ _ _ , m~ _ = = ~ G CC C~ {D - C~ ~ ._ C~ ~ t. ~ 'Y ~ ~ _ ~ ~ ~ | I N ·w ~ ~

Class A Operation Refemng back to Figure A.~.5.2-2, second column, NTCIP will support an alternate, full featured, Class A, protocol stack that includes: I) More robust and complete layers ~ Trough 4 functionality, and 2) Significantly expanded and complete application message sets. The Class A protocol stack is intended for rrS-related systems which support: I) Additional functions for Class B operation such as download on an interruption basis; 2) Modem communication infrastructure (fiber, microwave, etc.) capable of supporting higher bit rates; and 3) Any application requiring complete network communication and address (i.e., complete end- to-end store and forward) as opposed to Class B's single link address capability. Beginning In late 1995, two candidate Class A protocol stacks are being considered. One is based on the international X.25 standard. The other is based on We TCP/IP Mat is widely employed for Sterner applications. These alternatives provide functionality at Me network layer (3) and the transport layer (4~. Over layers (i.e., I, 2, 5, 6, ?) are essentially Me same. Layers ~ Trough 4 of the NTCIP protocol for bow Class A and B are based (or derived/adapted) on wed established standards (see Table A.~.5.2-2~. Network Management An essential element of modern networks is network management Network management provides integrated computer and communication support for Me foBow3ng important functions: L:\NC}~Phase2erpt NCHRP3-51n Phase2~1nalReport A1-218

1) Fault detection and management; 2) Provisioning and configuration control/management; 3) Performance monitoring and management; 4) Network security management; and 5) Accounting management. Networks are complex and require efficient and effective implementation of the above functions. Networks wad integrated fault-tolerant features and network management have proven cost- effective, in fact, essential in many public and private networks. The NEMA standards subcommittee has selected a derivative of the widely deployed Single Network Management Protocol (SNMP) for NTC1P. SNMP ong~nated in 1988 and prior years when die Internet community identified a need for common network management toolsets. The Internet consists of diverse network implementations compnsing: 1) Many incompatible computers running diverse applications; 2) Bridges' routers, brouters, etc., from many vendors; 3) Communication links of all types including wire, wireless, and fiber, 4) Connectivity to commercial packet network; 5) Extensive LAN network of all types; and 6) Diverse local network protocols. c.\.NCHRP\Phase:.'p ~NCHRP3-51e Phase2F~nalReport A1-219

Thus, SNMP provides a general framework that is adaptable to Me above and Is extensible to new equipment, and applications by convening appropriate user groups (or stakeholders) to define specific SNMP standards. SNMP is an application layer protocol Cat parallels end user application layers (e.g., signal systems, VMS, etc.) but shares lower layer (~-3) communication infrastructure as presented in Figure A.~.5.2-5. Implementation of SNMP requires: I) SNMP agent software in terminals, controllers, node, hubs, and over managed field equipment; 2) One or more network management workstations wad network management software, typically at TOCs; and 3) SNMP protocol for communication between the network manager and field agents. The concept is depicted in Figure A.~.5.2-6. ~ SNMP, managed treks, equipment, software, etc., have management information such as configumbon, operating parameters, control, status, etc., variables that are referred to as managed objects. By changing or observing these vanables, (usually by the network manager) remote network links, equipment, and operations can be provisioned, (re~configured, controlled, and monitored; and instantaneous or statistical performance data can be measured and recorded. As the list of SNMP managed objects is diverse, Me SAM]? (v.~) protocol specifies five general basic operations as presented in Table A.~.5.2-3. To define the specifics of these managed objects, SNMP employs an information data base concept called Management Formation Base (hang. Arl MA consists of a set of managed objects. Virtually any network element can have an MD3 Cat defines its variable charactenstics, relationships, name ~assignment, etc. An ITS- related example is the signal system application layer message set. Its MIB defines the message fields, data types, etc. Using As, controller message sets of multiple vendors can be defined to TOC computers by the simple loading of He FIB definition data base (usually from floppy disks) thus providing interoperability while usually avoiding expensive software redevelopment. L;`NCHRP`Phasc2 rip NCHRP 3-51 · Phase 2 Fmal Report A1-220

- a C _ An a ~ 1. ~I Z o . . AS E E o a,-In , ^> o ~ ~ of, J In _ o ~\ it\ ~ . W- /-~ ,i, ~3 ~3 ~ .' 1 I_ ~ ~3 ~3 _\ / - l u, In · - · - o ~ ~cn act ~ - o ~ = ~ - · - Qt,' l-o In_ ~ ~ ° a' In of C) ~ In c - CO ~ ._ o Hi U' I o Cal · ~23 1~ Q As _ ~C, | I ~ i

~ ~ - ~ o as o · - En in - 46 41 o o He in cO ~ In a, ~ em o - [L, cL a, En c. E. ~ - ,0 3 ~ =- ~ =iiJ em ~ o O ~ o c O ~ he cO cl) Or CJ3 cO E ~ ._ o ~ Cal ~ it. IO ~ cts - to ~ ~ I o o o _ o .Q 3 tS I:

MIBs are defined using industry standard MIB definition language called Abstract Syntax Notation ~ (ASN.~. Table A.~.5.2~3 SNMP Message Types .. Message Type Operation . . . _ . . . Get-request lo_ Set- request | Write information variable (managed object) Get - next request Enables sequential retrieval of variables Get - response Returns results of above operations , Trap Reports event occurrence The use of SNMP in ITS-related applications is straight forward, but requires specific ITS definitions and some fine tuning in NTCIP to define simp~iBed message set types and protocol for Me low bit rate modem circuits. NTCIP defines a Simple Transportation Management Framework (STMFi) for these purposes that consists of the following four components: I) Structure and identification of Transportation Management ~fonnation (STM0; 2) MIB; 3) Standard SNMP, version 1; and 4) Simple Transportation Management Protocol (STMP) (low overhead). STM! details Me common structures and identification schemes for defirung information used in ITS-related systems. SEMI? network management information is organized into a large tree structure administered by ISO and FLU which helps visualize relationships between vanables. NT~ defines a subtree for ITS systems Mat comply web this standard by defining: 1) An adm~nistradve structure; \NCHRP`Phasc2~p' NCHRP3-51 · Phase2FmalReport A1-223

2) An information structure; and 3) A naming structure. SHE' is He simplified, low overhead, SNMP-like protocol to support low bit rate circuits of legacy llS systems. When higher capacity circuits are available, SNMI' should be employed. STMF has many benefits for ITS implementation as presented in Table A.~.5.2-4. The general requirements for procuring SURF win systems are presented in Table A.~.5.2-5. Table A.~.5.2~ Specific ITS Benefits of STIFF . . , · Reduces system operation and maintenance costs · Supports integration with widely-deployed SNMP-based implementations Essential tool for supporting multiple field devices at TOCs Provides for configuration of Application Message Sets according to local requirements, vendor capabilities, and architectural / equipment capabilities · Streamlines and supports interoperability of equipment from different vendors Supports self-test and centralized monitoring - Supports computerized configuration management L:`NCHRPPhase2.rp ~NCHRP3-51. Phase2FmalReport A1-224

Table A.~.~2~5 Procuring STMF Involves: STMF agent capabilities in equipment Usually software Latest state-of-the-art equipment includes hardware support STMF network management station Located at TMC or communication maintenance facility Workstation with graphical displays depicting network status Software to control distributed STMF agents · MiBs can be provided for equipment without STMF agents via disks for configuration purposes - Procurement specifications for above An application protocol stack must define and specify all required layers of Me OSI stack in compliance web Me standards for each implemented layer. NT(;1F win permit multiple applications and STMF to share the lower 3 layers supported by Me communication Infrastructure. NTCIP win define application layer message sets and corresponding MIBs for Me applications in Table A.~.5.2-6. Table A.~.5.2~6 NTCIP Application Message Sets Actuated Controllers or Signal Systems Variable Message Signs (V \/IS) Ramp Meter Controllers Camera Controllers Sensors Highway Advisory Radio (MAR) Global Objects Philosophy: All application (layer) message sets will use common lower protocol stack layers. . . NTC/P Current Family of Protocols ~ addition to Class A and B protocols, NrrCIP also supports Class C and E protocol profiles for non-real-time data exchange wad a fuller feature set to support se.auenc~na and guaranteed ~O O delivery. Table A.~.5.2-7 illustrates Be Class A, B. C, and E OST protocol profiles. ~.`NCH=Phase~rpt NCHRP3-51. Phase2F~nalRepon A1-225

Table A.~.5.2.7 NTCIP Current Family of Protocols Profiles Class B Class A l pplication | STMF STIFF | SNMP Telnet, . FTP Presentation | Null | Null | Null Session | Null | Null | Null Transport | Null UDP | TOP Network ~Null - IP ~ ~ Data Link PMPP PMPP PMPP Physical EIA 232 E FSK EIA 232 E FSK EIS 232E FSK Class E SNMP Telnet, FTP Null Null TOP IP PPP EIA 232E FSK As presented in "A Family of Protocols" by Me NTCIP Steer~ng Co~nittee: The Class C profile provides connection oriented services, meaning that a caB setup period is needed prior to We actual exchange of information. While this reduces the overall efficiency of He profile, it provides a mechanism for guaranteed delivery services the transport layer takes responsibility for the integrity of the data delivered to the application, Debby freeing Be application from this function. The transport layer uses 'transmission Control Protocor' to provide this guaranteed delivery service. Because of the connection-or~ented nature of this profile and He resuldng overhead, this profile is not wed suited for low speed lines, although Here is nothing to preclude its use on such facilities. Its pnncipal application is in communicating win devices which need to exchange relatively large files, such as Highway Advisory Radio controllers, or Variable Message Signs. It would also support center to center communications. The File Transfer Protocol is well suited to these purposes. Class E provides He same services as Class C, but does so on presumably higher speed "dedicated" or point to point lines. The physical layer protocol In this profile does not support multidrop configuration, and He data link layer employs c:WCHRP\Phase2~pr NCHRP3-51e Ph~e2FmalReport A1-226

Point to Point Protocol which as the name implies, assumes a "one-on-one" sort of exchange. This class is targeted toward major "center to center'' exchanges of information, supporting interactive exchanges (Telnet) and file transfer ~P). Both of these application layer protocols provide a degree of security through user authentication procedures. Conformance Statements and Testing As even common protocols are complex, implementation developed solely from a common specification by multiple suppliers would not guarantee interoperability. To maximize We potential of interoperability, standards organ~zabons, including NEMA's NTCIP, require manufacturers (for certified ~mplementions) to complete a Protocol Implementation Conformance Statement (PICS) Cat answers detailed questions about mandatory and optional features provided. A PICS provides: 1) Verification of features implemented; 2) Checklist for conformance testing by independent test organizations; and 3) Detailed listens) of requirements for procurers. Even PICS do not provide 100% guarantee of interoperability on multivendor implementations, especially early releases; however, vendors conforming to standards will usually accept contractual statements requiring minor warrantee modifications to achieve interoperability. A list of Dublished standards and documents providing more details on NTCIP are contained in Table A.1.5.2-7. A.1.5.3 Circuit-switched Technology Packet networks are based on the concept of disassembly of messages into smaller packets for transmission store-and-forward at intermediate nodes in a network. No direct connection between origin and destination is established although virtual connection may be employed. This ~;\NCH~Phase2.rp: NCHRP 3-51 · Phase 2 Final Report A1-227

pre-establishes addressing/routing parameters so Mat actual transmissions are more efficient and can support higher throughput. Table A.~.5.2~7 NTCIP Standards and Supporting Documents Standards 1 ) NTCIP Steering Group - Point to Mulfi-point Protocol (PMPPJ 2) NEMA Standards Publication TS3.1 - 1996 National Transportation Communication for ITS Protocol- Overview 3) NEMA Standards Publication TS3.2 - 1996 National Transportation Communication for ITS Protocol - Simple Transportation Management Framework 4) NEMA Standards Publication TS3.3 - 1996 National Transportation Communication for ITS Protocol - Class B Profile 5) NEMA Standards Publication TS3.5 - 1996 National Transportation Communication for ITS Protocol Object Definition for actuated Traffic Signal Controller Units 6) National Electrical Manufacturers Association, Draft Standard - NTCIP Object Definitions for Ramp Meter Controllers 7) National Electrical Manufacturers Association, Draft Standard - NTCIP Object Definitions for Variable Message Signs 8) National Electrical Manufacturers Association, Draft Standard - NTCIP Object Definitions for Camera Controllers Supporting Documents (Ge! Complete Titles) 1 ) NEMA Standards Publication, How to Use NTCIP 2) NEMA Standards Publication, NTCIP Systems Developers Guide 3) NEMA Standards Publication, Hows and Whys of NTCIP 4) NTCIP Steering Group 1996 Draft - Class A Profile 5) NTCIP Steering Group 1996 Draft- C/ass B Profile 6) NTCIP Steering Group 1996 Draft- C/ass C Profile 7) NTCIP Steering Group 1996 Draft - Class E Profile Circuit switching establishes a permanent connection between origin and destination. It is We memos used by me telephone industry for switching voice. In its infancy, c~rcuit-sw~tch technology was analog win stepper relays. Since the 19SOs, digital switching has been replacing analog switching, due to me availability of low cost digital components aIld computer technology to control and manage circuit-switched networks. Key requirements for voice and video L:\NCHRP\Phase2.rpt NCHRP3-51 e Phase2FmalReport Al-228

networks are controlled time delay of the digitized signals and an intolerance to random ordering of data at the destination. Table A.~.5.3-1 summarizes and contrasts packet-switched and c~rcuit-switched technologies. More information on digital c~rcuit-switched technologies is in Section A.~.5.3 which discusses T} and SONET multiplex~ng/transmission hierarchies. Modern technology advances have blurred He use of packet technology for data and circuit switched technology for voice and video. V~rtual connections in packet networks and Asynchronous Transfer Mode (ATM) are defining packet capabilities for circuit-switched telephone service providers. A.~.5.4 LANs Local Area Networks ~ANs) are being deployed in TOCs in ITS-related systems within TOCs to link operator workstations with venous servers, and to integrate field data. AS presented in Figure A.~.5.~, L`AN protocol stacks typically define Be physical (1) layer and link (2) layer protocols. The physical layer specifies a medium (e.g., TWP, coaxial cable, fiber, etc.~. The hardware elements of an LAN consist of: I) Network Interface Cards Tics) Mat interface PCs, pnnters, workstations, etc., to the medium; 2) Servers which are computers, such as file servers, communication servers, or application servers; and 3) Communication devices such as hubs, repeaters, bndges, routers/brouters, and gateways. :\NCHRP\Phase~p ~NCHRP 3-51 · Phase 2 Fmal Report A1-229

cn cn os e~ cn eQe Q cn _ O e~ O C~ ~_ e~. ~ ,a ·" _ CO C, O O~ e_ ~: e~ O e ~a) ~ O e~ C, ~ ~_ 0I _, 3 ~a) e" S ._ ·3 ~ e O a e~ .O cn g O CLS CO U) c_ ~8 ~e aC ~ _ eO ~ e ~ C~ ~ ·~ C~ · ~ O ~ .O ~ CL e~ C~ 0 e~ G) eO 2' 0 ~ ~ .` g D _ e~ E ~t ° O e ~C\S .O t.) ee ~CtS e ~Q ~e 03 ~ e cn ~ O J° ~' ma, ~ eY C' O Oe _ g _ ~ ~ e~ eO . '~ Q ,U) 0 Ct Ce O _ ~ _ U) ~ a) ce cn ~e G C' ___ · ~ ~ ~ ~ ~ _ ,= a) ~ .O ~ g Q _ O) O ,~ ·_ ~ ~ ~e E s ·- cn . eC (8 tt e c 0 _ Q ,U) o Q E ~ ' E ~ o^ _ 0 =] et5 _ (D ~ Oc ~ ~ Q tl5 Q CC ~e g a Q CO cn o Q - - 8 ~n eQ o C, ·~ ~_ 3 ._ el_ - - Oe CtS ~e ._ 0 52 eTe ~ e~e `,~ e ~e CO a~ ~S ~ CtS e" 4, Pt C3 co cn oo Ce C15 Q Q CIS ~ ~ ._ o ._ C as- O _ cn o CO C~ C~ - ~S ·O ~Q~ C~ a, C, ~ ,0 0.m . `' E- ,cn cO ~ _ Q U) Q O O ~ ~ ~ ~ m ~n Ct Y ._ CO C' ._ ~- - C :~ ~ CD - CO ~ a, C~ C 0 ·° ~ U) 0 ,cn c E ._ cn C' ~ Ct ~ $ o S Z ~ ~ CS ~ m ~ ~ O o' O Q 0 {55 0 0 ~ ~ E ~ ~ C, ~ Q O ~ ° ~- ° a, 2 ~s ~ ~ s ~ ~ C) 0 I · ~ ~ ~ ._ cn ._ ._ a Cd c o .g c o C~ - ~n ~ - a) - cd s c) cs - cn o ~o s ~ol. ^u, o 2 - Ct s o o U, - D

Figure A.~.5.4-l presents an overview of a typical LAN environment in the popular star topology. LANs employ several network topologies: bus, star, ring. The topologies are presented as Figure A.15.4-2. The most widely deployed Ethernet (' ME 802.3) LAN ong~naDy used a 10 Mbps bit rate on a shared coaxial cable bus with ad devices employing Catner Sense Multiple Access wad Collision Detect (CSMA/CD). This essentially says, before access: listen, Den talk, and if two or more messages collide, then (each Ones wait random and try again. This worked well in small fixed systems, but users encountered He following problems: ~ Reconfigurations for moves, addidons, and deletions were difficult; and 2) Network throughput was detenruned poorly as numbers of devices and network traffic increased. The star topology provides an alternative that substantially reduces these problems. Each device is provided win a dedicated TWP connection from its NIC to a hub at Be full lO Mbps data rate. The hub implements Be bus and experiences the collision. Like telephone circuits to Be desk, LANs also employ TWP wide parallel installation. Premise TWP standards for design, installation, configuration, and maintenance are defined by EIA/IIA, NEMA, and Bellcore. Additionally, this star arrangement permitted more natural segmentation of LAN networks to nary workgroups using bridges or routers. By proper segmentation of workgroups, collision only occur within shared segments undess a remote segment device is addressed. Thus, ovemll network capacity is increased. Many additional extensions to He E~emet standards are emerging Hat include 100 Mbps operations and fiber medium. These are summarized in Table A.1.5.4-1. A competing, but less popular, LAN configuration is the Token Ring ~ FIEF. Standard ~ lid it 802.5. Access to the shared ring is permitted only when an authorizing token is received by a device. This eliminates He collision problem of Ethernet and allows the network to operate at a throughput capacity close to He link bit rates of 4 and 16 Mbps, regardless of total system c:~t New 3-51 · Pie 2 Fig Rein A1-23 1

l - m c/) am _ 1~ mm _ == O Im Q _ _ in O LL _ I o - J llJ ~5 llJ m \ 111 Z Q Q m, '' :::: - ! lelll Ut! . no :: a:: nil' ~3 1 1 ~ Z O o TO O. _ MU ~- en A: LLI o <A ~ Be. En ~ y CY: ~ o _ to m ec J C, Q

l - ~ ¢ '-'l ::c5 CY > L,J CC CY llJ A CY c . . / En m _ \ \ \ \ CY En m' am ''n' - :~:: m m' Inn am MU C) o i a/ · _ tY ret llJ (a LY Let 'a - ~u' US - : UlBl U) o o O O CNJ F 1~ ~ LO echo o - lo: lo: l- ~: ~-

load. For reasons similar to Ethernet, token ring systems rapidly adapted the star configuration. The key features of token ring LANs are summarized in Table A.~.5.4-~. The Fiber Distributed Data Interface (FDDI) was developed in the early 1980s to support an emerging need for high capacity 100 Mbps LANs using fiber as the transmission medium. More recently, a filll 100 Mbps (shielded) 1-WP FDDI standard, suitable for shorter distances, has been developed. Early applications of FDD! were motivated by three requirements: I) Him speed backbones for Token Ring or Ethernet LANs; 2) Distance extensions provided by the bandy and low attenuation of fiber (see Table A.~.5.4-~; and 3) Internetworking for LANs and WANs. FDD! employs a token ring access mechanism like 802.5. Additionally, FDD] specifies dual rings which potentially could support 200 Mbps operation, although most implementations employ the second ring to provide fault tolerant backup. A more recent development is FDDI-H which provides isochronous (i.e., equal delay) capabilities for multimedia voice, video, and data transmission. Some commercial FDD] services are available, but not on a widespread basis. The overall features and capabilities of FDDI are summarized in Table A.~.5.4-~. Frame relay is a fast packet switching technology that provides end users a high-speed virtual private network (VPN) over public and private facilities. It provides bit rates ranging from 64 Kbps, DSO, to 1.544 Mbps, DS-1 (or 2.048 Mbps internationally). Frame relay is suitable for MAN/WAN applications. Frame relay is based on modern transmission systems that are far less error-prone than lower speed transmission systems that traditional data networks such as X.25 employed 1970s-80s. Thus, network (3) and link (2) layer services can be consolidated and simplified and generally accomplished in end-user equipment instead of the network infrastructure. Specifically, time consuming, expensive error-correction and retransmissions are not implemented in He network infrastructure. Thus, higher bit rates can be transmitted/ switched by the infrastructure. By using VPN, public service providers can offer lower cost L:~b=~t NC~ 3-51 · PI 2 Few Ream A1-234

c`i o Q A no _ ~ ~ _ ? z ~ - 8 A ' ~I C] to ~I to · ~ ~ ~ ~ O Q Y E =Q !1 ~o ~o=0D §~ ~ · ~ · ~ ~ · ~ ! ~1 1 1 E | to ~ ~ ~ o | = 5 | ~ | ~ x | 5 | e n = ~5 1: 55 n · 5 5 0 5 = ~ lomiB lo) .. ~ In 8~ 1 ~15050 ID ATE 15 1a' _ At 0 a, ~ ~ a, Qua CO ~ CO C, · ~ _ O a, ma_ cr (D.ce O ~ ~ ~ Cal · ~ ~ ffl ~ 1: ~ · ~ . O LO ~ C e_ ~ ~ O ~O ~ ~ Q CD · ~ C~ CD ~ ~QO I~0 Q O ~ o ` · · ~ m 2 -, sO t° ° ° ·- ~ ffl .,2. o C] ~_ ·. · ~O 2 ; ~"o · - ~o° co ~ u, c' ~ _ · - N ._ 0 0 U' cn ~ ~ffl ~ .- C~ .= o~ ·- ~n Ct Q ~ cn - 1_ ~ _ <: ~ · - 0 eS ~ Q _ ._ UJ ~ cn · ~ ~ U' i~ ~ ~ Ul C' ~ CO · Ct ._ c - cn a, ~._ O ~ ~ C, - C,~ ~ ~S ._ C Y CO

c~ - o c~ Q - o ~ ~ ° s ., cn ° ce o o o o C~ o cn o - ~q ~ ' a) _ 1 ~C,9 Q 0~ ~ ~ O q) O ~ Q ~ o ° ~ Ce a) =.') 3 ~ ~o ~o · ~ o o o o C~ ~ ~ ~n · ~ L ~: 4, ~ Y _ ~ o ., Q 3 Q Q `: ·3 U) cn C~ ·2 =3 I 2 s x 1 m8 o · 2 N C _ ~ N O ~ _ ~ o Q z C~ ~2 o o - t: C CO ~ 0 o,,, o o. ~. CO as ,<~) 5°O 3 e~ ~IL o o E ~ CL o o , o o ~ o _ ~ C~ CO ~ C O ~ O ~ C1S ~ ~ ~ ~ ~ 3 ~ ~ _ m ~ ° U.' - _ ~ Q ~_ ~ -_ ~ CL _ $ ~ t ~g ~D · ~ ,= .- c~ _ t~s Q- Z ~ O._ o UJ Z . - ~o ~ cn o Z Z ~ c5 ~C] _ x ~D Q C] o ._ ~0 _ Q o _ _ Q ~ ._ ~ Q o Q cn o ° - - ~ CtS ~ ._ o 52 - C,~ Y o

. services than is possible win the development of a comparable private network with leased DS-O/DS-1 circuits. The standards bodies for frame relay are lTU-T (~.233), ANS! (T! .606), and BelIcore (TR-TSV-001369 and TR-TSV-001370~. Standard UNIs (user-to-network interfaces) are defined under the auspices of the frame relay forum. Fiber channel is a networking standard that has been developed by several supercomputer, mainframe, workstation, networking, and peripheral companies. The purpose is to provide high speed (100 Mbps to 2 Gbps) networking. Media supported include Single Mode Fiber Optics (SMFO), Multimode Mode Fiber Optic (MMFO), coaxial cable, and shielded twisted pair (STP). Fiber channel networking transparently supports several LAN protocols plus TCP/IP. The overall characteristics are presented in Table 1.5.4-~. Fiber channel key characteristics include: ~ Low latency (end-to-end delay); 2) Full complement of bit rates including rates greater than those supported by ATM; and 3) Efficient support of short and long message transmission and long me transfers. L:\NCHRP\Phase2.rpt NCHRP3-51e Phase2FmalReport A1-237

Next: A.1.6 Video Applications in ITS »
Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report Get This Book
×
 Communication Mediums for Signal, ITS, and Freeway Surveillance Systems: Final Report
MyNAP members save 10% online.
Login or Register to save!

READ FREE ONLINE

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!