MACICO D2.1 End-users Requirements Specification€¦ · Pasi Kämppi Last draft for final approval...

MACICO D2.1 End-users Requirements Specification

MACICO

D2.1 End-users Requirements Specification

AABBSSTTRRAACCTT The WP2 will focus on acquisition of use cases and system requirements. WP2 gathers all work related to the interaction with operators and end-users. It is organized around a framework for gathering operational scenarios and requirements, as well as systematic methodology for harmonization of needs at the European level.

Document Title MACICO D2.1 End-users Requirements Specification

Deliverable D2.1

Document Id N° Version 1.1 Status Date 17/04/2013

Project Classification MACICO partners

Filename MACICO

Document manager

Laurea

Approval status

Author Responsible Partner Verification Project Approval

Laurea Laurea Cassidian SAS

<Name> Laurent Drouglazet

T2.1 Leader <Role> Coordinator

MACICO : D2.1 End-users requirements specification

1 REVISION HISTORY

Date Description Authors Comments 14.12.2012 Draft Version

0.1 Pasi Kämppi, Jaakko Tyni First draft.

02.01.2013 Draft version 0.2

Pasi Kämppi, Jaakko Tyni Comments by Jaakko Saijonmaa added.


Pasi Kämppi, Jaakko Tyni Update after meeting with Jaakko Saijonmaa.


Pasi Kämppi, Jaakko Tyni, Jaakko Saijonmaa

Document reviewed for final approval.


Pasi Kämppi Comments implemented


Pasi Kämppi Comments implemented


Pasi Kämppi Last draft for final approval

22.4.2013 Version 1.0 Seija Tiainen Approved 18.10.2013 Version 1.1 Pasi Kämppi, Mari Aro, Jaakko

Saijonmaa Second draft

18.11.2013 Version 1.2 Pasi Kämppi, Mari Aro Third Draft

26.3.2014 Version 2 Seija Tiainen Final version

30.4.2014 Version 3 Pasi Kämppi, Riku Leppänen Final version, corrected

2 DOCUMENT APPROVAL The User Requirements Outline has been accepted and approved by following: Signature Name Title Date

(Note: This is largely following the IEEE Guideline for Requirements Specification)

MACICO : D2.1 End-users requirements specification Table of Contents 1 Revision History ................................................................................................................. 2 2 Document Approval ........................................................................................................... 2 3 Introduction ........................................................................................................................ 4

3.1 Objectives .................................................................................................................... 4 3.2 End-users Requirements Capture ................................................................................ 4 3.3 Definitions, Acronyms, and Abbreviations .................................................................... 5 3.4 References .................................................................................................................. 7

4 Standardization and Previous Projects ............................................................................... 8 4.1 Standardization ............................................................................................................ 8 4.2 Three Country Pilot (2003) ........................................................................................... 9 4.3 Rakel-Bosnet (2009) ...................................................................................................11

5 Use Cases ....................................................................................................................... 12 5.1 Case 1: Cross-border Cooperation with Police ............................................................12 5.2 Case 2: Cross-border cooperation with emergency vehicles .......................................14

6 User interviews ................................................................................................................ 16 7 Specific Requirements ..................................................................................................... 18

7.1 External Interface Requirements .................................................................................18 7.1.1 Air interface .........................................................................................................18 7.1.2 ISI Interface (TETRA only) ...................................................................................18 7.1.3 Service interworking with legacy networks (TETRA/TETRAPOL or TETRAPOL/TETRAPOL) ...................................................................................................18 7.1.4 PSTN interface ....................................................................................................18 7.1.5 Remote dispatcher interface ................................................................................18

7.2 Functional Requirements ............................................................................................19 7.2.1 Network ...............................................................................................................19 7.2.2 Terminal ...............................................................................................................26

7.3 Technical solutions .....................................................................................................28 7.3.1 Solution-1: Inter-network communication .............................................................28 7.3.2 Solution-2: Overlapping networks ........................................................................29 7.3.3 Solution-3: Coverage expansion ..........................................................................30 7.3.4 Solution-4: Migration ............................................................................................31

7.4 Non-Functional Requirements ....................................................................................32 7.4.1 Performance ........................................................................................................32 7.4.2 Reliability .............................................................................................................32 7.4.3 Availability ............................................................................................................32 7.4.4 Security ................................................................................................................32

List of Figures ........................................................................................................................... 33 List of Tables ............................................................................................................................ 34 Annex I: MACICO Requirement Acquisition Interview Form ...................................................... 35


3 INTRODUCTION This document provides User Requirements Specification (URS) for TETRA and TETRAPOL communication systems in cross-border operations. The document describes functional and non-functional requirements. TETRA is an open standard that is developed by European Telecommunications Standards Institute (ETSI). The target of standardization work was to define open interfaces to enable seamless interoperability between different network and equipment manufactures. TETRA standard contains features to allow interoperability between deployed national networks, but TETRA has been used in cross border operations only in pilots. The first remarkable pilot was deployed in 2003. The Three Country Pilot was a project among The Netherlands, Belgium and Germany. The target was to connect the TETRA networks of all three countries using an Inter-System Interface (ISI phase 0). In simulated crisis, a specified group of civil protection authorities were able to communicate to each other on the Aachen – Limburg – Liège border area. The pilot was a success and many great lessons were learnt. The second pilot was organized in 2010. Cassidian deployed another pilot project with ISI phase 1 where Swedish and German TETRA networks were connected to each other. This time the pilot was organized on a maritime area. Again, the pilot was successful and many new things were found. The MACICO project implements the latest version of ISI interface (ISI phase 2) on top of TETRA architecture. MACICO also creates scenarios and user requirements for implementation and demonstrations. User requirements are based on results of previous projects, end users interviews and discussions with technical experts.

33..11 OObbjjeeccttiivveess

MACICO’s main objective is to reply to the Public safety organization needs on radio communication systems for cross-border operations and for cooperative crisis missions on short term. The organizations will communicate without functional perturbance and corrupting the network's security. MACICO will also study interoperability issues that rise for the transition period between the existing networks and next broad band generation.

33..22 EEnndd--uusseerrss RReeqquuiirreemmeennttss CCaappttuurree

The WP2 will focus on acquisition of use cases and system requirements. WP2 gathers all work related to the interaction with operators and end-users. It is organized around a framework for gathering operational scenarios and requirements, as well as systematic methodology for harmonization of needs at the European level. The requirements are produced by existing operational users/operators from (several) already deployed networks. It shall address issues such as:

o Capability and conditions for use of radio terminals by foreign users in their networks

o Use cases for Voice Communications including foreign terminals in a network o Uses case for inter network communications o Management conditions for gateways deployment and interoperability

configuration

4/35


o Requirements on the interoperability backbone

33..33 DDeeffiinniittiioonnss,, AAccrroonnyymmss,, aanndd AAbbbbrreevviiaattiioonnss

AES Advanced Encryption Standard AVL Automatic Vehicle Location AVLS Automatic Vehicle Location Server CCK Common Cipher Key CPI Calling Party Identity DCK Derived Cipher Key DGNA Dynamic Group Number Assignment DNC Data Network Controller E2EE End to End Encryption FIFO First In First Out GCK General Cipher Key Gi-interface Standardized GPRS interface for Public Data Network (PDN) Gp-interface Standardized GPRS interface for interworking between backbones DMO Direct Mode Operation DWS Dispatch Work Station ETSI European Telecommunications Standards Institute GPS Global Position System GSM Global System Mobile HW Hardware IDEA International Data Encryption Algorithm IPI IP Interworking ISI Inter-System Interface ISSI Individual Short Subscriber Identity ITSI Individual Tetra Subscriber Identity LA Location Area LIP Location Information Protocol MCC Mobile Country Code MGCK Modified Group Cipher Key MNC Mobile National Code MNI Mobile Network Identifier MS Mobile Station MoU Memorandum of Understanding OTAR Over the Air Re-Keying PEI Peripheral Equipment Interface PMR Professional Mobile Radio PSTN Public Switched Telephone Network RFSI TETRAPOL subscriber address (Region-Fleet-Subfleet-Individual) SCK Static Cipher Key SDS Short Data Service SFPG TETRA Association Security and Fraud Prevention Group (SFPG) SMS Short Message Service SSI Short Subscriber Identity SW Software SwMI Switching and Management Infrastructure TA TETRA Association TCCA TETRA Critical Communications Association TCCE TDMA Time Division Multiple Access TETRA Terrestrial Trunked Radio, Digital professional mobile standard defined by

European Telecommunications Standards Institute (ETSI)

5/35


TETRAPOL Tetrapol, Digital professional mobile standard defined by Tetrapol Publicly Available Specification (PAS)

UDN User Data Terminal URS User Requirements Specification 3-CP Three Country Pilot

6/35


33..44 RReeffeerreenncceess

This document takes into account TETRA-TETRA ISI requirements, as collected from the TC TETRA standard, TCCA IOP specifications and end user organizations: TC TETRA standard, section ISI:

o ETSI EN 300 392-3-1 V1.3.1 (2010-08), Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 3: Interworking at the Inter-System Interface (ISI); Sub.part 1: General design

o ETSI EN 300 392-3-2 V1.4.1 (2010-08), Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 3: Interworking at the Inter-System Interface (ISI); Sub.part 2: Additional Network Feature Individual Call (ANF-ISIIC)

o ETSI EN 300 392-3-3 V1.2.1 (2004-01), Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 3: Interworking at the Inter-System Interface (ISI); Sub.part 3: Additional Network Feature Group Call (ANF-ISIGC)

o ETSI EN 300 392-3-4 V1.3.1 (2010-08), Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 3: Interworking at the Inter-System Interface (ISI); Sub.part 4: Additional Network Feature Short Data Service (ANF-ISISDS)

o ETSI EN 300 392-3-5 V1.4.1 (2010-06), Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 3: Interworking at the Inter-System Interface (ISI); Sub.part 5: Additional Network Feature for Mobility Management (ANF-ISIMM)

o ETSI EN 300 392-7 V3.3.1 (2012-7), Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 3, Security

o ETSI TR 101 448 V1.1.1 (2005-05), Terrestrial Trunked Radio (TETRA); Functional requirements for the TETRA ISI derived from Three-Country Pilot Scenarios

TCCA documents:

o TETRA and the Inter System Interface, White Paper produced by TETRA Association, August 2010

o TETRA Interoperability and Certification explained, issued by The TETRA Association, January 2008

End user documents:

o Final report, Three Country Pilot (3-CP) November 2003 o Inter-system interface, list of requirements V1.0 (2008-11), BDBOS, A.S.T.R.I.D,

Politie Netherlands o Cross Border Communication Trial, Final report, Rakel – BOS-Digitalfunknetz,

EADS (Cassidian) May 5, 2011 o Interconnecting TETRA systems, White Paper by Motorola, 2009

End user interviews:

o 5 end-user interviews and 5 written answers to a questionnaire (Annex I, see page 36).

Other sources:

o TETRA Critical Communications Association http://www.tandcca.com/ o TETRA –Consultancy http://www.tetra-consultancy.com o TETRA Security http://www.tetramou.com/about/page/12027

7/35

http://www.tandcca.com/

http://www.tetra-consultancy.com/

http://www.tetramou.com/about/page/12027


4 STANDARDIZATION AND PREVIOUS PROJECTS

44..11 SSttaannddaarrddiizzaattiioonn ETSI TETRA standards (TC TETRA) include the interface between two TETRA network infrastructures: TETRA Inter-System interface (ISI) standards. First set of TETRA ISI standard was available already in year 2000 in ETSI. First set of ISI interoperability TIP profiles (ISI ph1) was ready in 2001 in TETRA Association (TA). Since then, there has been development/updates of the ISI standard as well as completion of further ISI TIP ph2 and ph3 profiles. It can be said that a full set of ISI standard and TCCE TIP profiles have been available for over 5 years. In TCCE (Former TA) TETRA IOP work continues also in context of ISI standard, currently defining so called ISI ph4, complementing the interoperability functionality in some aspects. Following figures show the timetable of TETRA ISI milestones, including also some Cassidian and Motorola certification achievements. Cassidian has certified ISI ph2 in its TETRA infrastructure release in 2012. presents the TETRA ISI milestones Figure 1: TETRA standard and IOP milestones The TETRA Inter-System Interface (ISI) standards are available and published by ETSI, the following lists the standards:

- EN 300 392-3-1 Interworking at the ISI; Sub-part 1: General design - EN 300 392-3-2 Interworking at the ISI; Sub-part 2: Individual Call ANF-ISIIC - EN 300 392-3-3 Interworking at the ISI; Sub-part 3: Group Call ANF-ISIGC - EN 300 392-3-4 Interworking at the ISI; Sub-part 4: Short Data Service ANF-ISISDS - EN 300 392-3-5 Interworking at the ISI; Sub-part 5: Mobility Management ANF-ISIMM - TS 300 392-3-6 Interworking at the ISI; Sub-part 6: Speech format implementation for

circuit mode transmission - TS 300 392-3-7 Interworking at the ISI; Sub-part 7: Speech format implementation for

packet mode transmission.

8/35


The following ISI related TIP specifications are available (in TCCE) - TETRA MoU Technical Report 001 Part 6: Air Interface Migration - TETRA MoU Technical Report 003 Part 01; Inter Systems Interface (ISI) Mobility Management ANF-ISIMM Implementation - TETRA MoU Technical Report 003 Part 02; Inter Systems Interface (ISI) Individual Call ANF-ISIIC Implementation - TETRA MoU Technical Report 003 Part 03; Inter Systems Interface (ISI) Short Data Service ANF-ISISD Implementation - TETRA MoU Technical Report 003 Part 04; Inter Systems Interface (ISI) Lower Layers Implementation - TETRA MoU technical report 003 Part 5-1; Inter Systems Interface (ISI) Speech Format Implementation for Circuit Mode Transmission - TETRA MoU technical report 003 Part 5-2; Inter Systems Interface (ISI) Speech Format Implementation for Packet Mode Transmission - TETRA MoU Technical Report 003 Part 06; Inter Systems Interface (ISI) Group Call ANF-ISIGC 3. IOP Test Plans: By today the following IOP Test Plans related to ISI have been approved (the TTR-001-06 actually belongs to the Voice + Data TIP suite): - TIP Compliance test plan for testing of TIP Part 6: Air Interface migration Phase 2 (TTR001-06); IOP001-06 - TETRA MoU Technical Report 003 Part 01; Inter Systems Interface (ISI) Mobility Management - TETRA MoU Technical Report 003 Part 02; Inter Systems Interface (ISI) Individual Call - TETRA MoU Technical Report 003 Part 03; Inter Systems Interface (ISI) Short Data Service The following IOP Test plan for TETRA ISI is pending in the specification process: - TETRA MoU Technical Report 003 Part 06; Inter Systems Interface (ISI) Group Call A set of ISI interoperability test profiles have also been defined by the TETRA Association.

44..22 TThhrreeee CCoouunnttrryy PPiilloott ((22000033))

The Schengen three-country pilot was a project among The Netherlands, Belgium and Germany. Its aim was to connect the TETRA networks of all three countries using an Inter System Interface (ISI) phase 0. The target was that a specified group of civil protection authorities could communicate in a simulated cross-border crisis on the Aachen – Limburg – Liège border area. By connecting three national sub-networks emergency professionals were able to test their ability to work together and evaluate TETRA technology on a simulated crisis. The whole project was based on article 44 of the Schengen Agreement: In accordance with the relevant international agreements and account being taken of local circumstances and the technical possibilities, the Contracting Parties shall set up, in particular in border areas, telephone, radio, and telex lines and other direct links to facilitate police and customs co-operation, in particular for the transmission of information in good time for the purposes of cross-border observation and pursuit. In addition to these short-term measures, they will in particular examine the following possibilities: the exchange of equipment or the assignment of liaison officials provided with appropriate radio equipment; the widening of the frequency bands used in border areas; the establishment of a common link for police and customs service’s operating in these same areas; Co-ordination of their programs for the procurement of communications equipment, with a view to achieving the introduction of standardized compatible communications systems.

9/35


As stated in the final report, “the Schengen Agreement’s mandate was confirmed by the Working Group on “Police co-operation” of the Council of the European Union with document 9865/2/96 ENFOPOL 139.” The aim was to investigate whether TETRA meets the standards for cross-border communication in practice set by the security organizations working on border areas: Does the TETRA standard meet the tactical and operational requirements of the organizations involved? Do the mobile communication applications enabled by TETRA meet the needs of the cross-border co-operation officials, which include various security agencies, organizations and their dispatch centers? The Schengen Three Country pilot was divided into two phases, but the agreement to conduct this kind of project was already agreed upon in 1996, seven years before the field tests begun. During those seven years each attending country had to build up the technical solutions to enable the tests to take place. In practice, all countries had to upgrade their TETRA based radio communication networks and equipment. The first phase of the test included the preparation of the network, equipment and the field test scenario. The preparation phase lasted one year. During this phase all needed features were tested: group call individual call telephony call emergency call Air interface encryption and authentication from the foreign network were left out of the scope. As there was no ISI per se available, the connection between different networks was made possible by a modem. The test phase was a success. All tested features worked very well and all participants were able to communicate with each other. The pilot project helped to identify several issues that need to be addressed before the cross-border co-operation in this mode could be taken into everyday use: Operational aspects integration of intervention teams in foreign networks common training and language courses agreements on common basic principles on radio procedures terminal numbering takes account the international radio communication needs Legislative protection of privacy proposals to improve the radio communication possibilities in the border regions Technical limited air interface encryption authentication and encryption can only be done by exchanging very important keys end-to-end encryption not possible use of modems and leased lines (costs) necessary multiple conversions from digital to analogue and back to digital reduce the audio quality terminal numbering for international communication (GSSI/ISSI) have to be aligned manually dispatcher cannot see when and to which network the radios are migrating exchange of status and SDS-messages is not possible exchange of emergency call is not possible individual call between countries is not possible

10/35


The end result in short was that recommendations for international cooperation should be made. The most needed mutual agreements were technical, legislative and operational issues. Because of these recommendations, the board of this project urged to continue to phase two, which never happened.

44..33 RRaakkeell--BBoossnneett ((22000099))

The Rakel - Bosnet project demonstrated the usability of TETRA networks in international and multi-authority operations in 2009-2010. The participants were Cassidian, BDBOS and MSB, the Swedish Coastguard, the German Federal Police Sea and the Swedish Police. Cassidian was the technology provider for both the German operational network BDBOS (Bosnet) and the Swedish MSB (Rakel). This project was the first in the world to succeed in enabling two nationwide TETRA networks to be connected on a cross-border operation with the use of ISI phase 1. It was shown that roaming between two secure TETRA networks was possible and it was possible to control the outside connections within a network. This project proved that TETRA network worked well in an international incident management scenario although it was played at the Baltic Sea. It also showed that a dispatcher connection to visited network was possible and that it could control the DSW user rights. Both countries gave positive feedback on the security and functionality of the network. An EU Council’s agenda on cross-border communications was also raised. This is where the MACICO-project and the possible spinoffs come forward, as the purpose of the project is to connect different countries’ and different officials’ TETRA networks on cross-border areas within the EU.

11/35


5 USE CASES This section will present fictional use cases, where the functionality of ISI could be beneficial. These scenarios will be located in the Finnish-Swedish-Norwegian border area. It was chosen because all countries have fully functioning TETRA-network with full coverage at the cross border area. It would be beneficial to enable smooth cooperation between different authorities in everyday use.

55..11 CCaassee 11:: CCrroossss--bboorrddeerr CCooooppeerraattiioonn wwiitthh PPoolliiccee A heist takes place in Finland. The Finnish police begin the chase to catch the criminals who move across the border to Sweden. It is obvious that the criminals are going move across the border several times during the chase. Finnish police operation center contacts the Swedish police operation center and explain the situation. It is agreed that the Swedish patrol continues chase in the Sweden and the Finnish patrol is allowed to go across the border if needed. Swedish command center activates needed features in the network and police patrols are able to communicate with each other fluently.

Finnish police detects a criminal car and starts chasing. It seems obvious that the car (Lithuanian registered) tries to escape to Sweden over the border. Finnish police operations center contacts Sweden police operations center, asking for coordination for the chasing.

Figure 2 Communication flow for police in cross border operation

12/35


Swedish operations center activates two TETRA voice groups over ISI in Swedish network: one for FI-SWE co-operation, one for Finnish police force to continue to communicate in their home voice group. Finnish and Swedish operations centers command field units in the chasing to use those two voice groups as their purpose is. Police patrols are able to communicate with each other during the mission. Communication setup:

Chasing started in Finland using national police home group: use Finland normal operational group. Dispatcher of the operational group in Finland contacts Sweden police operations center via 1:1 call over ISI. Both control centers activate the international co-op groups, which are interconnected via ISI. Both control centers instruct the operative users of the chase and to start using the interconnected groups (in addition to national group). Finnish control center instructs Swedish center to activate home group for Finnish visitor (pre-provisioned to be connected to the corresponding police home group in Finland). Finnish operative unit crosses border and authenticates to the Swedish network (home authentication over ISI). The user is pre-provisioned to Swedish network with pre-defined (limited) user rights. Interconnected groups are used in co-operation (agreed to use English language). Finnish police national home group is used by migrated Finnish unit, when communication entirely with Finland colleagues (in Finnish). The chasing terminates in Sweden and the Finnish visiting operative unit returns to Finland making re-authentication in home network in Finland. Finnish and Swedish operative centers agree to de-activate the groups over ISI.

Figure 3 Communication setup for police in cross border operation

13/35


55..22 CCaassee 22:: CCrroossss--bboorrddeerr ccooooppeerraattiioonn wwiitthh eemmeerrggeennccyy vveehhiicclleess

A Swedish person gets injured in the north of Sweden. He calls the EU unified emergency number 112 which connects to the Swedish Emergency Service center SOS Alarm because the call is made in the Swedish mobile network. SOS Alarm locates notices that a Finnish ambulance is the nearest one for the incident place and orders help from Finnish Emergency Service.

VIRVERAKELRESCUERESCUE

ISI

SOS Alarm HÄKE

2 3

4

567

Figure 4 Communication flow for emergency services in cross border operation

Swedish person is injured in the Sweden. Swedish person makes an emergency call to Swedish emergency center (SOS Alarm) via commercial mobile network. Swedish emergency center positions (AVL) nearest free ambulance to be a Finnish unit (being either in Sweden or near border in Finland). Swedish emergency center contacts Finnish emergency center to call for the Finnish ambulance to take the incident. Finnish ambulance is ordered to go to the incident place and gives first aid Finnish ambulance goes to incident place. Swedish ambulance is called to the place. Swedish ambulance takes the Swedish patient to hospital in Sweden.

14/35


Communication setup:

112 call of an incident in Sweden, received by SOS Alarm. Swedish emergency center receives continuously real time AVL info of all ambulances in the neighborhood via TETRA SDS (AVL messages of ambulances in Finland are sent as SDS messages over ISI to Swedish emergency center). Swedish emergency center contacts Finnish emergency center to dispatch Finnish ambulance via direct 1:1 call over ISI. Finnish ambulance drives to the incident place in Sweden, informs all other units and emergency centers of its new task, using the permanently active ISI-interconnected TETRA voice group (for ambulances). Finnish ambulance gives first aid and informs via the ISI-interconnected TETRA group the operations centers and other units of the required next steps (need of transfer of victim to a hospital). Using the ISI interconnected group, Swedish emergency center dispatches the nearest Swedish ambulance to the incident place to transfer the patient to a Swedish hospital if needed. The nearest free Swedish ambulance, when called, may reside also on Finnish soil. Swedish ambulance performs the task and informs Swedish emergency center of the completion of the task using the ISI-interconnected group.

Figure 5 Communication setup for emergency services in cross border operation

15/35


6 USER INTERVIEWS The interviews were conducted with the help of Finnish end users with significant expertise on TETRA technology. The interviewees came from different organizations throughout the Finnish Officials’ field which had been using the devices as both fieldworkers and managers. The first round of interviews was organized by email but the response rate was very low. The second round of interviews was made face to face or remote meetings. The second round indicated to interviewers that the questionnaire form is too technical and a lot of discussion was needed to get satisfying results. Following tables presents the main results of user interviews. Requirements for interoperability between different mobile communication technologies Role Experience in

years TETRA- TETRA

TETRA- TETRAPOL

TETRA- 3G/4G

TETRAPOL- 3G/4G

FIN Border guard

13 NEEDED NOT NEEDED NOT NEEDED NOT NEEDED

FIN Border guard


FIN Border guard


FIN Fire/Rescue


FIN Fire/Rescue


NECESSITY RATE

100% 0% 0% 0%

Table 1 Requirements for network interoperability Role Experience in

years ROAMING INDIVIDUAL

CALL GROUP CALL

EMERGENCY CALL

FIN Border guard

13 NEEDED NEEDED NEEDED CAN´T SAY

FIN Border guard


FIN Border guard


FIN Fire/Rescue


FIN Fire/Rescue


NECESSITY RATE

100% 100% 100% 0%

Table 2 Requirements for TETRA features

16/35


Role Experience in

years SDS AVL PRIORITY

PRE-EMPTION CALLER-ID

FIN Border guard

13 NEEDED CAN´T SAY CAN´T SAY CAN´T SAY

FIN Border guard

20 NEEDED NEEDED CAN´T SAY CAN´T SAY

FIN Border guard


FIN Fire/Rescue


FIN Fire/Rescue


NECESSITY RATE

100% 80% 0% 0%

Table 3 Requirements for TETRA features The collective opinion is that the VIRVE TETRA network in Finland is secure and good but it’s coverage over sea areas as well as in scarce areas in Lapland could be better. The most important feature is group calls. With the long experience of TETRA they pointed out that not only the technical issues make the cooperation between different authorities hard. A maritime rescue expert explained how the protocols on radio use and talk groups make cooperation very difficult. Representatives of different departments in the police force, rescue services (8 districts) and health care districts (7 in all) could all benefit from the same information. It would be tremendously helpful to harmonize the standards and protocols. An issue that almost all interviewees pointed out was the crowdedness of the talk groups due to lack of training amongst the end users. However, features of multi-official talk groups were still longed for. A specialist from the rescue field in Finland pointed out, that a temporary management center placed in an aerial vehicle, or alternatively with an access of a view from an aircraft would help in natural hazards, such as forest fires and at sea. Following table presents requirements for other features: Role Experience in

years SITUATIONAL SNAP SHOT

VIDEO STREAMING

FIN Border guard

13 NEEDED NEEDED

FIN Border guard

20 NEEDED NEEDED

FIN Border guard

14 NEEDED NEEDED

FIN Fire/Rescue

13 CAN´T SAY NEEDED

FIN Fire/Rescue

20 CAN´T SAY NEEDED

NECESSITY RATE

60% 100%

Table 4 Requirements for other features The future features wished by the end users were also relatively identical: Live streaming and situational awareness snapshots could be beneficial for incident remote operation.

17/35


7 SPECIFIC REQUIREMENTS This section presents functional requirements for TETRA and TETRAPOL technologies in cross border environment. Requirements are based on user interviews, results of previous projects and discussions with project partners, especially with Cassidian Finland. Many of needed features are transparent for end users but still necessary to guarantee system reliability and security.

77..11 EExxtteerrnnaall IInntteerrffaaccee RReeqquuiirreemmeennttss

7.1.1 Air interface

Air interface is used for communication between mobile terminal and network. Used networks and terminals have to be implemented according TETRA/TETRAPOL standards.

7.1.2 ISI Interface (TETRA only)

TETRA ISI represents a set of basic services necessary to support communication between home and visited network. Used networks have to be implemented according TETRA standards.

7.1.3 Service interworking with legacy networks (TETRA/TETRAPOL or TETRAPOL/TETRAPOL)

Current preferred solutions for service interworking with legacy networks consist in developing a gateway between the existing PMR network and the guest network and a dedicated application in order to export the features / services from the existing network.

7.1.4 PSTN interface

PSTN interface provides access to Public Switched Telephone Network (PSTN). It is used to communicate with e.g. commercial mobile networks (2G, 3G). PSTN interface has to be implemented according to standards.

7.1.5 Remote dispatcher interface

Remote dispatcher interface provides connection for control rooms. This interface is not standardized and it allows vendor specific interface specifications.

18/35


77..22 FFuunnccttiioonnaall RReeqquuiirreemmeennttss

Operative requirements and special features will be described in this section.

7.2.1 Network

7.2.1.1 Numbering and Addressing When networks are connected to each other for interworking, it is essential that each network element and subscriber has a unique address or subscriber number to avoid possible number collisions. Migrated subscribers can be identified by using full ITSI (MCC+MNC+SSI) in TETRA or RFSI in TETRAPOL. The home and visited network should be able to handle traffic with MNI identifiers. Questions: Do operators support full ITSI/RFSI for home and migrated terminals to avoid number space collisions (collisions could occur if SSI is used without MNI)? Are operators prepared to configure their network to handle traffic with foreign MNI?

7.2.1.2 Pre-provisioning It is not considered safe for any subscriber to be allowed to migrate in visited network without specific authorization. It is possible to grant access only for certain subscribers by pre-provisioning subscribers. The visited network checks if the visiting subscriber fulfills basic migration requirements before fetching authentication parameters from the home network (ETSI TR 101 448 V1.1.1). There are also defined migration profiles in the visited network that define what services are allowed for visiting subscribers. Migration profiles, to allow/deny use of visited TETRA or TETRAPOL network, should include at least following services (ETSI TR 101 448 V1.1.1): Group call Individual call Telephone call Emergency call Status SDS Packet data Questions: Does the TETRA/TETRAPOL operator require that the provisioning is made for each subscriber individually, or for certain number range of visiting subscribers? What services are allowed to be used for visiting subscribers?

19/35


7.2.1.3 Authentication The TETRA standard supports the mutual authentication of a Mobile Station (MS) and the network, which is in TETRA normally referred to as the Switching and Management Infrastructure (SwMI). This makes it possible for a TETRA system to control the access to it and for an MS to check if a network can be trusted (TETRA Security). If a TETRA MS roams to a TETRA network other than its “home” network, this “visited” TETRA network will need to obtain authentication information from the “home“ network of this MS in order to be able to perform mutual authentication and generate and/or distribute encryption keys. The transfer of authentication information between networks is in principle supported in three ways (TETRA Security). The most straightforward method is to simply transfer the authentication key K to the visited network. Transfer of a data file of keys, even being encrypted, for security reasons is however not advisable. A second option is to transfer certain information that can be used for one single authentication procedure. This is basically the same method as is applied in GSM and can be implemented in a very secure way. However this is only practical where the MS cannot mutually authenticate the SwMI – otherwise the visited SwMI would have to interrogate the home SwMI for a response each time the MS invoked this mutual authentication. A third alternative is therefore supported. This allows a home network to transfer a set of session authentication keys for an MS, which can be used for repeated authentications to a visited network without revealing the original authentication key of the MS. This option combines security and efficiency and permits mutual authentication to take place at a realistic pace. The transfer of the session keys over ISI link should be secured making the use of home session keys safe. Current TETRA terminals, supporting authentication in home network support also authentication in visited network without HW/SW updates. In TETRAPOL, a terminal cannot be used until authenticated by the network. Authentication consists in checking that the terminal parameters (serial number, individual address, etc.) match those recorded when the terminal was registered. Questions: Does the TETRA/TETRAPOL operator trust on authentication parameters from the foreign network (authentication triplet KS, KS, RS)? Does the TETRA/TETRAPOL operator want to authenticate every migrating subscriber (K-keys of the visiting subscribers are copied from the home network to the visited network)?

7.2.1.4 AIE Security User traffic and signaling information can be encrypted over the air interface between the MS and the SwMI, both for individual and group communications. The Air interface encryption mechanism is available for Voice and Data in Trunked Mode Operation and in Direct Mode Operation. The use of several encryption algorithms, both standard and proprietary, is supported (TETRA Security). Traffic encryption protects user speech and data. Signaling encryption provides protection from traffic analysis, and prevents an eavesdropper from discovering who is operating in a particular area, or who is calling who (TETRA Security). There are several sorts of encryption keys. Some keys may be derived or transferred as part of the authentication procedure, some keys can be sent to MSs using Over the Air Re-keying

20/35


(OTAR) or some may be preloaded in the MSs. There are keys with long term and short term key lifetimes. Special mechanisms are included to protect the keys with a long lifetime (TETRA Security, ETSI EN 300 392-7 V3.3.1).

o The Derived Cipher Key (DCK) is derived during the authentication procedure. It can be used to encrypt the link between the network and the MS on an individual basis. Thus it can also provide an extended implicit authentication during the call and can be used for encryption of uplink communications (i.e. the communication from the MS to the network) as well as downlink communications from network to an individual MS (TETRA Security).

o The Common Cipher Key (CCK) is generated by the SwMI and distributed,

encrypted with the DCK, to each MS. It is efficient to use this key for encryption of messages that are directed to groups of MSs spread across one or more Location Areas (LAs). When the CCK is distributed to an MS over the air interface using OTAR it is encrypted with the DCK of this MS (TETRA Security).

o The Group Cipher Key (GCK) is linked to a specific closed user group. It is

generated by the SwMI and distributed to the MSs of a group (e.g. by pre-provisioning of the MS, on a Smart card, or by using OTAR (see below)). Within a Location Area the GCK is always used in a modified form. It is combined with the CCK in a specific algorithm to obtain the Modified Group Cipher Key (MGCK). The MGCK is used to encrypt the closed user group messages for groups of MSs. When the GCK is distributed to an MS over the air interface using OTAR it is encrypted with a session encryption key derived from the Authentication Key for this MS, or with a Group Session Key (TETRA Security).

o The Static Cipher Key (SCK), finally, is a predetermined key, which can be used

without prior authentication. It is “static” in the sense that it is a fixed key that is not changed by another security function (e.g. by an authentication exchange) until it is replaced. TETRA supports the use of up to thirty-two (32) SCKs in an MS, per network. They can be distributed similarly to the GCKs. Their use is largely implementation dependent but they can be used for encryption in Direct Mode Operation (where they may also provide explicit authentication) and in certain TETRA systems also for encryption for group and individual communications. The SCK may also be used in a system that normally uses DCKs and CCKs as an alternative to those keys in fallback conditions. When an SCK is distributed to an MS over the air interface using OTAR it is encrypted with a session encryption key derived from the Authentication Key for this MS (TETRA Security).

o When used in DMO, SCKs may be grouped in a way that allows several SCKs to

be associated with the same talk group(s). This allows an MS to have a current SCK defined for transmission, but to allow reception on one of the others. This allows a practical key management mechanism to be constructed, where one MS may be commanded to start using a new SCK for transmission before the changeover message has reached another MS (TETRA Security).

Questions: Is there used Derived Cipher Key (DCK) or Static Cipher Key (SCK) or both (SCK in DMO, DCK in TMO) in the home network Is there used Class 3 operation in DCK and Class 2 operation SCK in the home network? What are the requirements for the migrated MS?

21/35


7.2.1.5 End to End (E2EE) Security TETRA and TETRAPOL support End to End encryption using a variety of encryption algorithms as deemed necessary by national security organizations. The TETRA Association Security and Fraud Prevention Group (SFPG) have extended the work carried out in the TETRA standard to define a general framework for the incorporation of End to End encryption. Recommended sample solutions have also been provided for the International Data Encryption Algorithm (IDEA) algorithm (IPR owned by Ascom) and the newer Advanced Encryption Standard (AES) algorithm (IPR free), which benefits from a larger cryptographic algorithm block size. Custom and indigenous algorithms are also possible with End to End encryption (E2EE), although these are not recommended for air interface encryption due to their need for integration in signaling protocols and availability of standard compliant terminals (www.tetramou.com). End to End encryption is available for following services in TETRA and TETRAPOL:

o Voice communications o Data communications o Network can handle both encrypted unencrypted user groups o There cannot be user groups between encrypted and unencrypted subscribers

without terminal fallback feature (usage of encryption is selected in the terminal) Questions: Is there used E2EE in the home network? Should E2EE work also when the MS is migrated? How there is communicated with groups that contain user that does not support used E2EE method? How the fall back is implemented to non-E2EE communication (automatically or manual setting in terminal)?

7.2.1.6 Group Call Group call enables the users that have selected the same talk group in their mobile radios to communicate with each other on a half-duplex basis. Half duplex means that one user is speaking while the others in the same group listen to the person that is transmitting. Questions: How many talking groups are needed for communication between different parties? Should there be one owner (home or visiting organization) of a shared group? Should there be groups for only visiting users (using their own E2EE) locally and connected to home network groups? Should visiting network dispatcher be able to join all groups, where ISI linked?

7.2.1.7 Group Call Queuing In TETRA and in TETRAPOL a queue is provided in the trunking controller during network busy periods to store and handle calls on a First in First out (FIFO) basis in order of user priority level. The advantage is that a user only has to initiate a call request once, knowing that even in busy periods the call will be automatically established once a traffic channel becomes free, thus

22/35


reducing user stress and frustration when contending with other users on a busy network (www.tetramou.com). It is known that all network vendors do not support call queuing. Questions: Is there network support for queuing of talk item with group calls in the home network? Is there needed network support for queuing of talk item with group calls when the terminal is migrated?

7.2.1.8 Individual Call Individual call is a one-to-one call between two mobile radios. The call can be full duplex or half duplex in TETRA and only half duplex in TETRAPOL. Individual call should work over ISI or through the gateways as it works internally in home network. Questions: Is individual call used in the home network? If network does not support individual call, what is done for visiting terminal, which tries to make an individual call (deny of service vs. creating group to the called party?)

7.2.1.9 Emergency Call / Emergency Call Routing Emergency call provides the highest uplink priority and highest priority access to network resources. If a network is busy, the lowest priority communication is dropped to handle the emergency call. Activating the emergency call automatically alerts the affiliated control room dispatcher and other terminal users in that persons talk group. Interoperability enhancements should support emergency call of visited user in similar way to work internally in home network. Questions: Is emergency call used with individual call? Is emergency call used with group call? Should emergency call be routed to emergency center in the home network or the emergency center in the visited network or both? Does emergency indication (emergency status message) work over ISI or through gateways?

23/35


7.2.1.10 Short Data Service (SDS) Short Data Service (SDS) is a data service that is comparable with the Short Data Message (SMS, short message service) of GSM. Many applications can use the SDS service to carry information. The most common use of SDS service is the sending of message that is entered via the keypad of the subscriber. Also the GPS location information is usually transported via SDS messages. The limit of data is 140 byte per message. Questions: How frequently SDS is used for individual or group communication? What services are implemented in the home network by using SDS? Is there a need for encrypted SDS

7.2.1.11 Status Messages Status messages allow defining preconfigured status messages that are identified by unique number. The system interprets messages numbers to messages. There could be different associations for message numbers in different networks. Questions: How status messages are associated with meanings in the different networks?

7.2.1.12 PSTN Call PSTN call provides full duplex call in TETRA and half duplex call in TETRAPOL to Public Switched Telephone Network (PSTN) like to commercial mobile networks. Questions:

o Should a PSTN call be routed to the home network or is it allowed to be routed via visited network?

o Should calling party identity (CPI) be visible in the migrated terminal?

7.2.1.13 Packet Data The packet data service can be supported on one TDMA time slot with a gross protected bit rate of 4800 bits/s or multiple TDMA time slots up to a maximum of four. The use of multiple TDMA time slots is often referred to as bandwidth on demand and can be used to increase gross protected data throughput up to 19.2 kbits/s (www.tetramou.com). In the core network data can be routed via Gp- or Gi-interface and it should be considered what interface is used with interworking. There is an IPI standard in ETSI, supporting packet data over ISI. IPI is not supported in any TCCA TIP profiles and there are currently no suggestions to support IPI or packet data over ISI. Default is to route packet data out of the network, where the terminal is registered and to internetworking in IP networks. IP mobility can be used for migrating between TETRA networks.

24/35

http://www.tetramou.com/


On the TETRAPOL side and with a solution based on a gateway, the problem is simplest. The interface to the control rooms already contains all the elements necessary to the provision of the services in connected packet mode. Questions:

o Is there any use case that would require the usage of the packet data in visiting network?

o Should the data be routed via Gp- or Gi-interface?

7.2.1.14 Dynamic Group Number Assignment (TETRA) / Merging (TETRAPOL)

This service allows the creation of unique Groups of users to handle different communication needs and may also be used to group participants in an ongoing call. This service is considered by many public safety organizations to be extremely useful in setting up a common talk group for incident communications. For example, selected users from the Police, Fire and Ambulance could be brought together to manage a major emergency where close co-ordination between the three emergency services is required. Similarly, DGNA is also considered useful for managing incidents by other user organizations such as Utilities and Transportation (www.tetramou.com). Questions:

o Is DGNA/Merging used in the home network? o Need DGNA/Merging to work when the terminal is migrated?

7.2.1.15 Automatic Vehicle Location (AVL) Automatic Vehicle Location (AVL) is used to track and trace persons or vehicles using TETRA/TETRAPOL radios. Most TETRA radios are equipped with an integrated GPS receiver and TETRAPOL radios need additional GPS receiver to be integrated with terminal. The TETRA/TETRAPOL radio is able to determine its location and can send this information to the infrastructure were it can be forwarded to an end point which is in most cases a control room (www.tetra-consultancy.com). The location is sent via a SDS or packet data to an AVL server. The AVL system may be a fixed host in the TETRA network, connected via control room API of the TETRA network or a server connected to the PEI of a radio terminal. The radio needs be have the destination address (ISSI) of the AVL system pre-programmed. It is common that the TETRA radio sends the location message as a LIP (Location Information Protocol) to the AVLS server. The LIP protocol is an ETSI standardized protocol for location information. The control room(s) connects to the AVL server to obtain the location information of the TETRA mobile radios and display their locations on a map. The connection between the control room(s) and AVL server is usually a proprietary protocol (www.tetra-consultancy.com). In a TETRAPOL the location is sent via Short Datagram to an AVL server. The AVL system may be a fixed host in the TETRAPOL network identified by a functional IP address, connected to the Data Network Controller (DNC). In TETRAPOL server is not recommended the use of a radio terminal to connect the AVL Server due to collision of messages. The UDT (User Data Terminal) connected to the radio must have configured the functional IP address of the AVL Server. There is no TETRAPOL location protocol defined, so the messages use a proprietary protocol and it

25/35

http://www.tetramou.com/


depends on the AVL Server integrator. The connections between the control room(s) and AVL server and between UDT and Radio Terminal are defined in TETRAPOL Publicly Available Specification. Questions:

o IS AVL used in the home network? o Is AVL sent to home AVL server (over ISI) and/or visited network AVL server? o Is there used LIP protocol for AVL (over SDS)? o Is there need to control AVL load of visiting terminals

7.2.1.16 Integration with control rooms Control room operation and connection is outside of ETSI ISI interface service. The default assumption is that visiting user can be connected/under control of a local command center in the visited network or connected/under control of home control center. TETRA ISI is to support control room dispatcher workstation to join visiting terminals groups in visited network as well as joint (linked) groups, like joining the groups of home network. In the TETRAPOL presupposed the solution, the interface to the control room will be exploited to achieve the connection between the network and the gateway. Questions: Do you need to have a control room visibility of foreign operator network (where you end-users have migrated)? How do you communicate with foreign control room?

7.2.2 Terminal

7.2.2.1 Features for migration TETRA/TETRAPOL terminals should include migration support as defined in TETRA/TETRAPOL standards, to visited network. It has to be ensured that the needed features are supported by the visited network and the terminals in the visited network. Considered features are: Authentication AI Encryption E2E Encryption Group call Individual call Telephone call Emergency call Status SDS Packet data AVL

26/35


7.2.2.2 Network Selection The radios must have to the possibility to favors one network. A manual change must always be possible. This is made because by logging in automatically on the strongest network. The displays of the radios have to show the active network. Identification of a calling team has to be displayed on the radios. Questions: Is there needed to migrate automatically or manually? Is there needed to see on the phone screen the network identity of the visited network?

7.2.2.3 Direct Mode (DMO) In direct mode of simplex operation where mobile subscriber radio units may communicate to each other by using radio frequencies, which may be monitored by, but which are outside the control of the TETRA/TETRAPOL Trunked network. In case of different standard (TETRA/TETRAPOL) and even in case of different frequency planning’s inside the same standard, this raises the question of the dual mode terminal. Interoperability between handsets of different standards can only be provided by overlapping, bridged networks or locally through direct mode. More general interoperability, for example roaming, can only be achieved through dual standard appliances. Many recent Public Safety radios use a similar internal architecture for both standards, the differing technical protocols being implemented in firmware. It may therefore be feasible for manufactures to produce a dual standard option at an affordable price, or even upgrade existing appliances with new firmware. This task will consist in a feasibility study to assess options for bringing dual standard handsets to the market, and resolve any licensing issue this might imply. Questions: Is direct mode used in the home network? Is direct mode needed in the visited network? What frequencies are used for DMO communication? Is DMO to be used encrypted (SCK) or clear voice? Is automatic adaptation to visited network SCK needed? Are operators ready for using dual mode terminals?

7.2.2.4 Phonebook associations It is supposed that cross border operations are not performed as daily basis (except concerning customs personals) so fixed phonebook associations for seamless communications are needed (SDS, talk) between different parties. Questions: How many associations are needed in each terminal?

27/35


77..33 TTeecchhnniiccaall ssoolluuttiioonnss

7.3.1 Solution-1: Inter-network communication

’ Figure 6 Inter-network communication with ISI

Communication between terminals in two different networks. Each terminal is under its nominal coverage. Needed features for interworking are: Group call Individual call On field use case: Cooperation cross-border, cooperation in a coordinated effort to raid a criminal organization operating in different countries.

28/35


7.3.2 Solution-2: Overlapping networks

Figure 7 Overlapping networks with ISI Communication between terminals from two different networks. Each terminal is under its nominal coverage and can communicate to all terminals. Needed features for interworking are: Group call Individual call Network selection and display for used network (terminal) On field use case: Cooperation of private fire brigades Communication of security personnel with public safety officers in the control room during incidents Communication of armed forces to police officers. Connection of a rapid deployment system to the regional or countrywide network

29/35


7.3.3 Solution-3: Coverage expansion

Figure 8 Coverage expansion with ISI In need of coverage expansion, a terminal A can move into network B with the same communication services than nominal network. Needed features are: Pre-provisioning for the migrating subscribers in the visited network Authentication AI Security No limitations for used features compared to the home network On field use case: Cross-border operation of public safety officers

30/35


7.3.4 Solution-4: Migration

Figure 9 Migration with ISI Communication inter-network with terminals mobility. Needed features for interworking are: Authentication AI Encryption E2E Encryption Group call Individual call Telephone call Emergency call Status SDS Packet data AVL On field use case: Operation of public safety officers in foreign radio networks

31/35


77..44 NNoonn--FFuunnccttiioonnaall RReeqquuiirreemmeennttss

Non-functional requirement focus on how the system should perform the specific operation instead of what the system can do. Performance, reliability, availability, security, maintainability and portability are some of non-functional requirement approach discussed in the following chapter. Although non-functional requirement are stated below, measurement of the requirements should be declared in order to analyze, verify, and to meet the needed non-functional requirements.

7.4.1 Performance

The system should meet following performance parameters (ETSI TR 101 448 V1.1.1): Dimensioning according use cases For group calls the call setup delay should be less than 1,0 seconds 95 % of the setups should be within the specified time The end-to-end audio delay experienced by the users for calls without end-to-end encryption over the ISI should not be higher than 0,7 seconds The initial migration registration procedure (including authentication) to a foreign network should not take more than a few seconds longer than the first registration (including authentication) on the home network of a radio

7.4.2 Reliability

o Physical connections for ISI-interfaces should be provided by reliable and secure service provider

o Same as in home network

7.4.3 Availability

Same as in home network

7.4.4 Security

The link of the ISI-interface between SwMIs should be encrypted Visited network should fulfill same security standards as home network

32/35


List of Figures Figure 1: TETRA standard and IOP milestones ............................................................................ 8 Figure 2 Communication flow for police in cross border operation ...............................................12 Figure 3 Communication setup for police in cross border operation .............................................13 Figure 4 Communication flow for emergency services in cross border operation .........................14 Figure 5 Communication setup for emergency services in cross border operation .......................15 Figure 6 Inter-network communication with ISI .............................................................................28 Figure 7 Overlapping networks with ISI ........................................................................................29 Figure 8 Coverage expansion with ISI..........................................................................................30 Figure 9 Migration with ISI ...........................................................................................................31

33/35


List of Tables Table 1 Requirements for network interoperability .......................................................................16 Table 2 Requirements for TETRA features ..................................................................................16 Table 3 Requirements for TETRA features ..................................................................................17 Table 4 Requirements for other features ......................................................................................17

34/35

Annex I: MACICO Requirement Acquisition Interview Form

ANNEX I: MACICO REQUIREMENT ACQUISITION INTERVIEW FORM

35/35


MACICO Requirement Acquisition

Interview Form

AABBSSTTRRAACCTT This document will be used in collecting end user and network operator requirements and use cases in task D2.1 of Work Package 2 (WP2) in MACICO project. It will be one of the many input documents, which are to be used in producing End Users Requirements Specification (deliverable D2.1).

Document Title MACICO Requirement Acquisition Interview Form

Deliverable

Document Id N° Version V02 Status Date 28/05/2012

Project Classification MACICO partners & end users

Filename MACICO_Req_Acq_Interview_Form.docx Document manager

Jaakko Tyni Laurea

Approval status

Author Responsible Partner Verification Project Approval

Laurea <Company> Cassidian SAS

Jaakko Tyni <Name> Laurent Drouglazet

T2.1 Leader <Role> Coordinator

1/5


Revision table Version Date Modified

Pages Modified Sections

Comments

01 20/04/12 Creation of the document

02 28/05/12 4-5 2.2 and 2.3 Comments from Cassidian, Prescom and Altech included

Table of Contents 1 MACICO Project ................................................................................................................ 3

1.1 Objectives ....................................................................................................................... 3 1.2 WP2: End users requirements capture ........................................................................... 3 1.3 Task 2.1 End-users requirements specification ............................................................... 3

2 Requirements Acquisition .................................................................................................. 4 2.1 User information ............................................................................................................. 4 2.2 Past experience in digital PMR ....................................................................................... 4 2.3 Future needs in TETRA/Tetrapol interoperability with other networks ............................. 5

2/5


1 MACICO PROJECT

11..11 OObbjjeeccttiivveess

MACICO’s (Multi Agency Co-operation In Cross Border Operations) main objective is to reply to the short term needs of the Public safety organisation on radio communication systems for cross-border operations and for co-operative crisis missions. The organisations will communicate without functional perturbance and corrupting the network's security. MACICO will also study interoperability issues that raise from the transition period between the existing networks and next broad band generation.

11..22 WWPP22:: EEnndd uusseerrss rreeqquuiirreemmeennttss ccaappttuurree WP2 will focus on acquisition of use cases and system requirements. WP2 gathers all work related material to the interaction with operators and end-users. It is organised around a framework for gathering operational scenarios and requirements, as well as systematic methodology for harmonisation of needs at the European level.

11..33 TTaasskk 22..11 EEnndd--uusseerrss rreeqquuiirreemmeennttss ssppeecciiffiiccaattiioonn The requirements are produced by existing operational users/operators from (several) already deployed networks. It shall address issues such as:

Capability and conditions for use of radio terminal by foreign users in their networks;

Use cases for Voice Communications including foreign terminals in a network;

Use cases for Data Communications including foreign terminals in a network;

Uses case for Inter Network Communications;

Management conditions for gateways deployment and interoperability configuration;

Requirements on the interoperability backbone.

3/5


2 REQUIREMENTS ACQUISITION

22..11 UUsseerr iinnffoorrmmaattiioonn Type of user (border guard, police, military, fire & rescue, customs, industry, other):

Role in your organisation:

Years of experience: ____ years

22..22 PPaasstt eexxppeerriieennccee iinn ddiiggiittaall PPMMRR

For how many years have you been using TETRA/Tetrapol terminals:______ years Which services have you used:

Group call

Individual call

Text messaging (SDS)

Packet data

Have you used command & control systems in the field based on TETRA/Tetrapol communications? If yes, please describe. What have been major problems, limitations, weaknesses or challenges in using these? Have you been involved in national/international multi-authority situations? If yes, please describe. Have you been in situations, where communications (voice and/or data) between networks (TETRA-TETRA, TETRA-Tetrapol, TETRA/Tetrapol-3G, Tetrapol-Tetrapol) would have helped in managing the situation? If yes, please specify/describe. What kind of interoperability would have been needed?

4/5


22..33 FFuuttuurree nneeeeddss iinn TTEETTRRAA//TTeettrraappooll iinntteerrooppeerraabbiilliittyy wwiitthh ootthheerr nneettwwoorrkkss

What kind of interoperability will you need in the future: TETRA – TETRA

TETRA – Tetrapol

Tetrapol – Tetrapol

TETRA – 3G/4G

Tetrapol – 3G/4G

other:

What kind of services between networks will be needed: roaming (migrating into other network)

individual call

group call

text messaging (SDS)

Narrow band packet data (status, free messages, AVL, resource management, database

queries, telemetry,…)

Wide band packet data (TEDS, image transmission, data files transmission, ANPR,…)

Broad band packet data (video streaming,…)

Caller ID

Priority / pre-emption

Emergency call

Other:

Please describe briefly the scenarios and use cases, in which interoperability would be beneficial: What about security challenges & requirements: Security of networks

Security of organisations

Security of individuals (end users)

Security of voice and data communications

Free word: what else would you like to say?

5/5

MACICO D2.1 End-users Requirements Specification€¦ · Pasi Kämppi Last draft for final approval...

Documents

Transcript of MACICO D2.1 End-users Requirements Specification€¦ · Pasi Kämppi Last draft for final approval...