GUI thread for interaction with the public safety officer and a network monitoring control thread, which is used to maintain active connectivity levels with the data ...
Using Two-Way Datacasting to Deliver Real-Time Public Safety Information Scott A. Valcourt , Pushpa Datla , Kent Chamberlin , Benjamin McMahon †
†
‡
‡
Computer Science Department, University of New Hampshire, Durham, NH 03824, +1-603-862-4489, {Scott.Valcourt, Pushpa.Datla}@unh.edu ‡ Department of Electrical and Computer Engineering, University of New Hampshire, Durham, NH 03824, +1-603-862-3766, {Kent.Chamberlin, Benjamin.McMahon}@unh.edu †
Abstract—Datacasting involves the use of the excess bandwidth in a digital terrestrial television station’s stream to deliver broadcasted data to a variety of receivers. Initially developed as a stationary fixed technology, this project involves receiving this broadcast in a mobile environment. This one-way transmission allows the datacast receiver to decouple data packets at a rate of up to 2.5 Mbps. Utilizing these data rates, various real-time applications can play a major role in placing information in the field where the existing low-speed data transmission methods in use today cannot.
Researchers at the University of New Hampshire have already reported in various papers the successes achieved in datacasting in the mobile environment, an implementation that the original developers of datacasting had not intended. The introduction of two-way communication using multiple channels coordinated with datacasting has allowed the datacasting system to achieve real-time, asymmetric broadband communication in the mobile environment that is both cost-effective and viable for delivering critical data to the field in a timely and reliable fashion. This paper explains the technical concepts jointly engineered to deliver the two-way datacasting model, as well as highlights the results of prototype applications and devices installed in a mobile environment. Further, future challenges and enhancements of the technology are highlighted.
P
I. INTRODUCTION
ublic safety officers need current, accurate and complete information to maintain the security of their communities. Existing communications systems for public safety officers
consist of analog and digital radios supplemented with cell phone communications in many instances. Dispatchers with a need to broadcast information can only do so via voice. Small data packets can be exchanged via point-to-point methods with modern digital radios, but no data broadcast exists for public safety communications. Broadcasting images, audio and text to officers in the field will offer a better collection of information necessary to make critical, time-sensitive public safety decisions. Live updates to in-vehicle databases and computer systems will provide officers with critical, up-to-theminute information. The application of datacasting for this purpose has been reported in previous publications [1],[2],[3],[4],[5] by the authors. A more complete, two-way system subsequently has been developed where a request for data can be sent via an upload channel and delivered through the download datacast channel. This method of data request and transfer is far more efficient and reliable than a voice request for data to dispatch, which had previously been the only method of requesting up-to-date data on the datacast channel.
II. PROJECT54™ Public safety officers rely on various sources of information to satisfy the responsibility of protecting the public interest. The information available to them needs to be accurate, complete and up-to-date in order to make the most appropriate decision involving public safety. At the University of New Hampshire (UNH), a system has been developed to support communication and operations in the public safety arena called Project54™. Project54 is a collaborative research and development program at the UNH Consolidated Advanced Technologies Laboratory (CATLab). This project focuses on the incorporation of embedded mobile computing equipment and wireless networking into the patrol vehicles of the New Hampshire Department of Safety (NHDS), including State Police and Department of Motor Vehicles. Project54 systems integrate all in-car electronic devices and systems, software and user interfaces to offer advanced support for New Hampshire State Troopers [8]. Traditional police cruisers require public safety officers to control and manage many different in-vehicle systems along with the management of a myriad of external information support. With Project54, vehicle systems are able to be
controlled from a single system control head. Officers are able to communicate with Headquarters (HQ) and other officers using Association of Public Safety Communications Officials International (APCO) Project 25 digital Radio Control Protocol (RCP) communications [10]. However, this VHF digital radio channel can transmit only a very small amount of data due to both a narrow bandwidth and channel congestion. The two-way datacasting project development, testing, and implementation is based on the Project54 platform.
III. DATACASTING United States digital television (DTV) signal bandwidth is viewed as a single pipe carrying various signals within that pipe, both television programming in high definition (HDTV) or standard definition (SDTV), as well as other non-television digital data. When digital television broadcasters allocate their bandwidth to support HDTV and SDTV channels, a small amount of bandwidth remains unallocated, which is available at a near continuous rate. This available bandwidth and the delivery of non-DTV data within that bandwidth is the technology known as datacasting [9]. The term datacasting comes from the words data and broadcasting, and the technology is designed to provide a variety of digital data such as text, audio, graphics and video, with a unidirectional transmission channel from the broadcast center to remote stations. There is a significant amount of bandwidth that goes unused with every DTV broadcast, sometimes as much as 2.5 Mbps of bandwidth, even in the most miserly of broadcast signal configurations, because digital image transmissions and encoding schemes capitalize on efficient means to deliver image changes. This generally occurs when the television image does not contain a high degree of motion. The data carried in the datacast channel can be retrieved using relatively low-cost equipment within the television station’s coverage area. Data carried via the datacast channel can be encrypted and sent to targeted receivers only, or to groups of receivers, making this form of data transmission desirable for a range of commercial and government applications.
IV. DATA TRANSMISSION AND AVAILABLE COVERAGE Using the initial datacast platform developed at the University of New Hampshire, a two-way symmetric broadband system was implemented. Since cellular data coverage in the state is nearly ubiquitous, the datacast signal coverage area for this project was of interest, since it is the limiting factor in twoway datacast coverage. Data were collected repeatedly by different vehicles and under different operational conditions to generate the coverage map in Figure 1 below. As expected, the location of data points corresponds to the roadways patrolled by the cruisers, and each point plotted represents a location where the cruiser was stopped and the receiver either did (represented by a green dot) or did not
(represented by a red dot) lock to the datacast signal. As seen in Table 1, the yellow dots represent locations where the receiver locked, but had only a marginal signal-to-noise ratio. The signal-to-noise ratio values used in generating the coverage maps often come from measurements over time by a single vehicle, and/or from multiple vehicles collecting data at the same location (within the 11 meter resolution of the GPS equipment used in this study). Consequently, each dot on the map may represent the average of many individual measurements. Table 1 – Color Codes for Signal Reception Indicators Average Signalto-Noise Ratio
Color
Reception Capability
0 to +2 dB
Red
No reception – expect rare or unreliable reception
+2 to +10 dB
Yellow
Marginal reception – expect variability in reception and low data rates
+10 dB and above
Green
Good reception – expect high reliability
Figure 1 – Statewide Datacast Coverage Map for New Hampshire
V. DATACAST SOFTWARE The datacast software system is a distributed client-server environment that runs in both the data center as well as within the mobile environment. Using applications in both the Linux and Microsoft Windows operating system environments, TCP/IP network communications are utilized for maximum interoperability with public data sets.
Server Process The datacasting equipment installed in the NHPTV broadcast center consists of a variety of components working together to provide real-time information to public safety officers in the field. The broadcast center equipment communicates with the remote receivers to define the complete datacasting data path from origination to reception. To process simultaneous requests from several remote clients, we utilize a non-blocking server. The server listens for the requests directed to TCP port 5456 on the public server. The streams of data sent by the client contain key informational elements: date, time, latitude, longitude, car number and an identification field. For example, the request for a topographic map from the client will appear as a stream of data with the format “06042007,133328,43 08.2248 N,70 56.0940 W,SV001,0”. When the data arrives at the server, the stream is parsed for the car number, latitude, longitude, and identification. The identification corresponds to the three different application calls currently supported by the server (topographical maps, weather radar maps, or weather alert information). After identifying what the client has requested, the server uses public web-based resources to gather the requested information. Our present system uses Yahoo Maps [12], National Weather Service text-based products [13] and the Weather Underground radar maps [14]. The datapath and component linkages are illustrated in Figure 2. When the server prepares to extract mapping information from the web, the converted latitude and longitude values of the current client location become seed data for external requests to the public data sources. Each map request, once received, is saved in its native file format, typically GIF, with specific naming in the system based on the client requesting the data. Since the Project54 application environment requires all images to be displayed as bitmap images, all native file formats that are not already bitmaps are converted to bitmap files using the Imagemagick software [16] at the server, prior to transmission to the remote clients. When weather alert data is generated and requested from the client, state and county boundary information must be extracted from the GPS coordinates. Reverse geo-coding [15] allows the server to parse the pertinent weather alert information that is received through the National Weather Service text products specified for New Hampshire and relative to the location of the mobile client. Amongst all of the data being processed for clients, the server system logs all transactions, initially for two-way datacasting coverage and statistics in the research phase of this project, but eventually for audit tracking of requests and field operations of the mobile clients.
Figure 2 – The Functionality Outline of the Server System At present, a source file in the datacast system at the broadcast center can reside on any computer networked to the Internet. That file can be inserted into the system using the appropriate password and source recognition information, or automated using pull technology residing in the datacast system. Once a file is placed into the datacast system located at New Hampshire Public Television (NHPTV), the system packages the file to be transmitted and sends the data to the broadcast center’s IP encapsulator and multiplexer, where the file is converted into appropriately sized IP packets, weaving those packets into the MPEG2 data stream appropriate to the NHPTV-configured digital television (DTV) transmission. The DTV stream is sent to the transmitters via microwave uplinks to NHPTV’s Saddleback Mountain facility. The signals are radiated from an antenna positioned 44.9 meters above ground at a frequency of 731 MHz (Channel 57) with an effective radiated power of 589 KW. Remote datacast receivers monitor the DTV stream and extract the data transmitted over the datacast program information channel (PID), decoding the stream back into IP packets, reassembling those packets back into files and storing the files on the mobile receiving computer. Client Process The Project54 environment is developed using Microsoft Visual Studio 6.0, and our application components integrate into the Project54 Application Manager 2.0. Using a common graphical user interface (GUI) library, P54Guilib.lib, any developed application can maintain the look-and-feel of other Project54 tools available to public safety officers in New Hampshire and other jurisdictions that have adopted the Project54 environment. In this way, there is less interface learning required of the user as all applications are similar in
operation. Our datacast test application has the unique identifier in the Project54 environment tied to the common name dctest. This application runs as a dynamic linked library (DLL) to communicate with other modules in the Project54 environment, as well as maintain operations specific to the dctest application. At the startup of a typical Project54 system, the main screen visible in the Project54 environment will display a dctest button on the right-most button field as is shown in Figure 3.
to the data server and a notation of the request is made in the mobile device’s log file for audit tracking. If the connection is successful, the application waits for seventy (70) seconds for the image to be received, as the current datacast protocol will only lock on data signal reception in the absence of motion. Once the image is received, the application manager updates all of the status lights to “GREEN”, updates the image display and logs the request as successful. A successful topographic map reception is displayed in Figure 4.
Figure 3 – Project54 Environment Main Screen
Figure 4 – Mapping Application Display in Project54.
When the officer in the field selects the dctest application button, either via a touch screen device, mouse click or voice command, the application manager brings the corresponding application to the front of the stacked active windows. Two threads are continuously operating in the dctest application—a GUI thread for interaction with the public safety officer and a network monitoring control thread, which is used to maintain active connectivity levels with the data server and check for received datacast files. The application control thread sends periodic pings to the data server and reports availability status on the monitoring screen. These upstream pings are sent across the cellular modem interface, allowing researchers to determine where cellular coverage is supported for two-way datacast communication.
After a period of thirty (30) seconds, the status lights on the application turn back to the initial grey, signifying to the officer that another request may be made with the status lights signifying the new request status. In a similar set of procedures, a successful request for the current weather radar map for a given GPS location is displayed in Figure 5.
On the right side of the application screen is a set of options that the public safety officer can request, such as a topographic map, a weather radar map and a weather alert. The status lights indicate the current state of the cellular modem signal ability to reach the data server, the availability of a locked datacast signal from NHPTV, and the successful reception of the requested data from the server, which is an artifact of the dctest application not displaying received data. The user interface also displays the current latitude, longitude and velocity of the car, which is extracted from the live GPS installed in the mobile device. When the officer requests a topographic map, the dctest application reads the current data from the GPS and populates the fields in the user interface and constructs the request in the format readable by the server as described above. The small data packet is then sent upstream
Displaying the weather alert announcement in response to a request is work currently being addressed in the Project54 environment. In this application, weather alerts sent via RSS feed from the National Weather Service are parsed for state and county relevance and forwarded to mobile clients at the time of alert notification. The client application, once the alert is received, will make an audio alert announcement to the public safety officer, who will then have the option to select the weather alert application. Since the alert is entirely transmitted in text format, the officer may either remain in a stationary environment and read the alert, or the officer may choose to drive to another location while selected the “Read Alert” option in the application, which uses speech synthesis to read the text alert out loud to the officer. In either case, the officer will be notified of any pending weather conditions at the same time as the public is warned by the National Weather Service.
way coverage study were due to the poor reliability of the datacast signal in the mobile environment, not an unavailable upload channel. In fact, cellular modem coverage was available at all locations where a test was performed. Causes of a failed datacast transmission include poor propagation circumstances, constant moving of nearby vehicles causing multipath interference, and very slow data rates due to being on the threshold of reception.
Figure 5 – Weather Radar Mapping Application Display in Project54 Areas of Impact Real-time data in support of public safety often makes the difference in critical situations. Topographic map information can give public safety officers more localized physical presence data that personal memory, radio directions or paper maps cannot provide. The topographic map application places a red star in the center of the map to show the officer where the mobile vehicle is located according to the GPS coordinates. Additional information on the mapping graphic show the surrounding street information, state level information, interstate names, and other related information. Using the location mapping application, an officer can quickly record the location of an incident for report generation and processing later, when danger has passed. With the ability to see the weather radar map in advance of travel, the officer can change the intended plan of action.
VI. TWO-WAY DATACAST AND ITS COVERAGE The two-way transmission software developed by Project54 researchers utilizes datacasting as a download channel and a Verizon cellular modem as an upload channel. The field testing of this system was not as extensive as the one-way datacast coverage study [11], but gives a confirmation that the system is feasible and operational. The system was installed in a single vehicle and stopped at various locations throughout the state. A request was made via the cellular upload channel, and a Yahoo street map referenced to the GPS location of the vehicle was downloaded via the datacast channel. The results of these measurements are seen in Figure 6. A red dot represents a location where two-way communication was not available, and a green dot represents a successful two-way request and download transmission. The knowledge gained from the limited two-way coverage study is purely a proof of concept. The software was successful in the field at many locations. Because the Verizon Wireless cellular modem coverage is nearly ubiquitous in the State of New Hampshire, the failed transmissions in the two-
Figure 6 – Two-way Datacast/Cellular Coverage for Selected Locations in New Hampshire
VII. CONCLUSION AND FUTURE WORK The results of the study addressed here are that datacasting can provide a reasonably robust download channel in the mobile environment and that it can be coupled with an uplink channel to provide for a 2-way channel. The primary advantage of such a system is that it can enable large data files to be distributed to targeted receivers using in-vehicle equipment costing around $300 (datacast receiver and antenna). The current disadvantages to the current datacast system in the mobile environment are that it can receive data only when the receiver is stationary and that reception is susceptible to raininduced multipath. To address the disadvantages of the current datacast system described above, several manufacturers have developed new error-correction schemes compatible with the ATSC format. One is by Samsung, named the Advanced-Vestigial Side-Band (A-VSB) [6] and the other is by Harris Corporation named the MPH [7] approach. The additional error correction added to the data stream with these approaches will purportedly enable reception while in motion and will be immune to rain effects, albeit at a cost to the data rate. For example, a 1.5 Mb/sec data stream will only yield around 550 Kb/sec of useable data using these schemes. Once one of these approaches is implemented, a study should be performed to assess the robustness of the approach under operational conditions. Further, coupling datacasting with a variety of available uplink channels to achieve a functional two-way channel should be investigated. We contend that a more communicationsensitive environment will achieve significant gains in
multiple paths for two-way communication. However, with those multiple paths comes a need to manage those paths in a manner that does not introduce additional burden on the officer in the field or communication route collision on the overall two-way datacast environment.
ACKNOWLEDGMENTS The authors extend their appreciation to Lt. Mark Liebel and the test officers of the New Hampshire State Police for their insight and active participation during this project. In addition, appreciation goes to Brian Shepperd and Steve Chao of New Hampshire Public Television (NHPTV) for their support of this project. The authors express their deepest appreciation to Dr. Andrew Kun and the staff and students of the Consolidated Advanced Technologies Laboratory (CATLab) at UNH for their leadership and assistance.
[9] Scott A. Valcourt, “Datacasting as a Public Network Service,” in Proceedings of the First International Conference on Community Networks (COMNETS), Boston, MA, 2005. [10] Kaitlin Wilson-Remmer, “The P25Proxy Application for Remote Messaging,” Technical Report ECE.P54.2005.2. University of New Hampshire, Durham, NH. May 12, 2005. [11] Scott A. Valcourt, Kent Chamberlin, Benjamin McMahon, Andrew Kun, “Systems Engineering of Datacasting for Public Safety Vehicles,” in Proceedings of 2007 IEEE International Conference on Technologies for Homeland Security, May 2007. [12] Yahoo Maps Website, [Accessed: 05 March 2008].
http://www.maps.yahoo.com
This work was supported by the U.S. Department of Justice under Grant 2001-LT-BX-K010.
[13] National Weather Service Website, http://www.nws.noaa.gov [Accessed: 05 March 2008].
REFERENCES
[14] Weather Undergrounnd Website, http://www.wunderground.com [Accessed: 05 March 2008].
[1] Kent Chamberlin, Scott Valcourt and Benjamin McMahon, “NIJ Final Report: Evaluation of Datacasting in the Mobile Environment,” National Institute of Justice, Washington, DC, January 2007.
[15] Geocoding Website, http://geocoder.ca [Accessed: 05 March 2008].
[2] Kent Chamberlin, Andrew Kun, Scott Valcourt, and Benjamin McMahon, “Measuring Datacast Channel Characteristics for the Mobile Environment,” URSI Presentation, Ottawa, Canada, July 2007. [3] Kent Chamberlin, Scott Valcourt, Andrew Kun, and Benjamin McMahon, “Evaluation of Datacasting in the Mobile Environment,” in Proceedings of IEEE Fall VTC2007, October 2007. [4] Kent Chamberlin, Andrew Kun, Scott Valcourt, and Benjamin McMahon, “Measurement of Propagation Effects for High-Speed, Digital UHF Channels,” in Proceedings of IEEE AP-S, August 2007. [5] Kent Chamberlin, Scott Valcourt, Benjamin McMahon and Pushpa Datla. “NIJ Final Report: Evaluation of Datacasting in the Mobile Environment (Part II),” National Institute of Justice, Washington, DC, January 2008. [6] Darren Murph, “Samsung builds on ATSC, develops AVSB for mobile broadcasting,” Engadget, January 7, 2007. [7] Glen Dickson, “Mobile DTV Gets Its Road Test”, Broadcasting & Cable Magazine, November 6, 2006. [8] W. Thomas Miller, III, Andrew L. Kun and William H. Lenharth, "Consolidated Advanced Technologies for Law Enforcement Program," in Proceedings of the IEEE Intelligent Transportation Systems Conference, Washington, DC, October 3-6, 2004.
[16] Imagemagick Website, [Accessed: 05 March 2008].
http://www.imagemagick.org
