- Email: [email protected]
Modeling the NAJPTC network using NS-2
I N T E R N AT I O N A L J O U R N A L O F C R I T I C A L I N F R A S T R U C T U R E P R O T E C T I O N
1 (2008) 29–36
available at www.sciencedirect.com
journal homepage: www.elsevier.com/locate/ijcip
Modeling the NAJPTC network using NS-2 Paul Vincent Craven a,∗ , Paul Oman b,1 a Carver Science Building, Simpson College, 701 N C Street, Indianola, IA 50125, USA b Department of Computer Science, University of Idaho, Moscow, ID 83843, USA
A R T I C L E
I N F O
A B S T R A C T
Article history:
Positive Train Control (PTC) refers to microprocessor-based communication technologies
Received 12 June 2008
that are capable of preventing train collisions, derailments, and injuries to workers
Received in revised form
operating within the railroad system. In North America, there are 11 competing PTC
3 August 2008
projects in various stages of refinement. The North American Joint Positive Train Control
Accepted 6 August 2008
Project (NAJPTC) is one of those efforts, based on the Advanced Train Control System (ATCS) protocol. NAJPTC is a joint development project of the Association of American Railroads, the Federal Railroad Administration, and the Illinois Department of Transportation. In this
Keywords:
paper, we use a network simulation system (NS-2) to model NAJPTC ATCS communications
ATCS
to determine the feasibility of that PTC system when overlaid onto geographic data
NS-2
from Google Earth, and digital elevation data from the United States Geological Survey.
Positive train control
Our simulations were useful in observing and tracking the signal strength of a moving
Railroad communications
train, resolving packet collisions via strategic base station placement, and modeling and
Wireless communications
mitigating communication losses. c 2008 Elsevier B.V. All rights reserved.
1.
Introduction
Positive Train Control (PTC) is a system that employs technology to prevent train-to-train collisions, overspeed derailments, and prevent trains from striking track workers. A vital part of this system is a microprocessor based communication system. In 2007 there were 179 accidents in the US of the type that PTC seeks to prevent. These accidents killed 8 people and injured 170. These accidents also caused $26.4 million dollars in damage to equipment and track.2 From 2004 to 2006, rail traffic increased by 3.2% each year, while the miles of track actually used
decreased by 1% [1]. Thus, each year we have more rail traffic operating on less track, thereby increasing the probability of collisions, derailments, and worker injury. Railroad operators want to combat this problem via a system of improved communications that better control rail traffic and, thereby, increase rail safety. The North American rail industry has called for Positive Train Control (PTC), a microprocessor-based communication system that monitors train locations, and automatically applies braking efforts to prevent collisions and derailments. In North America, there are 11 competing PTC projects in various stages of refinement: Advanced Civil Speed Enforcement
∗ Corresponding author. Tel.: +1 515 961 1834; fax: +1 515 961 1498. E-mail addresses: [email protected] (P.V. Craven), [email protected] (P. Oman). 1 Tel.: +1 208 885 6899; fax: +1 208 885 9052. 2 Statistics compiled by the authors using 2007 accident data from the Federal Railroad Administration accident database. Accidents types that PTC is designed to prevent: most types of collisions outside rail yards, operating a locomotive outside a block it is cleared for, and excessive speed outside a switching yard.
c 2008 Elsevier B.V. All rights reserved. 1874-5482/$ - see front matter doi:10.1016/j.ijcip.2008.08.002
30
I N T E R N AT I O N A L J O U R N A L O F C R I T I C A L I N F R A S T R U C T U R E P R O T E C T I O N
System operating in trials between Boston, MA and New Haven, CN; Collision Avoidance System being phased in statewide in Alaska; Communications Based Train Management operating between Spartanburg, SC, and Augusta, GA; Electronic Train Management System on BNSF lines in Texas and Oklahoma; Incremental Train Control System on Amtrak’s Michigan line between Chicago and Detroit, IL; Vital Train Management System being tested in both the Powder River basin of Wyoming and Washington state; Optimized Train Control in central South Carolina; Train Sentinel PTC System on approximately 300 miles of the Ohio Central Railroad System; Chicago METRA to be installed on approximately 60 miles of the Joliet and Rock Island subdivisions of Chicago; the Port Authority of New York and New Jersey Communications Based Train Management to run on the Trans-Hudson River Commuter Rail Line underground between New Jersey and New York City; and the North American Joint Positive Train Control Project (NAJPTC) that was field-tested in Illinois between Springfield and Braidwood (south of Joliet) [2]. NAJPTC is a joint development effort between the Association of American Railroads, Federal Railroad Administration, Illinois Department of Transportation, Amtrak, and several companies, including Wabtec, Lockheed Martin and the Union Pacific Railroad [3]. NAJPTC was successfully fieldtested between 1998 to 2006. Besides preventing collisions, NAJPTC included features to prevent trains from going too fast for the section of track they are on; allow locomotives to remotely change track switches; and monitor train locations and movements. In 2006, the NAJPTC field tests were concluded and it was decided that further development was needed before the revenue-service PTC system was ready for deployment [4]. Protocol development and testing is ongoing at the Transportation Technology Center in Pueblo, Colorado. Of the 11 competing PTC development efforts, the NAJPTC project was chosen for this simulation because (a) it is based on the existing and widely used ATCS protocol, (b) the protocol specification is public and open for study, (c) the field test data is large enough to make interesting and meaningful simulations, and (d) the project is a collaboration involving several government agencies, rail providers, and private industries. In an earlier paper, we described how the NS-2 network simulation system was adapted to model the Advanced Train Control System (ATCS) protocol [5]. As a continuation of that work, we adapted our ATCS models to simulate NAJPTC operating in 3-D space using track routing data from Google Earth (earth.google.com) and elevation data from the US Geological Survey (USGS) [6]. As ATCS is the core communication technology of NAJPTC, we expanded our simulations to model NAJPTC over 3-D space, as represented by Google Earth (for track routing) and the US Geological Survey (USGS, for elevation data). This paper describes those simulations. In the next section, we review ATCS because that background information is necessary to understand the NS-2 simulation of NAJPTC. We then describe modeling NAJPTC, using data from Google Earth and USGS, and the problems of signal propagation delay. After that we present our simulation results showing the data for signal strength, packet collisions, performance, and optimization.
1 (2008) 29–36
Fig. 1 – Sample ATCS network.
2.
ATCS
The rail industry uses many communication protocols specific to the industry [7]. NAJPTC is based on the ATCS protocol, which is quite popular and covers several thousand miles of track [8,9]. The ATCS standard is open, and allows different manufacturers to create inter-operable rail communications equipment [10]. The specification is documented in several volumes, each of which is given a numeric label [11]. Each of these specification volumes covers a different logical grouping of ATCS functionality. For instance, ATCS Specification 250 covers message formats, while ATCS Specification 130 covers standards for software quality assurance. There are 25 different volumes in the specification. ATCS defines three main types of network nodes: Cluster Controller/Front End Processor (CC/FEP), Base Control Packages (BCPs), and Mobile Communication Packages (MCPs). At the center of the network communications is the CC/FEP device(s) controlled by the rail dispatcher. The CC/FEP knows the status of all the networked equipment. Any commands to change switches or signals can be given to the CC/FEP, and it will route the command to the appropriate distributed device. The CC/FEP communicates through wired data lines to several base stations called BCPs. The BCPs retransmit information between the CC/FEP and the MCPs, wirelessly creating the last link in the ATCS communications network. Sending and receiving the wireless signals are the MCP devices mounted on locomotives for communications as they travel along the track. The MCPs control signals, switches, and sensors. Data is also transmitted from MCP to BCP and back to the CC/FEP to complete the sensor/control network. Fig. 1 shows a sample network with all three types of nodes. The trucking industry also uses wireless communications via satellite. But there are several differences in their use that makes rail very different from the trucking industry. Satellite communications usually cost money for each byte transmitted. Since the rail industry has many constant streams of data for sending status on signals, switches, bearing wear, and other items, the satellite costs would be
I N T E R N AT I O N A L J O U R N A L O F C R I T I C A L I N F R A S T R U C T U R E P R O T E C T I O N
1 (2008) 29–36
31
Fig. 2 – Google earth image overlain with BCP and MCP nodes.
more expensive than maintaining UHF data radios. Track side sensors have also been found more reliable than maintaining GPS equipment on each rail car. Plus, the trucking industry is not yet at the stage of creating a system that actively prevents collisions with other trucks.
2.1.
Modeling NAJPTC
While the NAJPTC project was being planned and executed, there was no way to run a simulation of the ATCS traffic. Creating a virtual network before the actual deployment of NAJPTC would have given engineers a better idea of what to expect. Simulations also make it easy to create a week’s worth of sample data in only a few minutes. The effects of conditions, such as a lost transmitter station, can be predicted easily and safely, using a simulation environment. Several tools exist to model the behavior of other networking protocols, such as TCP/IP. One of these tools is named Network Simulator 2 (NS-2). NS-2 is a discrete event simulator [12]. It has support for many common networking protocols, although ATCS is not one of them. For this research, code was written to plug into NS2 that allows it to model ATCS networks. This new code supports ATCS at all layers of the OSI model. Code was also added to support two new propagation models, import digital elevation maps, and create propagation maps. More details about adding ATCS support to NS-2 are available [5,13].
The NAJPTC field test used a total of 156 MCPs and 9 BCPs along 195 km (120 miles) of track. The location for each BCP and MCP was obtained as a milepost location. With some work, these milepost locations were turned into latitude and longitude coordinates. In order to verify the accuracy of these coordinates, they needed to be checked against a map. Google Earth is a program that allows the user to view detailed satellite photo maps for any location on Earth. It also has the ability to import and export map locations in XML format. A Perl script was written that converted the MCP and BCP locations into Google Earth XML format. Once loaded into Google Earth, the data could be checked for quality. Where high-resolution satellite photos were available, the actual wayside station could be seen in the image. The initial coordinates we obtained appeared to be accurate to about 50 m. Most of the error came from the fact that the coordinates only listed how far along the track the wayside station was. The actual wayside station would be set off to the side of the track. For locations where high-resolution imagery was available, the coordinates were adjusted to their exact location according to the satellite photo. Fig. 2 shows an image from Google Earth that lists some of the MCPs and BCPs. The simulations also assumed one MCP was mounted to a locomotive traveling along the track at 50 kph (31 mph).
32 3.
I N T E R N AT I O N A L J O U R N A L O F C R I T I C A L I N F R A S T R U C T U R E P R O T E C T I O N
1 (2008) 29–36
Propagation modeling
The ATCS NS-2 model has the ability to calculate signal loss in two different ways. The first is Free-Space Loss [5]. This method assumes stations are on a flat plane with no obstructions between them. This method of calculating signal loss can be done quickly on the computer, and does not require the user to specify any information about the terrain. This method is a good choice when trying out a new model, or doing a simulation where accurate propagation estimates are not needed. The second method of signal loss calculation is Longley–Rice. This method offers increased accuracy, in exchange for longer calculation times. Longley–Rice improves the propagation estimate by taking into account the terrain elevation between the transmitter and receiver. Longley–Rice was first published in 1967 [14,15]. A Fortran implementation of the algorithm accompanied that paper. The Fortran algorithm was translated to Microsoft-specific C code by the US Department of Commerce [16]. An amateur radio enthusiast, John Magliacane, updated the code for use in a Unix environment [17]. Magliacane’s code also loaded and used Digital Elevation Models (DEMs) published by the United States Geological Survey (USGS). Another nice feature of the code was that the user could create propagation maps. These maps showed how the signals spread out. Magliacane’s code is distributed under the GNU Public License. For this research, we took Magliacane’s code and updated it to C++. It was then interfaced to TCL and NS-2. Signal loss can now be calculated in NS-2 using Longley–Rice. Users can download detailed, free Digital Elevation Models from the United States Geological Survey [6]. Each file represents a one degree by one degree section of land. There is approximately one datapoint every 65 feet. Once pointed to the directory where they are stored, the correct maps are automatically loaded by the ATCS NS-2 model. In addition to calculating signal loss for packet transmission, the user can generate “splat” maps. These maps show propagation-loss or line-of-sight for wireless transmitters that a user has in his or her simulation. Fig. 3 shows an example of a line of sight map for two of the NAJPTC base stations. All the colored areas in the map have line-of-sight to one of the ten meter tall transmitter towers. The rail industry has successfully used Longley–Rice for an estimate of signal strength when planning radio networks. While propagation of radio waves involves many variables, this technique provides a close enough approximation to actual results, that the rail industry continues to find it useful.
4.
NAJPTC simulation results
4.1.
Modeling signal strength
Running the ATCS simulation produces a comma delimited file with information about packets at different nodes and different OSI layers. Included in the packet data is received signal strength. A simulation generates a large amount of data, but it can easily be filtered. For the next few graphs, the data has been filtered to only look at packets for an MCP located on a locomotive traveling down the NAJPTC rail line.
Fig. 3 – NAJPTC line of sight map.
Fig. 4 – BCP signal received by southbound locomotive MCP (free-space).
The signal strength received by an MCP on a locomotive traveling along the NAJPTC rail line is shown in Figs. 4 and 5. Fig. 4 is done with the free-space propagation, and Fig. 5 is done with Longley–Rice. Fig. 6 is also calculated using Longley–Rice and shows the signal going in the other direction, from the MCP to the various BCPs along the path. The spikes in the signal strength shown in figures happen when the locomotive is closest to one of the base stations. Note that there are also increases in strength between the spikes, such as those at 1800 and 4100 s. These jumps come from when the cluster controller changes the routing to a base station closer to the locomotive. Another interesting item, as the train travels down the line, the routing algorithm can be resistant to changing the BCP. This can be seen in Fig. 4. Note the sharp jump around 8000 s. The routing algorithm keeps a running average of signal strengths. The more signal strength readings the algorithm keeps, the larger these jumps will be. If no running average is used, the routing algorithm will unnecessarily change the routing due to random signal fluctuations or
I N T E R N AT I O N A L J O U R N A L O F C R I T I C A L I N F R A S T R U C T U R E P R O T E C T I O N
1 (2008) 29–36
33
Fig. 7 – Average MCP retransmissions for each MCP. Fig. 5 – BCP signal received by southbound locomotive MCP (Longley–Rice).
Fig. 8 – BCP packet counts with North Lincoln BCP failure. Fig. 6 – MCP signal received by BCPs from southbound locomotive (Longley–Rice).
minor effects of the terrain. In the simulation it is easy to change the routing algorithm and see the results. For the NAJPTC project, keeping only the last three signal strength readings seemed to work well.
4.2.
Modeling packet collisions
ATCS networks are part of a real-time system. Data must arrive in a timely fashion. If a high percent of packets collide, it will increase the average delivery time. Using the simulation environment we created, the user can predict where in the network packet collisions will happen. The histogram in Fig. 7 shows the number of times each MCP in our simulation needed to retransmit information during a one hour interval. To reduce random fluctuations, five simulations were run and the data was averaged. Each bar represents one MCP, with the northern-most MCP on the left side. As shown in Fig. 7, the MCPs closest to a BCP are least likely to retransmit packets, because their signal is stronger than MCPs that are further away. The MCP communications with the highest retransmissions (i.e., the tallest bars) are therefore more likely to experience data delivery delays.
The model user can quickly run several simulations to experiment with different BCP placements by repositioning the BCP coordinates and then re-running a master script to automatically update graph shown in Fig. 7. This type of adhoc network configuration experimentation shows the power and utility of the NS-2’s NAJPTC model. Via experimentation, we found that the actual placement of the BCPs in the NAJPTC field tests was good, but not optimal. That is, almost any ad hoc adjustment made to the original BCP positions resulted in an increase of packet collisions. However, a user can use the ATCS NS-2 model to automatically find optimal BCP placement and survivable placement for BCPs under failure scenarios, both of which are as described later in this section.
4.3.
Modeling BCP loss
In addition to seeing the behavior of a fully functional network, it is important to see how the network performs when a component fails. If a BCP fails, the network as a whole needs to continue working. The front end scripts for the NS-2 ATCS simulator can iterate through and run simulations with each of BCPs disabled. Fig. 8 shows data from a simulation of the NAJPTC network. The histogram represents a count of the packets
34
I N T E R N AT I O N A L J O U R N A L O F C R I T I C A L I N F R A S T R U C T U R E P R O T E C T I O N
1 (2008) 29–36
Table 1 – 5-W network performance with BCPs disabled
transmitted by the BCPs over a 1500 s interval. Each pair of bars represents the data received by an individual BCP. The bar on the left side of the pair shows the packet count for a simulation run when all BCPs were functioning. The hatched bar on the right shows packet count if the BCP at North Lincoln is taken off-line. As can be seen from the graph, the neighboring Elkhart and McLean BCPs pick up the traffic that the North Lincoln BCP was handling before. The other nodes are unaffected. Fig. 9 shows what happens in our simulation to packet collision frequency when the BCP in Dwight, Illinois disabled. When comparing Fig. 7 to Fig. 9, we can see there is a significant increase in packet retransmissions with the loss of that BCP.
Network performance with BCP loss
The user can get a quick idea of network performance in a simulation, by calculating the ratio of packets sent for the first time, verses the total of all packets. The total would include packets that are being retransmitted. This ratio is represented by R and calculated in Eq. (1). T represents the total packets transmitted, and F represents count of retransmissions. R=
T−F . T
Network performance
None Springfield Lexington Elkhart North Lincoln McLean Wilmington Bloomington Ocoya Dwight
0.9632 0.9620 0.9597 0.9587 0.9574 0.9549 0.9542 0.9484 0.9463 0.9265
Table 2 – 2-W network performance with BCPs disabled
Fig. 9 – MCP retransmissions with Dwight BCP failure.
4.4.
BCP disabled
(1)
Table 1 shows the ratio of successfully transmitted packets with a fully functional network, and also the performance if one of the BCPs were disabled. From this data it can be seen that the Dwight BCP is the most critical BCP for network performance. But even if that node is lost, the network still performs well. We can easily simulate what would happen if the output power of the BCPs were reduced from 5 W to 2 W. Table 2 shows the same network as before, but the MCPs are only transmitting 2 W. Network performance when all the BCPs are working does not change significantly. But the performance numbers do change quite a bit when we disable some of the BCPs. This is because some MCPs are no longer in range of a BCP, and will attempt to send packets over and over before giving up. The simulation environment can be used to compare BCP layouts, according to the number of dropped packets and
BCP disabled
Network performance
None Springfield North Lincoln Elkhart McLean Lexington Ocoya Wilmington Bloomington Dwight
0.9624 0.9583 0.9561 0.9558 0.9530 0.9523 0.9391 0.9145 0.7976 0.2254
packet retries when individual BCP nodes are taken out. This helps the user to find a good network layout that continues to work well if a base station is off-line. Using the network performance equation above, we can find how essential each BCP station is to the network’s health. As shown in an earlier paper [5], collisions can be reduced drastically, by setting the BCPs to always transmit busy-bit information. This does not work for the NAJPTC network. Each BCP transmits on the same frequency. Some MCPs are equidistant from two BCPs. This works when the BCPs are not transmitting at the same time. But if they are, then the MCP will register a collision. With BCPs only transmitting occasionally, there is rarely a collision for an MCP. But if the BCP transmits busy-bit information all the time, then the MCPs in the middle are constantly hearing both BCP stations and can’t successfully receive data.
4.5.
Optimization of BCP placement
While ad-hoc improvement might be difficult, we have created an algorithm to automatically improve BCP placement. To do this with NAJPTC, we started with the nine pairs of coordinates that specify the original locations of the base stations. By creating a “score”, we can run an optimization algorithm to improve the score, based on moving the base stations. In Table 3, we show two sets of throughput values. One is the original throughput, based on the actual NAJPTC station locations. These throughput values are the same numbers shown in Table 1. The second set of numbers shows the results of a simulated system where our algorithm methodically tries other BCP locations to come up with improved placements. Throughput numbers, along with the change, are rounded to three decimal places.
I N T E R N AT I O N A L J O U R N A L O F C R I T I C A L I N F R A S T R U C T U R E P R O T E C T I O N
1 (2008) 29–36
35
Table 3 – Network performance of actual vs. optimized BCP placement BCP Disabled
Original performance
Optimized performance
Change
None Springfield Elkhart North Lincoln McLean Bloomington Lexington Ocoya Wilmington Dwight
0.963 0.962 0.959 0.957 0.955 0.948 0.960 0.946 0.954 0.927
0.967 0.964 0.967 0.965 0.961 0.963 0.960 0.953 0.953 0.955
0.003 0.002 0.008 0.008 0.006 0.014 0.000 0.006 −0.001 0.028
5.
Fig. 10 – Distance train travels from initial status message, to when it receives a response message.
By looking at the change between the original and the optimized setup, we can see how much improvement was made to the network. If the Dwight or Bloomington stations are lost, the network will be it better shape with the improved BCP placements compared to the original ones. All but one of the other stations showed improvement as well.
4.6.
Simulations with high-speed trains
One of the problems encountered in the NAJPTC trial was that ATCS did not work as well for high-speed trains as it did for slower trains. High speed trains can also be simulated with the NS-2 ATCS environment. In Fig. 10 we can see the results of a simulation that shows how far a train moves from the time it sends out a status message, to the time it receives a command from the dispatcher office. In Fig. 10 each bar represents a command/response cycle that occurs every minute in the simulation. The wayside devices are also sending out status messages causing the packet times to vary. From the graph, it can be seen that one message does not get received until the train travels nearly 1600 feet, because of several collisions with the initial packets. Five messages are never received due to a combination of packet collisions, and the train traveling out of radio range too quickly. These are represented by the missing bars.
Conclusion
The ATCS NS-2 simulator allows users to create network scenarios for detailed or ad-hoc network tests. Network scenarios can be created via a script, or created by using Google Earth. Anyone familiar with the NS-2 framework should be able to simulate ATCS networks. Users are not limited in how results from the simulation data can be summarized. The output of the simulator is in the form of raw packet dumps and logs of messages passed between nodes and OSI layers. This allows the user to summarize the data anyway that is needed, using whatever tools are appropriate. Examples in this paper were prepared with software programs Perl, Bash, and Gnuplot. In this paper, we have shown the ATCS NS-2 simulator modeling data communications for the NAJPTC project. The simulator can be used to quickly predict if a network can survive failures of BCP nodes, and to what the effects of those failures would be. It can also be used as part of an automated process to find improved BCP placement. The use of this network simulator in planning PTC setups can help engineers see how network traffic will occur on networks before they are actually built. REFERENCES
[1] American Association of Railways, Class I railroad statistics, November 2006. URL www.aar.org/PubCommon/Documents/ AboutTheIndustry/Statistics.pdf. [2] Federal Railroad Administration, Positive train control overview, November 2007. URL www.fra.dot.gov/us/content/ 1265. [3] T. Tse, IDOT PTC, National Transportation Safety Board, 2005. URL www.ntsb.gov/events/symp_ptc/presentations/06_ Tse.pdf. [4] Federal Railroad Administration, North American Joint PTC (NAJPTC), January 2007. URL www.fra.dot.gov/us/content/605. [5] P.V. Craven, P. Oman, Modeling ATCS networks using NS-2, in: Critical Infrastructure Protection, International Federation for Information Processing, Springer, 2008. [6] United States Geological Survey, 1:250,000-scale Digital Elevation Models (DEM), 2007. URL http://edcftp.cr.usgs.gov/ pub/data/DEM/250/. [7] P.V. Craven, A brief look at railroad communication vulnerabilities, in: Intelligent Transportation Systems Conference 2004, vol. 5, IEEE, 2004, pp. 245–249. [8] Norfolk Southern Corp, Form 10-K for Norfolk Southern Corp for the fiscal year ending December 31, 2003 (2004).
36
I N T E R N AT I O N A L J O U R N A L O F C R I T I C A L I N F R A S T R U C T U R E P R O T E C T I O N
[9] D.R. Williams, B.R. Metzger, G.M. Richardson, Spec 200 radio code line ducting—cause and effect, in: 2001 AREMA Conference Proceedings, 2001. [10] P.V. Craven, S. Craven, Security of ATCS wireless railway communications, in: Proceedings of JRC2005, 2005 Joint Rail Conference, vol. 5, 2005, pp. 227–238. [11] American Association of Railways, System Architecture, ATCS Specification 100, Revision 4.0, May 1995. [12] K. Fall, K. Varadhan, The ns manual, 2007. URL www.isi.edu/ nsnam/ns/doc/ns_doc.pdf. [13] P.V. Craven, Architecture of an ATCS network simulator, in: Proceedings of the 2008 IEEE International Conference on Electro/Information Technology, 2008.
1 (2008) 29–36
[14] P.L. Rice, A.G. Longley, K.A. Norton, A.P. Barsis, Transmission loss prediction for tropospheric communication circuits, in: NBS Tech. Note 101, 1967. [15] A.G. Longley, P.L. Rice, Prediction of tropospheric radio transmission loss over irregular terrain: A computer method, in: Environmental Science Services Admin. Technical Report ERL 79-ITS 67, Institute for Telecommunications Sciences, 1968. [16] US Department of Commerce NTIA/ITS, C++ code for Longley–Rice propagation, 2007. URL http://flattop.its. bldrdoc.gov/itm.html. [17] J. Magliacane, Splat! A terrestrial RF path analysis application for linux/unix, 2007. URL www.qsl.net/kd2bd/splat.html.
1 (2008) 29–36
available at www.sciencedirect.com
journal homepage: www.elsevier.com/locate/ijcip
Modeling the NAJPTC network using NS-2 Paul Vincent Craven a,∗ , Paul Oman b,1 a Carver Science Building, Simpson College, 701 N C Street, Indianola, IA 50125, USA b Department of Computer Science, University of Idaho, Moscow, ID 83843, USA
A R T I C L E
I N F O
A B S T R A C T
Article history:
Positive Train Control (PTC) refers to microprocessor-based communication technologies
Received 12 June 2008
that are capable of preventing train collisions, derailments, and injuries to workers
Received in revised form
operating within the railroad system. In North America, there are 11 competing PTC
3 August 2008
projects in various stages of refinement. The North American Joint Positive Train Control
Accepted 6 August 2008
Project (NAJPTC) is one of those efforts, based on the Advanced Train Control System (ATCS) protocol. NAJPTC is a joint development project of the Association of American Railroads, the Federal Railroad Administration, and the Illinois Department of Transportation. In this
Keywords:
paper, we use a network simulation system (NS-2) to model NAJPTC ATCS communications
ATCS
to determine the feasibility of that PTC system when overlaid onto geographic data
NS-2
from Google Earth, and digital elevation data from the United States Geological Survey.
Positive train control
Our simulations were useful in observing and tracking the signal strength of a moving
Railroad communications
train, resolving packet collisions via strategic base station placement, and modeling and
Wireless communications
mitigating communication losses. c 2008 Elsevier B.V. All rights reserved.
1.
Introduction
Positive Train Control (PTC) is a system that employs technology to prevent train-to-train collisions, overspeed derailments, and prevent trains from striking track workers. A vital part of this system is a microprocessor based communication system. In 2007 there were 179 accidents in the US of the type that PTC seeks to prevent. These accidents killed 8 people and injured 170. These accidents also caused $26.4 million dollars in damage to equipment and track.2 From 2004 to 2006, rail traffic increased by 3.2% each year, while the miles of track actually used
decreased by 1% [1]. Thus, each year we have more rail traffic operating on less track, thereby increasing the probability of collisions, derailments, and worker injury. Railroad operators want to combat this problem via a system of improved communications that better control rail traffic and, thereby, increase rail safety. The North American rail industry has called for Positive Train Control (PTC), a microprocessor-based communication system that monitors train locations, and automatically applies braking efforts to prevent collisions and derailments. In North America, there are 11 competing PTC projects in various stages of refinement: Advanced Civil Speed Enforcement
∗ Corresponding author. Tel.: +1 515 961 1834; fax: +1 515 961 1498. E-mail addresses: [email protected] (P.V. Craven), [email protected] (P. Oman). 1 Tel.: +1 208 885 6899; fax: +1 208 885 9052. 2 Statistics compiled by the authors using 2007 accident data from the Federal Railroad Administration accident database. Accidents types that PTC is designed to prevent: most types of collisions outside rail yards, operating a locomotive outside a block it is cleared for, and excessive speed outside a switching yard.
c 2008 Elsevier B.V. All rights reserved. 1874-5482/$ - see front matter doi:10.1016/j.ijcip.2008.08.002
30
I N T E R N AT I O N A L J O U R N A L O F C R I T I C A L I N F R A S T R U C T U R E P R O T E C T I O N
System operating in trials between Boston, MA and New Haven, CN; Collision Avoidance System being phased in statewide in Alaska; Communications Based Train Management operating between Spartanburg, SC, and Augusta, GA; Electronic Train Management System on BNSF lines in Texas and Oklahoma; Incremental Train Control System on Amtrak’s Michigan line between Chicago and Detroit, IL; Vital Train Management System being tested in both the Powder River basin of Wyoming and Washington state; Optimized Train Control in central South Carolina; Train Sentinel PTC System on approximately 300 miles of the Ohio Central Railroad System; Chicago METRA to be installed on approximately 60 miles of the Joliet and Rock Island subdivisions of Chicago; the Port Authority of New York and New Jersey Communications Based Train Management to run on the Trans-Hudson River Commuter Rail Line underground between New Jersey and New York City; and the North American Joint Positive Train Control Project (NAJPTC) that was field-tested in Illinois between Springfield and Braidwood (south of Joliet) [2]. NAJPTC is a joint development effort between the Association of American Railroads, Federal Railroad Administration, Illinois Department of Transportation, Amtrak, and several companies, including Wabtec, Lockheed Martin and the Union Pacific Railroad [3]. NAJPTC was successfully fieldtested between 1998 to 2006. Besides preventing collisions, NAJPTC included features to prevent trains from going too fast for the section of track they are on; allow locomotives to remotely change track switches; and monitor train locations and movements. In 2006, the NAJPTC field tests were concluded and it was decided that further development was needed before the revenue-service PTC system was ready for deployment [4]. Protocol development and testing is ongoing at the Transportation Technology Center in Pueblo, Colorado. Of the 11 competing PTC development efforts, the NAJPTC project was chosen for this simulation because (a) it is based on the existing and widely used ATCS protocol, (b) the protocol specification is public and open for study, (c) the field test data is large enough to make interesting and meaningful simulations, and (d) the project is a collaboration involving several government agencies, rail providers, and private industries. In an earlier paper, we described how the NS-2 network simulation system was adapted to model the Advanced Train Control System (ATCS) protocol [5]. As a continuation of that work, we adapted our ATCS models to simulate NAJPTC operating in 3-D space using track routing data from Google Earth (earth.google.com) and elevation data from the US Geological Survey (USGS) [6]. As ATCS is the core communication technology of NAJPTC, we expanded our simulations to model NAJPTC over 3-D space, as represented by Google Earth (for track routing) and the US Geological Survey (USGS, for elevation data). This paper describes those simulations. In the next section, we review ATCS because that background information is necessary to understand the NS-2 simulation of NAJPTC. We then describe modeling NAJPTC, using data from Google Earth and USGS, and the problems of signal propagation delay. After that we present our simulation results showing the data for signal strength, packet collisions, performance, and optimization.
1 (2008) 29–36
Fig. 1 – Sample ATCS network.
2.
ATCS
The rail industry uses many communication protocols specific to the industry [7]. NAJPTC is based on the ATCS protocol, which is quite popular and covers several thousand miles of track [8,9]. The ATCS standard is open, and allows different manufacturers to create inter-operable rail communications equipment [10]. The specification is documented in several volumes, each of which is given a numeric label [11]. Each of these specification volumes covers a different logical grouping of ATCS functionality. For instance, ATCS Specification 250 covers message formats, while ATCS Specification 130 covers standards for software quality assurance. There are 25 different volumes in the specification. ATCS defines three main types of network nodes: Cluster Controller/Front End Processor (CC/FEP), Base Control Packages (BCPs), and Mobile Communication Packages (MCPs). At the center of the network communications is the CC/FEP device(s) controlled by the rail dispatcher. The CC/FEP knows the status of all the networked equipment. Any commands to change switches or signals can be given to the CC/FEP, and it will route the command to the appropriate distributed device. The CC/FEP communicates through wired data lines to several base stations called BCPs. The BCPs retransmit information between the CC/FEP and the MCPs, wirelessly creating the last link in the ATCS communications network. Sending and receiving the wireless signals are the MCP devices mounted on locomotives for communications as they travel along the track. The MCPs control signals, switches, and sensors. Data is also transmitted from MCP to BCP and back to the CC/FEP to complete the sensor/control network. Fig. 1 shows a sample network with all three types of nodes. The trucking industry also uses wireless communications via satellite. But there are several differences in their use that makes rail very different from the trucking industry. Satellite communications usually cost money for each byte transmitted. Since the rail industry has many constant streams of data for sending status on signals, switches, bearing wear, and other items, the satellite costs would be
I N T E R N AT I O N A L J O U R N A L O F C R I T I C A L I N F R A S T R U C T U R E P R O T E C T I O N
1 (2008) 29–36
31
Fig. 2 – Google earth image overlain with BCP and MCP nodes.
more expensive than maintaining UHF data radios. Track side sensors have also been found more reliable than maintaining GPS equipment on each rail car. Plus, the trucking industry is not yet at the stage of creating a system that actively prevents collisions with other trucks.
2.1.
Modeling NAJPTC
While the NAJPTC project was being planned and executed, there was no way to run a simulation of the ATCS traffic. Creating a virtual network before the actual deployment of NAJPTC would have given engineers a better idea of what to expect. Simulations also make it easy to create a week’s worth of sample data in only a few minutes. The effects of conditions, such as a lost transmitter station, can be predicted easily and safely, using a simulation environment. Several tools exist to model the behavior of other networking protocols, such as TCP/IP. One of these tools is named Network Simulator 2 (NS-2). NS-2 is a discrete event simulator [12]. It has support for many common networking protocols, although ATCS is not one of them. For this research, code was written to plug into NS2 that allows it to model ATCS networks. This new code supports ATCS at all layers of the OSI model. Code was also added to support two new propagation models, import digital elevation maps, and create propagation maps. More details about adding ATCS support to NS-2 are available [5,13].
The NAJPTC field test used a total of 156 MCPs and 9 BCPs along 195 km (120 miles) of track. The location for each BCP and MCP was obtained as a milepost location. With some work, these milepost locations were turned into latitude and longitude coordinates. In order to verify the accuracy of these coordinates, they needed to be checked against a map. Google Earth is a program that allows the user to view detailed satellite photo maps for any location on Earth. It also has the ability to import and export map locations in XML format. A Perl script was written that converted the MCP and BCP locations into Google Earth XML format. Once loaded into Google Earth, the data could be checked for quality. Where high-resolution satellite photos were available, the actual wayside station could be seen in the image. The initial coordinates we obtained appeared to be accurate to about 50 m. Most of the error came from the fact that the coordinates only listed how far along the track the wayside station was. The actual wayside station would be set off to the side of the track. For locations where high-resolution imagery was available, the coordinates were adjusted to their exact location according to the satellite photo. Fig. 2 shows an image from Google Earth that lists some of the MCPs and BCPs. The simulations also assumed one MCP was mounted to a locomotive traveling along the track at 50 kph (31 mph).
32 3.
I N T E R N AT I O N A L J O U R N A L O F C R I T I C A L I N F R A S T R U C T U R E P R O T E C T I O N
1 (2008) 29–36
Propagation modeling
The ATCS NS-2 model has the ability to calculate signal loss in two different ways. The first is Free-Space Loss [5]. This method assumes stations are on a flat plane with no obstructions between them. This method of calculating signal loss can be done quickly on the computer, and does not require the user to specify any information about the terrain. This method is a good choice when trying out a new model, or doing a simulation where accurate propagation estimates are not needed. The second method of signal loss calculation is Longley–Rice. This method offers increased accuracy, in exchange for longer calculation times. Longley–Rice improves the propagation estimate by taking into account the terrain elevation between the transmitter and receiver. Longley–Rice was first published in 1967 [14,15]. A Fortran implementation of the algorithm accompanied that paper. The Fortran algorithm was translated to Microsoft-specific C code by the US Department of Commerce [16]. An amateur radio enthusiast, John Magliacane, updated the code for use in a Unix environment [17]. Magliacane’s code also loaded and used Digital Elevation Models (DEMs) published by the United States Geological Survey (USGS). Another nice feature of the code was that the user could create propagation maps. These maps showed how the signals spread out. Magliacane’s code is distributed under the GNU Public License. For this research, we took Magliacane’s code and updated it to C++. It was then interfaced to TCL and NS-2. Signal loss can now be calculated in NS-2 using Longley–Rice. Users can download detailed, free Digital Elevation Models from the United States Geological Survey [6]. Each file represents a one degree by one degree section of land. There is approximately one datapoint every 65 feet. Once pointed to the directory where they are stored, the correct maps are automatically loaded by the ATCS NS-2 model. In addition to calculating signal loss for packet transmission, the user can generate “splat” maps. These maps show propagation-loss or line-of-sight for wireless transmitters that a user has in his or her simulation. Fig. 3 shows an example of a line of sight map for two of the NAJPTC base stations. All the colored areas in the map have line-of-sight to one of the ten meter tall transmitter towers. The rail industry has successfully used Longley–Rice for an estimate of signal strength when planning radio networks. While propagation of radio waves involves many variables, this technique provides a close enough approximation to actual results, that the rail industry continues to find it useful.
4.
NAJPTC simulation results
4.1.
Modeling signal strength
Running the ATCS simulation produces a comma delimited file with information about packets at different nodes and different OSI layers. Included in the packet data is received signal strength. A simulation generates a large amount of data, but it can easily be filtered. For the next few graphs, the data has been filtered to only look at packets for an MCP located on a locomotive traveling down the NAJPTC rail line.
Fig. 3 – NAJPTC line of sight map.
Fig. 4 – BCP signal received by southbound locomotive MCP (free-space).
The signal strength received by an MCP on a locomotive traveling along the NAJPTC rail line is shown in Figs. 4 and 5. Fig. 4 is done with the free-space propagation, and Fig. 5 is done with Longley–Rice. Fig. 6 is also calculated using Longley–Rice and shows the signal going in the other direction, from the MCP to the various BCPs along the path. The spikes in the signal strength shown in figures happen when the locomotive is closest to one of the base stations. Note that there are also increases in strength between the spikes, such as those at 1800 and 4100 s. These jumps come from when the cluster controller changes the routing to a base station closer to the locomotive. Another interesting item, as the train travels down the line, the routing algorithm can be resistant to changing the BCP. This can be seen in Fig. 4. Note the sharp jump around 8000 s. The routing algorithm keeps a running average of signal strengths. The more signal strength readings the algorithm keeps, the larger these jumps will be. If no running average is used, the routing algorithm will unnecessarily change the routing due to random signal fluctuations or
I N T E R N AT I O N A L J O U R N A L O F C R I T I C A L I N F R A S T R U C T U R E P R O T E C T I O N
1 (2008) 29–36
33
Fig. 7 – Average MCP retransmissions for each MCP. Fig. 5 – BCP signal received by southbound locomotive MCP (Longley–Rice).
Fig. 8 – BCP packet counts with North Lincoln BCP failure. Fig. 6 – MCP signal received by BCPs from southbound locomotive (Longley–Rice).
minor effects of the terrain. In the simulation it is easy to change the routing algorithm and see the results. For the NAJPTC project, keeping only the last three signal strength readings seemed to work well.
4.2.
Modeling packet collisions
ATCS networks are part of a real-time system. Data must arrive in a timely fashion. If a high percent of packets collide, it will increase the average delivery time. Using the simulation environment we created, the user can predict where in the network packet collisions will happen. The histogram in Fig. 7 shows the number of times each MCP in our simulation needed to retransmit information during a one hour interval. To reduce random fluctuations, five simulations were run and the data was averaged. Each bar represents one MCP, with the northern-most MCP on the left side. As shown in Fig. 7, the MCPs closest to a BCP are least likely to retransmit packets, because their signal is stronger than MCPs that are further away. The MCP communications with the highest retransmissions (i.e., the tallest bars) are therefore more likely to experience data delivery delays.
The model user can quickly run several simulations to experiment with different BCP placements by repositioning the BCP coordinates and then re-running a master script to automatically update graph shown in Fig. 7. This type of adhoc network configuration experimentation shows the power and utility of the NS-2’s NAJPTC model. Via experimentation, we found that the actual placement of the BCPs in the NAJPTC field tests was good, but not optimal. That is, almost any ad hoc adjustment made to the original BCP positions resulted in an increase of packet collisions. However, a user can use the ATCS NS-2 model to automatically find optimal BCP placement and survivable placement for BCPs under failure scenarios, both of which are as described later in this section.
4.3.
Modeling BCP loss
In addition to seeing the behavior of a fully functional network, it is important to see how the network performs when a component fails. If a BCP fails, the network as a whole needs to continue working. The front end scripts for the NS-2 ATCS simulator can iterate through and run simulations with each of BCPs disabled. Fig. 8 shows data from a simulation of the NAJPTC network. The histogram represents a count of the packets
34
I N T E R N AT I O N A L J O U R N A L O F C R I T I C A L I N F R A S T R U C T U R E P R O T E C T I O N
1 (2008) 29–36
Table 1 – 5-W network performance with BCPs disabled
transmitted by the BCPs over a 1500 s interval. Each pair of bars represents the data received by an individual BCP. The bar on the left side of the pair shows the packet count for a simulation run when all BCPs were functioning. The hatched bar on the right shows packet count if the BCP at North Lincoln is taken off-line. As can be seen from the graph, the neighboring Elkhart and McLean BCPs pick up the traffic that the North Lincoln BCP was handling before. The other nodes are unaffected. Fig. 9 shows what happens in our simulation to packet collision frequency when the BCP in Dwight, Illinois disabled. When comparing Fig. 7 to Fig. 9, we can see there is a significant increase in packet retransmissions with the loss of that BCP.
Network performance with BCP loss
The user can get a quick idea of network performance in a simulation, by calculating the ratio of packets sent for the first time, verses the total of all packets. The total would include packets that are being retransmitted. This ratio is represented by R and calculated in Eq. (1). T represents the total packets transmitted, and F represents count of retransmissions. R=
T−F . T
Network performance
None Springfield Lexington Elkhart North Lincoln McLean Wilmington Bloomington Ocoya Dwight
0.9632 0.9620 0.9597 0.9587 0.9574 0.9549 0.9542 0.9484 0.9463 0.9265
Table 2 – 2-W network performance with BCPs disabled
Fig. 9 – MCP retransmissions with Dwight BCP failure.
4.4.
BCP disabled
(1)
Table 1 shows the ratio of successfully transmitted packets with a fully functional network, and also the performance if one of the BCPs were disabled. From this data it can be seen that the Dwight BCP is the most critical BCP for network performance. But even if that node is lost, the network still performs well. We can easily simulate what would happen if the output power of the BCPs were reduced from 5 W to 2 W. Table 2 shows the same network as before, but the MCPs are only transmitting 2 W. Network performance when all the BCPs are working does not change significantly. But the performance numbers do change quite a bit when we disable some of the BCPs. This is because some MCPs are no longer in range of a BCP, and will attempt to send packets over and over before giving up. The simulation environment can be used to compare BCP layouts, according to the number of dropped packets and
BCP disabled
Network performance
None Springfield North Lincoln Elkhart McLean Lexington Ocoya Wilmington Bloomington Dwight
0.9624 0.9583 0.9561 0.9558 0.9530 0.9523 0.9391 0.9145 0.7976 0.2254
packet retries when individual BCP nodes are taken out. This helps the user to find a good network layout that continues to work well if a base station is off-line. Using the network performance equation above, we can find how essential each BCP station is to the network’s health. As shown in an earlier paper [5], collisions can be reduced drastically, by setting the BCPs to always transmit busy-bit information. This does not work for the NAJPTC network. Each BCP transmits on the same frequency. Some MCPs are equidistant from two BCPs. This works when the BCPs are not transmitting at the same time. But if they are, then the MCP will register a collision. With BCPs only transmitting occasionally, there is rarely a collision for an MCP. But if the BCP transmits busy-bit information all the time, then the MCPs in the middle are constantly hearing both BCP stations and can’t successfully receive data.
4.5.
Optimization of BCP placement
While ad-hoc improvement might be difficult, we have created an algorithm to automatically improve BCP placement. To do this with NAJPTC, we started with the nine pairs of coordinates that specify the original locations of the base stations. By creating a “score”, we can run an optimization algorithm to improve the score, based on moving the base stations. In Table 3, we show two sets of throughput values. One is the original throughput, based on the actual NAJPTC station locations. These throughput values are the same numbers shown in Table 1. The second set of numbers shows the results of a simulated system where our algorithm methodically tries other BCP locations to come up with improved placements. Throughput numbers, along with the change, are rounded to three decimal places.
I N T E R N AT I O N A L J O U R N A L O F C R I T I C A L I N F R A S T R U C T U R E P R O T E C T I O N
1 (2008) 29–36
35
Table 3 – Network performance of actual vs. optimized BCP placement BCP Disabled
Original performance
Optimized performance
Change
None Springfield Elkhart North Lincoln McLean Bloomington Lexington Ocoya Wilmington Dwight
0.963 0.962 0.959 0.957 0.955 0.948 0.960 0.946 0.954 0.927
0.967 0.964 0.967 0.965 0.961 0.963 0.960 0.953 0.953 0.955
0.003 0.002 0.008 0.008 0.006 0.014 0.000 0.006 −0.001 0.028
5.
Fig. 10 – Distance train travels from initial status message, to when it receives a response message.
By looking at the change between the original and the optimized setup, we can see how much improvement was made to the network. If the Dwight or Bloomington stations are lost, the network will be it better shape with the improved BCP placements compared to the original ones. All but one of the other stations showed improvement as well.
4.6.
Simulations with high-speed trains
One of the problems encountered in the NAJPTC trial was that ATCS did not work as well for high-speed trains as it did for slower trains. High speed trains can also be simulated with the NS-2 ATCS environment. In Fig. 10 we can see the results of a simulation that shows how far a train moves from the time it sends out a status message, to the time it receives a command from the dispatcher office. In Fig. 10 each bar represents a command/response cycle that occurs every minute in the simulation. The wayside devices are also sending out status messages causing the packet times to vary. From the graph, it can be seen that one message does not get received until the train travels nearly 1600 feet, because of several collisions with the initial packets. Five messages are never received due to a combination of packet collisions, and the train traveling out of radio range too quickly. These are represented by the missing bars.
Conclusion
The ATCS NS-2 simulator allows users to create network scenarios for detailed or ad-hoc network tests. Network scenarios can be created via a script, or created by using Google Earth. Anyone familiar with the NS-2 framework should be able to simulate ATCS networks. Users are not limited in how results from the simulation data can be summarized. The output of the simulator is in the form of raw packet dumps and logs of messages passed between nodes and OSI layers. This allows the user to summarize the data anyway that is needed, using whatever tools are appropriate. Examples in this paper were prepared with software programs Perl, Bash, and Gnuplot. In this paper, we have shown the ATCS NS-2 simulator modeling data communications for the NAJPTC project. The simulator can be used to quickly predict if a network can survive failures of BCP nodes, and to what the effects of those failures would be. It can also be used as part of an automated process to find improved BCP placement. The use of this network simulator in planning PTC setups can help engineers see how network traffic will occur on networks before they are actually built. REFERENCES
[1] American Association of Railways, Class I railroad statistics, November 2006. URL www.aar.org/PubCommon/Documents/ AboutTheIndustry/Statistics.pdf. [2] Federal Railroad Administration, Positive train control overview, November 2007. URL www.fra.dot.gov/us/content/ 1265. [3] T. Tse, IDOT PTC, National Transportation Safety Board, 2005. URL www.ntsb.gov/events/symp_ptc/presentations/06_ Tse.pdf. [4] Federal Railroad Administration, North American Joint PTC (NAJPTC), January 2007. URL www.fra.dot.gov/us/content/605. [5] P.V. Craven, P. Oman, Modeling ATCS networks using NS-2, in: Critical Infrastructure Protection, International Federation for Information Processing, Springer, 2008. [6] United States Geological Survey, 1:250,000-scale Digital Elevation Models (DEM), 2007. URL http://edcftp.cr.usgs.gov/ pub/data/DEM/250/. [7] P.V. Craven, A brief look at railroad communication vulnerabilities, in: Intelligent Transportation Systems Conference 2004, vol. 5, IEEE, 2004, pp. 245–249. [8] Norfolk Southern Corp, Form 10-K for Norfolk Southern Corp for the fiscal year ending December 31, 2003 (2004).
36
I N T E R N AT I O N A L J O U R N A L O F C R I T I C A L I N F R A S T R U C T U R E P R O T E C T I O N
[9] D.R. Williams, B.R. Metzger, G.M. Richardson, Spec 200 radio code line ducting—cause and effect, in: 2001 AREMA Conference Proceedings, 2001. [10] P.V. Craven, S. Craven, Security of ATCS wireless railway communications, in: Proceedings of JRC2005, 2005 Joint Rail Conference, vol. 5, 2005, pp. 227–238. [11] American Association of Railways, System Architecture, ATCS Specification 100, Revision 4.0, May 1995. [12] K. Fall, K. Varadhan, The ns manual, 2007. URL www.isi.edu/ nsnam/ns/doc/ns_doc.pdf. [13] P.V. Craven, Architecture of an ATCS network simulator, in: Proceedings of the 2008 IEEE International Conference on Electro/Information Technology, 2008.
1 (2008) 29–36
[14] P.L. Rice, A.G. Longley, K.A. Norton, A.P. Barsis, Transmission loss prediction for tropospheric communication circuits, in: NBS Tech. Note 101, 1967. [15] A.G. Longley, P.L. Rice, Prediction of tropospheric radio transmission loss over irregular terrain: A computer method, in: Environmental Science Services Admin. Technical Report ERL 79-ITS 67, Institute for Telecommunications Sciences, 1968. [16] US Department of Commerce NTIA/ITS, C++ code for Longley–Rice propagation, 2007. URL http://flattop.its. bldrdoc.gov/itm.html. [17] J. Magliacane, Splat! A terrestrial RF path analysis application for linux/unix, 2007. URL www.qsl.net/kd2bd/splat.html.