INTEGRATION OF SDR CELLULAR BASESTATIONS INTO MILITARY TELEPHONE NETWORKS

INTEGRATION OF SDR CELLULAR BASESTATIONS INTO MILITARY TELEPHONE NETWORKS Steve Muir, Jagadeesh Yedetore, Laura Stich, John Chapin Vanu, Inc. Cambridge, MA ABSTRACT The Network-In-a-Box cellular system has been used by military customers to integrate commercial cellular communications into their existing telephone networks. The combination of flexible software with COTS hardware provides a low-cost solution that supports a wide variety of network interfaces. This paper describes the integration of a Network- In-a-Box system into two different military telephone networks, and discusses some of the design and integration challenges faced. A key component of the integrated solution is the open-source PBX application. The first case study shows how can be easily used to connect the VoIP-based Network-In-a-Box system to a legacy T1 telephone network. The second case study describes how the standard Network-In-a-Box was enhanced with Type 1 secure communication capabilities in order to interconnect a GSM cellular network with a classified VoIP network. INTRODUCTION Vanu, Inc. s software-defined radio (SDR) cellular basestation has been deployed by military customers for various applications. The majority of these early deployments have been in standalone, isolated systems, where the basestation provides communications only between the cellular users associated with the standalone system. However, recent deployments have successfully integrated the system into the customer s existing network, enabling cellular users to communicate with users on the military network. This paper describes the engineering approach taken in those efforts. Cellular systems offer many advantages to military customers, including low cost and extensive feature set when compared to traditional military radios, and a high degree of user familiarity, thus reducing training costs. Most systems support data as well as voice communications, and also include short messaging services that may be useful in tactical scenarios. Newer cellular standards support data rates in the megabit-persecond range, and handsets/terminals are capable of utilizing that bandwidth to display real-time video. Finally, cellular systems incorporate a range of security measures including authentication and encryption; for classified data it is also possible to use modified handsets that include Type 1 secure capabilities. The basestation supports standard cellular protocols including GSM and CDMA 2000 for radio communications. However, unlike other cellular basestations that use specialized telephone protocols on the wireline side, uses VoIP for both internal and external voice traffic. Therefore it can be integrated more readily into military networks than other cellular basestations. There are a range of existing products that connect VoIP systems to military analog, digital TDM, and other voice networks. One that is particularly appealing is the open-source PBX, already in use in multiple military deployments. s software is freely available at no cost, can be modified by its users, and runs on COTS PC hardware. In addition, a range of low-cost hardware interface cards are available to connect to various legacy voice and data links. Integrating with provided a solution that operates in both VoIP and legacy military networks. This paper reports integration challenges and solutions for both basic network interoperability and for Type 1 secure communications. Type 1 communications were demonstrated between Sectera cellular handsets and terminals in a red VoIP enclave (unencrypted), by integrating the / system with off-theshelf security devices that support Type 1 encryption. THE ANYWAVE NETWORK-IN-A-BOX Vanu, Inc. s Network-In-a-Box (NIB) is a software-defined radio system that integrates the standard commercial basestation (BTS) and basestation controller (BSC) with a specialized mobile switching center (MSC) on a single PC server. The NIB interfaces to an external RF transceiver and power amplifer in order to provide a complete cellular basestation that can be connected to a variety of antenna solutions, as appropriate for a particular application. The NIB is capable of supporting multiple commercial cellular standards currently GSM, CDMA 2000 and iden simultaneously on a single server, and can also transmit and receive in multiple frequency bands depending upon the RF equipment Page 1 of 7

A over TCP/IP Abis over TCP/IP Basestation Controller (BSC) RF Power Amplifier Mobile Switching Center (MSC) MGCP UDP/IP Base Transceiver Subsystem (BTS) Transcoder and Rate Adaptation Unit (TRAU) RF Converter Basestation Subsystem (BSS) RTP over UDP/IP RF over GigE configuration. The interfaces between each of the main software components are IP-based, so the system can be physically separated into remote BSS and central MSC units, with wired or satellite backhaul between the two. A wide variety of satellite links have been successfully used, including GlobalStar, INMARSAT, VSAT and T-CDL. NIB systems have been tested in a number of operational scenarios. The small physical size of the hardware components means that the NIB takes up only a moderate amount of rack space; this allows the NIB to be deployed on a range of vehicles, including Humvees and various aircraft, and it can also be packaged in a portable transit case. Figure 1 shows the structure of the software components. Minor details of certain components and connections between them have been elided in order to reduce the complexity of the diagram. One important point to note is that all software components BTS, BSC, TRAU and MSC can be run on a single server, or split across multiple systems in order to suit particular network or performance requirements. Vanu s key technical innovation is the use of highlevel languages, such as C++, to implement the entire radio functionality in portable software that can be easily retargeted to different platforms; this approach is in contrast with traditional radio designs that utilize DSPs, SIP RTP RTP over UDP/IP Figure 1: Network-In-a-Box architecture FPGAs or ASICs to perform signal processing. By leveraging COTS technology, such as Intel processors and Gigabit Ethernet interconnects, the system combines high performance with low cost; furthermore, the SDR approach provides unparalleled flexibility and future upgradeability. As shown here, the NIB contains a Micro-MSC, which performs the same basic functions as a standard MSC registration, authentication, call setup and teardown but can be run on a standard PC server rather than requiring expensive telecommunications platforms. The Micro-MSC does not support the same interfaces usually used to connect an MSC to the PSTN, but instead uses the Session Initiation Protocol (SIP) to connect to other networks. The SIP stack incorporated into the Micro- MSC does not directly support the full functionality of a SIP proxy server, but rather is designed to connect the NIB to an external system that does; an example of such a system is the open-source PBX. THE ASTERISK PBX [1] is an open-source application that runs on standard PC platforms and provides a full-featured PBX system. includes support for a broad range of communication interfaces, both software and hardware: VoIP: IETF standard SIP, Cisco s proprietary Skinny Client Control Protocol (SCCP), and H.323 TDM networks (T1/E1): supports inexpensive hardware cards that provide multi-port T1/E1 interfaces. Analog PSTN interfaces: both FXS and FXO interfaces are supported using low-cost PCI cards. ISDN: an implementation of the industry standard CAPI protocol for both BRI and PRI interfaces is available. Inter- Exchange (IAX): a proprietary protocol used to efficiently connect instances of together. supports a range of voice formats and codecs, and also provides a rich set of typical PBX features, such as call waiting and forwarding, voicemail, and powerful interactive menu systems. An extensive set of integrated applications and a flexible programming model allow system administrators to create a dialplan that combines features in whatever ways are necessary for their network. communicates with the NIB using the standard SIP protocol; the NIB interface supports both calls into and out of the PBX. In the simplest integrated deployments is used as a SIP proxy server that allows cellular users to make and receive calls to/from SIP devices, but the real benefit of Page 2 of 7

Voice over RTP Military PBX T1 900 MHz 1900 MHz GSM BSS A-over-IP (SCCP-Lite) MGCP SIP MSC Figure 2: NIB integrated with legacy TDM network integration is the ability to exploit all of the other features and interfaces supported by. CASE STUDY 1: TDM NETWORK INTEGRATION The combination of the NIB with the PBX provides customers with a highly flexible system that allows commercial cellular standards to be incorporated into their existing network environment. A simple example of how the NIB was integrated into a military customer s existing network is shown in Figure 2. The customer has a standard T1 network used to provide voice service to a range of tenants on the military base, and also as communications infrastructure for training exercises. For training exercises all communications were monitored and recorded, so it was essential that the NIB could be connected into the monitoring and recording device via the voice network. For this deployment the PBX was connected to the NIB using SIP over an IP/Ethernet connection, and a T1 interface card was installed in the server. A T1 line was then connected from the customer s network to the interface, and the T1 provisioned according to the network configuration. The flexibility of allowed the customer to experiment with different T1 signaling protocols, of which there are many, to determine which was most appropriate for their network. A significant advantage of the combined / solution is cost-effectiveness: the software can be run on the same server as the NIB, so the cost of hardware is greatly reduced. The additional cost for network interfaces is also low, with the T1 interface card costing less than $1000. CASE STUDY 2: INTEGRATION WITH TYPE 1 SECURE CELLULAR HANDSETS An additional capability that is extremely valuable to military customers is the ability to leverage standard cellular handsets that have been augmented with a Type 1 encryption module, such as the General Dynamics Sectera GSM handset. These devices are intended for use in endto-end applications, where each party to a call has an encryption device. However, in most military networks the security of a classified network is provided by physical security and isolation from unclassified network elements; only when classified data must be transmitted across an insecure network is it encrypted, and thus all communication within a secure network is actually unencrypted. Therefore, in order to integrate an end-to-end device such as the Sectera GSM handset into a secure network the secure channel to/from the wireless handset must be terminated by a gateway device at the edge of the network. Unfortunately existing gateway devices were not intended to be used in such a manner, and there are a number of practical obstacles that have to be overcome in order to support Type 1 secure cellular handsets on the NIB. In order to ensure maximum compatibility with the Sectera GSM phone we selected the Sectera wireline terminal as the most appropriate encryption endpoint for integration with the NIB. Other devices that support the FNBDT/SCIP protocol could be substituted, but the Sectera wireline terminal is a safe choice. The Sectera GSM handset uses the standard GSM circuit-switched data (CSD) facility to transfer encrypted voice data over a black (non-secure) network to another secure device, such as another Sectera GSM handset or a Sectera wireline terminal. In the NIB the CSD Page 3 of 7

Clear voice Avaya PBX Encrypted voice H. 323 Clear voice RED network Sectera Wireline Terminal Encrypted voice BLACK network Encrypted voice over RTP Clear voice over RTP H. 323 Avaya PBX 900 MHz 1900 MHz A-over-IP (SCCP-Lite) SIP GSM BSS MSC MGCP Figure 3: NIB integrated with secure network packets are transported as an RTP stream with a proprietary codec type. Figure 3 shows how the NIB can be integrated into a secure military network. The black network is used for unclassified communications, while the red network is suitable for classified data up to secret level. Although the diagram shows that the integrated system is connected to both black and red networks, for COMSEC reasons the system as used in practice would only be connected to one network or the other. MODEM EMULATION The basic approach taken for integration of the Sectera wireline terminal (SWT) into the NIB is to create an channel driver that connects to the SWT and receives encrypted digital data from the SWT. This data is then converted to the appropriate format and sent over an RTP channel to the NIB. Although some of the details of our implementation are specific to the SWT, the general principles followed can be used in other applications where modem emulation is necessary. A number of different methods of physically connecting the PC server to the SWT were considered: Analog connection to the SWT modem port: the default interface used by the SWT is an analog modem that connects to a PSTN line; unfortunately, there are no devices readily available for a PC that can terminate such a connection. ISDN connection via ISDN modem: the SWT s analog modem can also be connected to an ISDN modem, which then transmits data digitally over ISDN. This approach appears promising but is actually impractical, since the ISDN modem does not terminate the analog modem channel, but rather just transmits the modem tones over an ISDN voice channel. Serial interface to the SWT: an enhanced version of the SWT is available that includes a black digital interface (BDI), typically used for connecting to a satellite phone. This proved to be the most practical interface to use, but not without problems of its own. The basic functionality of the SWT in secure voice mode can be considered as two functional blocks: an encryption device that uses a Mixed Excitation Linear Prediction (MELP) codec to generate a low bandwidth (6.4kb/s) stream of data that is subsequently encrypted; and an analog modem that takes the encrypted stream and modulates it for transmission over the PSTN. The BDI port essentially makes the stream of data between these two Page 4 of 7

PC serial port DCD Rx Tx DTR Ground DSR RTS CTS RI SWT BDI port DCD Rx Tx DTR Ground DSR RTS CTS RI Figure 4: Custom serial cable used by modem emulator modules directly available, and in fact we verified that by connecting a standard 56k modem to the BDI port we were able to interoperate with a standard analog SWT. Hence we decided that the simplest way to extract the digital data stream via the BDI port would be to emulate the functionality of a standard 56k modem. At first glance this appears to be straightforward, since the BDI is just a standard serial port, and thus should be compatible with a PC server s serial interface, but upon further consideration a number of technical problems emerged. The most significant problem is not specific to the SWT or BDI, but rather arises from the asymmetric nature of the serial interface between a modem and a terminal. A modem connects the terminal device to a public switched telephone network (PSTN), and thus must translate standard PSTN signaling into a manner compatible with the a terminal. This signaling must handle the two most common operations: Incoming call modem indicates ringing by asserting the Ring Indicator (RI) signal Call connected modem indicates that data connection to remote modem has been completed by asserting Data Carrier Detect (DCD) signal. Therefore any device that is emulating a modem must be able to transmit these two signals RI and DCD to the terminal device. Furthermore, the signals are used in such a way that they must be controlled independently i.e., they cannot both be driven by a signal output on the modem emulator. Unfortunately, a standard PC serial port only exposes two non-data signals to software applications in such a way that the application can change the state of those signals. Normally these signals Request To Send (RTS) and Data Terminal Ready (DTR) are used by the PC for flow control and readiness signaling respectively, but by reconfiguring the physical connection between the PC and SWT it is possible to attach these two softwareaccessible signals to the RI and DCD inputs on the SWT. The issue then becomes one of how to control the SWT s Clear To Send (CTS) and Data Set Ready (DSR) inputs, which are normally connected to the modem s (PC s in this case) RTS and DTR signals, since those have now been repurposed. Fortunately, the manner in which these signals are used by the SWT allows for a simple solution: the SWT always asserts its RTS signal, which is used for flow control, and requires that its CTS and DSR inputs are both asserted thus we can simply connect the SWT s RTS output to its CTS and DSR inputs. This simple scheme will fail if the SWT ever deasserts RTS, but we have not observed such behaviour in practice. Figure 4 shows the custom cable used to make these connections. Once the physical signaling between PC and SWT had been implemented, we next had to determine the nature of the communication between the two devices. In standard modem operation the modem is essentially a slave device that accepts commands from the attached terminal; a large set of commands, known as the Hayes AT commands, have been standardized over the years for controlling various aspects of modem operation e.g., modem speed, flow control configuration, error reporting, etc. When the SWT, or any terminal, is initialised it typically sends a sequence of AT commands to the modem in order to set the modem s operating parameters. We captured the set of modem commands issued by the SWT, and the responses generated by our example 56k modem, in an iterative two-step process. First, using a null modem cable to connect the SWT to a PC and reading the issued commands with a terminal program; then, connecting the PC to the modem and monitoring the modem s response to those commands. This was complicated by the fact that certain commands issued by the SWT cause error responses by the modem, which in turn cause the SWT to issue different commands than if the original command had succeeded. By repeating this process until the SWT completed its initialization sequence we determined the appropriate set of responses to be issued by our modem emulator. The channel implements the modem emulator by using an asynchronous software thread to continuously monitor the SWT over the serial connection. That thread performs initialization of the SWT using the predetermined responses to the AT command sequence, and monitors the serial port for subsequent commands, such as a dial command issued by the SWT in order to initiate a secure voice call. These commands and other changes of the SWT s state are communicated to the main system using standard multi-threaded programming techniques. Page 5 of 7

Encrypted voice over RTP Serial control BDI serial connection Red Wireline Terminal Black Cleartext voice over H.323 POTS voice THE ASTERISK SCIP STACK Red/Secure Network Black/Insecure Network Figure 5: Connections between Sectera Wireline Terminal and Red/Black servers The NIB is responsible for setting up a clear data channel between the GSM handset operating in CSD mode and the SWT, which is connected to an server using the modem emulation scheme described above. The NIB passes data back and forth between the GSM handset and SWT over RTP, using the standard GSM CSD 9.6kb/s transparent mode of operation. is responsible for terminating the RTP stream and passing communicating with the SWT over the BDI port. In order to do so we implemented an channel driver for an SWT class of device. The driver manages a number of serial ports, each of which can be attached to an SWT device, and performs both modem emulation and the necessary protocol functions required to establish a clear data channel between the SWT and GSM handset. These functions include: CSD encapsulation: each data byte is encoded with a preceding start bit and a following stop bit, thus turning an 8-bit byte into a 10-bit symbol. Gaps in data flow are padded using sequences of stop bits in order to maintain a constant rate of one 24-byte RTP frame every 20ms. SCIP monitoring: the GSM and SWT endpoints use SCIP to exchange security parameter and establish a secure channel; monitors the flow of CSD packets from the GSM handset towards the SWT in order to determine when the clear data channel has been established by the NIB, and thus indicate to the SWT that the data carrier is now present i.e., assert the DCD signal. Other than monitoring the SCIP packets as described the channel driver plays no part in the setup of a secure channel between the endpoints it acts only to provide a clear data channel between them. LIMITATIONS OF INTEGRATED SYSTEM Our experiences with the design, implementation and trial of the integrated Type 1 secure cellular system revealed a number of limitations in the system. Many of these stem from the nature of the wireline terminals used to terminate the Type 1 secure channel to the GSM cellular handset. The design of the wireline terminal assumes that it will be attached to a standard wireline phone handset and used by a human operator sitting next to the device. This basic assumption, and the requirement for interoperability with standard POTS handsets, PC terminals and PSTN lines, means that the interfaces to the SWT are not well suited for integration into a standalone system. Another limitation arises from the use of the BDI port, and the fact that the SWT operates slightly differently when that port is used than when the built-in analog modem is utilized. In BDI mode the SWT disables certain functions, such as gathering of the number to be dialed from the attached POTS handset, and requires that the SWT keypad be used instead. Similarly, an incoming voice call does not trigger the standard POTS handset signaling that usually indicates ringing, but instead a tone is emitted by the SWT itself. A red network-facing serial port can be used to dial numbers and listen for incoming calls, which introduces more software complexity but ultimately is necessary for automation of the dialing process. Figure 5 shows how the SWT is integrated with the servers on both the red and black networks. The SWT device itself only terminates a single secure channel, so providing even a moderate number of secure channels requires many SWTs. This problem is compounded by the fact that the common use case of the SWT i.e., attached to a desk phone, means that the SWT has a large number of physical connections that are not particularly robust: in our integrated system each SWT has DC power supplied by a standard wall-wart, an RJ-11 connection for secure voice, and two serial ports (one for the BDI connection, the other for device control). This quickly leads to tangled cables when many devices must be attached, and an operational deployment of such a system would likely have very high failure rates in the mechanical connectors and cables. Although other devices exist that solve some of these problems, none of them address the basic fact that current Type 1 secure terminals are not suitable for integration into a high capacity, standalone system. For example, the DRS Tactical Interface Gateway [2] can be used to connect a number of modified Secure Terminal Page 6 of 7

Equipment (STE) devices to an H.323 network, but does not address the black side interface and only partially solves the physical robustness problem. Other developments that may improve the integration situation include the move towards use of a standard protocol Future Narrow-Band Digital Terminal/Secure Communications Interoperability Protocol (FNBDT/SCIP) for secure communications between different types of device, and the subsequent availability of systems that connect compatible devices over an IP network. Examples of such systems include the DTECH LABS Whisper [3] line of products and the Network Equipment Technologies VX SERIES Secure Voice Exchange [4] systems; unfortunately neither can directly support cellular devices. Although COMSEC considerations may prevent supporting multiple encrypted channels in a single device, a simple repackaging of the internal components of a number of terminals into a single physical unit, perhaps with aggregated I/O ports, would go a long way towards addressing concerns of both scalability and physical robustness. FUTURE PROJECTS Although the system described here in the second case study is focused on secure interconnection of cellular and wired VoIP networks, a similar approach could be used to allow wireless data terminals, such as 802.11 or WiMAX devices, to securely connect to a tactical data network. The same basic idea using a bank of secure end-to-end crypto devices to terminate a secure channel to a wireless terminal allows commercial WLAN technology to be leveraged without sacrificing security. The secure NIB could also be enhanced by replacing (or supplementing) the SWT channel driver with an SCIP channel driver that implements the complete SCIP stack and thus allows to function as a secure endpoint. Although such a system would be limited to using encryption modes that have been approved for implementation in software, it would have the advantage of not requiring connection to external encryption devices (the SWT units). The Vanu Network-In-a-Box system supports multiple cellular waveforms on a single hardware platform. The system is based upon Voice-over-IP protocols and therefore can readily be integrated into current and future VoIP networks. However, there still exists a need for interoperability with legacy networks, such as those using TDM or PSTN technologies. In those scenarios the Network-In-a-Box can be combined with the open-source PBX to provide a single box solution that can be connected to a wide variety of network interfaces. Although we have successfully integrated the Network-In-a-Box with existing secure communications devices, our experiences reveal that those devices are not well-suited to either integration into larger systems or for deployment in tactical environments. In light of these observations we recommend that future efforts be directed towards development of new secure devices that better support interoperability with VoIP systems. REFERENCES [1] : an Open Source PBX and telephony toolkit, http://www.asterisk.org/ [2] Tactical Interface Gateway, DRS Codem, http://www.drs-cs.com/products/ tacticalinterfacegateway.asp [3] Whisper Secure Mobile VoIP Systems, DTECH LABS, http://www.dtechlabs.com/p_whisper.html [4] VX SERIES Secure Voice Exchange, Network Equipment Technologies, http://www.net.com/pdf/vxseries-ds-gov.pdf CONCLUSIONS Commercial cellular systems offer many advantages to military users: low cost, extensive feature sets, and high degree of user familiarity. Thus it is imperative that military networks are able to interoperate with cellular systems, and this requires that cellular systems support the same level of security Type 1 required in military applications. Page 7 of 7