Red Bar

Emergency communications using GSM and WiFi over a BGAN satellite link

Markus Werner and  Axel Jahn of TriaGnoSys describe an integrated and transportable communication terminal using GSM and WiFi over a BGAN satellite link for emergency communications.


Disasters often come along with the destruction of the local telecommunication infrastructure (provided that this infrastructure existed beforehand) causing severe problems for rescue operations. Satellite communications is then the only communication means for the rescue teams.

Today costly satellite telephones with low data rates are used in the early disaster phase (usually several hours after the disaster). In order to quickly restore the local mobile communication networks (GSM or 3G) with higher data rates, more complex satellite communication terminals (up to container size with several hundred kilograms) are available, which connect local base stations via satellite to the core network. Transportation and installation of these satellite terminals take usually up to several days.

TriaGnoSys developed a emergency communication system under the WISECOM (Wireless Infrastructure over Satellite for Emergency Communications) project, co-funded by the European Commission in the 6th Framework Program. The system is rapidly deployable lightweight, satellite-based communication infrastructure, which can be easily transported by one person and can be installed within minutes. The communication infrastructure consists of small, rapidly deployable, terrestrial base stations (GSM, WLAN), which are connected to the public telephone network and to the Internet via satellite. The system supports voice and data communications for the rescue teams and it also provides a local GSM or 3G communication infrastructure for the victims in the disaster area.

GSM over Inmarsat BGAN

To provide voice and basic data services such as SMS or GPRS, WISECOM considers the use of GSM over BGAN technology to be implemented in the emergency suitecase. The global system architecture is depicted in the picture below: The communication architecture intercepts  the signaling and the data communication between the GSM BTS (Base Transceiver Station) and the BSC (Base Station Controller). The BTS performs encapsulation of GSM packets (signaling and data) into IP packets. The GSM packets are later recovered by the NSGS (Network Side GSM Server), forwarded to the BSC, and switched to the core network elements. The TSGS is basically a ruggedized industrial computer running TriaGnoSys’ Mobile GSM Infrastructure (TRIAMOGIS) software which performs the following functions:

  • Satellite bandwidth on demand: the software requests dynamically the required bandwidth in the satellite modem, and when there is no more resource available, the incoming call will be blocked.
  • BSC signaling suppression: TSGS and NSGS suppress most GSM signaling messages which are sent periodically to minimize the satellite usage and required bandwidth.
  • Codec selection and IP compression: To efficiently utilize the scarce satellite resource, the TSGS supports different types of voice codecs to reduce the size of the voice packets. Both GSM full-rate and Adaptive Multirate narrow band (AMR-NB) with rate as low as 4.75 kbps are supported. Further decrease in the transmission bit rate is achieved by robust IP/UDP/RTP header compression.

Other functions such as Quality of Service (QoS) support, GSM BTS automatic control functions, GSM service selection, and network management are also supported. The chosen technology for the BTS is ip.access nanoBTS. It provides coverage of approximately 350 meters with full power in open space. Due to its small size, the BTS can be carried and deployed anywhere, providing GSM coverage to practically any place on earth, as long as there is satellite connectivity.

GSM over BGAN System Architecture

GSM over BGAN System Architecture

The satellite to be used is the Inmarsat BGAN (Broadband Global Area Network) technology. BGAN provides data and voice services globally via its 3 satellites. There exist different types of terminal to access the satellites. The Thrane & Thrane Explorer 300 and Explorer 500 are the ones found to have reasonable trade-off between performance and dimension (size and weight). The small size of the satellite terminal limits the maximum data rates that can be achieved in the satellite link. The usage of the scarce bandwidth resource is managed through the usage of traffic classes. There are two types of class that could be opened for data communication: streaming and background class.  The streaming class gets higher priority and ensures that constant data rate is available to the user.

The Explorer 500 terminal is capable of providing streaming class connections up to 128 kbps. Users are charged based on the time spent on the connection. The rest of the satellite channel capacity is assigned to the background class. Here the available bit rate may vary, and the user is charged based on the volume of data transferred on the satellite link. The three main components of the WAT are: the GSM base station, the industrial PC, and the satellite modem. The three components only weigh approximately 5 kg.

Provision of Data Services via WiFi

A general overview of the WiFi over BGAN system architecture developed in the framework of the WISECOM project can be seen below. The architecture is composed of the WISECOM Access Terminal (WAT), encompassing mainly the WiFi router (Linksys WRT54GL with DD-WRT firmware), the WISECOM client and the BGAN terminal. At the interface between the WISECOM client (WC) and the BGAN terminal, several virtual interfaces (potentially using the same physical interface), can be supported for data transmission. These virtual interfaces will be associated with IP tunnels carrying IP datagrams from the WAT to the Control Center in the disaster-safe segment, or directly to the public IP networks.

Authentication and authorization of users is done via a RADIUS server. It provides the rescue team members having specific credentials (username, password) with unlimited access to all IP services, and limits access by all other authenticated users only to HTTP service, including a specific web page giving all information relevant to the ongoing disaster. The WISECOM client also supports traffic management and prioritization thanks to built-in tools (Linux tc command) performing traffic classification, traffic shaping, and implementing different queuing, dropping, and scheduling strategies In addition, the WC performs cache and proxy for optimal use of the limited satellite link bandwidth, dynamically manages the satellite connection (using the satellite modem’s AT commands) according to the amount of traffic to carry over the satellite link, supports different HTTP proxy servers managing the WISECOM emergency web page, accessed by default by the different users in the WiFi public domain and prior to login, the database of users allowed to connect to the system, and the state of the VoIP connections running over the system. Finally, VoIP functionalities like voice over IP calls, voicemail, and voice conference are provided using Asterisk VoIP server.

Integration of GSM and WiFi into the WAT

A key factor is the integration of the GSM and WiFi component in a robust deployment suite. The GSM and the WiFi module each has its own mechanism to guarantee QoS, namely via the TRIAMOGIS software in the GSM part, and via internal Linux tool in the WiFi part. The WiFi traffic management tool may alter the way the traffic is routed between the GSM base station and the satellite modem. However this should not produce much impact as long as the highest priority is still given to the GSM traffic.  The following figure shows the assembly of the emergency suitcase.

Satellite terminal

Satellite terminal

Markus Werner, Axel Jahn are Managing Directors of TriaGnoSys GmbH, Argelsrieder Feld 22, 82234 Wessling, Germany, http://www.triagnosys.com  tel: +49 (0) 8153 88678-0