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

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


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


Figure 4-16: DUC #6 communications over multiple technologies ...................................................... 42

ABSOLUTE D6.7


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


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


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


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


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


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


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


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.

http://appcomm.org/

ABSOLUTE D6.7


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


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


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


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


3G+Femtocell

3G



First Responders


WiFi

. . .

. . .

. . .

ABSOLUTE D6.7


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


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


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


3G+Femtocell

3G



First Responders


WiFi

. . .

. . .

. . .

DISTRESSMESSAGES

FIRST RESPONDERSMESSAGES

ABSOLUTEApplication ABSOLUTE Application

ABSOLUTE Application


ABSOLUTE D6.7


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


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


3G+Femtocell

3G



First Responders


WiFi

. . .

. . .

. . .

SENSORSDATA

COLLECTED DATA

ABSOLUTEApplication ABSOLUTE Application


ABSOLUTE D6.7


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


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


3G+Femtocell

3G



First Responders


WiFi

. . .

. . .

POWER MONITORING

SYSTEMMANAGEMENT

ABSOLUTEApplication

ABSOLUTE D6.7


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


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


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



AeNB

Loca

l bac

khau

l

HQ

Long backhaul

FME

FME

FME

ABSOLUTE D6.7


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


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


AeNB


AeNB

Local backhaul

HQ

Long backhaul

Cell sites grouping

ABSOLUTE D6.7


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


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


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


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


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


Figure 4-9: AeNB1 high level functional architecture

SIP Server

PT

T

Co

nfe

ren

cin

g

AeNB

EPC


Vid

eo

Mes

sagi

ng

Vo

ice

SAT

Mo

dem

AeNB1 SUBSYSTEM

SIP Client, Web Browser

ABSOLUTE D6.7


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


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.


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


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)


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


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.


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


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


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 establishes a satellite communication link in Ka-Band to relay MMUE voice calls to HQ and

PSTN.



- 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.


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


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 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.


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


The PLMU runs the ABSys server.

The PLMU hosts a database where the Sensor’s data is stored.


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


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 establishes a satellite communication link in Ka-Band.

MMUE, TETRA terminals, commercial UE and tablets are ready to be used.



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



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


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


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"

http://appcomm.org/

http://www.thalesgroup.com/

ABSOLUTE D6.7


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.

fp7-ict-2011-8-318632-absolute/d6.7 end user application ... · fp7-ict-2011-8-318632-absolute/d6.7...

Documents