|
Items in cart [0] |
Questions? Call 888-624-8373 |
| Copyright © 2009. National Academy of Sciences. All rights reserved. Terms of Use and Privacy Statement |
Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 361
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
OCR for page 362
OCR for page 364
OCR for page 365
Representative terms from entire chapter:
data networks
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
/
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
