Abstract
In disaster management scenarios with seriously damaged, not existing, or saturated communication infrastructures satellite communications can be an ideal means to provide connectivity with unaffected remote terrestrial trunked radio (TETRA) core networks. However, the propagation delay imposed by the satellite link affects the signalling protocols. This paper discusses the suitability of using a satellite link for TETRA backhauling, introducing two different architectures. In order to cope with the signal delay of the satellite link, the paper proposes and analyzes a suitable solution based on the use of a performance enhancing proxy (PEP). Additionally, robust header compression (ROHC) is discussed as suitable technology to transmit TETRA voice via IP-based satellite networks.
1. Introduction
Safety-critical systems are designed as highly available networks with redundant components and network connectivity. Nevertheless, situations can occur requiring either a dynamic network extension (e.g., mass gatherings, rescue missions in uncovered regions, or abroad) or temporary replacement of damaged network infrastructure (e.g., after a flooding or an earthquake). Under these conditions satellite communication as wide area network is a valuable means to complement terrestrial lines. Nonetheless, current satellite-based solutions applied to disaster management scenarios are mostly limited to satellite phones (such as Globalstar [1] or Iridium [2]) even if some work has been done towards systems using satellite backhauling solutions (such as Emergesat [3] and WISECOM [4]), that is, connecting base stations for wireless services to their corresponding base station controllers via a long-haul link.
Additionally, many countries have already set up or are rolling out digital trunked private mobile radio (PMR) systems for emergency medical services, fire departments, civil protection, police, and armed forces. Furthermore, an increasing number of public services (e.g., transportation) and private companies implement their own PMR networks. These user groups require service attributes which a public cell phone system like GSM cannot provide. Among others, the most important features are fast push-to-talk (PTT) call set-up, group and broadcast calls, emergency calls, and secure encrypted communications. The three most widely used systems are Project 25 (P25), which is a Telecommunications Industry Association (TIA) standard, the proprietary solution TETRAPOL, and the European Telecommunications Standards Institute (ETSI) standard TETRA.
The insertion of a satellite link within the TETRA architecture (i.e., backhauling for voice services) would help to improve the network’s resilience, making the system not dependent on the availability of the network. Robustness of satellite links together with the deployment of light-weight TETRA equipment could be a suitable solution for the described scenario. However, the high delay introduced by the satellite link would negatively affect the TETRA call setup, making it not compliant with the established ETSI recommendations. Therefore, it is necessary to analyze the different delay problems that appear and investigate the different solutions that can be applied.
Basis for our work is reference [5]. The authors describe and analyze the intersystem backhauling architecture including the approach of using PEPs. We extend this work with a second architecture and compare these two scenarios. Additionally, we show that ROHC can help to improve utilization of the satellite link.
The work is structured as follows. In Section 2 a brief description of the TETRA standard is provided. Then we describe two different network architectures and solutions to the unavoidable signaling delay problems for voice calls. Since the least common denominator for many current satellite networks is Internet Protocol (IP), we will address in Section 3 mechanisms to save satellite bandwidth by means of applying header compression to voice over IP (VoIP) streams. Finally, a summary concludes the paper.
2. Satellite Links within the TETRA Architecture
TETRA is a 2nd generation trunked radio system in which two standard families have been developed: voice plus data (V+D) and packet data optimized (PDO). V+D is supported by all TETRA products and is the subject of our study, while PDO results were transferred into subsequent standardization activities.
A TETRA system consists generally of mobile stations (MSs), line stations (LSs) (i.e., wired devices like control centers), and a switching and management infrastructure (SwMI). The latter contains base transceiver stations (BTSs) providing the air interface to MSs, supports the necessary call switching functionality using home and visitor location registers, and is responsible for key management. In case of no connectivity between the BTS and the main switching center (MSC), TETRA provides a fall back mode allowing the establishment of local calls within a cell thanks to the local switching center (LSC) attached to each BTS. Figure 1 shows a diagram of the TETRA network architecture, including the interface for interconnection with other TETRA networks. For the sake of completeness, the network management and direct mode operation (DMO) interfaces are included in the diagram, although they are out of the scope of this work. Additionally, the terminal equipment interface (TEI) I4 inside MS and LS is not depicted.
In this section we will propose two different architectures for integrating a satellite link within the TETRA network, analyze the impact of the satellite link in terms of introduced delay during call setup, and, finally, present a solution based on the use of PEPs to mitigate the negative effects of this additional delay.
2.1. TETRA Backhauling Architectures
The first solution presented allows interconnection of different TETRA networks, which can be useful, for instance, in order to interconnect networks from different organizations, such as different public-safety services. In the second case, backhauling allows the connection of a base station controller (BSC) with a remote BTS belonging to the same network. This solution can be used, for instance, to rapidly provide TETRA coverage in the incident area and connect users to the core network.
2.1.1. ISI-Based Backhauling
The TETRA intersystem interface (ISI) has been standardized as a suite of services necessary to support vendor-independent interoperability between different TETRA networks, both between national and cross-border SwMIs. Basic design goals are support of foreign terminals (migration) and support of individual and group calls between different SwMIs. (Note: in TETRA terminology “roaming” means a MS changing its location area within the same mobile network/country code, whereas migration means a MS changing its location area to a different mobile network/country code. The latter means in most cases changing the SwMI). Thus, the ISI interface will be involved whenever a calling or a called subscriber (individual or a member of the called group TETRA subscriber identity (GTSI)) is in the coverage area of a nonnative SwMI. A first approach, already described in literature [5] and which we repeat for completeness, is to backhaul the ISI traffic via satellite instead of using a terrestrial line (see Figure 2). ISI-based backhauling requires two complete SwMIs with all network management facilities (switching centers, location registers, etc.), which have to be set up and maintained with possibly non-negligible effort. A key advantage is that communication to and from other SwMIs over the satellite link is possible via the standardized intersystem interface I3 [7, 8].
Operators of public-safety SwMIs have usually very strict confidentiality requirements. Key advantage of ISI-based backhauling is that in addition to the regular SwMI a second temporary SwMI with relaxed security constraints can be set up. The backhauled network can be configured to accept all roaming requests also from unknown terminals, which is a key requirement for international rescue missions, where uncomplicated information exchange between different organizations must be guaranteed.
2.1.2. A-bis-Based Backhauling
In the Global System for Mobile Communications (GSM) architecture the interface between a BSC and an associated BTS, which form together the base station subsystem (BSS), is known as the A-bis interface [9]. A similar approach is imaginable for TETRA as well, but unlike the GSM case this interface and all others within a SwMI are completely vendor-specific and interoperability between devices from different manufacturers is unlikely. For simplicity, in the following we will denote the interface between the TETRA BTS/LSC and MSC as A-bis interface, too (Figure 3). Apart from the additional delay introduced by the satellite link, there are several issues to be taken into account. As already mentioned, the A-bis interface is not standardized and therefore, interoperability between devices from different vendors is not likely to be assured. From the call admission control point of view (i.e., the network authenticates users, MSs, and services) there is no difference if the physical A-bis link is a terrestrial or satellite one, which is an advantage for dynamic network extensions or temporary replacement of damaged network elements. Nevertheless, a pre-requisite is that MSs served by the backhauled TETRA cell are known by the home SwMI. From this perspective, the A-bis based backhauling is not an option for international rescue missions, since TETRA MSs from other nations or organizations would need explicit migration agreements for the deployed network.
2.2. Call Setup Considerations
One of the main drawbacks of introducing a satellite link within the TETRA network is the additional propagation delay. This section analyzes this effect taking as reference the list of functional requirements for the TETRA ISI presented in [10]. The two most concerned delay issues include the following:(i)the call setup delay, defined as the delay experienced by the user between the moment of pressing the PTT button and getting an audio indication of permission to talk. For inter-SwMI calls across the ISI interface, the call setup delay should be shorter than 1 s;(ii)the end-to-end audio delay experienced by a user over the ISI should not be more than 0.7 s.
In our work the call setup delay has been taken as a reference to measure the impact of the satellite link delay. The end-to-end audio delay via a geostationary earth orbit (GEO) satellite will most likely exceed the recommended 0.7 s but has not been taken into consideration for this study.
A series of simulations have been carried out using OMNeT++ [11] in order to determine the call setup delay according to the two different proposed architectures both for individual and group calls. For performing the simulations, the following propagation delays have been assumed for the different elements of a TETRA network:(i)ISI (I3): one-way propagation delay caused by a terrestrial link 30 ms, by a satellite link 250 ms.(ii)A-bis: one-way propagation delay caused by a terrestrial link 5 ms, by a satellite link 250 ms.(iii)Air interface (I1): one-way delay 5 ms. Note that I1 has to be taken into account both for calling and called terminal.(iv)Intra-SwMI: one-way link and processing (e.g., time needed for database lookup) delay of 15 ms.
Another important issue to be taken into account is that TETRA uses different protocol timers to keep track of a call status. Related to the work discussed here, the three most important timers along with their possible ranges are listed in Table 1. In case of unexpected events during the call setup phase, these timers might expire and terminate the call setup process. Therefore, the values assigned to them have to be carefully chosen matching the expected network delays.
2.2.1. TETRA Individual Calls
An individual or point-to-point call is established between two parties only that is, calling and called subscriber. In the following we assume that at time of a call-setup both subscribers are either in different coverage areas of different SwMIs, or they are registered in different SwMIs. Subsequently, we will describe the different message sequences considering the two presented integration solutions, using the satellite link at the ISI and at the A-bis interfaces, and, according to this sequences, the call setup delays obtained from the simulations will be presented.
The message sequence chart for both subscribers in different coverage areas of different SwMIs, with the satellite link in the ISI interface and using on/off hook signaling, is depicted in Figure 4(a). In this case, signaling messages are exchanged over the ISI only. refers to the delay imposed by the satellite link, whereas Tnx refers to inherent TETRA network delays, which vary depending on the call scenarios and network entities involved. In the cases where no Tnx is considered between the reception of a message and the transmission of the corresponding answer, it is assumed that the message is directly answered by the entity receiving the message, without forwarding it to any additional entity of the system. In principle, seven messages must be exchanged for a successful establishment of an individual call. However, ISI-IC-CHARACT.CHGE_req_ind, and ISI-IC-SETUP PROLONG_req_ind packet data units (PDUs) are optional, so they may be ignored for the delay considerations presented here, whereas the other four PDUs are mandatory.
![(a) ISI individual call message sequence chart [12]](https://static.hindawi.com/articles/jcnc/volume-2014/562546/figures/562546.fig.004a.jpg)
(a) ISI individual call message sequence chart [12]
(b) A-bis individual call message sequence chart
Once SwMI-1 has sent ISI-IC-SETUP_req_ind to SwMI-2, it must wait for the reception of ISI-IC-SETUP_resp_conf and ISI-IC-COMPLETE_req_ind, which can be transmitted by SwMI-2 in parallel, before sending ISI-IC-COMPLETE_resp_conf. On the called side, SwMI-2 should have received ISI-IC-SETUP_req_ind before it can answer with ISI-IC-SETUP_resp_conf and ISI-IC-COMPLETE_req_ind. Later on, it has to wait for ISI-IC-COMPLETE_resp_conf for call establishment.
For SwMI-1 it takes at least two one-way propagation delays before receiving ISI-IC-SETUP_resp_conf or ISI-IC-COMPLETE_req_ind and transmitting ISI-IC-COMPLETE_resp_conf, while SwMI-2 must also wait for two link delays between receiving ISI-IC-SETUP_req_ind and ISI-IC-COMPLETE_resp_conf. Since SwMI-1 waits two link delays before transmitting ISI-IC-COMPLETE_resp_conf and SwMI-2 must wait for another link delay for the reception of ISI-IC-COMPLETE_resp_conf, the establishment of an individual call involving a satellite link at the ISI, requires two satellite link delays for SwMI-1, plus all other inherent TETRA network deferrals. Call setup delays obtained from the simulations in case of using a satellite link at the ISI interface are summarized in Table 2: the call setup time for an individual call stays well below 1 s, as required.
In case of introducing a satellite link at the A-bis interface, the message flow sequence for establishment of an individual call is depicted in Figure 4(b). In total, seven messages need to be exchanged over the A-bis interface. A similar analysis and excluding the optional messages from the signalling protocol results in two satellite link delays to be added to the TETRA inherited delays for a successful call establishment. However, the called subscriber will require an additional one satellite link delay before he can receive the transmission. The results obtained for this scenario are shown in Table 3. Basic result is that the call setup delay does not meet the requirement of being shorter than 1 s.
2.2.2. TETRA Group Calls
A group call is a half-duplex point-to-multipoint call with one user calling more than one subscriber. All members of the called group belong to the same group TETRA subscriber identity (GTSI), by which they are addressed. Two different categories of group calls can be defined: acknowledged and unacknowledged. In case of acknowledged group calls, all called users are polled and the call is established once all the polling responses have been received, while in the unacknowledged case no polling is done and the call is immediately established without knowing if the called users are ready to communicate. The latter approach is very similar to analogue radio.
The involved SwMIs can play different roles, resulting in a number of different cases [12]:(i)originating SwMI (OSwMI): this is the SwMI from where the calling user initiates the call set up procedure. After the call has been established, the same SwMI also becomes a participating SwMI (PSwMI),(ii)controlling SwMI (CSwMI): the CSwMI is responsible for establishing and maintaining the call between two or more different SwMIs,(iii)group home SwMI (GSwMI): the SwMI for which the GTSI is the same as the mobile network code (MNC),(iv)linking controlling SwMI (LCSwMI): a LCSwMI is responsible for the linking of one of its own groups to one or more groups from the other SwMIs,(v)participating SwMI: the PSwMI is the SwMI that only participates in the call without controlling the inter-SwMI group calls. It is normally the end point where the call is terminated. It may have one or more members of the group call registered either as resident or as visitor.
Depending on the actual location and registration of the group members in their respective SwMIs, several group call scenarios can be defined [12], as depicted in Figure 5:(i)Scenario 1: the home SwMI of the called user group is the OSwMI and at least one of the members of the called group is served by a different SwMI.(ii)Scenario 2: both calling MS and called user group belong to the same home SwMI, but the calling MS is served by another SwMI.(iii)Scenario 3: the called user group belongs to a different SwMI than the OSwMI. The calling user is located in the OSwMI which can be either the home SwMI or a visited SwMI.(iv)Scenario 4: OSwMI and CSwMI are the same, but the MS is calling a group ID which is linked to another group ID in another SwMI. Moreover, the other SwMI is the GSwMI of the linked group.
(a) Scenario 1: Originating and controlling SwMI are collocated
(b) Scenario 2: Originating and controlling SwMI are not collocated
(c) Scenario 3: Calling and called MS belong to different group IDs
(d) Scenario 4: MS calls to a group ID linked with the group ID of another SwMI
The effect of the satellite link on group call setup can be analyzed as before by using the messages exchanged over the ISI and the A-bis interfaces, but unlike individual calls we have different scenarios along with acknowledged and unacknowledged group calls. Among the different cases, since three SwMIs are involved, scenario 4 can be considered the worst case scenario in terms of the introduced delay (see Figure 6), so it will be the case to be analyzed in this study: the OSwMI (SwMI-1) must ask the CSwMI (SwMI-2) for the routing information of the LCSwMI (SwMI-3) before the group call request can be finally sent to SwMI-3. The extraction of routing information takes two additional link delays compared to the other scenarios where the OSwMIs already have the routing information of their PSwMIs.
(a) Using the ISI interface
(b) Using the A-bis interface
In case of using the satellite link at the ISI (Figure 6(a)), in total seven signaling PDUs are sent through the ISI, but for our delay considerations, since two of them (ISI-Info_req_ind and ISI-Setup_req_ind) can be sent in parallel, they will be considered as one. Therefore, for scenario 4 we end up with six additional satellite link delays () for an unacknowledged group call setup. Furthermore, some of the call setup timers must be adjusted in order to cope with the link delays. For instance, timer T302 (see Table 1) has to be amended to bridge the long delay between the transmission of ISI-Originating Setup_req_ind and reception of ISI-Connect_req_ind, in order to avoid an automatic disconnection.
In a similar way, the corresponding message flow chart for this scenario and the A-bis interface is presented in Figure 6(b). Using the same considerations regarding parallel messages as in the ISI case, here it takes four satellite link delays before the unacknowledged group call can be set up.
For acknowledged group calls, all called subscribers must be polled after the initial group call signaling. Regarding the message flow using the ISI, until the polling starts the message sequence is the same as for the unacknowledged case. As an example, the signaling for scenario 1 is shown in Figure 7. For both analyzed cases (ISI and A-bis) the subsequent polling of called users takes two additional link delays compared to an unacknowledged group call. Tables 2 and 3 summarize the necessary call setup times for individual and group calls for all the described scenarios. The highlighted values are the ones that do not satisfy the ETSI requirement regarding setup time. For the worst case scenario 4, the call setup delay clearly exceeds the recommended time of 1 s.
2.3. Performance Enhancing Proxies (PEPs)
Our results listed in Tables 2 and 3 show that the expected call set-up times are partly far beyond the ETSI recommendations. Users expect fast PTT functionality and are accustomed to moderate delays only; excessive call setup delays might be taken for a malfunction. In any case, a deviation from the normal (without satellite link) network behavior will put additional stress on the users which has to be avoided. The impairments on the performance of standard transport protocols (e.g., transmission control protocol (TCP)) introduced by the use of satellite links have been widely analysed in the last decades ([13, 14]). As stated in the delay analysis above, our work will focus on the techniques to reduce the call setup delay introduced by the long propagation delay over the satellite link. Therefore, other well known issues, such as the presence of segment losses due to physical channel errors, remain out of the scope of the current work. According to [15], the different solutions that can be used to alleviate the satellite-related impairments can be classified into four different categories: optimization of TCP interactions with lower layers [16], TCP enhancements [17, 18], PEPs [19], and delay tolerant networkss (DTNs) [20].
Due to the necessity of keeping the protocol stack unchanged on the terminals, the satellite segment is the one we can influence in order to improve the performance in terms of reducing the call setup delay. Therefore, the use of PEPs seems a reasonable way to try to overcome the presented issue. PEPs are network agents which are designed to improve the end-to-end performance of communication protocols. They are mostly known for improving the degraded performance of TCP [19] via satellite [21] or performing caching operations for improving transmission over wireless networks [22]. The most common PEP techniques are splitting and spoofing [14]. Splitting is used to isolate the satellite segment from the rest of the network so that different connections and communications protocols, optimised for each segment, can be used. Normally, spoofing is understood as corresponding proxies generating fake TCP signalling messages in order to mitigate the effect of the long round-trip delay time (RTT) introduced by the satellite. In this study we follow a similar approach, but the fake signalling messages are generated for the TETRA protocol stack which can be considered as application layer above the satellite transport layer.
PEPs can be used either on one side of the communication link or at both ends and can be aimed at either improving throughput or link response time. For our work, the spoofing approach using asymmetric (i.e., independent PEPs behaving differently in both directions) spatially distributed PEPs at both sides of the satellite link will be assumed.
The idea of using PEPs to mitigate this effect when using TETRA has been already explained in [5]. This section extends the works done in [5] by applying a PEP-based solution to the two different architectures under study and defining the necessary functionality and signalling algorithms to be provided.
2.3.1. PEPs for ISI Backhauling
The required functionality of these PEPs highly depends on the actual call setup scenario. Due to limitation of space, only group call scenario 4 is discussed here, but for other scenarios a similar approach can be followed. In group call scenario 4, PEP-1, which is associated with the calling SwMI-1, should behave as follows.(i)After receiving ISI-Reroute Setup_ind, when PEP-1 receives ISI-Originating Setup_req_ind, it shall forward this PDU via the ISI towards SwMI-3, but at the same time it should reply back to SwMI-1 with a fake ISI-Info_req_ind and ISI-Setup_req_ind PDUs, assuming that the SwMI-3 will not have any disagreement on the services requested in these PDUs. In the meantime, while the real PDUs are approaching SwMI-3, SwMI-1 when receiving ISI-Setup_req_ind will evaluate if it has the necessary resources for the group call progress. If there are available resources, it will reserve them and get ready for the connection. At this time, even though the original ISI-Originating Setup_req_ind might not have arrived at SwMI-3 yet, SwMI-1 already has all the necessary resources reserved and is waiting for the ISI-Connect_req_ind to establish the group call. Without PEPs this state would have been reached two satellite link delays after the transmission of ISI-Originating Setup_req_ind towards SwMI-3.(ii)If PEP-1 receives the original ISI-Info_ind or ISI-SETUP_req_ind PDUs from SwMI-3, it should forward these unmodified PDUs to SwMI-1. Reception of the original ISI-SETUP_req_ind PDU means that services requested by SwMI-1 in the ISI-Originating Setup_req_ind PDU could not be agreed by SwMI-3. If SwMI-3 can not provide all the requested services, it will reply with the ISI-SETUP_req_ind PDU with the parameters indicating the new allowed services. This PDU will arrive at SwMI-1 only if there is a disagreement of services. In this case SwMI-1 will adjust its parameters according to allowed services and will send a modified ISI-Setup_resp_conf to SwMI-3.(iii)For all the other PDUs, PEP-1 should simply forward the received messages.
PEP-2, which is associated with the calling SwMI-2, shall behave as follows.(i)When PEP-2 receives ISI-Originating Setup_req_ind, it shall save a copy and forward this PDU towards SwMI-2.(ii)When PEP-2 receives the original ISI-Reroute setup_ind it shall forward the PDU to SwMI-1, but at the same time it should forward the previously saved ISI-Originating Setup_req_ind towards SwMI-3 mentioned in ISI-Reroute setup_ind. Consequently, ISI-Reroute setup_ind will arrive after two satellite delays only. Without PEPs, it would have arrived after three satellite link delays.
On the called side PEP-3, associated with SwMI-3, shall act as follows.(i)Upon reception of ISI-Originating Setup_req_ind, PEP-3 must check if it is the first instance of ISI-Originating Setup_req_ind. If it is the first instance, PEP-3 must store the contained requested service parameters, increment CID.orig_setp, and forward it to SwMI-3; otherwise it should drop the ISI-Originating Setup_req_ind PDU.(ii)When PEP-3 receives the ISI-Setup_req_ind PDU from SwMI-1, it must check the parameters in this PDU, which are meant to inform SwMI-1 about the services agreed or disagreed by SwMI-3. If services requested in previous PDUs match the services offered by SwMI-3, there is no need for transmitting this PDU since PEP-1 had already sent this PDU to SwMI-3 in the past. However, if there is a disagreement on the services, PEP-3 should forward this PDU to SwMI-1.(iii)When PEP-3 receives ISI-Setup_resp_conf, it should check if the requested and allowed parameters had been agreed. If the PDU received is the first instance of ISI-Setup_resp_conf, it is received as a result of a fake ISI-Setup_req_ind sent by PEP-1 to SwMI-1. If service parameters were miss-matching and ISI-Setup_resp_conf is the first instance, then PEP-3 should drop this PDU; otherwise, it should forward it to SwMI-3.(iv)For all other PDUs, PEP-3 should simply forward them to the destination node without any modification.
With this proposal two satellite link delays plus the time spent to reserve resources at SwMI-1 can be saved in unacknowledged group call setup time. The corresponding information flow sequence is shown in Figure 8 with satellite links between the PEPs. Figure 9 shows the information flow sequence for an acknowledged group call using PEPs. Here, PEP-1 upon reception of ISI-Poll_req_ind replies with a fake ISI-Poll_resp_conf triggering ISI-Connect_ind. On the other side, PEP-3 checks if a real ISI-Poll_resp_conf has been sent before forwarding ISI-Connect_ind. Altogether two satellite link delays are saved. Table 4 summarizes the results obtained using our PEP in an ISI backhauled TETRA network. The results show that most of the unacknowledged group call setup times do not exceed the required limit of 1 s.
2.3.2. PEPs for A-bis Backhauling
Similarly, PEPs can be used to reduce the call setup delay when backhauling the A-bis interface. As an example, excerpts of the message flow sequence for group call scenario 4 with PEPs at both ends of the A-bis link are shown in Figure 10. Spoofing the SwMI with the fake PEP-2 message ISI-Setup_resp will force the SwMI to reserve the necessary resources in advance and to get ready to establish a successful group call. This will save two satellite link delays.
Regarding acknowledged group calls for the case of using the satellite link at the A-bis interface, results can be derived in a way analogous to the ISI one (see Figure 9).
Table 5 summarizes the results obtained using a PEP with an A-bis backhauled TETRA network. As expected, all group call setup times stay below 1 s.
Finally, Figure 11 shows a comparison of TETRA individual and group call setup times with and without PEPs, both for A-bis and ISI backhauling. PEPs can drastically improve call setup times so that in most cases the 1 s threshold can be met. The only major exception is an acknowledged group call (scenario 4) with ISI backhauling which takes nearly 2 s.
(a) Call setup times without PEPs
(b) Call setup times with PEPs
3. Optimizing Satellite Link Bandwidth Utilization
Despite the availability of highly efficient modulation/coding schemes and resource management algorithms, data transmission via satellite is still costly. With IP being nowadays the common denominator for a majority of voice and data services and being supported by most commercial satellite operators, it is straightforward to think about a suitable strategy for transporting TETRA voice over IP more efficiently. This becomes crucial when using, for instance, quickly deployable satellite terminals, like the Inmarsat BGAN [23], which offer streaming classes with limited throughput, for voice communications. In the remainder of this paper we therefore discuss an approach for voice only; embedding TETRA signaling messages in IP packets is uncomplicated and there is not much room for optimization.
3.1. TETRA Voice Codec and IP Encapsulation
A TETRA speech encoder generates 274 bit (≈35 B) per 60 ms speech frame resulting in a net data rate of 4.56 kbit , whereas a TETRA burst on the air interface has a length of 510 bit, including error correction, training sequences, and piggy-back signaling of logical control channels, too [24]. We assume that an IP gateway of a SwMI fully decodes and unpacks TETRA bursts, so that the pure voice frames remain as single stream.
Appending IP (20 B), user datagram protocol (UDP) (8 B), and real-time transport protocol (RTP) (12 B) headers to a single voice frame, a 75 B long packet with 40 B of IP/UDP/RTP overhead is obtained. In other words, each 60 ms-long sample of encoded speech produces a packet size of 75 B, with a rate of 17 packets , resulting in 9.6 kbit . This increases the net bandwidth demand by a factor of 1.38.
Obviously there is a need for improvement. One approach is to use voice activity detection (VAD): during a typical voice call each user is silent on average for 60% of the total call duration. Normally both speech and silent intervals are packetized. With VAD packets of silent intervals can be suppressed and up to 35% corresponding bandwidth can be saved. However, these savings can be only observed over a considerable long period of time and for networks serving more than 24 calls simultaneously [25]. Besides, subsequent VAD based on IP may not have any effect at all, depending on the trunking mode used (SwMIs configured for many bi-directional point-to-point calls will very likely apply (quasi-)transmission trunking) and deciding which trunking method is applied is up to the operator.
3.2. Robust Header Compression (ROHC)
Another solution to reduce bandwidth demand over an IP link is header compression. Of the aforementioned IP encapsulation most of the information in IP, UDP, and RTP headers is redundant for a point-to-point link. During the lifetime of a call (stream) some fields of the IP/UDP/RTP headers remain unchanged, like source and destination IP addresses and UDP ports. Some other fields change in predictable patterns with always the same differences between adjacent packets, like IP-ID (IP header), sequence number (SN), and time stamp (TS) (RTP header).
Others might change unforeseeable like marker flag (RTP) and UDP checksum. On a point-to-point link, a considerable amount of bandwidth can be saved, if static fields are only sent when starting a session, and if deltas are only sent relatively to their previous values for predictably varying fields. However, randomly changing fields have always to be sent. This approach is called header compression.
For this work ROHC has been selected, although many other compression schemes exist, including compressed RTP (CRTP) and enhanced compressed RTP (ECRTP). ROHC has been considered here due to its robust nature against high packet loss rates and long round trip delays in wireless environments. It maintains a context on both sides of the link to keep record of the last successfully decompressed header fields and reference values to be used for the decompression of subsequent packets. ROHC compresses packets to initialize and refresh (IR), first order (FO), or second order (SO) state depending on the amount of varying information to be sent towards the decompressor. Unlike other compression schemes, ROHC uses a sophisticated window-based least significant bit (LSB) encoding method for the predictably varying fields like SN, TS, and IP-ID. ROHC can operate both in unidirectional and bidirectional modes.
The bidirectional mode can be used when a return channel exists between decompressor and compressor. Unlike unidirectional mode, in bidirectional mode every time the decompressor fails to decompress a predefined number of consecutive packet, it sends back a negative acknowledgment, forcing the compressor to increase the level of information to be sent in the subsequent packets, or to send uncompressed packets. Hence, the decompressor can always recover from desynchronization after a loss of packets corresponding to one round trip link delay. To increase the level of robustness, in case of update packets getting lost, the compressor sends the updating packets more than once [26].
A testbed was implemented for the purpose of analysis and performance evaluation of ROHC on a satellite link. Figure 12 shows example results recorded over twenty minutes transmission of a TETRA voice call encapsulated in IP over a satellite link, using ROHC as header compression scheme. Channel profiles used for this evaluation are listed in Table 6. The correlated packet loss pattern was derived from a land-mobile satellite link and serves as an example for burst losses.
(a) Histogram of consecutive packet losses caused by desynchronization (20 min sample channel, accumulative for all link profiles)
(b) Packet distribution over IR, FO, and SO states (for all link profiles, both unidirectional and bidirectional transmission)
(c) Compression gain (unidirectional, profile D)
(d) Compression gain (bidirectional, profile D)
A desynchronization makes the decompressor wait for the next IR packet to refresh its context and start successful decompression again. In bidirectional mode a desynchronization triggers a negative acknowledgment to be sent towards the compressor, which in turn switches to a lower level of compression or to the IR state. However, the decompressor has to wait one complete round trip time until an IR packet arrives so that it can start successful decompression again. Unlike bidirectional mode, there is no (negative) acknowledgment in unidirectional mode, so desynchronization here results in a compression failure until the next scheduled IR packet arrives. The number of packets lost in unidirectional mode as a consequence of desynchronization depends on the relative position of packets causing desynchronization with respect to the next IR packet.
In order to get a first impression of the ROHC behaviour, Figure 12(a) depicts the histogram of the cumulative occurrences (events) over the number of consecutive packet losses using all channel profiles one after the other. In bidirectional mode desynchronization due to erroneous packets or bursts of lost packets (more than 30 consecutive packets) causes events with up to 18 missing consecutive packets. However, for unidirectional mode, results are more disturbing, since desynchronization causes consecutive losses of up to 95 packets, again, depending on the relative IR packet position. Periodic transmission of IR packets after every burst of 100 packets has been considered here.
Figure 12(b) provides more details and shows the number of IR, FO, and SO packets sent for unidirectional/bidirectional modes and all channel profiles, while Figures 12(c) and 12(d) show the compression gain achieved by ROHC in case of unidirectional and bidirectional modes for the most challenging profile D. The compression gain is calculated as difference between uncompressed header size and compressed header size divided by the sum of uncompressed header size and payload size. In both cases the compression gain reaches up to 49% for most of the time; the average compression gain is slightly smaller. A negative compression gain arises out of IR packets, which contain more information than uncompressed voice packets.
There is no noticeable difference in terms of bandwidth demand between unidirectional and bidirectional mode. However, when it comes to robustness, the bidirectional mode clearly outperforms the unidirectional mode which is especially important for short voice calls suffering a lot from missing packets. Alternatively a small value of the IR counter could be used for the unidirectional mode at cost of bandwidth efficiency.
4. Conclusions
In this paper we analyzed the possibility of extending TETRA SwMIs with satellite links. Two main backhauling architectures were considered with both of them having specific advantages and disadvantages. Backhauling the ISI interface requires two complete SwMIs but allows different security settings, which can be a key advantage for scenarios with MSs belonging to different home SwMIs. Using the A-bis interface is more lightweight but the backhauled network segment has no flexibility at all to change security settings.
In any case satellite links impose a serious degradation in call setup times. This paper developed the necessary functionality of PEPs so that for most considered cases the call setup delay can be reduced to values below 1 s.
Finally, ROHC can be effectively used to reduce the excess bandwidth needed due to overhead protocol headers. Both unidirectional and bidirectional modes can be used; however, bidirectional mode must be preferred in order to achieve high level of robustness. In case unidirectional mode is used, the periodic repetition of IR packets must be set to a low value, so as not to lose voice data of significant duration.
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgments
This work was conducted within the e-Triage project which was sponsored by the German Federal Ministry of Education and Research under contract no. 13N10542. The sole responsibility for the content of this paper is with the authors.