ETSI TR 103 166 V1.1.1 (2011-09)

Satellite Earth Stations and Systems (SES); Satellite Emergency Communications (SatEC); Emergency Communication Cell over Satellite (ECCS)

DTR/SES-00313

General Information

• Status: Published
• Publication Date: 11-Sep-2011
• Technical Committee: SES SatEC - Satellite Emergency Communications
• Current Stage: 12 - Completion
• Due Date: 14-Sep-2011
• Completion Date: 12-Sep-2011

Standards Content (Sample)

Technical Report
Satellite Earth Stations and Systems (SES);
Satellite Emergency Communications (SatEC);
Emergency Communication Cell over Satellite (ECCS)

2 ETSI TR 103 166 V1.1.1 (2011-09)

Reference
DTR/SES-00313
Keywords
emergency, local loop, radio, satellite
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network
drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2011.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TR 103 166 V1.1.1 (2011-09)

Contents
Intellectual Property Rights . 5
Foreword . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Abbreviations . 7
4 Emergency Communication Cells over Satellite (ECCS) . 8
4.1 Introduction . 8
4.1.1 Analogue radio . 8
4.1.2 Digital radio . 9
4.1.3 GSM/UMTS . 9
4.1.4 Satellite phones . 9
4.1.5 Very Small Aperture Terminals (VSAT) and portable satellite systems . 9
4.1.6 Wireless local area networks and DECT . 9
4.2 ECCS challenges and roles . 10
4.2.1 ECCS concept . 10
4.2.2 Overall challenges of an ECCS system. 11
4.2.3 ECCS role model . 11
4.3 ECCS architecture . 13
4.3.1 Introduction. 13
4.3.2 Service interoperability . 14
4.3.3 Connection scenarios . 15
4.3.3.1 On-disaster to/from disaster-safe area connection . 15
4.3.3.2 On-disaster to/from on-disaster area connection . 16
4.3.3.3 Summary of connection scenarios . 16
4.4 Interfaces . 17
4.5 Usability and operational aspects . 18
Annex A: ECCS state-of-the-art . 20
A.1 Commercially available products and solutions . 20
A.1.1 Emergesat . 20
A.1.1.1 Inter-connectivity / inter-operability matrix. 22
A.1.2 Proximity B1 . 22
A.1.2.1 Inter-connectivity / inter-operability matrix. 25
A.1.3 Proximity Drive Away . 25
A.1.3.1 Inter-connectivity / inter-operability matrix. 28
A.2 Research projects . 28
A.2.1 WISECOM . 28
A.2.1.1 WISECOM Access Terminal based on Inmarsat BGAN. 29
A.2.1.2 WISECOM Access Terminal based on DVB-RCS . 30
A.2.1.3 WISECOM inter-connectivity / inter-operability matrix . 32
A.2.2 RECOVER and MOBIDICK . 32
A.2.2.1 RECOVER . 32
A.2.2.2 MOBIDICK . 34
A.2.2.3 Networking RECOVER and MOBIDICK . 35
A.2.2.4 RECOVER or MOBIDICK inter-connectivity / inter-operability matrix . 37
A.2.3 ABCSat . 37
A.2.3.1 ABCSat specifications . 38
A.2.3.2 ABCSat inter-connectivity / inter-operability matrix . 39
A.2.4 OSCAR . 40
A.2.4.1 OSCAR specifications . 40
ETSI
4 ETSI TR 103 166 V1.1.1 (2011-09)
A.2.4.2 OSCAR inter-connectivity / inter-operability matrix . 42
A.2.5 DECISION . 42
A.2.6 Multi-national Telecom Adapter (MTA) . 43
A.2.7 TANGO . 44
A.2.7.1 The TANGO Project Goal . 44
A.2.7.2 The TANGO Project Learned Lesson toward the standardization. 45
A.2.8 TRACKS (transportable station for communication network by satellite). 45
A.2.9 EMERSAT . 46
Annex B: Complete definition of potential scenarios. 48
Annex C: Bibliography . 50
History . 51

ETSI
5 ETSI TR 103 166 V1.1.1 (2011-09)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Satellite Earth Stations and
Systems (SES).
The present document is intended to be used as a report on the current status quo.
ETSI
6 ETSI TR 103 166 V1.1.1 (2011-09)
1 Scope
The present document is intended to outline the concept of Emergency Communication Cells over Satellite (ECCS). An
ECCS is understood as a temporary emergency communication cell supporting terrestrial wireless and wired standard(s)
(e.g. based on IEEE 802.11 [i.4], VHF/UHF, IEEE 802.16 [i.5], GSM, or TETRA), which are linked/backhauled to a
permanent infrastructure by means of bi-directional satellite links. The present document covers the involved roles for
operating an ECCS and describes ECCS architectures based on existing products and introduces the challenges for
providing interoperable services. An annex with existing ECCS solutions concludes the present document.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] Report ITU-R Recommendation M.2033: "Radiocommunication objectives and requirements for
public protection and disaster relief".
[i.2] ETSI TS 102 181: "Emergency Communications (EMTEL); Requirements for communication
between authorities/organizations during emergencies".
[i.3] ETSI TR 102 641: "Satellite Earth Stations and Systems (SES); Overview of present satellite
emergency communications resources".
[i.4] IEEE 802.11: " IEEE Standard for Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area networks-Specific requirements -
Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications".
[i.5] IEEE 802.16: "IEEE Standard for Local and metropolitan area networks - Part 16: Air Interface
for Broadband Wireless Access Systems".
ETSI
7 ETSI TR 103 166 V1.1.1 (2011-09)
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AAA Authentication, Authorization and Accounting
ATA Spec 300 Air Transport Association
NOTE: See https://publications.airlines.org/CommerceProductDetail.aspx?Product=68.
BGAN Broadband Global Area Network
BSC Base Station Controller
BSS Base Station Subsystem
BTS Base Transceiver Station
CNES Centre National d’Etudes Spatiales
DECT Digital Enhanced Cordless Telecommunications
DNS Domain Name System
DVB-RCS Digital Video Broadcasting Return Satellite Channel
ECCS Emergency Communication Cell over Satellite
EMTEL Emergency Telecommunications
ETSI European Telecommunications Standards Institute
GEO Geostationary Earth Orbit
GIS Geo Information Service
GSM Global System for Mobile Communications
HLR Home Location Register
HPA High Power Amplifier
IP Internet Protocol
ISI Inter-System Interface
ITU-R International Telecommunication Union Radiocommunication Sector
LAN Local Area Network
LBS Location Based Service
LSC Local Switching Centre
MNO Mobile Network Operator
MSC Main Switching Centre
MTA Multi-national Telecom Adapter
NAT Network Address Translation
NGO Non-Governmental Organization
PABX Private Automatic Branch Exchange
PEA Pan-European Satellite Telecom Adaptor
PEP Performance Enhancing Proxy
PKC (please remove the bullet point with this acronym)
PLMN Public Land Mobile Network
PMR Professional (or Private) Mobile Radio
PPDR Public Protection and Disaster Relief
PSTN Public Switched Telephone Network
QoS Quality of Service
SatEC Satellite Emergency Communications
SCPC Single Channel Per Carrier
SES Satellite Earth Stations and Systems
SIM Subscriber Identity Module
SMS Short Message Service
SwMI Switching and Management Infrastructure
TCP Transmission Control Protocol
TETRA Terrestrial Trunked Radio
UHF Ultra High Frequency
UMTS Universal Mobile Telecommunications System
VHF Very High Frequency
VLR Visitor Location Register
VoIP Voice over IP
VPN Virtual Private Network
VSAT Very Small Aperture Terminal
ETSI
8 ETSI TR 103 166 V1.1.1 (2011-09)
WiMAX Worldwide Interoperability for Microwave Access
WISECOM Wireless Infrastructure over Satellite for Emergency Communications
WLAN Wireless Local Area Network
4 Emergency Communication Cells over Satellite
(ECCS)
4.1 Introduction
Recent major disasters like the tsunami in 2004, earthquakes in Turkey (1999 and earlier/later years), a hurricane in the
USA (2005), or the earthquake on Haiti (2010), have shown that terrestrial telecommunication infrastructures in the
affected areas are either damaged or overloaded - or not existing at all. Consequently, international rescue teams may
not rely on local services and they have to take their own communication equipment to the operation area.
Emergency Communication Cells over Satellite (ECCS) are intended as instant means to address this problem by
setting up quasi-autonomous communication infrastructure in the field (i.e. incident area) supporting one or more
terrestrial wireless standards. Connectivity with remote emergency control centres is enabled by backhauling these
terrestrial standards via a non-ground based satellite network.
Report ITU-R Recommendation M.2033 [i.1] lists general radiocommunication objectives of Public Protection and
Disaster Relief (PPDR) agencies and organizations. Among other requirements, like interoperability and interworking
between networks, services have to be provided for "wide range of geographic coverage areas, including urban,
suburban, rural and remote environments".
The EMTEL specification TS 102 181 [i.2] clearly states that "access to permanent bidirectional links between
emergency control centres and their mobile teams is crucial in the handling of emergencies and need to be available for
the duration of the emergency/disaster".
There is a variety of communication systems in use by governmental and non-governmental rescue and relief
organizations from different countries and the most common systems in use are briefly described in the following
clauses.
4.1.1 Analogue radio
Analogue Professional Mobile Radio (PMR) systems are simple, robust, still widely deployed and actively used by
rescue organisations. Many of them operate in the VHF or UHF frequency bands. In contrast to regular telephone
systems for analogue radio point-to-multipoint communication is a built-in feature. Radio sets can be operated either
locally in direct (called "tactical") mode or as part of a regional transceiver network (e.g. common-wave broadcasting).
The communication infrastructure is reliable as long as the interconnections of the radio stations and relay transmitters
(repeaters) are available. In case of a disaster these repeaters might be damaged resulting in a restricted (in terms of
range and coverage) but still working communication system. Analogue radios provide mostly voice service in direct or
relayed mode. Data communication are also supported for bit rates below 10 kb/s (e.g. packet radio).
Analogue radios are also used by radio-amateur societies who provide assistance to administrations in case of
emergency (e.g. F.N.R.A.S.E.C in France (http://www.fnrasec.org/), or TRAC in Turkey (http://www.trac.org.tr/).
Transmitted contents are normally not protected by strong ciphering/scrambling schemes so that confidentiality can not
be granted. Contrariwise this can be an advantage especially if members from different organisations without common
hierarchy have to exchange information.
ETSI
9 ETSI TR 103 166 V1.1.1 (2011-09)
4.1.2 Digital radio
Digital PMR systems are successors of these analogue systems and many countries have set up or are setting up digital
PMR networks for team and operation coordination, both for police and non-police organisations (e.g. firebrigades) and
Non-Governmental Organizations (NGO). These systems support similar to their analogue predecessors talkgroups, but
are much more effective in terms of frequency usage. Their major disadvantage is the most likely incompatibility with
existing PMR communication infrastructure outside the regular deployment area since the operation of PMR networks
is, due to obvious security requirements, very much restricted and PMR handhelds typically need explicit clearing
before booking into the network. Ciphering of transmitted content is possible but can turn out to be an obstacle to
information exchange between different user groups too (e.g. in multi-national operations).
In several countries base-stations of digital PMR systems are considered to be critical components which means that
uninterruptible power supplies and redundant network connections are used. Depending on the deployed technology it
is partly possible to run a base-station in island mode without connectivity to the core network. Many digital PMR
systems support a direct mode between terminals without using a base station transceiver too.
4.1.3 GSM/UMTS
Since cell phones are widely available, communication via GSM/UMTS has become popular in disaster situations too.
As an example, the German rescue forces in Phuket during the tsunami were equipped with GSM mobile phones to
coordinate evacuation of victims to Europe.
The major drawback to using public cell phone systems is their full availability to the public without any mechanism for
priority calls. Especially in abnormal situations with high relevance for media, networks easily get into saturation.
There is no possibility to establish calls directly between cell phones, i.e. without the GSM/UMTS network
infrastructure up and running (location registers, network links, power supply) cell phones cannot be used.
Finally, Public Land Mobile Networks (PLMN) do not necessarily implement group calls (push-to-talk functionality),
which is a key requirement for effective operation management.
4.1.4 Satellite phones
International rescue forces are using more and more satellite communications. E.g. almost all air rescue fixed wing
providers in Central Europe do have Iridium mobiles on their aircraft, as it is a reliable communication means
independent of terrestrial infrastructure. Usually satellite phones are used for speech only and not for data
communication. Key advantages are that there is practically no time needed for deployment and mobile usage is
possible. Main drawbacks are that there are usually not enough satellite phones available for the team and
communication is always point-to-point without the possibility to set up group calls.
4.1.5 Very Small Aperture Terminals (VSAT) and portable satellite
systems
VSAT provide satellite based communications for voice and data services. Deployment of a VSAT station can take
from a couple of minutes to few hours depending on the characteristics and capabilities of the equipment (antenna size,
manual or automatic pointing). Data rates of up to a few Mb/s are supported, but VSAT terminals normally require an
external power source for operation or else are limited to a few hours of operations on batteries.
VSAT systems are not intended for landmobile usage, which means that they are deployed for a certain period of time
(e.g. close to a local coordination centre).
4.1.6 Wireless local area networks and DECT
Wireless Local Area Network (WLAN, IEEE 802.11) systems plays currently a minor role for emergency data
communication. With the availability of robust handhelds and emergency management applications this is likely to
change soon. WLAN used for IP telephony has the potential to compete with DECT systems (see below).
WiMAX (IEEE 802.16) is suitable both for mobile devices and directional radio, but at time of writing the present
document there are not too many commercially available WiMAX-based handhelds. Besides setting up a directional
wireless connection might be an option for the recovery phase, but it might be too time consuming during the reaction
phase directly after a disaster.
ETSI
10 ETSI TR 103 166 V1.1.1 (2011-09)
Sometimes rescue organisations use DECT (Digital Enhanced Cordless Telecommunications) phones in the direct
vicinity of local coordination centres. Cell radius in buildings is typically between 30 m and 50 m, outdoors up to
300 m. As before, connectivity to a Public Switched Telephone Network (PSTN) depends on the availability of an
access to this network.
4.2 ECCS challenges and roles
4.2.1 ECCS concept
TR 102 641 [i.3] identifies different categories for telecommunications equipment: fixed, transportable and mobile. The
basic assumption for ECCS is that the ECCS terminal deployed in the field is (trans)portable, ECCS server components
and access to core networks are fixed and only user terminals in the coverage area of ECCS-networks (see Figure 1) are
mobile.
Furthermore [i.3] defines a number of parties and stakeholders during and after a crisis situation and the information
flows between them. An ECCS is intended as a flexible means to support information transfer between remote control
centers/authorities and teams active in the field.
Primarily ECCS are meant to be deployed directly after an incident/crisis/disaster as one of the first actions of the
response phase, but for planned or plannable situations an early set-up as part of the preparedness phase is possible too.
From the above it is clear that with different organisations involved there will be different needs.
Although the single pieces of technology are readily available as successfully shown in several research projects, there
are only a few commercial products on the market combining the advantages of satellite communications and terrestrial
wireless handhelds. In the following, this technical report will provide a non-exhaustive overview of current products
and initiatives dealing with ECCS. In the present document we define ECCS as a combination of a satellite component
and at least one terrestrial wireless service to be deployed in the field. The terrestrial wireless service can be considered
as a small subnetwork which is connected via a satellite backhaul link to its core network. Figure 1 shows a simplified
example ECCS architecture consisting of two satellite terminals:
• one located in the field, interconnected to a wireless network supporting mobile actors equipped with
handhelds (voice, data, or combined);
• one located remotely, interconnected to core networks.

Figure 1: Example ECCS Scenario
In Figure 1, the ECCS terminal deployed in the field is co-located with a local coordination point. For practical reasons
this configuration will be the normal approach, but it is not required for operating an ECCS. Reference [i.3]
distinguishes between different operational authorities (e.g. temporary local operation control vs. remote operation
control) and employer authorities (e.g. fire brigades vs. medical rescue), but throughout the present document we will
not make a difference between user groups.
ETSI
11 ETSI TR 103 166 V1.1.1 (2011-09)
4.2.2 Overall challenges of an ECCS system
The peculiar environment and context of deployment requires versatile solutions, which have to match actual
requirements. Since there will be conflicting design constraints (e.g. size vs. functionality), it is likely that several
classes of ECCS devices will co-exist, for example:
• Portable yet basic ECCS systems: easily packaged in an airborne-cabin-format suitcase, providing voice and
data access via satellite.
• Transportable and elaborate ECCS systems: packaged in an airborne-container format or multiple man-carried
containers. They typically provide a wide range of interoperability services (including among multiple ECCS).
• Mobile ECCS systems with "on the move" access.
Moreover, ECCS models will be declined taking into account criteria such as:
• Power supply: an ECCS with moderate power consumption might be powered by a rechargeable battery which
can be used either for temporary autonomous operation, for bridging the set-up time of a power generator, or
as uninterruptible power supply to cope with unreliable electrical power supply. Generally, power
consumption should be as small as possible.
• Deployment time: an ECCS intended for coordination of immediate first response needs to be deployed as
quickly as possible, whereas an ECCS for medium to long-term usage may require a more time-consuming
set-up phase.
• Environmental protection: an ECCS has to cope with a variety of environmental conditions, e.g. humidity,
high/low temperatures, dust, etc. A dust-tight design and protection against powerful water jets is for outdoor-
components (and possibly for indoor-components too) mandatory; heating or cooling of (electrical)
components may be required too.
4.2.3 ECCS role model
An ECCS role model has to follow typical organisational structures in handling of global, regional or national disasters,
whereby current practice but also ongoing efforts and future plans for an improved (re)organisation of disaster relief
operations should be taken into account. Nevertheless basic design goal should be to support as many as possible
different organisation structures.
Note that the role model discussed in this clause takes only into account the telecommunication point of view. The
various actors and interactions presented in this clause have been identified by considering only the role they play in the
communication system. Taking into account an ECCS system deployed with full functionality the following roles can
be identified (see Figure 2):
• ECCS operator or service provider - being the central role in the considered system and interfacing with all of
the following roles, as illustrated in Figure 2. The ECCS operator acts as a kind of "concentrator" for a
complete and tailored service provisioning - in terms of communications services, content and infrastructure -
to the system users and should be their main/single direct interface.
• Affected persons or citizens, who come in as passive (called) or active (calling) users from a communications
system viewpoint.
• Rescue organisations, including both early phase (immediate search and rescue) and response phase (rescue,
transport and medical treatment etc.); here the main relation is provisioning of services (communication,
coordination, location based services and content) via an ECCS system available to the rescue organisations.
• Coordination centers which mainly coordinate and command field rescue forces.
• PMR operators like national/regional Terrestrial Trunked Radio (TETRA)/TETRAPOL operators, which have
an established operator/provider relationship with the users and obviously should be interfaced also in the
more general ECCS role model and architecture.
• Content providers like geo information service (GIS)/map data providers; providers for location based
services.
ETSI
12 ETSI TR 103 166 V1.1.1 (2011-09)
• Satellite transport service operator/provider providing the key backhauling link from the disaster area to the
disaster-safe segment with a preferably simple and direct relation to the ECCS service provider.
• Internet service provider, providing access to Internet services.
• Public land mobile network (PLMN)/PSTN operator/provider providing voice/data communication and
gateways to the fixed and mobile legacy networks, mobile positioning and messaging.
• For the local access domain, a mobile network operator (MNO) - potentially the same as the previously
mentioned PLMN operator/provider - may come in as a specific player if the ECCS operator/provider does not
act at the same time as a (virtual) MNO itself; here the main relation would be a tailored contract for
provisioning of vendor-specific subscriber identity module (SIM) cards, specific roaming agreements and use
of its licensed frequencies.
• Regulatory authorities taking care of a global licensing process for dedicated reserved emergency frequency
bands (both terrestrial wireless and satellite) or facilitating temporary access to spectrum (e.g. through the
Tampere convention) only in emergency situations, etc.
It is clear from the above that as many roles as possible should be covered by one single organisation or company.
Every single interaction between the different roles has to be formalised with a framework contract and this needs to be
done early in advance.
Figure 2: Example ECCS role model and interaction/communication channels
The interactions and communication channels between the different roles depicted in Figure 2 are as follows:
1) Affected persons may be integrated in the ECCS communication system by means of their standard equipment
(mainly mobile phones), which may be used both in active and passive modes (active calling/sending SMS or
being called/located within a certain cell or receiving information/warning SMS).
2) ECCS provider/operator and rescue organization(s) interact through a contractual relationship and
communication via different means (voice, data, etc.), both in the field and in the disaster-safe area.
3) Coordination center(s) may interact with the ECCS provider indirectly via a rescue organization (or directly,
see 5).
4) Coordination center(s) either maintain their own PMR network or are customers of a dedicated PMR operator.
5) Coordination center(s) may have a contract with the ECCS operator and use the communication services
provided by the ECCS operator.
6) PMR operators interact with the ECCS operator either directly or via the coordination center (4).
ETSI
13 ETSI TR 103 166 V1.1.1 (2011-09)
7) Data from content/data providers is transmitted via the ECCS system. This might be done either directly so
that local operation controllers in the field can take decisions from the transmitted data, or indirectly via the
coordination center (not shown).
8) If more than one ECCS provider/operator is involved, then coordination among them might be necessary for
deployment and location of ECCS terminals in the field, frequency usage (e.g. WLAN), etc.
9) Frequency bands to be used by ECCS terminals both for satellite and terrestrial communication are most likely
subject to local regulatory issues (except for unlicensed frequencies).
10) Connectivity to PLMN/PSTN and gateways has to be agreed between ECCS operator and the respective
network operator.
11) A gateway to the public Internet needs to be agreed with an Internet service provider.
12) Finally, a provider for backhaul capacity has to be involved.
4.3 ECCS architecture
4.3.1 Introduction
An example architecture of an ECCS system, as illustrated in Figure 3, is typically based on a modular approach where
at least one access and one transport solution can be supported. The ECCS middleware should be able to interwork
between the various terrestrial access and satellite transport solutions. Different rescue and humanitarian organizations
have different requirements and the depicted modular architecture allows both full scalability and is open for possible
future extensions.
Despite the multitude of technical solutions that could be used to implement an ECCS system, several logical blocks
can be distinguished. In the following we define these logical blocks, so that a common high-level ECCS reference
architecture and terminology is introduced.
An ECCS system enables the communication between the disaster end-users (affected persons, victims, rescue teams or
any other kind of involved people) located inside or outside the disaster area using different sorts of communication
devices; the transmission path involves a number of network elements, which compose an ECCS communication chain.
The domains represent network elements involved in the ECCS communication chain and playing logically
neighbouring functionalities in this chain (e.g. a WLAN access point and a GSM base station) or jointly enabling the
provision of a given functionality (e.g. local access) belong to the same domain.
An interface between the two main segments is provided by the transport (backhaul) domain. One part of the network
elements of the Transport Domain is located in the On-Disaster Site Segment whereas another part is located in the
Disaster-Safe Segment. Throughout the present document we do not make a difference whether a satellite terminal is a
VSAT terminal or a gateway/hub station.
The segments represent sections of the ECCS communication chain involving network elements physically located in
(roughly) the same geographical area with respect to the disaster. All network elements in the same segment are subject
to similar usage constraints.
White boxes in each domain represent possible groups of network elements with complementary or similar
characteristics. Inside a network domain group there might be several network elements involved in the communication.
In Figure 3 in the transport domain a number of N satellite systems is depicted, serving a number of M different ECCS
terminals in the disaster-safe segment with N ≤ M, since ECCS terminals might be directly interconnected without
involving a remote ECCS system. These direct interconnections can be both satellite or terrestrial wired/wireless links.
ETSI
14 ETSI TR 103 166 V1.1.1 (2011-09)
…
…
.
.
Figure 3: Example ECCS functional diagram
4.3.2 Service interoperability
The main challenge for ECCS is not only backhauling single services via satellite, but also providing interconnectivity
and interoperability between different services. This interoperability is provided by gateways, which are defined as
network nodes equipped for interfacing with other networks using different technologies/protocols.
For IP-based data networks interconnectivity between ECCS terminal, ECCS server and IP core networks (Internet) is
comparable to terrestrial installations. When using source network address translation (Source-NAT), which is typically
applied to handle a shortage of IPv4 addresses, two different architectures are possible:
• The NAT router is located at the ECCS server and subsequent ECCS terminal(s) and other systems attached
form a private subnet.
• The NAT router is located at the ECCS terminal.
In general, a satellite link within an IP data-network needs special attention. In order to cope with the large bandwidth
delay product of Geostationary Earth Orbit (GEO) satellites, performance enhancing proxies (PEPs) are needed for
accelerating TCP/IP. On the one hand the broadcast nature of satellites requires encryption of transmitted contents, on
the other hand encryption standards like link Virtual Private Network (VPN) collide with resource management
algorithms and bandwidth optimization techniques like header compression. Furthermore, applications using out-of-
band signalling and return channels can suffer from NAT (e.g. VoIP protocols), but a detailed discussion of all these
implications is out of the scope of the present document.
Voice communication is supported by different technologies: PSTN, PLMN, IP telephony and PMR. The first three
standards are widely distributed and interoperability between them is supported by public gateways, whereas PMR
systems exist in many different variants which are not necessarily interoperable among each other. PMR networks are
designed for closed user groups with partly specific confidentiality requirements so that gateways to other voice
networks are always subject to security policies implemented by the operator. Furthermore additional PMR service
attributes like group calls can hardly be mapped to calls in telephone networks.
Public gateways between PSTN and PLMN exist in core networks, so for an ECCS operator there is normally no need
to set up his own gateways - unless there is a specific requirement that the ECCS terminal has to support calls in the
field between these two standards without satellite connectivity. The same considerations apply to gateways for VoIP.
Connectivity in the field between two PSTN terminals can be provided by a private branch exchange as part of the
ECCS terminal. This approach allows both "internal calls" (i.e. without backhaul link) and external calls via satellite.
PLMNs do not implement the concept of private branch exchanges, which means that a base station attached to an
ECCS terminal is either operated in a full autonomous mode without any connectivity to the core PLMN, or it is
integrated in the core PLMN via the backhaul satellite link. In the latter case for local calls signalling information has to
be sent via satellite although the data (voice) traffic itself is switched within the ECCS base station.
IP telephony service properties are subject to the actually implemented protocols and standards (VoIP examples: H.323,
SIP). Call switching can be performed locally at the ECCS terminal, at the ECCS server, or in the core network. Public
gateways to PLMN/PSTN exist, but depending on requirements gateways can be set up at ECCS terminal or server too.
ETSI
15 ETSI TR 103 166 V1.1.1 (2011-09)
4.3.3 Connection scenarios
The following clauses give examples for different ECCS connection scenarios. There are two major categories: on-
disaster to/from disaster-safe area and on-disaster to/from on-disaster area. The latter case may involve the deployment
of multiple ECCS terminals that are connected by means of satellite or terrestrial links.
Four different types of core networks are assumed: PLMN, PSTN, Internet and PMR. Matching representative wireless
access technologies chosen for these networks are GSM, DECT, WLAN and a not specified PMR standard. Note that
wired access devices might be attached to the ECCS terminal too (e.g. normal wired analogue telephones), or that end
devices can have built-in gateway functionality (e.g. cordless DECT telephones with IP interfaces).
The scenarios that are presented in the next clauses make use of a reduced set of entities Figure 3. For a network
scenario including multiple terrestrial technologies and several ECCS systems from different operators,
see Figure 6.
4.3.3.1 On-disaster to/from disaster-safe area connection
An initial scenario is illustrated in Figure 4 where a PSTN terminal (e.g. a cordless phone) in the field is connected to a
terminal in the PLMN core network (in the disaster-safe segment, not shown).
Elaborate variations of this scenario comprise the case where multiple ECCS terminals are deployed and linked using
terrestrial technology. Connection to core networks may be routed to an ECCS terminal other
...