Pilot project on the design, implementation and execution of the transfer of GNSS data during an E112 call to the PSAP

Transcription

1 Ref. Ares(2017) /07/2017 Pilt prject n the design, implementatin and executin f the transfer f GNSS data during an E112 call t the PSAP Cntract N 440/PP/GRO/PPA/15/8308 Deliverable D4.1-D4.2 - Tests specificatin Lïc Belln July 2017

2 Cntract N 440/PP/GRO/PPA/15/8308 Deliverable D4.1-D4.2 Tests specificatin Pilt prject n the design, implementatin and executin f the transfer f GNSS data during an E112 call t the PSAP Respnsibility-Office- Cmpany Date Signature Prepared by Lïc Belln 04/04/2017 Verified by Yves Capelle 04/04/2017 Apprved by Yves Capelle 04/04/2017 LEGAL NOTICE This dcument has been prepared fr the Eurpean Cmmissin hwever it reflects the views nly f the authrs, and the Cmmissin cannt be held respnsible fr any use which may be made f the infrmatin cntained therein. 2/71

3 ENREGISTREMENT DES EVOLUTIONS / CHANGE RECORDS ISSUE DATE : DESCRIPTION DES EVOLUTIONS : CHANGE RECORD REDACTEUR AUTHOR /02/2016 Deliverable utline L. Belln /07/2016 Draft versin Sectins 1 and 2 L. Belln J. Medland /07/2016 Sectins 3, 4, 5, 6, 7, and 8 L. Belln I. Embaby /08/2016 Mdificatin f sectin 6.1 Minr changes frm cnsrtium review /09/2016 Mdificatin f sectin 6 Implementatin n pilt sites infrmatin L. Belln L. Belln /09/2016 Minr changes frm cnsrtium review L. Belln /11/2016 Revisins based n cmments frm Checkpint 4 as dcumented in the minute with ids: EC-CKP4-23, GSA-CKP4-24, GSA-CKP4-25, EC-CKP4-26, EC-CKP4-27 L. Belln /01/2017 Final versin base n secnd batch f cmments frm EC and GSA. L. Belln /04/2017 Minr update fllwing FR review Y.Capelle 3/71

4 TABLE OF CONTENTS 1. INTRODUCTION PLACE OF THIS DOCUMENT AND OBJECTIVES FOREWORD APPLICABLE DOCUMENTS REFERENCE DOCUMENTS GENERIC TEST OF ESTIMATE AND TRANSMISSION OF HANDSET BASED LOCATION DATA TO EMERGENCY SERVICES TEST-BED TECHNICALITIES TEST DESCRIPTION General Testing Lcatin accuracy tests Transmissin methds tests The Test Prcess Determining the Lngitude and Latitude values fr yur Test Psitin Summarising Test Results Emergency call prcedure Test frm Test Results TEST OF INTERNATIONAL ROAMING-ENABLED SMS TRANSMISSION (ARCHITECTURE 2) TEST-BED TECHNICALITIES TEST DESCRIPTION TEST OF DATA CHANNEL (HTTPS) TRANSMISSION (ARCHITECTURE 4) TEST-BED TECHNICALITIES TEST DESCRIPTION TEST OF GALILEO ADDED VALUE (ARCHITECTURE 1) TEST-BED TECHNICALITIES TEST DESCRIPTION The test prcess Test Results Selected User Scenaris TEST OF USER PLANE NETWORK-BASED LOCATION METHOD ADDED VALUE (ARCHITECTURE 3) TEST-BED TECHNICALITIES TEST DESCRIPTION Prerequisites /71

5 6.2.2 Test envirnment and setup Prf f Cncept prcess TESTS TO PERFORM AND USER SCENARIOS FOR EACH PILOT UK PILOT (BT) Handset based Lcatin methd and SMS transmissin Internatinal raming enabled SMS transmissin User Plane Netwrk Based Lcatin methd added value Data channel (HTTPS) transmissin LITHUANIAN PILOT (112ERC) Handset based Lcatin methd and SMS transmissin User Plane Netwrk-Based Lcatin methd added value AUSTRIAN PILOT (NNO) Handset based Lcatin methd and SMS r data channel (HTTPS) transmissin ITALIAN PILOT (AREU) Handset based Lcatin methd and data channel (HTTPS) transmissin SUMMARY OF PILOTS DEPLOYMENTS AND TESTS Technlgies t be tested and implementatin required in each PSAP User Scenaris Pilts deplyment /71

6 LIST OF TABLES Table 1 Applicable dcuments Table 2 Reference dcuments LIST OF ILLUSTRATION TABLES Table 1 - HELP112 flw chart LIST OF FIGURES Figure 1 - Architecture 2-A cmpnents descriptin Figure 2 - Lcatin Calculatr test - Lgical prcess /71

7 LIST OF ABBREVIATIONS 3GPP - 3rd Generatin Partnership Prject A-GNSS - Assisted Glbal Navigatin Satellite System A2C - Authrities t Citizens cmmunicatin ACE - Accredited Center f Excellence AML - Advanced Mbile Lcatin API - Applicatin Prgram Interface BSC - Base Statin Cntrller (2G) BSSAP-LE - LCS Extensin fr Lb, Lp and Ls interfaces BSSMAP-LE - BSSMAP LCS Extensin BSSLAP - BSS LCS Assistance Prtcl C&C - Cmmand & Cntrl C2A - Citizens t Authrities cmmunicatin CAD - Cmputer-aided dispatch CAPEX - Capital expenditures CEN - Eurpean Cmmittee fr Standardisatin CERN - Eurpean Organisatin fr Nuclear Research CNES - French Space Agency CS Creativity Sftware EC - Eurpean Cmmissin E-CID Enhanced Cell ID ECAS - Emergency Call Answering Service ECC - Electrnic Cmmunicatins Cmmittee EE - British mbile phne peratr, frmerly Everything Everywhere EGNOS - Eurpean Gestatinary Navigatin Overlay Service E-GNSS Eurpean Glbal Navigatin System EISEC - Enhanced Infrmatin System fr Emergency Calls ESA - Eurpean Space Agency ESSN - Emergency Services Staff Netwrk ETC - Electrnic Tll Cllectin ETSI - Eurpean Telecmmunicatins Standards Institute EU - Eurpean Unin FP7 - Framewrk Prgramme 7 GIS - Gegraphical Infrmatin System GMLC - Gateway Mbile Lcatin Center GNSS - Glbal Navigatin Satellite System GPS - Glbal Psitining System GSM - Glbal System fr Mbile Cmmunicatins HSS - Hme Subscriber Server ICE - In Case f Emergency IETF - Internet Engineering Task Frce IP - Internet Prtcl IPR - Intellectual Prperty Right IRSN - French Nuclear Safety Institute Iupc - Interface between RNC and SAS (RNC interface) IVE - in-vehicle equipment IVS - in-vehicle systems KPI - Key Perfrmance Indicatr LAC - Lcatin Area Cde LBS - Lcatin based Services LCS - LCatin Services LCS-AP - LCS Applicatin Prtcl LPP - LTE Psitining Prtcl LTE - Lng-Term Evlutin LPP - LTE Psitining Prtcl MAC - Media Access Cntrl MEP - Member f the Eurpean Parliament MLC - Mbile Lcatin Centre MME - Mbility Management Entity (4G) 7/71

8 MNO - Mbile Netwrk Operatr MSD - Minimum Set f Data MSG - Mbile Standard Grup MSISDN Mbile Statin Integrated Services Digital Netwrk Number MT-LR - Mbile Terminating Lcatin Request NG - Next Generatin NG112 - Next Generatin 112 OPEX - Operating Expenditures OS Operating System OTDOA - Observed Time Difference Of Arrival PCAP - Psitining Calculatin Applicatin Part PCO - Prject Cntrl Office PEMEA - Pan-Eurpean Mbile Emergency Applicatin PSAP - Public Service Answering Pint R&D - Research & Develpment RNC - Radi Netwrk Cntrller (3G) Rx - Received Signal level RRLP - Radi Resurce Lcatin services Prtcl RTT Rund Trip Time SAS - Standalne SMLC SET - SUPL enabled terminal SIM - Subscriber Identity Mdule SIP - Sessin Initiatin Prtcl SL - SUPL Lcatin SLA - Service Level Agreement SLC - SUPL Lcatin Center SLP - SUPL lcatin platfrm SMLC - Serving Mbile Lcatin Center SMS - Shrt Message Service SSID - Service Set IDentifier SUPL - Secure User Plane TDOA - Time Difference f Arrival TA - Timing Advance (between an MS and its serving BTS) TL - Task Leaders TLRR - Trigger Lcatin Reprting Request TM - Technical Manager TOA - Time f Arrival TTFT - Time T First Fix WP - Wrk Package WPL - Wrk Package Leader UE - User Equipment (mbile) UMTS - Universal Mbile Telecmmunicatin System URI - Unifrm Resurce Identifier URN Unifrm Resurce Name WGS84 - Wrld Gedetic System Datum 84 VLTE - Vice ver LTE 8/71

9 1. INTRODUCTION 1.1 PLACE OF THIS DOCUMENT AND OBJECTIVES This dcument is the Tests technical design and specificatin, identified as D4.1 and D4.2 in the list f prject deliverables. It is generated as part f the cntract 440/PP/GRO/PPA/15/8308. The bjectives f this dcument are t specify the trials and specific technicalities related t the architectures selected fr the pilts in D3.3. As a reminder, here are the fur architectures selected fr the pilts: Architecture 1: Handset hybrid psitining methd + E-GNSS SUPL server and client + SMS transmissin. This architecture aims t evaluate the added value f Galile GNSS system (Precisin/Accuracy; Respnse Time, ) in the prcess f estimating the caller lcatin in the case f an emergency call. Architecture 2: Handset hybrid psitining methd + SMS transmissin internatinal raming enabled. This architecture aims t test the transmissin f caller lcatin using SMS in the case f internatinal raming cnditins. Architecture 3: Handset hybrid lcatin methd + SMS transmissin methd + NBL Lcatin Calculatr based n Radi Measurement Reprt (RMR). Fr this architecture, the pilts will fcus n ffline tests f the lcatin estimate prcess using enhanced Netwrk- Based Lcatin methds based n the Radi Measurement Reprt sent by the handset t the Mbile Netwrk Operatr. In this architecture, we shuld distinguish the s called HELP112 Lcatin Server that receive and decde the lcatin estimated by the handset lcatin API (this lcatin estimate is then available fr the PSAP), and the s called Lcatin Calculatr that uses the Radi Measurement Reprt (sent alng with the handset based lcatin estimate) t cmpute anther lcatin estimate based n NBL methds (TA, Enhanced Cell-Id, OTDO-A, ). The lcatin cmputed by the Lcatin Calculatr using the RMR is used as a safety net in the case where n lcatin r a simple Cell-Id lcatin is returned by the handset. Architecture 4: Handset hybrid lcatin methd + Data channel transmissin methd. Pilts will fcus here n testing the transmissin f lcatin data using the data channel (HTTPS). The technical descriptin f these fur architectures is given in HELP112 deliverable D3.2. Each test will be described in ne sectin f this dcument with regards t the technicalities t be implemented in the selected pilts. Fr each test previusly defined and their related pilt(s), the last sectin f the dcument will describe the use cases f the test with regards t the User Scenaris as defined in D1.1 and D3.1. The chart verleaf defines the place f this dcument and its interactin with ther wrk packages deliverables: 9/71

10 Table 1 - HELP112 flw chart As a reminder, here are the gals f each wrk package s deliverable: WP1: WP2: WP3: D1.1: Defines the user requirements and frmulates a set f user scenaris that will lead the implementatin and evaluatin f the architecture. D1.2: Analyses and cmpares the existing slutins and the underlying technlgies fr the prvisin f caller lcatin. D1.3: Analyses hw existing slutins satisfy the requirements, reprts the barriers fr deplyment and prvides recmmendatins fr the implementatin. D2.1: Defines the key lcatin and transmissin technlgy scenaris and assess the csts and benefits f each scenari. D2.2: Recmmends the ptimal scenari(s) fr the help112 caller lcatin based n the results f the cst-benefit analysis. D2.3: Prvides a mre detailed assessment f the csts linked t implementatin f the selected technlgy scenari(s) as well as key peratinal and financial recmmendatins. D3.1: Defines pssible implementatin architectures fr the pilt sites, cvering lcatin/transmissin tech. alternatives f WP1. D3.2: Describes technicalities f these architectures and recmmendatins fr their implementatin. D3.3: Selects the architecture t be deplyed fr the pilts based n utputs f WP2. 10/71

11 WP4: D3.4: Analyses the gaps between the selected architecture and the existing standards (ecall, 3GPP, ECC-REP-225). D4.1: Describes the necessary mdificatins, adaptatins, and new develpment in the PSAP based n D3.2 utputs. D4.2: Specifies the tests t be perfrmed in each pilt based n the Architectures selected in D3.3 and n the User Scenaris. D4.3: Describes the implementatin prcess and tests results f the selected architectures in the UK pilt. D4.4: Describes the implementatin prcess and tests results f the selected architectures in the Lithuanian pilt. D4.5: Describes the implementatin prcess and tests results f the selected architectures in the Italian pilt. D4.6: Describes the implementatin prcess and tests results f the selected architectures in the Austrian pilt. 1.2 FOREWORD Emergency caller lcatin is the mst imprtant piece f infrmatin fr bth PSAPs and first respnders. Ensuring it is accurate, reliable and timely will save lives and significant emergency services resurces. Nt having it will mean negative utcmes fr ur citizens. In the absence f a detailed and prescriptive regulatry framewrk, emergency mbile caller lcatin infrmatin in Eurpe has typically relied n Cell-ID. Often, Cell-ID is inadequate because the cell radius is t large, ntably in rural areas, and smetimes the serving cell might nt be the clsest ne t the handset. Develpments in lcatin technlgies and the prliferatin f GNSS enabled smartphnes are leading t imprved lcatin infrmatin being available in the handset. Making such handset derived psitining infrmatin available t PSAPs during emergency cmmunicatins in a secure and reliable manner is highly desirable. This cnsrtium, knwn as the HELP112 cnsrtium, aims demnstrate that accurate and reliable caller lcatin infrmatin is highly effective and is als highly efficient. It als studies pssible deplyment strategies acrss Eurpe in a cst effective manner, securing better utcmes fr ur citizens and simultaneusly nt placing any additinal burden n the emergency services, mbile netwrk prviders r public authrities. 11/71

12 1.3 APPLICABLE DOCUMENTS AD AD 1 Title f the dcument & reference Cntract 440/PP/GRO/PPA/15/8308 AD 2 Help112 Cnsrtium Agreement Table 1 Applicable dcuments 1.4 REFERENCE DOCUMENTS RD RD 1 Title f the dcument & reference Help112 Technical, Management & Financial Prpsal TPZF/SSA-T2015-PP-0451 is1.0 31/07/2015 RD 2 Help112 Requirements Dcument D1.1 RD 3 Help112 Requirements Dcument D3.1 RD 4 Help112 Technical descriptin D3.2 Table 2 Reference dcuments 12/71

13 2. GENERIC TEST OF ESTIMATE AND TRANSMISSION OF HANDSET BASED LOCATION DATA TO EMERGENCY SERVICES. 2.1 TEST-BED TECHNICALITIES The generic test f estimate and transmissin f handset based lcatin data t emergency services defines the prcedure t test the estimate f the lcatin f an emergency caller triggered by a call t 112 r whatever natinal emergency number using the caller s handset wn capabilities (GNSS, WiFi, ), and the transmissin f the lcatin data frm the handset t the PSAP. This generic test will be the basis fr the fllwing specific tests: Test f SMS transmissin methd (Sectin 3). Test f data channel (HTTPS) transmissin methd (Sectin 5). Test f SMS transmissin methd internatinal raming enabled (Sectin 4). Test f Galile added value in caller s lcatin estimate prcess (Sectin 6). The pilts which are ging t test the estimate and transmissin f handset based lcatin data t emergency services are under the prcess f implementing HELP112 slutins n the basis f Advanced Mbile Lcatin (AML). AML prcess is fully cmpliant with HELP112 architectures 1, 2, and 4 described in HELP112 deliverables D3.1 and D3.2, and particularly with the lcatin MSD (Minimum Set f Data) defined fr HELP112 slutins. The fllwing sub-sectin described the test prcess and are based n the AML Trial Guide and Test Results TEST DESCRIPTION The tests cnsist f a vice call t 112 (a natinal emergency number may be used if implemented as part f the slutin tested) and the lcatin is autmatically sent t 112 r the cuntry specific emergency number fr lcatin data. T avid any cnfusin n the live service, there is a script t be fllwed fr speaking t the 112 call handling agent at the PSAP answering the call. Test calls need t be planned and agreed with the PSAP call handling team cntact (insert lcal PSAP address) using HELP112 emergency test calls as the subject. The test results will be summarised by PSAP team prviding different results abut the lcatin prvided by the handset based lcatin slutin, including: An analysis f the rate f calls with handset lcatin prvided t the PSAP. 1 Please see the secnd part f the AML Specificatins & Requirements dcument, starting frm page /71

14 An analysis f the imprvement f precisin brught by the handset based lcatin slutin when cmpared t netwrk prvided cell cverage. An analysis f the respnse time f the HELP112 handset based lcatin slutin General Testing Handset settings Data settings If it is nt specifically instructed t turn OFF the data cnnectivity in the related test, mbile data is t be enabled at all times. Time settings autmatic (i.e. aligned with netwrk time, nt set by user). Netwrk Settings autmatic (i.e. uses 4G, 3G r 2G). HELP112 handset battery Prtectin Settings set as n. Battery battery is expected t have at least 15% battery charge (T be cnfigured n the handset if needed) Wifi mde Wifi can be enabled/disabled accrding t the individual tests described later Typical User settings fr lcatin functinality Three sets f tests are defined fr the different types f lcatin (use cases) in sectin 2.3 in rder t test a handset s ability t prvide a lcatin using Assisted GNSS, Wifi, cell cverage r standalne GNSS. T be sure that the HELP112 slutin is activating the GNSS and WiFi sensrs when a call t 112 is made, it is helpful t use the three Andrid Lcatin mdes as ur three typical user types: A. High Accuracy (the use everything fr best service user that can use assisted GNSS (A- GNSS), WiFi r Cell ID based lcatins B. Battery Saving (fr the careful user, WiFi and cell nly), C. Device Sensrs (privacy cnscius setting, uses stand-alne GNSS). Fr ther handset perating systems, the nearest equivalent shuld be used. Whatever the lcatin mde set n the phne (A, r B, r C), the HELP112 handset sftware shall activate the GNSS and WiFi sensrs during the emergency call, and then turn them t the state they were prir t the emergency call (disabled r enabled depending n the settings f the phne prir t the emergency call). Accrding with recital (36) and Art.10 f the Directive n privacy and electrnic cmmunicatins (Directive 2002/58/EC) Member States may restrict the users' and subscribers' rights t privacy with regard t calling line identificatin where this is necessary t trace nuisance calls and with regard t calling line identificatin and lcatin data where this is 14/71

15 necessary t allw emergency services t carry ut their tasks as effectively as pssible. In ding s, Member States shall ensure that there are transparent prcedures gverning the way in which a prvider f a public cmmunicatins netwrk and/r a publicly available electrnic cmmunicatins service may verride the eliminatin f the presentatin f calling line identificatin and the temprary denial r absence f cnsent f a subscriber r user fr the prcessing f lcatin data, n a per-line basis fr rganisatins dealing with emergency calls and recgnised as such by a Member State, including law enfrcement agencies, ambulance services and fire brigades, fr the purpse f respnding t such calls. Fr these purpses, Member States may adpt specific prvisins t entitle prviders f electrnic cmmunicatins services t prvide access t calling line identificatin and lcatin data withut the prir cnsent f the users r subscribers cncerned. The activatin f GNSS and WiFi sensrs allws t cmpute a lcatin using all the psitining methds available at the handset level with regards t the envirnment f the caller. T avid any ptential additinal charge fr the caller, the data cnnectivity is nt turned ON during the emergency call if turned OFF prir t the call. If the data cnnectivity is nt available during the emergency call, the handset will nt have any access t GNSS assistance data r WiFi access pint database. In this case, the GNSS lcatin prcess might be t lng with regards t HELP112 respnse time requirement, r the lcatin cmputed using WiFi psitining methd might be errneus (e.g: the first lcatin returned by the phne is the last WiFi lcatin estimate, but the caller is nt clse t the related WiFi access pint anymre). This is a direct cnsequence f the lack f GNSS assistance data. If n assistance data are available, the receiver will have t decde all the navigatin message frm the GNSS signal in rder t knw the psitin f the satellites in view. This prcess culd last several minutes and therefre nt be cmpliant with HELP112 respnse time requirement which says that the respnse time f the lcatin slutin shall be less than 30 secnds Lcatin accuracy tests Fr the purpse f HELP112 pilts, all tests assigned t a pilt site shuld be carried ut sequentially (i.e. withut switching typical user type between tests). That is t say A tests, B tests, and C tests are cmpleted sequentially fr a single phne. Fr each phne t be tested, a pilt will have t cnduct ne test fr each assigned user scenari (use case) Transmissin methds tests Transmissin methd such as SMS, HTTPS, r SMS when raming wuld nt be tested in the whle range f User Scenaris assigned t a pilt but prbably nly nce r twice in a suitable lcatin. 15/71

16 2.2.4 The Test Prcess Fr each user scenari: 1. Print ut the Test Frm frm Sectin f this dcument. 2. Find a place as described in the test descriptin, but chse a lcatin that is near a landmark yu can identify later n Ggle maps r anther n-line mapping surce, fr instance a rad junctin. 3. Write dwn the date and yur text descriptin f yur lcatin nt the test frm. This shuld be enugh t help yu find it later n a map, plus nte anything that might affect GNSS signals such as heavy rain r thick clud cver. 4. Cnduct each test fr the lcatin setting the GNSS and WiFi capabilities as specified in the test frm and fr the tested user scenari, and nting dwn the time yu initiated the call. 5. Make the emergency call fllwing the steps utlined in Sectin Once yu are back in ffice and have a PC, fill in the prvided Micrsft Excel spreadsheet (see sectin Test results ) with the date yu wrte dwn n the test frms. Enter ne rw per test. T get the lngitude and latitude f yur test lcatin see the sectin ( Determining yur Lngitude and Latitude ). Once yu have tested all f yur User Scenaris, please back the Excel spreadsheet t the PSAP Test cntact pint Determining the Lngitude and Latitude values fr yur Test Psitin In rder t test the accuracy f the crdinates in the HELP112 message, it is necessary t determine the actual psitin f where the test call is made. This can be dne by using this web tl: It can be useful t use reference landmarks fr pinpinting yur exact lcatin (using satellite view n internet mapping tl). Once yur psitin is lcated, cpy the Lat / Lng (decimal WGS84) values int the test rws in yur spreadsheet fr this lcatin. Example belw: 16/71

17 2.2.6 Summarising Test Results The pilt will nrmally prvide a summary f the test results highlighting the fllwing key measures: Average time fr HELP112 lcatin data t reach PSAP s HELP112 Lcatin Server (a lcatin server retrieves and decde the lcatin message sent by the handset and then stres the lcatin infrmatin and makes it available t the PSAPs see D3.2 fr further details). This will be measured at PSAP level (difference between the time f the lcatin estimate arrival at the PSAP call-taker level, and the time f the beginning f the call). Accuracy and precisin (radius) f HELP112 lcatin % f HELP112 lcatins estimated based n GNSS, WiFi and Cell % HELP112 failures Cmparisn with existing netwrk-based accuracy and precisin btained frm query t mbile netwrk s GMLC if available. Check the cmpliance f the lcatin infrmatin received at PSAP level with the HELP112 lcatin Minimum Set f Data (MSD) defined in D3.1. A cmpliance matrix f the slutin tested will be prvided fr each type f User Requirements (Please refer t list f User Requirements defined in D3.1). All infrmatin that might justify the cmpliance r the nn-cmpliance f the slutin with a user requirement will be written in the pilt reprt. The cmpliance matrix templates are presented in Appendices A t E f this dcument Emergency call prcedure This is an example fr the UK Stage 1 PSAP each cuntry will want t adjust t its wn PSAP call handling prcesses fr test calls. Fr each test, please fllw the script belw and cpy the respnses t the test sheets. Obtaining the crdinates (Nrthings & Eastings) is ptinal as Stage 1 PSAP will be able t retrieve these thrugh their recrds. NOTE: Please can yu ensure that yu clearly mark dwn the date and time f the tests yu have made (this can nrmally be btained frm the mbile s phne lg). Fr each test please can yu nte belw the precise lcatin f where the call was made frm. Any questins n the script please cntact (insert cuntry specific PSAP cntact pint) using HELP112 emergency test calls as the subject Vice script 17/71

18 Persn Dialg Recrd Respnse Tester Operatr Tester This is HELP112 pilt with a test call May I have yur initial please (this may be requested later in the call) Please cnfirm the telephne number is (Read the telephne number, r MSISDN, f yur mbile phne). Operatr Will cnfirm Yes r N. 2 Tester What is shwn in the Service Type? (This will be the mbile netwrk name). Operatr Will read back the infrmatin presented. e.g. T-Mbile, Three. Tester What is the zne cde r Cell Id please? Operatr Operatr will read ut the zne cde (4 digits) r cell Id (10 digits) presented. e.g Tester Are Plice Cnnect-t Numbers present? Which Plice abbreviatin please? Operatr Will cnfirm Yes r N and give the abbreviatin. e.g. NYKS Tester Operatr Tester Please can yu type HELP112D in the ntes field. Yes. Thank yu, that cmpletes the test. 2 PSAP peratrs may nt give this infrmatin but can cnfirm it. 18/71

19 2.2.8 Test frm User scenari Id Instructins Write User scenari Id here Write User scenari descriptin here Date f Test Text descriptin f yur lcatin Test WiFi Time f Test Cmments A ON B ON C OFF 19/71

20 2.2.9 Test Results Cpy this template and recrd test results fr returning t PSAP HELP112-Test-Resul ts-template-hbl-gen 20/71

21 3. TEST OF INTERNATIONAL ROAMING-ENABLED SMS TRANSMISSION (ARCHITECTURE 2) 3.1 TEST-BED TECHNICALITIES The pre-requisites t test the internatinal raming-enabled (Intra EU as well as Outside-EU) SMS transmissin f lcatin data fr an E112 call are the fllwing: Implementatin f HELP112 architecture 2 described in HELP112 deliverable D3.2. Amng the tw slutins prpsed in dcument D3.2, the pilt site(s) implementing this architecture have all chsen t implement slutin 2-A (See D3.2 fr further details). The chart belw shws the cmpnents invlved in Architecture 2-A and the interfaces between them: Figure 1 - Architecture 2-A cmpnents descriptin This test has t be cnducted between tw pilts, acting as Hme and Visitr netwrk/psaps. One pilt (Pilt A Visited Netwrk) will implement Architecture 2-A receiving the lcatin data frm the netwrk t the PSAP. The ther pilt (Pilt B Hme Netwrk) will prvide a smartphne having the HELP112 handset s sftware in the way presented in Architecture 2-A, that is t say a HELP112 sftware that sends the lcatin data SMS t the lng number f the apprpriate HELP112 lcatin server based n the MCC (Mbile Cuntry Cde) f the cuntry the tester is calling frm (Pilt A cuntry Visited Netwrk) instead f /71

22 T d s, pilt B (Hme Netwrk) will have t prvide pilt A (Visited Netwrk) with the crrespnding smartphne embedding the HELP112 sftware f HELP112 Architecture 2-A, and a SIM card f pilt B cuntry (Hme Netwrk). 3.2 TEST DESCRIPTION Fr each phne t be tested, this test is basically the generic test described in Sectin 2 where the call is made in pilt A cuntry (Visited Netwrk) using a pilt B (Hme Netwrk) phne embedding a pilt B (Hme Netwrk) SIM card. The expected result is t receive the lcatin data at the pilt A (Visited Netwrk) HELP112 lcatin server and nt at pilt B (Hme Netwrk) lcatin server. In rder t test the crrect transmissin f the HELP112 lcatin SMS t the apprpriate PSAP, the test will be dne fr ne r tw User Scenaris. The selected User scenari(s) fr each pilt site will be defined later in this dcument. The internatinal raming test using SMS transmissin will be dne alng with the accuracy tests fr the related User Scenaris. 22/71

23 4. TEST OF DATA CHANNEL (HTTPS) TRANSMISSION (ARCHITECTURE 4) 4.1 TEST-BED TECHNICALITIES The pre-requisites t test the transmissin f HELP112 lcatin data using the data channel (HTTPS) are the fllwing: Implement HELP112 architecture 4 as described in HELP112 deliverable D3.2. Amng the tw slutins prpsed in dcument D3.2, the pilt site(s) which will implement this architecture all chse t implement slutin 2-A (Natinal apprach - See D3.2 fr further details). All pilts need t agree n an ICD (Interface Cntrl Dcument) fr the sending f HELP112 lcatin data using HTTPS (e.g.: XML ver HTTPS as described in D3.2) befre implementing this slutin. The ICD used fr the test is the ne prvided by Ggle fr its AEL (Andrid Emergency Lcatin) implementatin f AML (Please see Appendix F fr further details). OS prviders r Handset manufacturers have t prvide handsets that implement the slutin presented in D3.2. Particularly, the HELP112 handset s sftware shell send the lcatin data t the URL f the mst apprpriate HELP112 lcatin server based n the MCC and MNC. 4.2 TEST DESCRIPTION Fr this test, the tester will perfrm the generic test described in Sectin 2 with different phnes (Tw r three with SIM cards frm different netwrk prviders) implementing HELP112 Architecture 2 described in D3.2 in a cuntry where the pilt has als implemented this slutin. The expected result is t receive the lcatin data at the apprpriate PSAP using the data channel t cnvey the data. In ne r tw cuntries, this test culd als be dne with a phne embedding a SIM card frm a freign netwrk prvider in rder t test the handling f internatinal raming using this slutin. Fr each pilt cncerned, this test will be dne fr ne r tw User Scenaris fcusing n the data cnnectivity settings and availability. The chsen User scenari(s) fr each pilt site will be defined later in this dcument. The internatinal raming test using SMS transmissin will be dne alng with the accuracy tests fr the related User Scenaris. 23/71

24 5. TEST OF GALILEO ADDED VALUE (ARCHITECTURE 1) This sectin aims at defining the technicalities related t the implementatin f the test-bed fr architecture 1, and the related test t evaluate the benefits f using Galile GNSS system t cmpute the lcatin f the caller in the case f a call t emergency services. Due t the impssibility t implement an end-t-end slutin that uses Galile assistance data during the timeframe f HELP112 prject, and the necessity t master the full lcatin prcess, the tests f lcatin estimate using bth Galile signals and Galile assistance data will be perfrmed ffline and then cmpared t the lcatins calculated withut using Galile in the exact same cnditins (envirnment and time). T, perfrm these tests, we will make use f chipset manufacturers test device t cmpute lcatin estimates fr several User Scenaris (defined later in the dcument) using GNSS signal in space (including Galile). Since these tests are ging t be perfrmed by Telespazi France cmpletely ffline frm any emergency call, and therefre frm any emergency services infrastructure, they will be perfrmed in France in Tuluse surrundings, apart frm any HELP112 pilt site. This will allw t fully master the test prcess (lcatins, cnditins, equipment, ), handle any issue that culd happen during the test phase, and be able t pstpne any test if the required cnditins are nt met. In additin, items f the first Galile enabled smartphne (i.e. the BQ Aquaris X5 plus with firmware release upper than Qualcmm Galile enabled GNSS engine inside) will be sent in tw pilt sites in rder t be tested alng with the ther phnes in an E112 end-t-end slutin perfrming the generic test depicted in sectin 2. Fr these pilts, the lcatins prvided by the BQ Aquaris X5 plus will be cmpared t the lcatin prvided by the ther phnes and the lcatin prvided by the netwrk (Cell-Id if available at the PSAP level) in rder t assess the impact f Galile signal in the lcatin estimate accuracy/precisin and prcess time (TTFF). Nevertheless, using these cmmercial phnes brings sme limitatins t the tests f Galile added value in the lcatin estimate prcess, such as: The Andrid lcatin API nly prvides the lcatin estimate, its type (GNSS, WiFi, Cell-Id), and its precisin. The Andrid lcatin API f Andrid Marshmallw (Release f Andrid installed in the BQ Aquaris X5 plus) cannt prvide the infrmatin abut the GNSS cnstellatin(s) used t cmpute the lcatin estimate. Using this phne, it is nt pssible t master the use r nt f GNSS assistance data. Using this phne, it is nt pssible t select which GNSS cnstellatin(s) t be used in the lcatin estimate prcess (in rder t effectively see the added value f Galile in the lcatin estimate prcess). That is the reasn why ffline tests will remain interesting t g deeper in the evaluatin f Galile added value in the lcatin estimate prcess (Precisin/Accuracy, Time T First Fix, Sensitivity). In the fllwing subsectins, we will fcus n the descriptin f these ffline tests using chipset manufacturers test devices. 24/71

25 5.1 TEST-BED TECHNICALITIES The technical pre-requisites t test the added value f using Galile in the lcatin estimate f a persn in distress during an emergency call t 112 are the fllwing: Get test platfrms including GNSS chipsets frm tw different manufacturers with the fllwing features (4 platfrms 2 frm ne chipset manufacturer and 2 frm anther wuld be needed t cver all the aspects f this test): 1. A multi-cnstellatin GNSS chipset including Galile. The chice f the GNSS chipset shall be relevant with regards t the smartphne market. 2. This chipset shall be able t receive and use assistance data fr GPS and Galile (at least predictive rbits). 3. Allw t cnfigure which cnstellatin (GPS a/ GLONASS a/ Beidu a/ Galile) t be used in the lcatin estimate prcess. 4. Allw t cnfigure fr which cnstellatin(s) the assistance data are sent t the chipset. 5. Allw t reset all previus data that culd accelerate the lcatin estimate prcess. That is t say be able t cnfigure the platfrm in rder t cmpute a lcatin frm a cld start. 6. Lg the start time f the lcatin estimate prcess. 7. Fr each lcatin estimate: Lg the timestamp f the lcatin (in GPS time), Lg the lcatin estimate in WGS84 crdinates system (in decimal degrees,with at least five decimal digits t get a ~1m precisin), Lg the precisin f the lcatin estimate (radius f cnfidence in meters), Lg the cnfidence in the lcatin estimated (in percentage), Lg the lcatin methd used t calculate the lcatin estimate, Cell-Id, WiFi, GNSS, And any hybrid slutin. Lg which cnstellatin(s) and which satellite(s) were in visibility f the GNSS antenna at the lcatin estimate time, If GNSS has been used in the lcatin estimate prcess: Lg which cnstellatin(s) and satellite(s) are used t cmpute the lcatin, Lg the Dilutin Of Precisin value (DOP), at least the Hrizntal- DOP value (H-DOP), 25/71

26 And fr each cnstellatin used t cmpute the lcatin estimate, lg whether r nt assistance data are used and their type (Almanac, Dppler, ). 8. And lg the end time f the lcatin estimate prcess. 9. All lgs mentined abve shall be written in a readable frmat. 5.2 TEST DESCRIPTION The added value f Galile in the lcatin estimate prcess will be tested by perfrming the test depicted in Sectin fr several selected User Scenaris using the test platfrms described in sectin 6.1. The User Scenaris will be chsen based n the difficulties t get GNSS lcatin in the related envirnment. The idea being t prve that Galile (Assisted r nt) imprves the availability f GNSS lcatin estimate and its TTFF (Time T First Fix) in envirnment with high lcal cnstraints such as frest, urban canyn, indr nt far frm a windw, and s frth. The selected User Scenaris are depicted in sectin The test prcess In the test described hereafter, tw platfrms with the same E-GNSS chipset and the same functinalities are used in parallel. One f these tw platfrms will perfrm lcatin estimate using all the available cnstellatins including Galile and the ther platfrm will perfrm the same lcatin estimate, at the exact same time, but withut using Galile. Fr ne chipset manufacturer, if nly ne platfrm is available, the tests with and withut Galile fr a User Scenari will be perfrmed sequentially by fllwing the test prcess hereafter. Here is the test prcess t fllw and fill in fr each selected User Scenari: 26/71

27 User scenari Id Instructins Write User scenari Id here Write User scenari descriptin here Pre-requisites Get the required test platfrm frm chipset manufacturers. In the case f 4 platfrms (frm 2 manufacturers 2 platfrm per manufacturer), each platfrm will be nted as fllws: Manufacturer 1/Platfrm 1 : Id P11 Manufacturer 1/Platfrm 2 : Id P12 Manufacturer 2/Platfrm 1 : Id P21 Manufacturer 2/Platfrm 2 : Id P22 Perfrm the test in a timeslt where at least 3 Galile satellites are abve the hrizn at the lcatin the test is perfrmed. In rder t test the accuracy f the crdinates in the HELP112 message, it is necessary t determine the actual psitin f where the test call is made. This can be dne by using the fllwing mapping tl that allws yu t wrk ut yur lcatin in apprpriate crdinates (WGS84): It can be useful t use reference landmarks fr pinpinting yur exact lcatin (using satellite view n internet mapping tl). Once yur psitin is lcated, cpy the Lat / Lng (decimal WGS84) values int the test rws in yur results spreadsheet fr this lcatin. Date f Test Text descriptin f yur lcatin Actin Id Descriptin Cmments Cld start withut assistance data 1 Cnfigure P11 t: Perfrm lcatin estimate using all the cnstellatins available including Galile. D nt use assistance data fr any cnstellatin during the lcatin estimate prcess. Erase all previus assistance data (such as predictive rbits) that culd imprve the lcatin prcess (Cld start). 27/71

28 2 In the results spreadsheet, nte that P11 is cnfigured in cld start mde, withut assistance data, and with all GNSS cnstellatins including Galile (enumerate each cnstellatin cnfigured). 3 Optinal (if P12 is available) 4 Optinal (if P12 is available) Cnfigure P12 t: Perfrm lcatin estimate using all the cnstellatins available except Galile. D nt use assistance data fr any cnstellatin during the lcatin estimate prcess. Erase all previus assistance data (such as predictive rbits) that culd imprve the lcatin prcess (Cld start). In the results spreadsheet, nte that P12 is cnfigured in cld start mde, withut assistance data, and with all GNSS cnstellatins except Galile (enumerate each cnstellatin cnfigured). 5 Nte the exact date f the test in the results spreadsheet. 6 Simultaneusly start the lcatin prcess n P11 and P12 (if available) and verify the prcess is nging n each platfrm. 7 After 2 minutes, stp simultaneusly the lcatin prcess n P11 and P12 (if available). 8 Optinal (if P12 is unavailable) 9 Optinal (if P21 and P22 are available) Repeat actins 3, 4, 5, 6, and 7 with P11. Repeat actin 1 t 8 by replacing P11 by P21 and P12 by P Fr each platfrm, repeat the lcatin prcess 5 times Warm start withut assistance data 11 Cnfigure P11 t: Perfrm lcatin estimate using all the cnstellatins available including Galile. 28/71

29 D nt use assistance data fr any cnstellatin during the lcatin estimate prcess. D nt erase all previus assistance data (such as predictive rbits) that culd imprve the lcatin prcess (Warm start). 12 In the results spreadsheet, nte that P11 is cnfigured in warm start mde, withut assistance data, and with all GNSS cnstellatins including Galile (enumerate each cnstellatin cnfigured). 13 Optinal (if P12 is available) 14 Optinal (if P12 is available) Cnfigure P12 t: Perfrm lcatin estimate using all the cnstellatins available except Galile. D nt use assistance data fr any cnstellatin during the lcatin estimate prcess. D nt erase all previus assistance data (such as predictive rbits) that culd imprve the lcatin prcess (Warm start). In the results spreadsheet, nte that P12 is cnfigured in warm start mde, withut assistance data, and with all GNSS cnstellatins except Galile (enumerate each cnstellatin cnfigured). 15 Nte the exact date f the test in the results spreadsheet. 16 Simultaneusly start the lcatin prcess n P11 and P12 (if available) and verify the prcess is nging n each platfrm. 17 After 2 minutes, stp simultaneusly the lcatin prcess n P11 and P12 (if available). 18 Optinal (if P12 is unavailable) 19 Optinal (if P21 and P22 are available) Repeat actins 13, 14, 15, 16, and 17 with P11. Repeat actin 11 t 18 by replacing P11 by P21 and P12 by P Fr each platfrm, repeat the lcatin prcess 5 times 29/71

30 Cld start with assistance data 21 Cnfigure P11 t: Perfrm lcatin estimate using all the cnstellatins available including Galile. Use assistance data fr any cnstellatin during the lcatin estimate prcess. Erase all previus assistance data (such as predictive rbits) that culd imprve the lcatin prcess (Cld start). 22 In the results spreadsheet, nte that P11 is cnfigured in cld start mde, with assistance data, and with all GNSS cnstellatins including Galile (enumerate each cnstellatin cnfigured). 23 Optinal (if P12 is available) 24 Optinal (if P12 is available) Cnfigure P12 t: Perfrm lcatin estimate using all the cnstellatins available except Galile. Use assistance data fr any cnstellatin during the lcatin estimate prcess. Erase all previus assistance data (such as predictive rbits) that culd imprve the lcatin prcess (Cld start). In the results spreadsheet, nte that P12 is cnfigured in cld start mde, with assistance data, and with all GNSS cnstellatins except Galile (enumerate each cnstellatin cnfigured). 25 Nte the exact date f the test in the results spreadsheet. 26 Simultaneusly start the lcatin prcess n P11 and P12 (if available) and verify the prcess is nging n each platfrm. 27 After 2 minutes, stp simultaneusly the lcatin prcess n P11 and P12 (if available). 28 Optinal (if P12 is unavailable) Repeat actins 23, 24, 25, 26, and 27 with P11. 30/71

31 29 Optinal (if P21 and P22 are available) Repeat actin 21 t 28 by replacing P11 by P21 and P12 by P Fr each platfrm, repeat the lcatin prcess 5 times Warm start with assistance data 31 Cnfigure P11 t: Perfrm lcatin estimate using all the cnstellatins available including Galile. Use assistance data fr any cnstellatin during the lcatin estimate prcess. D nt erase all previus assistance data (such as predictive rbits) that culd imprve the lcatin prcess (Warm start). 32 In the results spreadsheet, nte that P11 is cnfigured in warm start mde, with assistance data, and with all GNSS cnstellatins including Galile (enumerate each cnstellatin cnfigured). 33 Optinal (if P12 is available) 34 Optinal (if P12 is available) Cnfigure P12 t: Perfrm lcatin estimate using all the cnstellatins available except Galile. Use assistance data fr any cnstellatin during the lcatin estimate prcess. D nt erase all previus assistance data (such as predictive rbits) that culd imprve the lcatin prcess (Warm start). In the results spreadsheet, nte that P12 is cnfigured in warm start mde, with assistance data, and with all GNSS cnstellatins except Galile (enumerate each cnstellatin cnfigured). 35 Nte the exact date f the test in the results spreadsheet. 36 Simultaneusly start the lcatin prcess n P11 and P12 (if available) and verify the prcess is nging n each platfrm. 31/71

32 37 After 2 minutes, stp simultaneusly the lcatin prcess n P11 and P12 (if available). 38 Optinal (if P12 is unavailable) 39 Optinal (if P21 and P22 are available) Repeat actins 33, 34, 35, 36, and 37 with P11. Repeat actin 31 t 38 by replacing P11 by P21 and P12 by P Fr each platfrm, repeat the lcatin prcess 5 times 41 Extract all the data lgged by each platfrm and prcess them t get the required results defined in the next sectin and fill the results test frm in Test Results Hereafter is the Galile test results frm t fill in during the tests. HELP112-Test-Resul ts-template-galile.x In additin t the infrmatin gathered in the Test results frm, we will prvide a reprt cmparing fr each selected User Scenari the lcatin estimated using each test platfrm and each cnfiguratin, including: The TTFF and the psitining methd used at this mment. This TTFF will be cmpared t HELP112 RESP_002 requirement (The respnse time shall be less than 30 secnds fr any lcatin slutin that prvides mre accurate and precise caller lcatin and satisfies the accuracy/precisin requirements (E-GNSS, A-GNSS, WiFi, Enhanced Cell-ID, )). The lcatin estimate rate with a TTFF < 30 secnds (cmpliance with RESP_002) with fr each f these lcatin: If available, the cnstellatin(s) used t cmpute the lcatin (GPS and/r Galile and/r Glnass and/r Beidu). If available, the cnstellatin(s) fr which assistance data have been used. If available, the number f satellites used t cmpute the lcatin and the amunt f them related t each cnstellatin (nb_sat_gps, nb_sat_galile, ). 32/71

33 The lcatin estimate rate with a TTFF > 30 secnds (nn-cmpliance with RESP_002) with fr each f these lcatin: If available, the cnstellatin(s) used t cmpute the lcatin (GPS and/r Galile and/r Glnass and/r Beidu). If available, the cnstellatin(s) fr which assistance data have been used. If available, the number f satellites used t cmpute the lcatin and the amunt f them related t each cnstellatin (nb_sat_gps, nb_sat_galile, ). Fr the lcatin estimated 30 secnds after starting the lcatin estimate prcess (Lcatin estimate at the HELP112 handset sftware timeut): If available, the cnstellatin(s) used t cmpute the lcatin (GPS and/r Galile and/r Glnass and/r Beidu). If available, the cnstellatin(s) fr which assistance data have been used. If available, the number f satellites used t cmpute the lcatin and the amunt f them related t each cnstellatin (nb_sat_gps, nb_sat_galile, ). The TTFF mean value. The TTFF mean value fr the lcatin estimated in less than 30 secnds (HELP112 timeut). Rate f lcatin estimate (at the TTFF) with a Precisin/Accuracy cmpliant with HELP112 requirements. A lcatin is taken int accunt if and nly if it cmplies with HELP112 respnse time requirement (RESP_002). Precisin and Accuracy s mean value f the lcatin estimated at the TTFF (if TTFF < 30 secnds) r 30 secnds after starting the lcatin prcess. Precisin and Accuracy s standard deviatin value f the lcatin estimated at the TTFF (if TTFF < 30 secnds) r 30 secnds after starting the lcatin prcess. And fr the verall tests (All selected User Scenaris included), a glbal analyse based n the previus results btained fr each test platfrm accrding t each User Scenari and each cnfiguratin Selected User Scenaris Amng all the User Scenaris defined fr HELP112 prject in deliverable D1.1 and D3.1, the selected nes fr testing the benefits brught by Galile in the lcatin estimate prcess are the fllwing: 33/71

34 Id SCEN_002 SCEN_003 SCEN_004 SCEN_005 SCEN_006 SCEN_007 User scenari descriptin Rural building with all lcatin methds available. An utside lcatin ut f twn and ver 3 meters away frm buildings that culd blck GNSS, but where WiFi signals are present. Fr example, in a village within WiFi range f huse with a WiFi ruter. Rural car with GNSS/A-GNSS available but n WiFi available. A lcatin in the pen cuntryside and inside a parked car far away frm buildings r cnstructins that culd blck GNSS. Urban with GNSS/A-GNSS available but disrupted and WiFi available. An utside lcatin in a twn r city street where WiFi signals are present and GNSS signals are disrupted by buildings. Mtrway r Dual carriageway with GNSS/A-GNSS available but n WiFi available. While driving different sides f a carriageway where GNSS signals are available. Huse lcatin with all lcatin methds available. A lcatin inside a huse that has WiFi and in a lcatin that ffers a partial satellite cverage. Office lcatin with WiFi available but n GNSS available. A lcatin inside an ffice, which itself is deep inside a building where GNSS signals cannt reach, but WiFi is present. SCEN_008 Urban with mbile data disabled. An utside lcatin in a twn r city street where the caller has deliberately disabled his handset data cnnectin. In additin t the existing User Scenaris, 112ERC (Lithuanian pilt) and NNO (Austrian pilt) shws a great interest in testing HELP112 slutin in challenging envirnment and particularly the added value f Galile in the lcatin estimate prcess when the caller is under a dense frest cverage r nt a muntain. This new User Scenaris are the fllwing: Id SCEN_014 SCEN_015 User scenari descriptin Rural cuntryside in a dense frest with GNSS/A-GNSS available but n WiFi available. An utside lcatin far away frm buildings r cnstructins, but under a dense frest cverage that might blck GNSS signals. Rural cuntryside nt a muntain with GNSS/A-GNSS available but n WiFi available and bad netwrk cverage. An utside lcatin nt a muntain far away frm buildings r cnstructins that might blck GNSS signals, in a lcatin with bad netwrk cverage. 34/71

35 6. TEST OF USER PLANE NETWORK-BASED LOCATION METHOD ADDED VALUE (ARCHITECTURE 3) As mentined in HELP112 deliverable D3.2, it will nt be pssible t test an end-t-end test-bed f Architecture 3, since n handset s sftware sending the Radi Measurement Reprt (RMR) alng with the lcatin data t the PSAP will be develped in the timeframe f HELP112 prject. Nevertheless, it is still pssible t test ffline the added value f a user plane netwrk based lcatin methd as described in Architecture 3. The results f these tests will then be used in rder t encurage OS prviders/handset manufacturers t develp the needed handset s sftware t send the RMR t the Lcatin Calculatr (at PSAP level). We will therefre describe hereafter the technicalities required fr the ffline tests f the Lcatin Calculatr based n the RMR, and then define the related tests t perfrm in rder t see if this lcatin slutin meets the related accuracy and reliability HELP112 user requirements. 6.1 TEST-BED TECHNICALITIES Fr the purpse f HELP112 prject, the tests f this type f lcatin slutin will be cnducted by Creativity Sftware using their LcatinWise (CS ) mbile lcatin platfrm. This platfrm meets all the technical aspects described in HELP112 deliverable D3.2 cncerning the Lcatin Calculatr f Architecture 3. Besides, CS can prvide a test platfrm that culd be used independently f any MNO infrastructure. Fr the lcatins estimated using the LcatinWise platfrm, the required Radi Measurement Reprts will be extracted frm the Andrid phne and sent t Creativity Sftware in UK in rder t cmpute the related lcatins. The test descriptin hereafter is an adaptatin f CS dcument Prpsed Prject Plan fr a CS Lcatin Platfrm Pilt 3, and will be the basis fr the tests f a Lcatin Calculatr using the RMR t cmpute the lcatin f an emergency caller as described in HELP112 Architecture 3 (see deliverable D3.2). 6.2 TEST DESCRIPTION Prerequisites 1. Tw Andrid phnes f different vendrs and types. The preferred chice is HTC Wildfire S (Andrid phne with GPS). Using TEMS (ASCOM s) r Nem (Anite s) mbile phne culd als be used. 2. Tw lcal SIM cards preferably with data enabled. 3. Cell twer data file fr the requested areas. 3 Creativity Sftware, Prpsed Prject Plan fr a CS Lcatin Platfrm Pilt, Versin 1.0, /71

36 6.2.2 Test envirnment and setup The test envirnment will be cmpsed f the test phnes fr data cllectin in use cases selected fr the related pilt site while CS LcatinWise algrithms and databases will be based at CS ffices in Lndn. The lgical prcess is described belw: Figure 2 - Lcatin Calculatr test - Lgical prcess Prf f Cncept prcess Definitin f test areas Fr the selected User Scenaris in a pilt site, CS will perfrm lcal data cllectin in a subset f the candidate areas fr these User Scenaris, then cnduct a number f tests and finally issue a reprt fr these tests Preparatin phase CS makes available test phnes in pilt cuntries, while LcatinWise server and databases will remain in UK. 36/71

37 Initial drive test will be cnducted. It is wrth mentining that the supprt f MNOs in this phase wuld be f utmst value by prviding: Cell twer database fr the 2G netwrk as described in HELP112 deliverable D3.2 n the basis f CS dcument Radi Netwrk Data File 4. Recent 2G drive test fr the city (if available), cnducted within the target Test areas Handset s settings Data settings mbile data is t be enabled at all times. Time settings autmatic (i.e. aligned with netwrk time, nt set by user). Netwrk Settings 2G mde (t crrespnd t the furnished cell twer database). Verify that the handset s battery charge is gd enugh t perfrm the test Wifi mde Wifi can be enabled/disabled accrding t the individual tests described later Typical User settings fr lcatin functinality 4 Creativity Sftware, Radi Netwrk Data File, Versin 1.3, 23th September /71

38 Fr the Andrid phne with GNSS capabilities, the typical user settings shall be set n High Accuracy (the use everything fr best service user that can use assisted GNSS (A-GNSS), WiFi r Cell ID based lcatins. The secnd phne will have its GNSS capabilities turned OFF Determining the Lngitude and Latitude values fr yur Test Psitin In rder t test the accuracy f the crdinates in the HELP112 message, it is necessary t determine the actual psitin f where the test call is made. This can be dne by using an agreed internet mapping tl that allws yu t wrk ut yur lcatin in apprpriate crdinates. It can be useful t use reference landmarks fr pinpinting yur exact lcatin (using satellite view n internet mapping tl). Once yur psitin is lcated, cpy the Lat / Lng (decimal WGS84) values int the test rws in yur test results spreadsheet fr this lcatin. Example belw: The test prcess The gal is t test the lcatin prcess which uses the cllected Radi Measurement Reprt t make the handset lcatin estimate. The test prcess fr a defined User Scenari is the fllwing: 1. Print ut the Test Frm frm Sectin f this dcument. 2. Find a place as described in the User Scenari, but chse a lcatin that is near a landmark yu can identify later n Ggle maps r ther n-line mapping surce, fr instance a rad junctin. 3. Write dwn the date and yur text descriptin f yur lcatin nt the test frm (Sectin ). This shuld be enugh t help yu find it later n a map, plus nte anything that might affect GNSS r cellular netwrk signals such as heavy rain r thick clud cver fr GNSS. 4. Get the lcatin with the Andrid phne r any ther agreed test phnes with the GNSS turned OFF. 5. Get the lcatin at the same time with a different phne with GNSS turned ON. 38/71