ECE492Page 1 of 31
Communications Interoperability
Device (CID)
Executive Summary
Senior Design II 2006
LafayetteCollege
Date: May 12, 2006
Team Members
John Bayard
Scott Curry
Amanda Driscoll
Laura Fredley
David Glasser
Sherisse Hatcher
Tricia Indoe
Edward Kimotho
Hugh King
Marc London
Zach Silverman
Danielle Wyckoff
Yang Feng Zheng
Table of Contents
1Background
1.1Communication Interoperability
1.2Communication Technologies
1.3Communication Protocols
1.4Alternative Solutions
1.4.1Single Radio Systems:
1.4.2Software Defined Radios (SDR):
1.4.3Common Gateway:
1.4.4Internet Protocol
2CID Design Project
2.1Project Overview
2.1.1Statement of Work
2.1.2System Requirements
2.2Our Solution
2.2.1Interface
2.2.2Hub
2.2.3Configuration User Interface
2.2.4Power
2.3Design Constraints
2.3.1Manufacturability
2.3.2Sustainability
2.3.3Safety
2.3.4Timing Constraints
2.3.5Economic Constraints
2.3.6Ergonomic Constraints
2.3.7Ecological or Environmental Constraints
2.3.8Aesthetic Constraints
2.3.9Legal and Ethical Constraints
2.3.10Political Constraints
2.3.11Quality Constraints
2.4Project Management
2.5Design Process Flow
2.6Budget
2.6.1Labor
2.6.1.1Entry-Level Engineer Labor
2.6.1.2Upper Management
2.6.1.3Shop Resources
2.6.2Labor Costs
2.6.3Material Costs
2.6.3.1Board Costs
2.6.3.2Other Costs
2.6.4How much should we charge?
2.7Future Improvements
2.8Lessons Learned/Conclusion
Table of Figures
Figure 1: Generic Audio Baseband Switch
Figure 2: Communication Interoperability Device (CID) Solution
Figure 3: Communication Systems in a Typical Metropolitan City
Figure 4: Simplex
Figure 5: Half Duplex
Figure 6: Full Duplex
Figure 7: Common Gateway Approach
Figure 8: Line Replaceable Unit Diagram
Figure 9 – Weekly Breakdown of Student Labor
Figure 10 – Student Labor Projected Hours vs. Actual Hours
Figure 11 – Student Labor vs. System Block
Figure 12 – Labor Costs
Figure 13 – Interface Board Cost
Figure 14 – Power Board Cost
Figure 15 – Hub Board Cost
Figure 16 – Total CID Equipment Cost
Figure 17 – Price Needed to Sell CID to Break Even
1Background
1.1Communication Interoperability
The difficulty of intercommunication among first responders has been brought into the public eye recently due to tragedies such as the terrorist attacks on the WorldTradeCenter and the Pentagon and disaster efforts such as those following Hurricane Katrina. Law enforcement, fire departments, emergency medical services, along with other groups and agencies, often need to communicate with each other in the event of an emergency as well as in daily operations. The communication devices these agencies use are not normally compatible with other agencies' equipment because the devices use different technologies and operate at different frequencies. This is referred to as the problem of communication interoperability. Technological advancements in communication devices such as Voice over IP (VoIP) and cell phones have exacerbated the problem of interoperability.
There are many ways to approach solving the interoperability problem including swapping or sharing radios across agencies, establishing a common frequency or protocol for transmissions, and creating an interface between radio systems. The system developed for this project is called Communication Interoperability Device (CID), and was designed using an interface approach (Figure 1) where a transmission from one communication device is received and rebroadcast to other communication devices.
Figure 1: Generic Audio Baseband Switch (from Guide to Radio Communications Interoperability Strategies and Products, AGILE Report No. TE-02-02,
NR/rdonlyres/8F919F4D-B077-4338-876D-98F440C90606/0/Guide_Radio_Comm_Strategy_ and_Products.pdf)
The goal of the project CID is to build an inexpensive prototype system that provides communication interoperability between a minimum of eight voice communication technologies (Figure 2). The system supports wireless and wire line communication technologies. Protocols of the communication technologies are full duplex, half duplex or simplex. The system has a battery backup to keep the system running in the case of a power outage. It is enclosed in an equipment rack and is upgradeable to support new voice technologies provided that an audio baseband signal can be obtained. The system allows for user defined talk groups with up to one priority communication device within each group, which is specified through a graphical user interface on a PC. The system receives an audio baseband signal from a communication device, conditions and digitizes the signal, and then routes it to the communication devices in the user defined talk group.
Figure 2: Communication Interoperability Device (CID) Solution
The following includes background information that aided in the development of our system. This background covers communication technologies, communication protocols, and possible technical approaches that guided us towards our solution.
1.2Communication Technologies
The purpose of CID is to allow many different technologies to communicate with one another. A problem with today’s technology is that many different communication interfaces can not communicate with each other. For example, when emergencies occur, fireman, police and other emergency departments cannot communicate with one another because their handheld radios are not compatible. Our system allows radios operating at different frequencies, telephone, cell phone and Voice over IP (VoIP) to communicate with each other.
Different types of radio communications operate at different frequencies. The two basic types that CID is accommodating are radios that operate at Very High Frequencies (VHF) and radios that operate at Ultra High Frequencies (UHF). VHF frequencies range from 30 MHz to 300MHz. UHF frequencies range from 300MHz to 3.0GHz. There are different channels on these radios, which allow users to only communicate with other users on their channel. Radios that are not operating on the same channel cannot communicate with one another even if they are both using UHF or VHF operating frequencies.
The National Telecommunication and Information Administration (NTIA) and the Federal Communications Commission (FCC) are responsible for allocating frequency space for different purposes. Some radio frequencies require a license, and many of these licensed bands are reserved for use by public safety services such as fire and police departments. Other licensed radio frequencies can also be used for personal purposes such as the General Mobile Radio Service, which is available for communication among a family for recreational activities such as hiking. Only users who have a license can transmit over licensed frequencies, but anyone can listen in on licensed frequencies. Unlicensed radio is generally classified by Citizens Band (CB). CB is an example of a two way voice communication radio service that can be used by the general public for personal or business activities.
Fire departments and police departments across the country use multiple types of communication. Some use full duplex, some use half duplex and some use simplex, which will be described in the Communication Protocols section. They also use different frequencies for their communications. The common frequencies are UHF, VHF, 800MHz, 900MHz, and 700MHz. The actual frequency that a fire company uses depends on which frequencies are available in their area and which one(s) fulfill the needs of their existing communication technologies. In Figure 3 you can see which services typically use which frequencies in a given geographic area.
Figure 3: Communication Systems in a TypicalMetropolitanCity (from
1.3Communication Protocols
There are three types of communication protocols, simplex, half duplex, and full duplex.
Simplex allows communication in one direction only. As shown in Figure 4, communication device A is sending audio to communication device B. A can only transmit and B can only receive. There is not any traffic management here because there is only one sender and multiple receivers lacking the ability to transmit.
Figure 4: Simplex
Half duplex allows communication in either direction, but only one way at a time. Figure 5 shows two different cases. In the top case communication device A is transmitting to communication device B. While A is transmitting it can not receive. While B is receiving it can not be transmitting. The reverse is true for the bottom case.
Figure 5: Half Duplex
In half duplex users must take turns talking. To talk a user presses down a pushbutton putting the device into transmit mode. When this happens the user can no longer receive incoming traffic. When they are done talking they release the pushbutton putting the device back into receive mode. This can cause problems if multiple people start talking at once. However, most emergency service professionals are accustomed to the shortcomings of half duplex technology.
Full duplex allows communication in both directions simultaneously. In Figure 6 Communication Device A can transmit to Communication Device B. At the same time B can transmit to A. Both devices receive all of the time.
Figure 6: Full Duplex
Full duplex can use a pushbutton to enable transmission, but it is also works without a pushbutton with devices such as the telephone. Even though multiple users can talk at the same time, they must manage their conversation so as not to talk over each other.
Full Duplex communication is accomplished with Frequency Division Multiple Access (FDMA). This allows many users to share the spectrum by dividing it up into different frequency bands. Each band is broken up into subdivisions each with its own carrier frequency. A control mechanism is used to ensure that two stations don’t transmit in the same subdivision at the same time.
1.4Alternative Solutions
In design there are various solutions to a problem. An engineering solution must meet numerous guidelines including technical, budget, time, etc.. Budget and time constraints must also be considered when designing solutions that will meet the needs of a client. Briefly, these respective constraints were a budget of $3,000 and a timeline of semester. This section provides an overview of general industry solutions to the interoperability problem.
1.4.1Single Radio Systems:
Perhaps the most obvious solution to interoperable communication is to simply have single radio systems. This would allow any party to communicate with another party in any given scenario. The problem is the cost and overhaul that would have to take place to make this solution possible. Across the nation, a myriad of parties ranging from public safety officers at a college to FBI agents would have to have this common device on hand to make it a plausible solution in any given situation. Cost is a large issue, not to mention that security issues could arise. Third party members with a model of the common device could easily pick up sensitive information. Finally, a single protocol could lead to interference issues,and multiple access in a single system would have capacity limitations.
1.4.2Software Defined Radios (SDR):
Another possible solution to interoperable communication is to have software defined radios. The software can control what bandwidths and modulation techniques are used to communicate in a given situation. This allow for devices to dynamically adapt to desired communication protocols. This gives the effect of single radio systems, but with the ability to select which devices to configure together.
Due to the nature of software development this solution is beneficial in that most of the coding can be done in Object Oriented Languages using well developed Software Development Kits. Furthermore, there are also many open source projects that focus on Software Defined Radios. One such project is GNU radio, which is maintained at Projects like this offer easy to access help and discussion forums available online. Finally, due to its open source nature, most code and tools that can be used for SDR are available for free. Of course there are also professional solutions in this field.
A disadvantage of the Software Defined Radio solution is associated with the hardware. Most of the communication technology is implemented directly on the computers where the software is developed. The computer is then interfaced to external transceivers and antennas. Alternatives to using typical computers are DSP chips and FPGAs. While this allows for a more portable design it comes at the cost of having to implement software into embedded systems. This can make the interoperable device more proprietary due to the nature of embedded systems.
1.4.3Common Gateway:
The concept of usingcommon gateways is to solve the interoperable communication problem by translating all incoming data from any source, into some nominal form which can be manipulated, routed, and rebroadcast. This sort of approach allows for a sense of abstraction between the routing or “interoperability” of communication, and the actual proprietary communication devices that must be integrated (Figure 7).
Figure 7: Common Gateway Approach
Data is received by the interoperable device in a common form. There are various formats that the central data can take on. Most notably would be base band audio or perhaps the conversion of base band audio into digital form. From this the audio can simply be routed onward to intended external microphones and broadcasted onward to intended devices by using simple routing mechanisms such as multiplexers, bridges, or switches.
Downfalls to this approach are that devices must have the ability to take in external audio sources; this limits the robustness and technology that can interface with the interoperability solution. Another major concern to central gateways is their scalability and integration into other similar networks. Adding more devices into a system may be unachievable with such limiting hardware as FPGAs and other embedded solutions, since they can only maintain so much input and output.
A resolution to the issue of scalability could be to scale up the central data form into a more sophisticated protocol. One that presently stands at the forefront of interoperability solutions is IP or Internet Protocol packets. Various companies currently are trying to use IP technology to seamlessly integrate various communication devices across the Internet.
1.4.4Internet Protocol
Using IP has benefits over other alternative solutions. Once in IP form, data that originated from proprietary communication devices can now be encrypted, routed, multi-broadcasted, translated into other media forms (text to speech), and simply sent around the world with technology that is already available at low costs. Of course, just as any other means of data transmission, using the Internet is vulnerable to crashing. If this occurred the interoperable communication system would be rendered useless.
2CID Design Project
2.1Project Overview
Design projects, including the Communication Interoperability Device, follow a process starting from a set of requirements and a brief statement of work. The statement of work and requirements appear in the sections 2.1.1 and 2.1.2. An architecture and design was engineered to meet these requirements. The system was designed to meet these requirements. The remainder of this document describes the top level architecture of the system resulting from a semester of engineering as well as a description of how the project was managed. Lessons learned and future improvements follow in sections 2.7 and 2.8.
2.1.1Statement of Work
OVERVIEW
We have been contracted to design and deploy a prototype system providing interoperability of multiple voice communications systems. This environment shall reliably support both wireless and wireline communications systems [including internet based voice communication systems]. Technical requirements are contained in the Systems Requirements Document.
DEPLOYMENT
The prototype system shall be deployed on the LafayetteCollege campus in Easton, PA. Representative wired and wireless communication systems shall be provided by the contracting office [GFE]. An engineering study shall be performed [with direction and assistance from user consultants] to select appropriate equipment configurations and operational scenarios for the demonstration.
BUDGET
Materials costs for the prototype configuration shall be limited to $3,000.
ENGINEERING RESOURCES
Thirteen [13] eager entry level engineers shall comprise the engineering team.
TECHNICAL RESOURCES
The Lafayette College Engineering Division shops shall be the primary technical resource for prototype fabrication. External contract fabrication facilities may be utilized when necessary.
STANDARDS
All engineering shall be performed under best engineering practices. All documentation shall be provided in electronic form and under configuration management.
SCHEDULE
The design and deployment of the system shall be performed between January 23, 2006 and May 08, 2006. Initial circuit board artwork is due to the shop by March 10, 2006.
DELIVERABLES
At the end contract period the team shall provide a detailed technical report, all documentation required for manufacturing, test reports, project web site, and a demonstrable prototype system.
2.1.2System Requirements
R000 - Dynamic voice interoperability system shall provide highly available configurable voice interconnectivity [talk groups] between multiple technology systems.
R001 - Both wireless and wireline [including internet-based schemes] voice communication technologies shall be supported.
R002 - Suitable technology interfaces [CSE] shall be supported providing appropriate signal levels, control and equipment protection.
R003 - A minimum of eight [8] technology interfaces shall be supported in a system.
R004 - Full duplex, half duplex and simplex voice communication technologies shall be supported.
R005 - Talk groups shall support a two [2] level priority scheme.
R006 - A single battery backed external voltage source [TBD] shall power each system.
R007 - The target operational environment shall be an equipment rack in a telephony equipment shelter [MIL or TIAA specification TBD].
R008 - Each system shall support fault localization to the line-replaceable unit [LRU] level.
R009 - An error reporting mechanism shall be implemented.
R010 - The design of the system shall be manufacturable.
R011 - The design and deployment shall be such that the system safely interacts with its environment, users and equipment installers/maintainers.
R012 - The system shall be sustainable to the extent of new voice technology insertion at the system level.
The system was designed to meet these System Requirements.
2.2Our Solution
As in any project, numerous design choices are made in order to come to a final solution. In our solution we have decided to break up our system into functional blocks and Line Replaceable Units (LRU). Our system has four major blocks: Interface, Hub/Sanity, Configuration User Interface, and Power as shown in Figure 8: Line Replaceable Unit Diagram.