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.
defeating the purpose of ATM, which is to optimize bandwidth utilization of non-continuous (i.e. asynchronous) data. llS-related systems have frequently employed synchronous TI, SONET, and modem technologies for extending the geographical reach of data networks, for cost-effective data multiplexing equipment, and for voice and video. As many previous ITS-related data networks have involved second-by-second real-time requirements over low speed data links, LAN network protocols have not been suitable. With He trend toward distributed intelligence and hider capacity communication links, Be real-time control aspects will be relaxed to permit less stringent monitoring of status and performance. This trend, and He availability of cost-effective LAN networking products and supporting standards, will undoubtedly make isochronous LAN networks an attractive option for multimedia ITS systems. This win integrate and enhance TOCs and He field infrastructure communication. While it is true that voice and video can be transmitted over non-isochronous networks, this is only by "luck" and not by standards and design. In a very lightly loaded non-isochronous network, there is non-significant delay in video or voice transfer. Thus, it "seems" to work; however, as terminals are added and network loading increases, a point Ah be reached where video and voice critical timing are impacted. Isochronous standards prevent this from happening; however, He opposite situation can occur in multimedia isochronous networks which are not properly designed. Video and voice cart overload a rnis~esigned isochronous network resulting in data being lost (such as wad ATM). The recommendation is: · Use the proper standards and design methodologies; · Properly select compression and decompression algorithms to meet needs; and · Properly size He network banded for current and future needs. A.2.5 Communication Load Analysis Communication load analysis has a close analogy in the sizing of pipe to permit Be required gallons per second of water to flow. Similarly, communication mediums have a capacity to support a maximum communication load expressed in bits per second at a specified bit error rate (BER). Figure A.2~5-1 illustrates this concept. The previous sections have discussed He Mann NCHRP 3-51 · Phase 2 final Report A2-17
o z a) LLJ c) / \ ~ o a) \ LLI Lo cL z L1J llJ - ~ LO :~ Hi: cy to A En LO 2 LO o En CL LO m F o C: Z ~- C:) Z C, ~ I o A / <O to \ :L \ ~ 1 LL LLJ z m z o o 7 ~0 z C:) En Q He to o l Z O _ (: at: - - to Cat ~ _ LO C~
capacities of current and anticipated ITS communication channels. A first step In communication system design is to determine communication loads that various ITS sensors, video cameras, VMS signs, etc., avid represent and to "size" We composite communication load. This is Me fundamental infonnation needecl to identify alternative communication mediums, topologies, and architectures capable of transmitting the individual loads from sources to destinations. Communication load analysis starts wig estimates of communication source data load requirements, which requires Me following: I. Identification of sources tonging of data to be communicated (WpicaBy field controllers or TOCs) and location; 2. Identification of sinks (destinations) of data (typically TOC or field controllers) and location; 3. Identification of message lengths and frequency (i.e., once per second, once per hour, etc.) of transmission; 4. Identification of any message data delay requirements from source to sink; and 5. Use of the above information to calculate link load or bit rate, typically In bits per second. For simplicity of discussion, constant data loads are assumed although extensions to account for variable (probabilistic) arrival times and message lengths are available. Fortunately, there exists a history of ITS-related systems so that the bit rates are weB known for many data sources as presented in Table A.2.5-~. ~ reality, historical lTS-related bit rates have been determined by the availability of wireline modems and data rates supported in multidrop circuits usually wad proprietary protocols. The evoludon to standard protocols required to support multimodal, integrated multijunsdictional, ITS interoperability requires expanded application message sets, protocol, and associated overhead. Table A.2.5-! also contains estimates of these required data rates. It should be noted that these message sets and protocol . are being defined In Me NTCIP protocol (see Section A.1.5.1) as a NEMA sponsored standard. L;\NCHR~Pha~n N~3-51 · ~2F~R - ~=-19
Table A.2.5~1 Traditional ITS Related Data Field Data Sources and Digital Data Rates | ITS-Related Equipment l Ramp Meters VIES R.F]roll Tans 1 -~_ Data llal~: lbps) | Data Rates (bps) l 1200 - 2400 '200 Weather Stations To - Coo Camera Control WIM/AVI HAR _ 2400 - 9600 1200 - 2400 l 3500 Hz Analog 64,000 bps 9600 - 28,800 2400 - 28,800 2400 - 28,800 2400 - 28 800 . , 2400 - 28 800 . , 1200 - 28,800 16,000 - 64,000 bps _ - 1200 - 2400 CCTV Cameras Digital Analog 30~5 Mbps (Uncompressed) 6 MHz 1200 - 500 000 , 3-8 Mbps (Compressed) 6 MHz By counting, the anticipated number of field devices in an lTS-related system, a preliminary analysis of Me composite data load can be obtained. To illustrate, Table A.2.S-2 contains examples of three U.S. signal systems for small, medium, and large cities. Assumptions in Me table are: 1. Each signal controller operates at 2400 bps. It should be noted that most signal controllers use multidrop configurations of 4-10 drops per circuit. Thus, the loads in Me table could be scaled down accordingly; however, filture ITS functionality will increase data rates and protocol overheads, so they are presented as is; 2. 3. CCTV cameras are assumed to operate at 3 Mbps which have been evaluated to provide acceptable full-modon video for ITS surveillance applications; The Variable Message Signs (VMS) are assumed to operate at 2400 bps. These are assumed to operate continuously, which does overstate Weir data load impact; and 4. As will be an lids requirement, TOC-to-TOC (Distributed Centers) are assumed to generate a 155.2 Mbps load which is a standard SONET OC-3 circuit as frequently employed. In addition to ITS data sharing requirements, it is assumer! that hot-standby mode of operation win be required. L::\NC~Wha~\ NCHRP3-51 · IF A2-20
- · cn J - · ,~ - _'e AS - C`e C] e C`e .~ O 8 ~2 ~ in 6 , o . ~N _ _ E cam . -o' 6 ~ N 6 :E ~ CO CO u, cn ED 0 D Cl) Cl) o g g 8 D D O O. O O ~ ~ o~o8- _.CO _ In In o O O O ° 8 ~ ~ o ~ con- =m co . ¢ a, Q Q 2, D ~8, =8 At ~ C\l N ~ ~ 8 ° o ,,, ° o Con Cto ~ ~ ~ Cut - ~ ' D INS z u) > I_ I~ · - cn ~ 0 (D ~ - ~s ~ a) u) (` 0 - 5 ~5 a. a), D D Ct5 ·- i~ ·O C~ - ~ C~ ~._ O I cn CO c o - r~ :r: ~o
