Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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