FP7-ICT-2011-8-318632-ABSOLUTE/D6.7 End user application ... · FP7-ICT-2011-8-318632-ABSOLUTE/D6.7...
Transcript of FP7-ICT-2011-8-318632-ABSOLUTE/D6.7 End user application ... · FP7-ICT-2011-8-318632-ABSOLUTE/D6.7...
Integrated Project
ABSOLUTE - Aerial Base Stations with Opportunistic Links for
Unexpected & Temporary Events
Contract No.318632
Deliverable
FP7-ICT-2011-8-318632-ABSOLUTE/D6.7
End user application description report
Contractual date: 30/09/2014 (M24)
Actual date: 15/10/2014 (M24)
Authors/Editors: Philippe Charpentier (TCS), Raquel Ramos Ramos, Vincent
Boussemart, Macià Mut Vidal (TGS)
Participants: TCS, TGS
Work package: WP6 – T6.4
Security: PU
Nature: Report
Version: 1.0
Total number of pages: 46
Abstract
The present document reports about end user applications development and integration within the
ABSOLUTE project.
Services and applications that will be developed and integrated within the Absolute project are
described in details. Architecture considerations for their integration in the context of a full IP
distributed network are presented. The physical implementation of the demonstration use cases with
an end-user perspective is finally described.
Keywords
Absolute; end-user applications; demonstration cases; SIP; victim GUI; PPDR GUI; MCPTT
Ref. Ares(2014)3930546 - 25/11/2014
ABSOLUTE D6.7
Dissemination Level PU Page 2
Table of Contents
Table of Contents .................................................................................................................................... 2
List of Figures ......................................................................................................................................... 3
Abbreviations .......................................................................................................................................... 5
Executive summary ................................................................................................................................. 7
1. Introduction ..................................................................................................................................... 8
1.1 Scope of the Document ........................................................................................................... 8
1.2 Structure of the Document ...................................................................................................... 8
2. Architecture considerations for end user applications ..................................................................... 9
2.1 Summary of user needs related to applications ....................................................................... 9
2.2 Services over LTE ................................................................................................................... 9
2.3 LTE Rel12 improvement ....................................................................................................... 10
3. Applications identification ............................................................................................................ 12
3.1 Existing applications ............................................................................................................. 12
3.2 Absolute services (ABSys application) ................................................................................. 13
3.2.1 Introduction ................................................................................................................... 13
3.2.2 SIP enabled services ...................................................................................................... 13
3.2.3 Internet Access .............................................................................................................. 15
3.2.4 Satellite Backhauling Link ............................................................................................ 18
3.2.5 ABSys Web-Enabled Services ...................................................................................... 18
4. System integration of applications ................................................................................................ 25
4.1 Architecture principles .......................................................................................................... 25
4.1.1 Centralized typical architecture ..................................................................................... 25
4.1.2 Absolute distributed architecture ................................................................................... 26
4.2 Architecture for applications’ demonstration ........................................................................ 30
4.2.1 Introduction ................................................................................................................... 30
4.2.2 Demonstration Cases (DUC) with Related Architecture for Applications .................... 34
5. Conclusions ................................................................................................................................... 44
References ............................................................................................................................................. 45
Acknowledgement ................................................................................................................................. 46
ABSOLUTE D6.7
Dissemination Level PU Page 3
List of Figures
Figure 1-1: WP6 organization ................................................................................................................. 8
Figure 2-1: LTE network generic architecture (simplified) ..................................................................... 9
Figure 2-2: SIP enabled services over IP .............................................................................................. 10
Figure 2-3: A GCSE architecture proposal from 3GPP TS 23.768 ....................................................... 11
Figure 3-1: APCOMM referenced PTT applications - extract from [1] ................................................ 12
Figure 3-3: Voice Calls and SMSs ........................................................................................................ 14
Figure 3-4: Internet Access ................................................................................................................... 16
Figure 3-5: Two VPN tunnels to remote site......................................................................................... 17
Figure 3-6: One VPN tunnel to remote site ........................................................................................... 18
Figure 3-7: Messages and Locations ..................................................................................................... 19
Figure 3-8: First Responders GUI Messaging tab ................................................................................. 20
Figure 3-9: The Victim’s GUI ............................................................................................................... 20
Figure 3-10: Area Monitoring ............................................................................................................... 21
Figure 3-11: First Responders GUI Map tab ......................................................................................... 22
Figure 3-12: First Responders GUI, Map tab sensor data ..................................................................... 22
Figure 3-13: System Management ........................................................................................................ 23
Figure 3-14: First Responders GUI System tab .................................................................................... 24
Figure 4-1: Typical Telco carrier base network .................................................................................... 25
Figure 4-2: Absolute hybrid architecture: local EPC / Applications servers......................................... 26
Figure 4-3: Flexible Management Entity architecture ........................................................................... 27
Figure 4-4: Cell sites grouping example ............................................................................................... 28
Figure 4-5: Absolute distributed architecture with global management center ..................................... 29
Figure 4-6: An illustration of the general demonstration setup with satellite-capable AeNBs ............. 30
Figure 4-7: Absolute demonstration physical architecture .................................................................... 31
Figure 4-8: PLMU high level functional architecture ........................................................................... 32
Figure 4-9: AeNB1 high level functional architecture .......................................................................... 33
Figure 4-10: DUC#1: Scene to remote peer via satellite without LTE network coverage .................... 34
Figure 4-11: DUC#2, featuring D2D communications with MM-UEs ................................................. 35
Figure 4-12: DUC#3: telephony, one-to-one and many-to-many, over LTE ........................................ 36
Figure 4-13: DUC#4 video streaming and remote control .................................................................... 39
Figure 4-15: DUC#5 access to wireless sensor network (WSN) and corporate data ............................ 40
ABSOLUTE D6.7
Dissemination Level PU Page 4
Figure 4-16: DUC #6 communications over multiple technologies ...................................................... 42
ABSOLUTE D6.7
Dissemination Level PU Page 5
Abbreviations
ABSOLUTE Aerial Base Stations with Opportunistic Links For Unexpected & Temporary Events
AC AeNB Controller
AeNB Aerial eNodeB
API Application Programming Interface
CCO Control Center Operator
D2D
DUC
Device to Device
Demonstration Use Case
DHCP Dynamic Host Configuration Protocol
EAB External Advisory Board
EMS Emergency Medical Services
EPC Evolved Packet Core
FF
FME
FireFighter
Flexible Management Entity
FP Field Physician
FR First Responder
FTP File Transfer Protocol
GEO GEostationary Orbit
GPS Global Positioning System
GUI Graphical User Interface
HQ HeadQuarter
HTTP HyperText Transfer Protocol
I/O Input/Output
I/Q Inphase and Quadrature
IMSI International Mobile Subscriber Identity
LAP Low Altitude Platform
LTE Long Term Evolution
LTE-A Long Term Evolution Advanced
MAC Medium Access Control
MM-UE Multi-Mode User Equipment
MME Mobility Management Entity
MMS Multimedia Messaging Service
MT Maintenance Technician
PBX Private Branch eXchange
ABSOLUTE D6.7
Dissemination Level PU Page 6
PLMN Public Land Mobile Network
PLMU Portable Land Mobile Unit
PPDR Public Protection and Disaster Relief
PO Police Officer
POV Point Of View
PS Public Safety
PSU Power Supply Unit
ProSe Proximity Services
PTZ Pan Tilt Zoom
QoE Quality of Experience
QoS Quality of Service
RRH Remote Radio Head
SIM Subscriber Identity Module
SIP Session Initiation Protocol
S-MIM S-band Mobile Interactive Multimedia
SM Social Media
SMS Short Message Service
TEI TETRA Equipment Identity
TeNB Terrestrial eNodeB
TETRA TErrestrial TRunked RAdio
TMO Trunked Mode Operation
UAV Unmanned Aerial Vehicle
UE User Equipment
UMTS Universal Mobile Telecommunications System
UR User Requirements
VIP Very Important Person
VoIP Voice over Internet Protocol
WLAN Wireless Local Area Network
WSN Wireless Sensor Network
ABSOLUTE D6.7
Dissemination Level PU Page 7
Executive summary
The main goal of Project ABSOLUTE is to design and validate a holistic and rapidly deployable
mobile network to provide broadband services based on a flexible, scalable, resilient and secure
network design. The most important elements that ABSOLUTE will pioneer are:
LTE-A base station embedded in Low Altitude Platform enabling wide coverage for
broadband services
Portable land mobile base stations interoperable with conventional public safety networks
Advanced multi-service professional terminals for first responders.
The usage of satellite communications for both broadband backhauling as well as narrowband
ubiquitous messaging services is another essential enabler.
Within Absolute project, the goal of Work Package 6 (WP6) is to integrate the sub-systems developed
in WP5 in order to allow the lab tests and field trials planned in WP7. This will include the following
tasks:
Integration of all components needed for the Aerial platform under task T6.1 led by HHI,
Integration of all necessary components for the portable land mobile station under task T6.2
led by TGS,
Integration of all necessary components for the Multi-Mode User Equipment under task T6.3
led by TCS,
Development of the end user applications (video, voice, messaging etc.) under task T6.4 led
by TCS,
Tests of each segment in order to prepare the system validation in WP7 under task T6.5 led by
MIT.
The present document D6.7 produced under task T6.4 of WP6 reports about first development of end
user applications as well as the end user applications’ integration.
ABSOLUTE D6.7
Dissemination Level PU Page 8
1. Introduction
1.1 Scope of the Document
The present document is deliverable D6.7 of the Absolute project. It reports the earliest achievement
concerning development of end user applications as well as their integration.
It encompasses integration of third party’s application such as video streaming, voice communications
and messaging solutions as well as dedicated applications developed in the frame of Absolute project
(so-called ABSYS): victims and first responders’ applications, management applications. It deals also
with some system architecture guidelines to perform the demonstration conducted by WP7.
As described in following picture, this document relies on inputs given by T6.1, T6.2 and T6.3
documents concerning characteristics of the PLMU (D6.3.1), the AeNB (D6.1.1) and MMUE (D6.5)
and will serve as an input for WP7, notably to prepare the final demonstration.
Figure 1-1: WP6 organization
1.2 Structure of the Document
The document is structured in 5 chapters as follows:
Chapter 1 Introduction
Chapter 2 Architecture considerations for applications and services integration versus user-
requirements
Chapter 3 Identification of applications for public safety: inventory of existing ones and presentation
of developed ones within Absolute
Chapter 4 System integration of the applications: discussion on the need of a distributed
architecture and description of demonstration use cases with end-user point of view
Chapter 5 Conclusion
TCSWP6
HHI
TGS
ABSOLUTE D6.7
Dissemination Level PU Page 9
2. Architecture considerations for end user applications
2.1 Summary of user needs related to applications
The user needs were captured through user requirements (UR) in deliverable FP7-ICT-2011-8-
318632-ABSOLUTE/D2.2.2 with the help of an External Advisory Board (EAB), gathering users in
four continents in widely varying disciplines including police, fire, civil protection, regulatory bodies
and a large events’ organiser.
Through these URs collection, the user needs in terms of applications can be summarized as follows:
Public safety functionalities: voice radio with group call, direct mode of operation between
devices (D2D), call pre-emption, enhanced security (through encryption or other means). Most
of these features are expected in future LTE release 12 with the so-called Proximity Services
(ProSe) and Group Communication System Enablers for LTE (GCSE).
Advanced services: voice telephony, teleconference, short text messaging with multimedia
attachments (SMS/MMS), file transfer, still image sending, live video, intranet / Internet
access (mission dedicated database, social networks etc…), personnel location, situation
awareness on map display, remote control of devices such as cameras / robot, etc…
2.2 Services over LTE
A generic (simplified) LTE architecture is depicted in following picture.
Figure 2-1: LTE network generic architecture (simplified)
AeNB MME
HSS
Radio Access Network Core Network
S-GW P-GW
AuC
LocalServers
S1-U S5
S11
EPC
S6a
S1-MME
TeNB
MMUE
App ServersStreaming
IPBX
Internet
X2
UE: User EquipmentMMUE: Multi Mode UETeNB: Terrestrial eNodeBAeNB: Aerial eNodeBP-GW: Packet Data Network GateWayS-GW: Serving GateWayMME: Mobility Management entityHSS: Home Subscriber Server
SGi
User tunneled traffic (via S1-U, S5)
Services Network
IP traffic (via SGi)
ABSOLUTE D6.7
Dissemination Level PU Page 10
EPC as the core network enables connectivity of the UE. Particularly, the P-GW grants the UE with an
IP address and manages the Network Address Translation (NAT).
EPC provides a seamless, secure and resource guaranteed subscription-based wireless IP connectivity
by adopting standard protocols and interfaces. Additionally, it provides the capabilities to access
networks from any service platform (be it IMS-based for the Session Initiation Protocol (SIP),
proprietary platforms or from the plain Internet) and to optimize service delivery support for a broad
range of IP applications. EPC provides also mobility management, QoS, charging and security support
and the integration of multiple application platforms.
Having a full IP network, SIP can be used as an open communications protocol for interactive
services. Regarding the Absolute requirements, the basic SIP functionalities are very interesting:
Call setup: establishment and management of communications parameters (e.g. codec),
User presence/availability: establishment of user presence and availability,
User location and mobility: establishment of UE current IP address and support of terminal
mobility,
Multimedia support: voice, e-mail, instant messaging, video and any other form of application
with session characteristics.
SIP gives the framework to enable services for group collaboration: unified messaging, chat,
multimedia conferencing, IP-PBX… Even push-to-talk can be enabled by SIP and is normalized under
the name PoC (Push to talk over Cellular) by the OMA (Open Mobile Alliance).
This is summarized on following picture where we can see the SIP-enabled services offered to the
users through LTE.
Figure 2-2: SIP enabled services over IP
2.3 LTE Rel12 improvement
With LTE Release 12, 3GPP will introduce effective means for group communication services and
proximity services, to cover critical communications needed by public safety first responders as well
as other users such as utility companies and railways.
AeNBSIP
ServerTeNB
MMUE
X2 SGiEPC
S1-MME
S1-U
Voice
Video
Messaging
ConferencingPTT
SIP-enabled services
ABSOLUTE D6.7
Dissemination Level PU Page 11
Group call and a Mission Critical Push To Talk (MCPTT) will be introduced. Requirements for
MCPTT will include the following areas:
Push To Talk (PTT) group and PTT individual communications;
Services, including talker identification, location, and emergency alerting for mission critical
voice communication;
Special privilege handling (For console interaction - e.g, override, monitor, exception
handling, etc);
Floor control, priority and pre-emption;
Performance, including call establishment times and permission to talk request to permission
granted times;
Security, including confidentiality of voice communications;
With higher performances, security and priority/pre-emption handling, it is expected that REL12 will
provide the needed PTT service for PPDR.
The service requirements of release 12 corresponding to public safety services are approved and
defined in Group Communication System Enablers for LTE (GCSE_LTE, TS 22.468) for MCPTT and
group call and Proximity Services (ProSe, TS22.278, TS22.115) for direct mode.
A high-level architecture diagram for a GCSE architecture proposal is depicted below. The GCSE
architecture diagram shows modifications of previous LTE architecture at application layer and 3GPP
Evolved Packed System (EPS) layer. The Application layer consists of GCSE application server. At
EPS layer, a function interacting with EPC current elements (MME, S-GW, P-GW) is added to
provide the Multipoint Service (MuSe) functionality.
UE eNBMBMS
GWBM-SC
GCSE
Application
server
MME P-GW
Uu GC3
S1-MME
SG-imb
SGi
SG-mb
GC2
S-GW
GC4 S11 S5
S1-U
GCSE
Application
UE
GCSE
Application
ProSe Communication
UEGC1GCSE
Application
MuSe
GC5Media
Figure 2-3: A GCSE architecture proposal from 3GPP TS 23.768
This architecture will enable efficient group communication, dynamic groups with mobile users and
dispatchers, support for large groups.
ABSOLUTE D6.7
Dissemination Level PU Page 12
3. Applications identification
3.1 Existing applications
Everybody has already experienced group call, videoconference or instant messaging in his day to day
life on his smartphone or tablet with such commercial applications such as Skype®, WhatsApp
Messenger®, Viber® etc…
The Association of Public-Safety Communications Officials (APCO), the largest organization of
public safety communications professionals and supports, has gathered APCO Application
Community (APPCOMM) and dedicated a website http://appcomm.org/ to make the inventory of
various interesting applications for public safety.
As one can see on following picture, four applications are displayed when doing a research with the
tag PTT.
Figure 3-1: APCOMM referenced PTT applications - extract from [1]
These applications propose a push-to-talk service which enables the user to talk to anyone in his group
using live voice, text, photos and location sharing from his smartphone or tablet with a simple WiFi or
3G/4G data connection. Some applications propose also situation awareness services, team
collaboration, and other functions that can prove to be useful for public safety missions (e.g. “Dragon
Force”, “NowForce Mobile Responder”, “Geosuite”).
The software architecture is as follows: an application installed on the smartphone communicates with
the application server located on a cloud. Some vendors sell the application server in order to install it
in one’s own information system and claim that their application is in use by police or fire department
already.
So there exist already interesting applications that take benefit from the LTE IP architecture.
ABSOLUTE D6.7
Dissemination Level PU Page 13
3.2 Absolute services (ABSys application)
This section describes the services and functionalities that the PLMU as a stand-alone unit can
provide. The PLMU users (e.g. First responders and Victims) can interact with the communication
components of the PLMU for profiting from the services and functionalities that it can offer to them.
Moreover, it gives an overview of the PLMU end user application, the ABSys, and the different
Graphical User Interface (GUI) that the user can have access to.
3.2.1 Introduction
The services that the PLMU can provide can be divided into two different groups: those using the SIP
protocol and therefore managed by a SIP server and those that are not.
The implementation of the following communications services enabled by a SIP Server and specific to
PPDR services (see D5.2.2 for implementation technical details) is foreseen:
Voice communications,
Communications interoperability,
SMS/MMS communications,
Group communications,
Unicast Video streaming.
Additional services such as Broadcast video streaming, Push-To-Talk or Pre-emption functionalities
may be also enabled by the SIP server, although this is still not clear and needs to be further studied
and tested during the upcoming months.
Then, services that are provided to the user but not based on the SIP protocol are:
Internet access,
Caching functionality,
Secure communications and access to remote site,
Geo-located messages including pictures and videos,
Area monitoring,
System management.
3.2.2 SIP enabled services
One of the services that the PLMU can offer to its users is related to voice calls and SMS support. This
is described in requirement SYS_F_19200 as ABSOLUTE shall provide voice and data
communications including voice, short messages (SMS/MMS)... Any user connected to the PLMU
using any of the integrated communications technologies (i.e. UMTS, WIFI, TETRA or LTE-A) can
ABSOLUTE D6.7
Dissemination Level PU Page 14
communicate with any other user of the PLMU through voice calls. In the same way, any user can also
communicate with any other through text messages.
These services are depicted in Figure 3-2. This diagram shows the version 1 of the PLMU, where only
WIFI and UMTS are available as communication technologies, and therefore only the following
interoperability can be shown:
Wi-Fi to Wi-Fi,
Wi-Fi to UMTS (and vice versa),
UMTS to UMTS.
Figure 3-2: Voice Calls and SMSs
When new communication technologies are integrated, the interoperability depicted above is extended
to any possible combination of all the available technologies.
This interoperability feature explained above for voice calls also applies to text message
communication. Any communication technology can be used to send a text message to any other user
using the same technology or any other.
Table 3-1: Text message types
Technology Text message type
3G Short Message Service (SMS)
LTE SMS over SIP
TETRA Short Data Service (SDS)
WiFi SMS over SIP
Internet
WLAN Router
PLMU User Interface
Single Board Computer
3G+Femtocell
3G
Wireless Sensor Network
First RespondersVictims
First Responders
Power Monitoring Unit
WiFi
. . .
. . .
. . .
EXTERNAL LOCAL
LOCAL
INTEROPERABILITY
ABSOLUTE D6.7
Dissemination Level PU Page 15
The compatibility between all the text message types shown in Table 3-1 is enabled by the SIP server.
Although, the compatibility through the SIP server with the TETRA messages (SDS) still need to be
tested.
In addition to the services previously described, group calls are also available for the PLMU users.
This service described in requirement SYS_F_19230 as the user shall be able to initiate a voice
communication with multiple other users is supported by the PLMU. These group calls are voice
communication with any number of users and, in addition, regardless of the communications
technology that they use.
One of the ways for a user to initiate a group call is by dialling a previously defined group extension
that initiates a group call by inviting all the users previously registered to that group.
Regarding the video streaming service, unicast video streaming has been already tested and can be
provided by the SIP server using appropriated SIP clients. Several have been tested and the results
were satisfactory. However, the broadcast functionality needs to be implemented on the SIP server
side and no SIP client supporting this functionality has been found so far. Therefore, it is still not clear
if this functionality can be supported and, in case it can be, there would be still some implementation
work on both the server side and client side.
The Push-to-talk functionality has been tested being emulated through several apps providing this
service. However, this can be better integrated into the system if it is provided by the SIP server. This
possibility needs to be further studied during the upcoming months of the project.
3.2.3 Internet Access
Another functionality identified during the collection of the user requirements is described in
requirement SYS_F_19030, which states that ABSOLUTE AeNB and PLMU shall be able to interface
to internet, and private VPN. For this, the PLMU has an interface, over the satellite backhauling link,
to the internet. This access to the internet is available for the first responders and technicians
regardless of the communication technology that they use, as depicted in Figure 3-3, but not available
for the victims as the bandwidth needs to be assured first for the disaster-relief operations.
ABSOLUTE D6.7
Dissemination Level PU Page 16
Figure 3-3: Internet Access
The router acts as a central node and is in charge of managing all the traffic to and from the internet
and applying the corresponding rules for each user. Therefore the router can be seen as a gateway
interfacing the Wide Area Network (WAN, i.e. Internet) with the Local Area Network (LAN, the on-
site network).
The router is configured in NAT mode (Network Address Translation), meaning that internal
addresses will be replaced by the one of the router when the traffic goes out, and the other way around
when the traffic comes in. This way the router insures security for the components and sub-
components belonging to the LAN by preventing access from the WAN. Different firewall rules
protect the entire local network, e.g. by rejecting ping requests.
Some forwarding rules can be present such that the servers present in the LAN can be accessed from
outside, for instance:
SIP: the SIP server hosted by the PLMU is reachable from outside,
VPN: the VPN server hosted by the PLMU is accessible by an external VPN client.
The VPN tunnels can be established in both directions: from the remote-site (VPN Client) to the on-
site area (VPN Server) or from the on-site area (VPN Client) to the remote-site (VPN Server). The
latter configuration is preferred and used in the ABSOLUTE system, as documented in D5.2.2 (for
more information about Virtual Private Networks, please refer to D4.5.1 which presents the concept,
D5.2.2 which shows the design, D5.2.4 which describes the configuration and D6.3.1 which addresses
the implementation). The other configuration, where the VPN server is at the PLMU, is only used for
testing purposes.
The next subsection also gives some more details about the VPN setup in the ABSOLUTE
architecture.
Internet
WLAN Router
PLMU User Interface
Single Board Computer
3G+Femtocell
3G
Wireless Sensor Network
First RespondersVictims
First Responders
Power Monitoring Unit
WiFi
. . .
. . .
. . .
ABSOLUTE D6.7
Dissemination Level PU Page 17
3.2.3.1 Virtual Private Networks
Communication should be protected using Virtual Private Networks (VPNs) for the link between the
on-site segment and the remote-site segment. We assume the local communications (on-site) have
their own security features: WPA2 for Wi-Fi, encryption/ciphering for LTE, TEA for TETRA, etc.
The communication means between on-site areas should also be secured, using the same security
mechanisms. Therefore VPN is only required when the PLMU needs to access the remote-site, via
satellite backhauling for instance. Since PLMUs should be stand-alone, each PLMU having the
capability to access remote sites shall embed a VPN client with the proper configuration. If an
interlink is available between the PLMUs, i.e. their coverage areas overlap, then one single VPN
connection is mandatory and it is more convenient to switch to the one offering the highest bandwidth
(datarates). For instance we consider three units:
1. PLMU: PLMU with all features, connected to remote site via portable satellite antenna,
2. LAP 1: backhaul provided by a light version of the PLMU, connected to remote site via a
“fixed” satellite antenna providing higher data rates than the previous setup,
3. LAP 2: backhaul provided by a light version of the PLMU, installed on top of a building for
instance, not connected to remote site.
In this scenario, we can have several cases. By default, the PLMU (1) and the LAP 1 (2) will be
connected to the remote site using their own VPN connection, thus two VPN tunnels will be built
between the on-site segment and the remote-site segment (Figure 3-5).
Another case would be that if a link can be established between all the units, then the WAN traffic of
all of them can be redirected to the PLMU, which can in turn forward it, using its own VPN
connection, to the remote site, depicted in Figure 3-6.
Figure 3-4: Two VPN tunnels to remote site
ABSOLUTE D6.7
Dissemination Level PU Page 18
3.2.4 Satellite Backhauling Link
As provided in D4.3.1 [6], different techniques for optimizing the satellite backhauling link were
studied. Based on the fulfilment of ten selected performance indicators and after several experiments
performed in order to assess these techniques, Squid was selected as the one offering the best solution
for our specific case, higher benefits and easier integration. Therefore, this technique is also integrated
into this demonstrator providing an optimization of the satellite link usage.
As provided in [6], this optimization can go up to 11% of reduction of the traffic transferred through
the satellite backhauling link depending on the kind of this traffic.
In addition, it also includes security mechanisms for using this satellite backhauling link. This security
is implemented by using VPN as a pipe connecting to the external Head Quarters, as mentioned in the
previous section.
3.2.5 ABSys Web-Enabled Services
The ABSys provides a sort of end-user Web applications in form of Graphical User Interfaces aimed
to give services for the First Responders and Victims of the ABSOLUTE network. These services, the
subcomponents involved on them and the Web applications are described within this subsection.
3.2.5.1 Messages and Location
The PLMU requirement PU_F_7040 states that The PLMU shall allow viewing location data on a
map. This has been implemented also for the messages sent by the PLMU users, both the First
responders and the victims. This implementation is based on the ABSys application which allows the
users to send geo-location with their message. Once the message is received at the server side, the
First responders can visualize the position of all of them on a map. Each single message is also
displayed on a board and showing a small map with its location.
Figure 3-5: One VPN tunnel to remote site
ABSOLUTE D6.7
Dissemination Level PU Page 19
Figure 3-6 depicts this functionality with all the elements involved. As seen in the diagram, this is
based on the usage of the ABSys application through which all the geo-located messages can be sent
and received by the users.
Figure 3-6: Messages and Locations
An example of how the First Responders GUI in the messages and location tab looks like is given in
Figure 3-7. For further information about the FRs GUI and the messaging tab functionalities refer to
the document [7].
Internet
WLAN Router
PLMU User Interface
Single Board Computer
3G+Femtocell
3G
Wireless Sensor Network
First RespondersVictims
First Responders
Power Monitoring Unit
WiFi
. . .
. . .
. . .
DISTRESSMESSAGES
FIRST RESPONDERSMESSAGES
ABSOLUTEApplication ABSOLUTE Application
ABSOLUTE Application
ABSOLUTE Application
ABSOLUTE D6.7
Dissemination Level PU Page 20
Figure 3-7: First Responders GUI Messaging tab
Victims can send Distress Messages connecting to the open WiFi network of the PLMU trough the
Victims GUI using their smartphone, tablet, etc. The Victims GUI aspect is depicted in Figure 3-8.
More information about its functionality is provided in document [7].
Figure 3-8: The Victim’s GUI
ABSOLUTE D6.7
Dissemination Level PU Page 21
3.2.5.2 Area Monitoring
The two main requirements considered for this functionality are PU_F_7029 and PU_F_7040 stating
that The PLMU application server shall provide information about the deployment situation and The
PLMU shall allow viewing location data on a map, respectively.
This functionality is provided by the ABSys application, which is described in more detail in Section 3
of deliverable [7]. The following Figure 3-9 depicts the main elements and flows involved in enabling
this functionality.
Figure 3-9: Area Monitoring
This area monitoring service provided by the ABSys can be managed by the First Responders users in
the GUI Map tab (Figure 3-10). The user can edit or insert new risk areas, apply filters, place elements
(like sensor nodes) in the map, etc. Refer to [7] for further information.
Internet
WLAN Router
PLMU User Interface
Single Board Computer
3G+Femtocell
3G
Wireless Sensor Network
First RespondersVictims
First Responders
Power Monitoring Unit
WiFi
. . .
. . .
. . .
SENSORSDATA
COLLECTED DATA
ABSOLUTEApplication ABSOLUTE Application
ABSOLUTE Application
ABSOLUTE D6.7
Dissemination Level PU Page 22
Figure 3-10: First Responders GUI Map tab
On the same Map tab, the location of the sensors nodes from a Wireless Sensor Network deployed by
the First Responders is shown. By clicking on each node the data measured is displayed in a graph
format as shown in Figure 3-11.
Figure 3-11: First Responders GUI, Map tab sensor data
ABSOLUTE D6.7
Dissemination Level PU Page 23
3.2.5.3 System Management
The system management functionality consists in informing the users about the power status (voltage,
current, power and battery remaining time) of the system provided by the Energino subsystem, also
informing them about the subsystems current load and, finally, also allowing them to turn on/off the
different subsystems in order to save power for instance. The main components enabling this
functionality are depicted in Figure 3-12.
Figure 3-12: System Management
The turning on/off functionality is physically implemented using the relays boards described in [8].
These relay boards are controlled by the GPIO ports of the Single Board Computer described in [8]
and these GPIO ports are managed by the ABSys applications described previously in Section 3 of
Deliverable [8].
This ABSys application is seen from the user point of view as a website accessible from their personal
user equipment and/or from the PLMU main touch screen, where they can, by clicking a button,
switch on/off any of the subsystems available in the PLMU.
Then, the power status of the system is also displayed to the user through the ABSys application. The
system status is monitored by Energino and stored on the Single Board Computer by the ABSys
application. Then, it is send to the website offered to the user for its visualization.
Another requirement related to system management is PU_NF_8016, which states that The PLMU
shall have a maintenance GUI. The Maintenance GUI is also implemented using a website form and
allows the technician to use other functions that the regular user like a first responder cannot access.
These maintenance functionalities can be managed through the FRs GUI in the System tab, as shown
Internet
WLAN Router
PLMU User Interface
Single Board Computer
3G+Femtocell
3G
Wireless Sensor Network
First RespondersVictims
First Responders
Power Monitoring Unit
WiFi
. . .
. . .
POWER MONITORING
SYSTEMMANAGEMENT
ABSOLUTEApplication
ABSOLUTE D6.7
Dissemination Level PU Page 24
in Figure 3-13. This tab is showing information about the sub-system status of the PLMU and the
power monitored data provided by the Energino. Users with special privileges will be able to switch
on and off subsystems (hardware) and their related services (software) from this System tab.
Figure 3-13: First Responders GUI System tab
ABSOLUTE D6.7
Dissemination Level PU Page 25
4. System integration of applications
4.1 Architecture principles
4.1.1 Centralized typical architecture
In a typical LTE network deployment, the core network (EPC) is centralized:
All traffic flows pass from local eNodeBs over a long backhaul to centralized EPCs (typically
in a regional centre),
Applications’ servers are hosted in regional centres as well,
User Authentication (HSS) is also centralized and typically hosted in a national data centre.
Figure 4-1: Typical Telco carrier base network
This architecture relies on the availability of a robust fibre backhaul as the aggregation of the traffic
coming from eNBs demands high data rates (from 1 Gbps at cell site, 40 Gbps at IP-RAN up to 100
Gbps in the MPLS core) at affordable costs and low end-to-end delay is mandatory for good quality
services.
As an example, the expected budget delay for conversational voice is expected to be less than 100 ms.
Even more stringent requirements have been requested for MCPTT: 75 ms [3].
So, the backhaul shall provide at the same time high data rate and low latency.
CentralizedCore Network
Long backhaul
AppsEPC
(Regional Datacenter)
HSS(National
Datacenter)
eNB
eNB
eNB
IP-RAN : 1 Gb to cellsite – 10 Gb Access – 40 Gb AggregationMPLS CORE: 100 Gb enabled
MPLS
Super backbone
IP
Backhaul
ABSOLUTE D6.7
Dissemination Level PU Page 26
4.1.2 Absolute distributed architecture
In the Absolute project, satellite communications are considered as the backhaul of the AeNB and
PLMU subsystems. Satellite communications mean limited data rates and above all high delay:
twofold 250 ms as the roundtrip delay.
This means that hybrid architecture shall be considered for Absolute with the objective to reduce the
requirements on the backhaul.
Figure 4-2: Absolute hybrid architecture: local EPC / Applications servers
As depicted in Figure 4-2, Hybrid architecture means:
Deploying local EPC so that local LTE calls are fully handled locally at the AeNB / PLMU
subsystem level. Local traffic is kept in the cells: only external calls (e.g.: to HQ) are
backhauled,
Using local applications servers for video, voice, data so that local data is kept local avoiding
to go through the backhaul,
Mirroring User Authentication (HSS) locally,
Preferring local management to support local control and visibility.
TeNB
Central Core Network
Internet
Sat Gateway
Trusted AppHSSData
Operations Center
Light EPC + mirror HSS+ local APP server
AeNB
Light EPC + mirror HSS+ local APP server
Light EPC + mirror HSS+ local APP server
AeNB
Loca
l bac
khau
l
HQ
Long backhaul
FME
FME
FME
ABSOLUTE D6.7
Dissemination Level PU Page 27
This architecture will avoid backhaul bottleneck, placing EPC elements / application servers / etc…
locally and increase the achievable throughput, improve availability (fault resilience), maintains
service in case of backhaul unavailability or allow standalone deployment (being easier to deploy).
Besides, the ABSOLUTE network architecture has several phases of roll-out and roll-back, in which
the routing, topology and link management techniques need to be considered. Based on these
considerations, a FME (Flexible Management Entity) concept, that encompasses a virtualized local
EPC and advanced routing capabilities, was introduced in the frame of the Absolute project (cf. D2.5.2
[9]). FME is a combination of EPC Units and Agents that entails the deployment of customized
services and resource management solutions locally at the eNBs. FME is a distributed element which
is designed to enable virtual EPC support at the eNB side and support additional units and entities that
are needed for allowing the ABSOLUTE architecture deployment in particular routing management,
topology management and link management.
Figure 4-3: Flexible Management Entity architecture
The core network intelligence being decentralized toward the AeNB and TeNB, this will also ease
scalability of the system. As each subsystem is merely autonomous, large deployment will not need
additional central resources.
This being said, to optimize collocated deployment of AeNB and PLMU, the distributed EPC solution
should enable also small groupings of cell sites. A local backhaul between AeNB and PLMU will thus
be of interest as illustrated below. In this case, one light EPC located at the PLMU could serve the
TeNB and the AeNB, simplifying the architecture of the AeNB subsystem (as illustrated below).
LTE - Work
ABSOLUTE architecture
Work
ABSOLUTE D6.7
Dissemination Level PU Page 28
Figure 4-4: Cell sites grouping example
So, the global Absolute hybrid architecture will have the following characteristics:
Decentralized EPC (FME) and applications server at system edge,
Local backhaul between subsystems.
This architecture will help keeping local all the local communications through SIP signalling over the
local backhaul and will enable “reactive” handovers as far as the communications between cell sites
are down locally without going through the satellite path.
Nevertheless, some items of the ABSOLUTE systems should remain centralized in what is called the
ABSOLUTE management centre in following picture. As an example, the Absolute management
centre could be used to register and manage securely large ABSOLUTE user fleets from multiple
organizations. The centralized items would be all that is needed to Absolute users’ registration and
management through their stored profile and security elements. The management centre could also
incorporate a market place to allow the secured installation of ABSOLUTE trusted professional
applications that are needed by first responders on their terminal.
TeNB
Central Core Network
Internet
Sat Gateway
Trusted AppHSSData
Operations Center
Light EPC + mirror HSS+ local APP server
AeNB
Light EPC + mirror HSS+ local APP server
AeNB
Local backhaul
HQ
Long backhaul
Cell sites grouping
ABSOLUTE D6.7
Dissemination Level PU Page 29
Figure 4-5: Absolute distributed architecture with global management center
SIP, Push To X Services
SGW PGWMME
Local mirror HSSPCRF
SIP, Push To X Services
SGW PGWMME
Local mirror HSSPCRF
ABSOLUTE ManagementCenter
Trusted AppHSSDataABSYS
PLMU
AeNB
Light distributed EPC
Light distributed EPC
Loca
l bac
khau
l
HSS data
SIP, handover (S1, X2), …
ABSOLUTE D6.7
Dissemination Level PU Page 30
4.2 Architecture for applications’ demonstration
4.2.1 Introduction
The Absolute project will be concluded by a demonstration of the system capabilities in tailored
scenarios.
The demonstration use cases (UC) have already been described in deliverable D2.1 [4] as well as an
early view of the demonstration setup, which is reproduced below.
Figure 4-6: An illustration of the general demonstration setup with satellite-capable AeNBs
Taking into account previous chapter architecture’s considerations, this setup can be detailed in the
following way:
EPC is distributed to AeNB1 and PLMU and a local backhaul is setup between AeNB2 and
the PLMU to illustrate a cell grouping and reactive handover.
SIP/Application servers are implemented locally in AeNB1 and PLMU cell.
Two long backhaul via satellite (Ka band) are setup for AeNB1 and PLMU. This backhaul
allows connecting the users to remote HQ and Internet services. The AeNB2 cell is connected
to the backhaul via the PLMU.
AeNB-1
AeNB-2
PLMU
HQ
MMUE
MMUE
TETRA
radio
LTE aerial link
LTE terrestrial link
Tetra link
WLAN
Sat link
Optical fiber
AeNB – TeNB link
ABSOLUTE D6.7
Dissemination Level PU Page 31
Based on these principles the global physical architecture for the demo is depicted below:
Figure 4-7: Absolute demonstration physical architecture
The PLMU layered architecture is as follows:
On the one hand, a SIP server enables different communications services (voice, video, messaging,
and call conferencing) over the different communications means: notably LTE, 3G, WIFI and TETRA
for voice.
On the other hand, the ABSYS web based software offers access to PPDR, victims, and
maintenance dedicated applications.
The MMUE or tablet is equipped with a SIP client and a web browser to take benefit of the
PLMU services.
The following picture gives a high level diagram of the PLMU functional architecture.
AeNB
AeNB LAN
DHCP
LTE RAN
SIP server APPsserver
TeNB
PLMU LAN
DHCP
WIFI
LTE RAN WLAN
AP
SIP server APPsserver
Internet
Sat.Gateway
HQ LAN
Server
Router /Firewall
Ka SatTerminal
HSS
EPC
HSS
EPC
AeNB1 subsystem
PLMU subsystem
IPBX
Operations centerTETRA RAN
BSC/BS
Apps, SIP Client, …
PSTN PLMN
Loca
l bac
khau
l
AeNB2 subsystemAeNB
LTE RAN
AeNB LAN
ABSOLUTE D6.7
Dissemination Level PU Page 32
Figure 4-8: PLMU high level functional architecture
The AeNB architecture is similar to the PLMU architecture. It is depicted in following picture.
A SIP server is instantiated locally to allow communications between MMUE in the cell without
backhauling need, whereas the PPDR, victims, and maintenance dedicated applications are accessed
via the PLMU through either local or satellite backhauling.
AeNB1 and PLMU SIP server shall be interconnected to allow communications between users in
PLMU cell and users in AeNB1 cell.
In the case of AeNB2, the aerial eNB is linked through a local backhaul to the PLMU: the users are
directly connected to the SIP server and the web based applications located at PLMU. So at AeNB2,
there is no need of a local EPC and a local SIP server.
ABSYS CORE
oth
ers
OA
M G
UI
SIP ServerP
TT
Co
nfe
ren
cin
g
TeNB
EPC
SIP-enabled services
3G BS
Vid
eo
Mes
sagi
ng
Vo
ice
WIF
I AP
SAT
Mo
dem
TETR
A B
SC/B
S
Coms Manager
DB
Mes
sage
s, S
yste
m in
foM
ap, S
enso
rs D
ata,
…
Sen
sors
GW
C2
GU
I
Vic
tim
s G
UI
WEB basedApplications
PLMU SUBSYSTEM
SIP Client, Web Browser
ABSOLUTE D6.7
Dissemination Level PU Page 33
Figure 4-9: AeNB1 high level functional architecture
SIP Server
PT
T
Co
nfe
ren
cin
g
AeNB
EPC
SIP-enabled services
Vid
eo
Mes
sagi
ng
Vo
ice
SAT
Mo
dem
AeNB1 SUBSYSTEM
SIP Client, Web Browser
ABSOLUTE D6.7
Dissemination Level PU Page 34
4.2.2 Demonstration Cases (DUC) with Related Architecture for Applications
4.2.2.1 DUC#1: scene to remote peer via satellite, without LTE network deployment
This demonstration case is related to the first stage of the demonstration, when the ABSOLUTE
network is not yet available. In this environment, it is intended to demonstrate how users are able to
send and receive messages from the scene to the HQ via satellite. It is worth highlighting that during
this first stage a message-based satellite technology is used (voice communications unavailable).
Figure 4-10: DUC#1: Scene to remote peer via satellite without LTE network coverage
Hardware setup:
The satellite communication mean is setup in a vehicle:
It provides a Wi-Fi access point to MMUE in its vicinity,
It establishes a satellite communication link in S-Band to relay MMUE messages to HQ and
HQ messages to MMUE using S-MIM,
The HQ is located in a place with Internet access.
Applications Architecture:
A ‘messaging type” application like Skype or a messaging APP specially developed for the project
will be used to illustrate this use case
Client side:
MMUE and HQ computer will be equipped with the messaging client,
HQ computer is equipped with the ABSYS light server in the case of the use of the dedicated
messaging APP.
The HQ computer is connected to Internet via its regular Internet access,
MMUE are connected to the satellite communication mean via Wi-Fi.
Server side:
The messaging application server is accessed through Internet either on the Internet (Skype like) or on
the HQ PC (dedicated APP)
ABSOLUTE D6.7
Dissemination Level PU Page 35
4.2.2.2 DUC#2: D2D communications with MM-UEs
When the ABSOLUTE network is unavailable or when a user is out of LTE coverage, it is assumed
that Device-to-Device (D2D) communications are available to support direct mode of operation.
Demonstration case 2 is hence intended to demonstrate a coverage extension via MM-UE to MM-UE
communications.
Figure 4-11: DUC#2, featuring D2D communications with MM-UEs
Hardware setup:
The Absolute system is deployed:
PLMU with TeNB is available,
One MMUE (MMUE1) is connected to PLMU via LTE
MMUE 1 is connected to another MMUE (MMUE2) out of the LTE coverage via a direct mode.
The HQ is located in a place with Internet access and is connected to PLMU via KA backhauling.
Applications Architecture:
Client side:
A relay functionality is available on the MMUE1
A browser is available on MMUE-2
MMUE-2 open web pages to access the FR GUI
Server side:
The PLMU hosts the ABSys server. It serves a FR GUI for the FR connected to the PLMU through
any of the wireless technologies (WLAN, UMTS, LTE),
E2E communications scenario:
A communication link is established between MMUE 2 and PLMU via MMUE 1 relaying.
MMUE2 opens the web page with FR GUI and send a message
All user connected to PLMU can read the message included the remote HQ.
1 2
ABSOLUTE D6.7
Dissemination Level PU Page 36
4.2.2.3 DUC#3: Telephony, one-to-one and many-to-many
The Absolute network being available, demonstration use case number 3 demonstrates main
ABSOLUTE core features:
Telephony one-to-one (via network): two subcases are demonstrated, MMUE to MMUE, and
MMUE to a remote peer (e.g. a remote user located in the premises of a HQ).
Telephony many-to-many (conference call via network): here also, both subcases MMUEs to
MMUEs and MMUEs to remote peers included HQ are demonstrated.
The features of text messaging, in which two subcases are also demonstrated: the transmission
of messages including images or videos by the FR and the transmission of distress messages by
the victims. Facsimile transmission is also part of the demonstration.
Figure 4-12: DUC#3: telephony, one-to-one and many-to-many, over LTE
Hardware setup:
The PLMU is deployed and its communication components are ready to be used:
It provides various wireless technologies to allow MMUE in its vicinity to connect to it,
It establishes a satellite communication link in Ka-Band to relay MMUE voice calls to HQ and
PSTN.
The HQ is connected to the Public Switched Telephone Network (PSTN)
Applications Architecture:
A regular voice call functionality is available on the MMUE connected over UMTS or TETRA,
A SIP client is available on the MMUE connected over WiFi or LTE.
ABSOLUTE D6.7
Dissemination Level PU Page 37
Client side:
MMUE and HQ can handle voice calls, either as a regular call or by using a SIP client installed
on it,
MMUE can open web pages so that they can access the C2 GUI,
Victims UE can open web pages so that they can access the Victim GUI,
The HQ is connected to the PSTN,
The PLMU is connected to the internet over the Ka-band satellite link.
Server side:
The PLMU hosts the ABSys server:
– It serves a C2 GUI for the FR connected to the PLMU through any of the wireless
technologies (WLAN, UMTS, LTE),
– It serves a Victim GUI to be used by the Victims connected to the open WLAN network
provided by the PLMU.
The PLMU runs a SIP server:
– It manages all the SIP communications of the PLMU,
– It accesses an external SIP provider over the satellite backhauling link.
E2E communications scenario:
Voice calls:
- Any MMUE can dial the extension of any other MMUE connected to the PLMU:
- If any of the two MMUE is using a SIP client, the call is managed and established by the SIP
server,
- If the two MMUE participating in the call are connected through different wireless
technologies to the PLMU, the call is also managed by the SIP server,
- If the two MMUE are connected using the same wireless technology (TETRA or UMTS), the
software core managing that technology is in charge of managing the call between them.
Any MMUE can dial the extension of a telephone connected to the PSTN (e.g. HQ):
These calls are managed by the SIP server. The SIP server connects to an external SIP
provider over the satellite backhauling link and this gives access to the MMUE to any
telephone connected to the PSTN (e.g. HQ).
Any MMUE can initiate a group call with several MMUE:
The groups need to be previously defined with all the MMUE belonging to it and identified by
an extension number,
Any MMUE can dial the extension number of a group and invite all the MMUE belonging to
that group to initiate a conference call,
All these group calls are managed by asterisk regardless of the wireless technology that the
MMUE use to connect to the PLMU.
ABSOLUTE D6.7
Dissemination Level PU Page 38
Messaging:
Any FR connected to the C2GUI can send a geo-located message to the rest of FR connected to it:
- These messages contain the location of the FR and a text field,
- They can also contain images and videos,
- These messages are displayed on the C2GUI for FR.
Any Victim connected to the Victims GUI can send a geo-located distress message to the PLMU:
- These messages contain the location of the Victim, name and a description of the need,
- These messages are displayed on the C2GUI for FR.
ABSOLUTE D6.7
Dissemination Level PU Page 39
4.2.2.4 DUC#4: video streaming and camera/robot remote control
The purpose of demonstration case 4 is to demonstrate a specific subset of the ABSOLUTE features,
once the LTE network is deployed:
Live video,
Remote control of Pan Tilt Zoom (PTZ) cameras,
Remote control of robots (this feature is still to be confirmed at the time of writing this
deliverable).
Figure 4-13: DUC#4 video streaming and remote control
Hardware setup:
The PLMU is deployed and its communication components are ready to be used:
It provides various wireless technologies to allow MMUE in its vicinity to connect to it,
It establishes a satellite communication link in Ka-Band to relay MMUE voice calls to HQ and
PSTN.
Applications Architecture:
The PLMU runs a SIP server:
- It enables live video streaming from a FR to any other FR.
The MMUE are equipped with SIP clients supporting live video streaming
Alternate scenario: MMUE are equipped with a browser. They can access the web page of the
remote PTZ camera.
E2E communications scenario:
Live video: Any MMUE can use the SIP client to stream video to any other FR.
Alternatively: a MMUE can control the PTZ camera and receive the video remotely through a
communication link established with the MMUE connected to the camera.
ABSOLUTE D6.7
Dissemination Level PU Page 40
4.2.2.5 DUC#5: access to WSN and corporate data
The purpose of demonstration case 5 is to demonstrate local and remote access to sensors, as well as
access to corporate networks and database.
Figure 4-14: DUC#5 access to wireless sensor network (WSN) and corporate data
Hardware setup:
The PLMU is deployed and its communication services are ready to use:
It provides various wireless technologies to allow MMUE in its vicinity to connect to it,
It establishes a satellite communication link in Ka-Band,
The PLMU hosts the ABSys server:
It serves a C2 GUI for the FR connected to the PLMU through any of the wireless
technologies (WLAN, UMTS, LTE).
The HQ is located in a place with internet access
The nodes of the Wireless Sensor Network (WSN) are deployed in the field. A Wireless Sensor
Gateway is integrated in the PLMU and collecting data from the deployed sensor Nodes.
Applications Architecture:
Client Side:
- MMUE and HQ can open web pages so that they can access the C2 GUI.
Server side:
- The PLMU is running the WSN service, which interfaces with the WSN API
ABSOLUTE D6.7
Dissemination Level PU Page 41
The PLMU runs the ABSys server.
The PLMU hosts a database where the Sensor’s data is stored.
E2E communications scenario:
The ABSys server polls the WSN coordinator and nodes to get new values every defined period
of time and stores the Sensors data in the database.
The data stored in the database is displayed on the C2GUI for FR
Access to WSN Data:
- MMUE and HQ can access the C2GUI and seethe WSN data in the Map tab.
- MMUE and HQ can see in a map the position of each sensor Node in the field.
- MMUE and HQ can see the data provided by each sensor node (including the gateway) by
clicking on the Node icon.
The data is represented in form of a Graph showing how it has changed over the last defined period of
time.
ABSOLUTE D6.7
Dissemination Level PU Page 42
4.2.2.6 DUC#6: Interoperability aspects
The purpose of demonstration case 6 is to demonstrate interoperability in a heterogeneous network:
once users are registered in the PLMU, voice communications between multiple users using different
communications equipment (TETRA, UMTS standard phone, tablet with WiFi, MM-UE…) is
possible.
Figure 4-15: DUC #6 communications over multiple technologies
Hardware setup:
The PLMU is deployed and its communication services are ready to use:
It provides various wireless technologies to allow MMUE in its vicinity to connect to it,
It establishes a satellite communication link in Ka-Band.
MMUE, TETRA terminals, commercial UE and tablets are ready to be used.
Applications Architecture:
The PLMU runs a SIP server:
It manages all the SIP communications of the PLMU,
It accesses an external SIP provider over the satellite backhauling link.
The MMUE can handle voice calls either by using regular voice call functionality or a SIP client.
ABSOLUTE D6.7
Dissemination Level PU Page 43
E2E communications scenario:
The MMUE has an extension number assigned by the SIP server.
Any MMUE can dial the extension of any other MMUE connected to the PLMU.
The SIP server is managing most of the services between the different wireless
technologies, with some exceptions in which the manager is the Core application for a
particular technology. Details are given in Table 4.1.
With this, all the interoperability in the system is shown in Table 4-1.
Table 4-1: Communication services over radio technologies
To
From LTE 3G TETRA WIFI PSTN
LTE
Voice Calls
Text Messages
Video Streaming1
Group Calls
Voice Calls
Text Messages
Video Streaming1
Group Calls
Voice Calls
Text Messages2
Group Calls
Voice Calls
Text Messages
Video Streaming1
Group Calls
Voice Calls
Text Messages
Video Streaming1
Group Calls
3G
Voice Calls
Text Messages
Video Streaming1
Group Calls
Voice Calls3
Text Messages3
Video Streaming1
Group Calls
Voice calls
Text Messages2
Group Calls
Voice Calls
Text Messages
Video Streaming1
Group Calls
Voice Calls
Text Messages
Video Streaming1
Group Calls
TETRA
Voice Calls
Text Messages2
Group Calls
Voice Calls
Text Messages2
Group Calls
Voice Calls4
Text Messages4
Group Calls
Voice Calls
Text Messages2
Group Calls
Voice Calls
Text Messages
Video Streaming1
Group Calls
WIFI
Voice Calls
Text Messages
Video Streaming1
Group Calls
Voice Calls
Text Messages
Video Streaming1
Group Calls
Voice Calls
Text Messages2
Group Calls
Voice Calls
Text Messages
Video Streaming1
Group Calls
Voice Calls
Text Messages
Video Streaming1
Group Calls
PSTN
Voice Calls5
Text Messages6
Voice Calls5
Text Messages6
Voice Calls5
Text Messages6
Voice Calls5
Text Messages6
1. Video Streaming services over SIP are still under study.
2. The compatibility between SDS and SMS has to be evaluated.
3. The 3G Core is managing these services.
4. The TETRA Core is managing these services.
5. Voice calls from the PSTN to local PLMU subsystems can be provided through an Interactive
Voice Response (IVR) system. However, its implementation is still being evaluated.
6. Sending text messages from the PSTN to local PLMU subsystems is still under study.
In addition to all the previous interoperability cases, any MMUE connected over any wireless
technology to the PLMU can reach any subscriber of the PLMU through the satellite backhauling link
(e.g. HQ).
ABSOLUTE D6.7
Dissemination Level PU Page 44
5. Conclusions
In this deliverable, we provided an in-depth description of end-user applications, as well as our up-to-
date vision of their integration in ABSOLUTE system and within the demonstration setup.
Firstly, we presented architecture considerations for applications integration in the context of a full IP
network based on LTE. As an illustration, an inventory of existing applications that already work on
such a technology basis has been highlighted.
Secondly, we described in details the services and applications that will be developed and integrated
within the ABSOLUTE project. Their integration in a distributed way within ABSOLUTE subsystems
has also been described.
Finally, we detailed the physical implementation of the demonstration use cases with an end-user
perspective, i-e at application level.
ABSOLUTE D6.7
Dissemination Level PU Page 45
References
[1] Application Community – the destination for public safety apps – by APCO International
http://appcomm.org/
[2] “Professional Mobile radio - NEXIUM Wireless Mission-Critical LTE”, www.thalesgroup.com
[3] 3GPP TR 23.768 V12.1.0 (2014-06) “Technical Specification Group Services and System Aspects;
Study on architecture enhancements to support Group Communication System Enablers for LTE
(GCSE_LTE) (Release 12)”
[4] FP7-ICT-2011-8-318632-ABSOLUTE/D2.1 “Use cases definition and scenarios description”
[5] FP7-ICT-2011-8-318632-ABSOLUTE/D5.2 “Portable Land Mobile Unit - Development Design”
[6] FP7-ICT-2011-8-318632-ABSOLUTE/D4.3.1 "Cooperative Transport and Data Delivery
Techniques"
[7] FP7-ICT-2011-8-318632-ABSOLUTE/D6.3.1 "Portable Land Mobile Unit Integration Report”
[8] FP7-ICT-2011-8-318632-ABSOLUTE/D5.2.2 "Portable Land Mobile Rapid Deployment Unit
Development Design"
[9] FP7-ICT-2011-8-318632-ABSOLUTE/D2.5.2 "FP7-ICT-2011-8-318632-ABSOLUTE/D2.5.2
Architecture Reference Model – Second Version"
ABSOLUTE D6.7
Dissemination Level PU Page 46
Acknowledgement
This document has been produced in the context of the ABSOLUTE project. ABSOLUTE consortium
would like to acknowledge that the research leading to these results has received funding from the
European Commission’s Seventh Framework Programme (FP7-2011-8) under the Grant Agreement
FP7-ICT-318632.