Chapter 6. Implementation

This section covers the different scenarios that can arise in e-Triage involving TETRA

and its interconnection with GSM, both in the disaster and the safe area. Although all

possible scenarios have been depicted, the approach focuses on situations where remote

communications are necessary, that is, voice and data is to be sent over satellite. In fact,

those are right the ones that have been tested. The possible scenarios have been divided

into individual calls (two users) and groups calls (three or more users), although as it will

be seen in the next and last chapter, only individual calls have been tested due to a shortage

of time. However, a brief insight of how group calls would be configured is given.

Likewise, tests have been carried out with the GSM BSC/MSC in the disaster area

and remotely in the safe area. TETRA BSC will be always located in the disaster area.

6.1 Architecture

Fig. 6.1 picture shows a general overview of the architecture that is going to be

simulated. For the sake of clarity, only TETRA and GSM coverage areas have been de-

picted. However, as it has been shown in chapter 2, there are a greater number of different

technologies coexisting in the disaster area.

Now, bearing in mind how the TETRA equipment works (remember calls between

TETRA are possible regardless of the Voice GW, the element that lets interconnection with

other technologies), the possible scenarios can be broken down as depicted in Fig. 6.2.

1

Figure 6.1. Architecture to be tested.

Figure 6.2. Possible types of calls.

Scenarios are presented in an increasing grade of complexity. Therefore, in first place

cases that involved individual calls with only TETRA terminals will be analysed1; at the

end, groups calls between either GSM/TETRA will be tackled. This is possible thanks to

the fact that all equipment runs over an entirely IP-based scheme; this heavily facilitates

compatibility issues. The figures presented in the following subsections include details on

how the elements of the test network have been arranged, such as IP addresses and UDP

ports used.

1Because TETRA is the technology that has taken the greatest amount of time and that has been studiedmore thoroughly in the present project.

2

The red spots mark the interfaces where packets have been captured in order to be

analysed with Wireshark and check up on the protocol stack. The red lines mark the route

of traffic.

6.2 Individual calls: GSM equipment in the disaster area

6.2.1 TETRA call in the disaster area

There are two different options in this scenario. On the one hand there is the most

basic case, depicted in Fig. 6.3, where two mobile within the same cell (in the disaster area)

call each other. Here there is no need to send information over satellite and thus, from the

point of view of the present project, this option is of little interest. However, this was the

result of the first two configurations steps given in chapter 5, Section 5.2 and so included

here.

Figure 6.3. Intra cell TETRA call in the disaster area (base case).

On the other hand, there is the scenario where the two mobile stations trying to

establish a call are not within the same cell. In this case, and taking into account future

needs, a linking device has been introduced. This device is no more than the previously

mentioned PC-based server and introduced in Section 5.3. Since the TETRA Voice Gateway

will need to use a PBX to connect to GSM in the next scenarios, it has already been included

here (Computers A and B in the figure). Both computers are connected via air interface by

3

means of another external technology (probably WLAN). This, however, will be something

completely transparent to the system as said in Section 5.1. The whole architecture is

depicted in Fig. 6.4.

Figure 6.4. Inter-cell TETRA call in the disaster area.

6.2.2 TETRA call between the safe and disaster areas

In this scenario, the element previously referred to as ’Computer A’ is present again,

with Asterisk along with the GSM equipment installed in it (still not used, and thus blurred)

in it. Fig. 6.5 shows this case.

As it can be seen, the TETRA base station controller is directly connected to As-

terisk, as well as the MSC (that belongs to GSM), and then Asterisk directly connected to

the remote area via satellite. It comes without saying that this device is to be located at

the CPCE (the van).

4

Figure 6.5. TETRA remote call.

6.2.3 TETRA - GSM call in the disaster area

Fig 6.6 shows the architecture where both TETRA and GSM mobile stations are

present. The figure pretty much resembles Fig. 6.4 (TETRA inter-cell call in the disaster

area), only instead of having two different cells of the same technology there are two different

technologies being interconnected. This is done again by means of a PC with Asterisk

installed in it.

5

Figure 6.6. TETRA - GSM call in the disaster area.

6.2.4 TETRA - GSM call in the both the safe and disaster areas

Figure 6.6. TETRA - GSM remote call.

6

In this scenario either a TETRA or a GSM mobile station calls another mobile station

in the safe area, or vice versa. This corresponds to Fig. 6.7. No new components have been

introduced in comparison to the previous diagrams except for the presence of the safe area

which is shown on the right side of the illustration.

6.3 Individual calls: A-bis interface over satellite

As for individual calls, this is the last scenario to be studied. In this situation the

A-bis interface - the one between the BTS and the BSC in GSM- has been taken over

satellite. This corresponds to the case of GSM over satellite described in chapter 4. This

means that the GSM BTS, in the disaster area, is being controlled remotely from the safe

area by the GSM core network. To implement this the two devices designed by TriaGnoSys

have been introduced as depicted in Fig. 6.8: the TSGS (Terminal Side GSM Server) in

the disaster area and the NSGS (Network Side GSM Server) in the safe area. As explained

before, they allow GSM/GPRS communications over satellite.

Figure 6.8. GSM equipment in the remote area.

7

6.4 Group calls

Similarly as it has been done for individual calls, in this section only calls involving

satellite communications will be presented. This time, however, three or more users are

to be involved in the communication process, and this heavily complicates the theoretical

approach. Two key points need to be kept in mind.

• First of all, group calls in TETRA are unidirectional, either point-to-multipoint or

broadcast. For example, when User A 01 (see Fig. 6.1 again) select a group and

pushes the group call button, all users included in the group, either in its particular

CPCE or in CPCE B or C, will listen to the conversation automatically (they won’t

have to push any button to accept the call), but they won’t be able to answer back

since communication goes only in one direction.

• Secondly, the group call feature is included within TETRA standard, but it is not in

GSM. This implies that GSM’s ability to make group calls must be added in the form

of an add-on to the technology.

The combined solution for both problems lies in configuring all group call issues in Asterisk.

The most remarkable advantage is this approach is that all group calls, no matter whether

GSM, TETRA or both are involved, will be bidirectional, creating a real multi-conference

call. Although this has not been carried out in the present project, the approach would

consist of creating a series of conference numbers to dial. When calling them, the other

mobiles will have to get the phone (meaning pushing a button to accept it) unlike as it is

just been explained for TETRA.

All in all, the system would work as follows:

• In TETRA, if a user selects a group and pushes the group call button, a unidirectional

call will be established; the other users will only be able to listen to the conversation

but not to answer back.

• In either TETRA or GSM, if a user simply dials one of the conference call numbers, a

normal call among several users will be established as soon as they get their respective

8

phones. In this case the call will be fully bidirectional and a real multi-conference

telephone call will take place.

Group calls have not been tested in the present project. However, the possible scenarios

have been drawn up here for further study. The scenarios only consider the GSM equipment

to be located in the disaster area.

6.4.1 Group calls within the remote area only.

As depicted in Fig. 6.9, any of the terminals in the disaster area, either from TETRA

or GSM, can establish a multi-conference call. In addition,in the case of TETRA terminals,

as explained before, a unidirectional call can be establish too by pressing the group call

button.

Figure 6.9. Group calls within the remote area only.

9

6.4.2 Group calls between the remote and safe areas.

Similarly, Fig. 6.10 shows the case where calls are to be established between the

disaster and safe areas.

Figure 6.10. Group calls between the remote and safe areas.

NB: Even though they are not depicted, there are obviously TETRA/GSM terminals

to the right of the safe area, reachable through the elements named ’PSTN’ and ’External

TETRA networks’. Since the gateway configured in Asterisk is connected to a SIP server

via Internet, all data will go through there and thus whether the external network is of one

type of another is something not to care about. The incoming calls and how it needs to be

redirected has been configured in Asterisk (for individual calls), too.

10