CalTrans Intelligent Transportations Systems (ITS)


John Slonaker

Instructor: Kevin Almeroth

December 11, 2000







     I am a graduate student in the Media Arts and Technology (MAT) program at UCSB.  I am also an electrical engineer with the New Technology and Research Program in Caltrans (The California Department of Transportation).  One of the Program's activities is to fund university research supporting Intelligent Transportation Systems (ITS) and its related technologies.  My office, within the program, funds research based at UCSB and has facilities on campus as well as a couple miles off campus.  The New Technology and Research Program has its main office in Sacramento as well as other remote offices on and near the UC Berkely and Irvine, and Cal Poly San Luis Obispo campuses.  Part of my job is to maintain and upgrade some of the communications networks that connect these offices and two municipal transportation agencies with which we partner.  During the Fall 2000 quarter, I made some additions and modifications to the equipment and topology of two of the networks that support our staff.


TRANSCAL Network Description


     This network supports multipoint video conferencing and IP data routing among eight main sights.  It also provides a gateway to Caltrans’ statewide video conferencing network (See Figure 1). 

     The communications lines it uses are ISDN (Integrated Services Digital Network) PRI (Primary Rate Interface) which have a maximum data transfer rate of  1.472 Mbits per second.  These are essentially T-1 lines with one end terminating at our various sites and the other end terminating at one of two MCI DMS 250 switches in Dominguez Hills and Hayward (Note A in Figure 1).  The T-1 lines provide the physical infrastructure (layer 1), while the switching capability (layer 2) is provided by signaling data on one of the T-1 lines’ 24 64Kbps TDM channels.  The aforementioned data rate of 1.472 Mbps is thus the aggregate of 23 channels of the T-1 (23 channels for data plus one for layer 2 signaling).  These PRI lines comprise a VPN, or Virtual Private Network, in that calls from sites not on the network are blocked by provisioning in the DMS 250 swithces.  This so others cannot dial one of the sites’ phone numbers are gain access to the IP data for hacking purposes.  It also means that video calls can be initiated and received among the TRANSCAL sites, while calls from public ISDN numbers can be initiated from TRANSCAL sites but not received by them.  The connection to Caltrans’ statewide video conferencing network is provided by a standard T-1, one end of which terminates at our switch at UCSB (Note B in Figure 1).  The other end terminates at a DACS (Digital Access Cross-connect System) at Qwest Communications in Los Angeles where it can be connected to to other T-1s going to the various other Caltrans sites.

     The terminating equipment for the PRIs and T-1 are “Access Swithes” from Madge Networks.  They switch data among T-1 (RJ-45) and serial data (RS-449 & V.35) ports and provide Inverse Multiplexing (IMUX) functionality for aggregating several channels of the PRIs to accept serial data streams of various rates.  They also have a user interface for provisioning and network diagnostics.

     The equipment connected to the ports of the Madge switches consists of video codecs (coder/decoders) and ISDN routers.  The routers have an Ethernet card and an ISDN PRI card and essentially place ISDN calls to route data off of the various subnets.  The Internet is reached through a PC with two NICs, one on the TRANSCAL network and one on a subnet on UCSB’s class B network (Note C in Figure 1).  The video codecs have serial RS-449 or V.35 interfaces that connect to the Madge switches as well as various user interfaces like cameras, monitors, microphones and control devices.  The codec equipment at different sites comes from various manufactures, but all video compression algorithms used can conform to the H.320 standard for video compression.  H.320 is part of the International Telecommunications Union’s (ITU) H.261 standard protocol suite for compressed audio and video over n x 64 Kbps circuit switched networks.  Unlike asymmetrical compression schemes like MPEG, that use more computation time to compress a signal than to decompress it, H.320 uses a symmetrical scheme so that compression and decompression happen simultaneously at each end point.  This provides the real time service required by the conferencing application.  After a switched connection is made, the codecs at each end (either in a room system or in the MCU) exchange “handshaking” information, in which they negotiate a compression scheme to use.  If the codecs are from different manufacturers, chances are they will end up using H.320, which they are both required to understand.  If the codecs happen to be from the same manufacturer, they may choose to use a proprietary algorithm that supposedly improves the picture quality over H.320.  These propriety connections can also introduce signaling out of the video band to implement non-standard functions like far end camera control.  Interoperability issues such as these are of great concern in researching communications technologies suppoeting ITS.


Additions and Modifications


     Our off campus facility in Santa Barbara has a video conferencing system (codec and peripheral equipment mentioned above) that had previously used public ISDN BRI (Basic Rate Interface) lines.  We wanted to put it on the TRANSCAL network, but in a cheaper, less complicated way than existing sites.  To do this, I  procured an Ascend IMUX switch and ordered another ISDN PRI line to that location.  The Ascend switch provides the functionality to connect the video conferencing system to the PRI line plus an integrated Ethernet port for routing data.  After connecting the hardware, I used a terminal emulation program (“Hyperterm”) on my laptop to configure the settings.  The most involved part was the PRI interface which had many parameters that had to match the signaling from the DMS 250 switch.  After a call to Ascend Technical Support, I eventually got it working.  The video conferencing system is now integrated in the TRANSCAL network, and we now have a simpler and cheaper way to integrate future sites or replace failed equipment at the existing ones (Note D in Figure 1).

     Another upgrade was made to our MCU (Multipoint Conference Unit), or video “bridge” (Note E in Figure 1) which connects to three or more video conferencing sites via the PRI lines and mixes the signals to allow all sites to participate in a meeting simultaneously.  This is somewhat analogous to a conference call on three of more telephones.  There are two different modes (from the users’ viewpoint) of doing this:  In one mode, the entire monitor is filled with an image of a single site.  This can be switched either manually or by “voice activation,” where the MCU shows the video signal from the site the where person currently speaking is.  The other mode is called “continuous presence,” where the monitor screen is split into four quadrants, and up to four remote sites are visible simultaneously.  All sites hear a mix the audio from all other sites in both modes.  The functionality added by the upgrade made it possible to have more than five sites (the local site plus four remote sites) participate in a continuous presence conference.  This is now done by voice (or manually) switching one of the quadrants to the additional site(s).  Another added functionality was the ability to connect sites in a single conference at various data rates.  For example, one of more sites with a PRI could use six of its 23 available channels and connect at 384 Kbps (6 x 64 Kbps), while one or more sites with a BRI line could connect at 128 Kbps (BRI lines have two 64 Kbps data channels only) and all these sites would see each other.  Of course, the BRI sites would see all other sites at the video quality supported by their 128 Kbps connection, but the PRI sites would be able to see other PRI at the higher quality supported by their 384 Kbps connections.  The most practical reasons for the upgrade, however, was that it included the latest software version, which is actively supported by the manufacturer (the previous version was no longer supported) and it included a Pentium processor, which made it officially “Y2K compliant” (sort of a political necessity within Caltrans).  I worked with the manufacturer to determine the necessary peripheral boards (new mother board for the Pentiium CPU, communications interface cards, and “Bridge Processing Unit” cards), hardware components (hard drive, CD ROM) and software (new “OS2 Warp” OS, applications, and drivers).  I later worked with the installer on the physical installation.

     Our facility on the UCSB campus consists of two rooms in different buildings.  As mentioned above, the TRANSCAL netowork gets its Internet connection through a routing PC with one NIC on TRANSCAL and the other on a Class C UCSB subnet.  This UCSB subnet is used to connect various hosts in one of our two campus rooms.  Previously, the other room had been on a different UCSB subnet, but we wanted to get both rooms one the same one for file sharring, etc.  To do this, I worked with UCSB communications services to re-route a fiber optic pair to terminate in the two rooms.  I then procured a pair of media converters (See Note F in Figure 2) to put on the ends of the fiber.  I ran category 5 cable (100baseT) to the existing Ethernet switch in the room that connects to the TRANSCAL network.  I then installed a hub in the other room and connected cables to the other media converter and hosts.   



                                                Figure 1 - TRANSCAL Network



                                                Figure 3 - Symbol Legend