GALILEI REF : DATE : Gali-TPZ-DD081 18/10/2002 System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 1 Logica Sustainable Mobility and Intermodality Promoting Competitive and Sustainable Growth GALILEI System Interoperability Analysis Non-Nav Written by Responsibility - Company Date Signature P. Balletta R. Capua Telespazio Telespazio 18/7/2002 C. Marionneau E. Kirby A. Renard Thales Av Fr THAV THAV S. Mullen Logica Verified by Certified by WBS Code : E.3.B Classification : RE
Transcript
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 1
Logica
Sustainable Mobility and IntermodalityPromoting Competitive and Sustainable Growth
GALILEI
System Interoperability Analysis Non-Nav
Written by Responsibility - Company Date Signature
P. Balletta
R. Capua
Telespazio
Telespazio
18/7/2002
C. Marionneau
E. Kirby
A. Renard
Thales Av Fr
THAV
THAV
S. Mullen Logica
Verified by
Certified by
WBS Code : E.3.BClassification : RE
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 2
Logica
THE INFORMATION IN THIS DOCUMENT IS PROVIDED AS ISAND NO GUARANTEE OR WARRANTY IS GIVEN THAT THE
INFORMATION IS FIT FOR ANY PURPOSE. THE USER THEREOFUSES THE INFORMATION AT ITS SOLE RISK AND LIABILITY.
FURTHERMORE, DATA, CONCLUSIONS ORRECOMMENDATIONS IN THIS REPORT ARE PROVIDED ON THE
BASIS THAT SUCH INFORMATION IS SUBSEQUENTLY, ANDPRIOR TO USE, VERIFIED BY THE PARTY WISHING TO USE
THAT INFORMATION.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 3
Logica
CHANGE RECORDS
ISSUE DATE § : CHANGE RECORD AUTHOR
0.A First issue. PierluigiBalletta/RobertoCapua
1.C 9/May/02 par 6.2.1.1 (only title mod)
par 6.2.1.2 (new par.: in line with the work Logica has toperform)
par 7.2.1.1 (only title mod)
par 7.2.1.2 (new par.: in line with the work Logica has toperform)
PierluigiBalletta/RobertoCapua
1.D 10/May/02 New Chapter 6 for Interop. Level 2 included to ensure thesame Chapter Numbering in DD-080 and DD-081 forreference; chapters 6 to 14 now shifted towards 7 to 15.
Change Record and final Page included, connected todocument template deliverables_galilei_v21.dot, insteadof normal.dot
Oswald Glaser
2.B For industrial review before DMR-2w delivery
2.C 18/7/2002 For industrial review PierluigiBalletta/RobertoCapua
2.1 20/09/2002 Review after GISS Comments PierluigiBalletta/RobertoCapua
2.2 18/10/2002 Final Release, Update of Thales Avionics contribution PierluigiBalletta/RobertoCapua
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 4
2.1 SCOPE OF THE WORK........................................................................................................... 342.2 JUSTIFICATION OF THE WORK......................................................................................... 34
4 MIA RESULTS SUMMARY ....................................................................................................... 46
4.1 CONSEQUENCES OF THE MIA ANALYSIS....................................................................... 464.2 LIST OF MIA REQUIREMENTS ........................................................................................... 494.3 RECOMMENDATIONS FROM MIA..................................................................................... 54
5.1 DESCRIPTION OF THE FUNCTIONS AT THIS LEVEL ..................................................... 555.1.1 Applicable definitions of Interoperability at IOL1 ..............................................................555.1.2 IOL1 interfaces and main functionality ................................................................................565.1.2.1 SIS interface with IOL1 .......................................................................................................565.1.2.2 IOL1 interface with IOL2....................................................................................................565.1.2.3 Main functionality of IOL1..................................................................................................565.1.2.4 Others possible functionality of IOL1 ................................................................................575.1.3 Detailed analysis system interfaces ........................................................................................575.1.3.1 Propagations Equations .......................................................................................................575.1.3.2 CW interference ...................................................................................................................585.1.3.3 NB interference.....................................................................................................................585.1.3.4 WB interference....................................................................................................................595.1.3.5 Pulsed interference ...............................................................................................................595.1.3.6 Special aspect of interference ..............................................................................................595.1.4 Criteria to ensure IOL2 requirements ..................................................................................605.1.4.1 Generalities ...........................................................................................................................605.1.4.2 Criteria to ensure compatibility without disturbance.......................................................605.1.4.3 Criteria to ensure operational mode with degraded performances.................................615.2 METHODOLOGY TO STUDY ELECTROMAGNETIC COMPATIBILITY................... 62
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 5
Logica
5.2.1 Compatibility problems ..........................................................................................................625.2.2 Disturbing signals ....................................................................................................................635.2.2.1 Generalities ...........................................................................................................................635.2.2.2 Spurious emission of non-navigation emitter on GALILEO receiver OR In-band compatibility ...............................................................................................................................635.2.2.3 Emission of useful signal of the non-navigation emitter on GALILEO receiverOr out-of-band compatibility..............................................................................................................635.2.3 Criteria .....................................................................................................................................655.3 METHODOLOGY TO STUDY INTEROPERABILITY ...................................................... 655.4 ELECTROMAGNETIC COMPATIBILITY STUDY ........................................................... 675.4.1 GSM/GPRS ..............................................................................................................................675.4.1.1 Description of the systems....................................................................................................675.4.1.2 Main characteristics .............................................................................................................685.4.1.3 GALILEO in-band compatibility with GSM out-of-band emission ................................685.4.1.3.1 Dimensioning values..........................................................................................................685.4.1.3.2 Separated navigation equipment and non-navigation equipment ................................685.4.1.3.3 Navigation and non-navigation services on the same equipment..................................705.4.2 GALILEO out-of-band compatibility with GSM useful emission ......................................715.4.2.1 Separated navigation equipment and non-navigation equipment ...................................715.4.2.2 Navigation and non-navigation services on the same equipment.....................................745.5 UMTS .......................................................................................................................................... 755.5.1 Description of the systems.......................................................................................................755.5.2 Main characteristics ................................................................................................................755.5.3 GALILEO in-band compatibility with UMTS out-of-band emission.................................765.5.3.1 Dimensioning values.............................................................................................................765.5.3.2 Separated navigation equipment and non-navigation equipment ...................................765.5.3.2.1 UMTS mobile stations.......................................................................................................765.5.3.2.2 UMTS base stations...........................................................................................................795.5.3.3 Navigation and non-navigation services on the same equipment.....................................825.5.4 GALILEO out-of-band compatibility with UMTS useful emission....................................835.5.4.1 Separated navigation equipment and non-navigation equipment ...................................835.5.4.2 Navigation and non-navigation services on the same equipment.....................................865.6 BLUETOOTH ............................................................................................................................ 865.6.1 Description of the system ........................................................................................................865.6.2 Main characteristics ................................................................................................................865.6.3 GALILEO in-band compatibility with bluetooth out-of-band emission ............................875.6.3.1 Dimensioning values.............................................................................................................875.6.3.2 Separated navigation equipment and non-navigation equipment ...................................875.6.3.3 Navigation and non-navigation services on the same equipment.....................................885.6.4 GALILEO out-of-band compatibility with bluetooth useful emission ...............................89
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 6
Logica
5.6.4.1 Separated navigation equipment and non-navigation equipment ...................................895.6.4.2 Navigation and non-navigation services on the same equipment.....................................895.7 WLAN.......................................................................................................................................... 905.7.1 Description of the system ........................................................................................................905.7.2 Main characteristics ................................................................................................................905.8 DECT........................................................................................................................................... 905.8.1 Description of the system ........................................................................................................905.8.2 Main characteristics ................................................................................................................905.8.3 GALILEO in-band compatibility with DECT out-of-band emission .................................915.8.3.1 Dimensioning values.............................................................................................................915.8.3.2 Separated navigation equipment and non-navigation equipment ...................................915.8.3.3 Navigation and non-navigation services on the same equipment.....................................925.8.4 GALILEO out-of-band compatibility with DECT useful emission ....................................935.8.4.1 Separated navigation equipment and non-navigation equipment ...................................935.8.4.2 Navigation and non-navigation services on the same equipment.....................................945.9 TETRA ........................................................................................................................................ 945.9.1 Description of the system ........................................................................................................945.9.2 Main characteristics ................................................................................................................945.9.3 GALILEO in-band compatibility with TETRA out-of-band emission ..............................955.9.3.1 Dimensioning values.............................................................................................................955.9.3.2 Separated navigation equipment and non-navigation equipment ...................................955.9.3.3 Navigation and non-navigation services on the same equipment.....................................965.9.4 GALILEO out-of-band compatibility with TETRA useful emission..................................975.9.4.1 Separated navigation equipment and non-navigation equipment ...................................975.9.4.2 Navigation and non-navigation service on the same equipment ......................................995.10 CO-OPERATION WITH A NON-NAVIGATION SYSTEM STUDY................................ 995.11 MODULES IN THE IOL1 PART THAT CAN BE ADDED TO INCREASEINTEROPERABILITY..................................................................................................................... 1005.11.1 Module against in-band interference ..................................................................................1005.11.1.1 Antenna isolation................................................................................................................1005.11.1.2 Antenna processing ............................................................................................................1005.11.1.2.1 Generalities.......................................................................................................................1005.11.1.2.2 Beam forming antenna ....................................................................................................1005.11.1.2.3 Null steering antenna.......................................................................................................1015.11.1.3 Polarisation discrimination ...............................................................................................1015.11.1.4 Clipping Blanking ..............................................................................................................1015.11.1.5 Adaptive filtering................................................................................................................1015.11.1.6 Co-operation .......................................................................................................................1025.11.2 Module against out-of-band interference ...........................................................................1025.11.2.1 Antenna isolation................................................................................................................102
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 7
Logica
5.11.2.2 Antenna processing ............................................................................................................1025.11.2.3 Filtering...............................................................................................................................1025.11.2.4 Co-operation .......................................................................................................................1025.12 FROM THEORY TO PRACTICE........................................................................................ 1035.12.1 Emission over-dimensionned hypotheses............................................................................1035.12.2 Receiver Over-dimensioned hypotheses..............................................................................1035.13 CONCLUSIONS...................................................................................................................... 1045.13.1 Main results on electromagnetic compatibility study........................................................1045.13.1.1 Separated navigation equipment and non-navigation equipment .................................1045.13.1.2 Navigation and non-navigation services on the same equipment...................................1055.14 SUMMARY OF LEGAL ISSUES............................................................................................ 1065.15 MRD & SRD RECOMMENDATIONS AT INTEROPERABILITY LEVEL 1..................... 1065.16 IMPACTS ON GALILEO OS AND CS................................................................................ 1075.17 ISSUES FOR OTHER GALILEI TASKS AND OTHER STUDIES ..................................... 1085.18 GENERAL RECOMMENDATIONS FOR GALILEO DESIGN ANDDEVELOPEMNT PHASE................................................................................................................ 108
6 NAVIGATION SYSTEM-INTEROPERABILITY LEVEL 3A: HYBRIDISATIONOF GNSS AND NON NAV PSEUDORANGES ............................................................................. 109
6.1 DESCRIPTION OF THE FUNCTIONS AT THIS LEVEL ................................................... 1096.2 SYSTEM INTERFACES .......................................................................................................... 1106.2.1 Detailed analysis: GSM/UMTS system interfaces ..............................................................1106.2.1.1 GALILEO-GSM Hybridisation at level 3A .....................................................................1106.2.1.2 EKF Data Fusion approach for full coupling solutions ..................................................1166.2.1.2.1 OTD and RTD measurements noise characterisation..................................................1216.2.1.3 Improvements of EKF........................................................................................................1226.2.1.4 Hybridisation Performance Improvements (level 3A) ....................................................1236.2.1.5 GALILEO-UMTS Hybridisation at level 3A...................................................................1246.2.2 “Limited analysis” system interfaces...................................................................................1246.2.3 transition among systems (Dual Mode/Stand-Alone mode)..................................................1266.3 SUMMARY OF CERTIFICATION AND STANDARDISATION ISSUES........................... 1286.4 MRD & SRD RECOMMENDATIONS AT INTEROPERABILITY LEVEL 3A ................... 1296.4.1 GSM and UMTS Systems .....................................................................................................1296.5 ISSUES FOR OTHER GALILEI TASKS AND OTHER STUDIES ...................................... 1306.5.1 Recommendations for B2 ICDs............................................................................................1316.5.1.1 Impacts on Galileo to UMTS ICD ID/GAL/0085/GLI ....................................................131
7.1 DESCRIPTION OF THE FUNCTIONS AT THIS LEVEL ................................................... 1327.2 SYSTEM INTERFACES .......................................................................................................... 132
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 8
Logica
7.2.1 GSM/UMTS System Interfaces ............................................................................................1337.2.1.1 E-OTD Hybridisation at IO Level 3B: positioning system level ....................................1337.2.1.1.1 Bayesian Estimation ........................................................................................................1337.2.1.1.2 Multiple Kalman Filtering..............................................................................................1387.2.1.2 OTDOA Hybridisation at IO Level 3B.............................................................................1407.2.2 Adaptation Protocols.............................................................................................................1407.2.2.1 NMEA-0183 updatings.......................................................................................................1407.2.2.1.1 GGA message...................................................................................................................1407.2.2.1.2 GLL message....................................................................................................................1417.2.2.1.3 GSA message....................................................................................................................1427.2.2.1.4 Quality Report messages.................................................................................................1427.2.2.1.5 GST: proposed new message ..........................................................................................1437.2.2.1.6 GSG message....................................................................................................................1437.2.2.2 NMEA 2000.........................................................................................................................1447.2.3 “Limited analysis” System Interfaces..................................................................................1457.2.3.1 Bluetooth .............................................................................................................................1457.2.3.2 WLAN..................................................................................................................................1467.2.3.3 UWB ....................................................................................................................................1477.2.3.4 TETRA ................................................................................................................................1477.2.3.5 DECT...................................................................................................................................1487.2.4 Transition Time Analysis......................................................................................................1487.3 SUMMARY OF LEGAL AND CERTIFICATION ISSUES ................................................... 1497.4 MRD & SRD RECOMMENDATIONS AT INTEROPERABILITY LEVEL 3B ................... 1517.5 ISSUES FOR OTHER GALILEI TASKS AND OTHER STUDIES ...................................... 1527.6 IMPACTS ON GALILEO OS AND CS................................................................................. 152
8.1 DESCRIPTION OF THE FUNCTIONS AT THIS LEVEL ................................................... 1548.2 SYSTEM INTERFACES .......................................................................................................... 1558.2.1 GSM communication system interface ................................................................................1558.2.1.1 Interfacing entities..............................................................................................................1568.2.1.2 Interoperability analysis for the system architecture interfaces....................................1578.2.1.3 System Interfaces requirements ........................................................................................1618.2.2 UMTS communication system interface .............................................................................1618.2.2.1 Interfacing entities..............................................................................................................1628.2.2.2 IMS services ........................................................................................................................1658.2.2.3 Interoperability analysis for the system architecture interfaces....................................1678.2.2.4 The Session Initiation Protocol..........................................................................................1698.2.2.5 System Interfaces requirements ........................................................................................170
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 9
Logica
8.2.3 Hybridisation at the Application Level (Map matching solutions)...................................1718.2.4 SAR-COSPAS SARSAT system interface...........................................................................1728.2.4.1 Interfacing entities..............................................................................................................1738.2.4.2 Interoperability analysis for the system architecture interfaces....................................1758.2.4.3 System Interfaces requirements ........................................................................................1788.2.5 GSM/UMTS Assisted-GALILEO system interface............................................................1808.2.5.1 Assisted Navigation requirements.....................................................................................1818.2.5.2 GSM Interfacing entities....................................................................................................1828.2.5.3 Interoperability analysis for User Terminal-Processing interfaces ...............................1838.2.5.3.1 Differential corrections data format..............................................................................1858.2.5.3.2 Assisted Navigation Protocol ..........................................................................................1878.2.5.3.3 Assistance Data ................................................................................................................1898.2.5.4 Augmentation Data and Assistance Data Broadcasting: Data Capacity forGSM and UMTS ................................................................................................................................1938.2.5.5 UMTS interfacing entities..................................................................................................1968.2.6 LBS and Interoperability between GALILEO and Mobile CommunicationSystems ...............................................................................................................................................2028.3 SECONDARY SYSTEMS ANALYSIS ..................................................................................... 2088.4 SATELLITES AND S-UMTS ................................................................................................. 2118.5 COMPARISON OF BENEFITS AMONG DIFFERENT SYSTEMS (RANKINGANALYSIS)........................................................................................................................................ 2138.6 MIGRATION CONSIDERATION ........................................................................................... 2178.7 LEGAL ISSUES AT INTEROPERABILITY LEVEL 4/5....................................................... 2188.8 MRD & SRD RECOMMENDATIONS AT INTEROPERABILITY LEVEL 4/5 .................. 2218.8.1 MRD .......................................................................................................................................2218.8.2 SRD.........................................................................................................................................2228.9 ISSUES FOR OTHER GALILEI TASKS AND OTHER STUDIES (TASKS A TO I,GALILEO B2 ICD, PILOT PROJECT) ............................................................................................ 2248.9.1 ICDs ........................................................................................................................................2248.9.1.1 Impacts on Galileo to UMTS ICD ID/GAL/0085/GLI ....................................................2248.9.1.2 Recommendations for a GSM ICD ...................................................................................2268.9.1.3 Impacts on Service Centres ICD (EXTICD-Part e) ........................................................2268.9.2 Task B, Task G and Task C..................................................................................................2278.9.3 Task I ......................................................................................................................................2278.9.4 Task H ....................................................................................................................................2288.10 IMPACTS ON OS (OPEN SERVICES) AND CS (COMMERCIAL SERVICES) .......... 228
9 SUMMARY OF MRD & SRD UPDATE RECOMMENDATIONS ...................................... 230
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 10
Logica
9.3.1 Impacts ON GALILEO to UMTS ICD ID/GAL/0085/GLI...............................................2339.3.2 Recommendations for a GSM ICD ......................................................................................2359.3.3 Impacts on Service Centres ICD (EXTICD-Part e) ...........................................................235
10 SUMMARY OF LEGAL ISSUES ........................................................................................... 237
11 SUMMARY OF ISSUES FOR OTHER GALILEI TASKS AND OTHERSTUDIES ............................................................................................................................................ 239
13 SUMMARY OF CONCLUSIONS AND TECHNICAL ACHIEVEMENT......................... 243
14 ANNEX A: INTEROPERABILITY SCENARIO FOR ROAD APPLICATIONS............. 255
15 ANNEX B: DESCRIPTION OF NON-NAV SYSTEMS CONSIDERED AT IOL1........... 257
15.1 GSM/GPRS/UMTS.................................................................................................................. 25715.1.1 2G Mobile Radio ...................................................................................................................25715.1.2 2.5G Mobile radio .................................................................................................................25815.1.3 3G Mobile Radio ...................................................................................................................25815.2 BLUETOOTH ......................................................................................................................... 25815.3 WIRELESS LAN (WLAN)..................................................................................................... 26015.4 TETRA (TERRESTRIAL TRUNKED RADIO).................................................................. 26015.5 DECT (DIGITAL ENHANCED CORDLESS TELECOMMUNICATION) .................... 26215.6 SATELLITE COMMUNICATION SYSTEMS................................................................... 26415.6.1 Globalstar satellite communication system (User-satellite) ..............................................26415.6.2 Globalstar satellite communication system (Satellite-user) ..............................................26615.6.3 Iridium satellite communication system (Satellite-user) ...................................................26915.6.4 Iridium satellite communication system (User-satellite) ...................................................27115.6.5 ICO satellite communication system (User-satellite) .........................................................27415.6.6 ICO satellite communication system (Satellite-user) .........................................................276
18 ANNEX F: OVERVIEW OF PRACTICAL RESULTS AVAILABLE FOR GPSUSE 290
18.1 SIMILARITIES BETWEEN GPS AND GALILEO............................................................ 29018.2 MAIN RESULTS..................................................................................................................... 291
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 11
Logica
18.3 MAIN RECOMMENDATIONS ISSUED FROM GPS STUDIES..................................... 29118.3.1 Specification Change ............................................................................................................29118.3.2 Measures and risk analysis ..................................................................................................29218.3.3 Monitoring Network .............................................................................................................292
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 12
Logica
LIST OF TABLES
Table 4-1GSM IORs sorted by IO Level selected by Sector (4-7) & Receiver (H)............................... 50Table 4-2_UMTS IORs sorted by IO Level selected by Sector (4-7) & Receiver (H) .......................... 51Table 4-3_All RF Interfaces IORs sorted by IO Level selected by Sector (4-7) & Receiver (H).......... 52Table 4-4_Digital Maps IORs sorted by IO Level selected by Sector (4-7) & Receiver ....................... 52Table 4-5_Augmentation Systems IORs sorted by IO Level selected by Sector (4-7) & Receiver (H) 52Table 4-6_Bluetooth IORs sorted by IO Level selected by Sector (4-7) & Receiver (H)...................... 53Table 4-7_SAR Systems IORs sorted by IO Level selected by Sector (4-7) & Receiver (H) ............... 53Table 4-8_External Aids IORs sorted by IO Level selected by Sector (4-7) & Receiver (H) ............... 53Table 4-9 Non Nav system interfaces: Baseline Requirements sorted by Identity ................................ 54Table 10: Power budget for E5 and L1 .................................................................................................. 60Table 11: IOL requirements to ensure compatibility without disturbance............................................. 61Table 12: IOL Requirements to ensure operational mode with degraded performances (non-working
limit) .............................................................................................................................................. 62Table 13: Compatibility problems to solve in our study........................................................................ 62Table 14: IOL requirements � Maximum interference level admitted................................................... 65Table 15: GSM main characteristics ...................................................................................................... 68Table 16: GALILEO in-band compatibility with GSM out-of-band emission � NB and WB interference
....................................................................................................................................................... 70Table 17: Rejection required to insure interoperability.......................................................................... 70Table 18: GALILEO out-of-band compatibility with GSM in-band emission � NB and WB interference
� mobile station.............................................................................................................................. 73Table 19: GALILEO out-of-band compatibility with GSM in-band emission � NB and WB interference
� base station.................................................................................................................................. 74Table 20: Rejection required insuring interoperability .......................................................................... 74Table 21: UTRA FDD main characteristics........................................................................................... 75Table 22: UTRA TDD main characteristics........................................................................................... 76Table 23: GALILEO in-band compatibility with UMTS out-of-band emission � NB and WB
interference � Mobile station ......................................................................................................... 78Table 24: GALILEO in-band compatibility with UMTS out-of-band emission � NB and WB
interference � Base station ............................................................................................................. 82Table 25: Rejection required insuring interoperability .......................................................................... 82Table 26: GALILEO out-of-band compatibility with UMTS in-band emission � NB and WB
interference � mobile station.......................................................................................................... 84Table 27: GALILEO out-of-band compatibility with UMTS in-band emission � NB and WB
interference � base station.............................................................................................................. 86Table 28: Rejection required insuring interoperability .......................................................................... 86Table 29: Bluetooth main characteristics............................................................................................... 87Table 30: GALILEO in-band compatibility with Bluetooth out-of-band emission � NB and WB
interference .................................................................................................................................... 88Table 31: Rejection required insuring interoperability .......................................................................... 88Table 32: GALILEO out-of-band compatibility with bluetooth in-band emission � NB and WB
interference .................................................................................................................................... 89Table 33: Rejection required insuring interoperability .......................................................................... 90Table 34: DECT main characteristics .................................................................................................... 90Table 35: GALILEO in-band compatibility with DECT out-of-band emission � NB and WB
interference .................................................................................................................................... 92Table 36: Rejection required insuring interoperability .......................................................................... 92Table 37: GALILEO out-of-band compatibility with DECT in-band emission � NB and WB
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 13
Logica
Table 40: GALILEO in-band compatibility with TETRA out-of-band emission � NB and WBinterference .................................................................................................................................... 96
Table 41: Rejection required insuring interoperability .......................................................................... 96Table 42: GALILEO out-of-band compatibility with TETRA in-band emission � NB and WB
interference � Mobile station ......................................................................................................... 98Table 43: GALILEO out-of-band compatibility with TETRA in-band emission � NB and WB
interference - Base station............................................................................................................. 98Table 44: Rejection required to insure interoperability.......................................................................... 99Table 45: Possible co-operation at IOL1 between navigation receiver and non-navigation mobile
station............................................................................................................................................. 99Table 46: Dimensioning protection distance between GALILEO receiver and non-navigation system to
insure interoperability at IOL1..................................................................................................... 104Table 47: Additional out-of-band rejection required ........................................................................... 105Table 6-1- Mapping of Positioning Systems vs. Environments........................................................... 125Table 8-1 - GALILEO service performances for Search and Rescue Service ..................................... 178Table 8-2; General data format for the assistance data ........................................................................ 185Table 8-3; Differential correction data-format..................................................................................... 186Table 8-4; Assisted positioning data format ........................................................................................ 187Table 8-5; Assisted Positioning protocol ............................................................................................. 188Table 8-6; Assistance data format........................................................................................................ 189Table 8-7; Almanac data...................................................................................................................... 191Table 8-8; CLASS1 Elementary Procedure ......................................................................................... 201Table 8-9; CLASS2 Elementary Procedure ......................................................................................... 201Table 8-10; Communication Systems Benefits Comparison Table ..................................................... 213Table 8-11 � Navigation Benefits Comparison Table (StandAlone/Dual Mode) ................................ 215Table 15-1: UMTS allocated frequency bands .................................................................................... 258
LIST OF FIGURES
Figure 6-1; Hybridisation at position level ......................................................................................... 111Figure 6-2; Hybridisation at ranging-measurements level .................................................................. 112Figure 6-3; Tight coupling-partial _Terminal Hybridisation architecture .......................................... 113Figure 6-4; Tight coupling-full _Terminal Hybridisation architecture ............................................... 114Figure 6-5- Hybridisation Dual Mode Operation (Switching Mode)................................................. 126Figure 6-6- Transition Scenario among systems................................................................................. 128Figure 7-1- Overview of Systems accuracy vs. Environments ........................................................... 133Figure 7-2; Position-Data fusion hierarchy......................................................................................... 136Figure 7-3; Position-data fusion-Bayesian Inference.......................................................................... 137Figure 7-4; Multiple Kalman Filter..................................................................................................... 139Figure 8-1; The Typical Architecture of a GSM Network.................................................................. 157Figure 8-2; The Value Added Services Business Model. ................................................................... 158Figure 8-3; An illustration of the various protocol stacks involved in carrying bearer traffic to the MS.
..................................................................................................................................................... 159Figure 8-4; A Schematic of the GSM interfaces with Galileo. ......................................................... 159Figure 8-5; an illustration of the various protocol stacks involved in carrying bearer traffic to the MS.
..................................................................................................................................................... 163Figure 8-6; The Protocols Supported for PS Communications with the MS. ..................................... 163Figure 8-7; The OSA Model is Divided Into Three Basic Layers. ..................................................... 164Figure 8-8 � IMS Architecture............................................................................................................ 166Figure 8-9 � IP Multimedia-GALILEO interrelation Scenario........................................................... 167Figure 8-10; A Charging Session for a One-off Charge. .................................................................... 168Figure 8-11; Number of SAR events assisted by COSPAS-SARSAT (January-December 2000) ..... 179Figure 8-12; Number of person rescued in SAR events assisted by COSPAS-SARSAT (January-
December 2000)........................................................................................................................... 179
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 14
Logica
Figure 8-13; Number of SAR events in which COSPAS-SARSAT was used (January1989-December2000) ............................................................................................................................................ 180
Figure 8-14; Interface entities between GSM Network and GALILEO ............................................. 182Figure 8-15; Position Measurements procedure ................................................................................. 184Figure 8-16; Assistance data delivery procedure ................................................................................ 184Figure 8-17 � UMTS GALILEO System Interfaces ........................................................................... 200Figure 8-18; Information Exchange Initiation procedure, Successful Operation................................ 201Figure 8-19; Information Reporting procedure, Successful Operation ............................................... 202Figure 8-20 � LBS interoperability Scenario ...................................................................................... 203Figure 8-22 � Migration Plan.............................................................................................................. 217Figure 14-1; GALILEO Interoperability environment........................................................................ 255Figure 16-1; The UMTS Network as Defined in Release 5 of the 3GPP Specifications. .................. 280
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 15
Logica
1 EXECUTIVE SUMMARY
The present Analysis has been performed in order to study the Interoperability and interfacingrequirements between GALILEO and Non Navigation systems (GSM, UMTS, Bluetooth,UWB, etc.), and to evaluate the impacts of interoperability on the implementation ofGALILEO services in the future Market environments. Relevant recommendations have beenput forward for the GALILEO MRD/SRD documents.
Level 1 RF Processing LevelThe RF interference between GALILEO and non-navigation systems has been here analysedin order to investigate the integration at terminal level. The analysis demonstrated that thefeasibility of an integrated GALILEO/Non Nav systems terminal force the two RFsubsystems to be sufficient separated with the aim to contemporary allow the Non Navtransmission and GALILEO satellite acquisition (Antenna spatial separation depends on thesystem considered).Main results coming from the RF interference analysis are reported in the following Tables,expressing the minimum distances between a Non-Navigation system antenna and aGALILEO antenna for a nominal operation.The protection distance between navigation and non-navigation equipments (separated) aresynthesised in the following Table.
Dimensioning protection distance between GALILEO receiver and non-navigationsystem to insure interoperability at IOL1
For what concerns base stations, protection distances are relatively low and acceptable, exceptfor UMTS for which installation precaution should be taken to preclude GNSS receiverperturbations.
The dimensioning protection distance between navigation and non-navigation equipment onthe same terminal are synthesised in the following table.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 16
Logica
Non-navigation
system
Non-disturbingcriteria
Non-workingcriteria
Dimensioning cases
GSM 81dB 68dB WB interferenceIn-band
UMTS 86dB 73dB WB interferenceIn-band
Bluetooth �WLAN
96dB 83dB WB interferenceIn-band
DECT 86dB 73dB WB interferenceIn-band
TETRA 80dB 67dB NB interferenceIn-band (H3)
Additional out-of-band rejection required
Even with antenna isolation, this level of rejection cannot be reached (a typical rangeaccessible is from 30 to 50dB, depending on configurations).Indeed, it should be recommended to pay attention to the level of the spurious emissions ofthe non-navigation equipment and to try to lower it as far as possible (for example: emissionfiltering, etc.) .As a final conclusion, one should say that the theoretical results trying to assess compatibilitybetween GALILEO and Non-Navigation systems appears to be at the same time critical butvery pessimistic. In particular, for GPS, that should have a similar behaviour than GALILEO,the major outages reports do not show problems with the studied Non-Nav systems but withother devices (TV, Military communications, etc.).Therefore, this �over-dimensioned� approach could lead to an important gap betweentheoretical results (derived from the specifications contained within the standards) andoperational measures. Nevertheless, the theoretical approach remains the �worst case� thatcan be encountered until nothing is done at standardisation level to guaranty a fullcompatibility between GNSS and Non-Navigation systems.
Level 3A Hybridisation at ranging measurements levelDefinition. Interoperability at level 3A represents the hybridisation at pseudorange levelbetween GALILEO pseudorange measurements and ranging measurements coming fromexternal ranging sources (e.g. E-OTD/TDOA measurements from GSM/UMTS BTSs)GALILEO and GSM ranging measurements hybridisationHybridisation between GALILEO and GSM (E-OTD) and UMTS (TDOA) rangingmeasurements, using also as starting point studies carried out on those matters (e.g. EMILY).Two basic options are envisaged for hybridisation at this level:
1. Tight coupling-partial: positions are derived from hybridisation of OTDsmeasurements both from Satellite (derived by ranging measurements) and from GSMBase Stations (BTSs). OTDs (Observed Time Difference) measurements areconsidered separately for Satellites and BTS and no mixing solution are considered
2. Tight coupling-full: position is derived from hybridisation of OTDs measured bothfrom Satellite and GSM network Base Stations as well from mix OTDsmeasurements between satellites and reference BTS
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 17
Logica
The main advantage of using different ranging measurements coming from different sourcesis the overall positioning system availability improvement, especially in the full option case.For the full option, in fact, three ranging sources (irrespective of Satellite or GSM BTS) areenough for the 2D positioning. Positioning computation, using E-OTD, requiressynchronisation of ranging measurements coming from different BTSs. In the GSM network,BTSs are not synchronised and OTDs measured at terminal level do not correspond to theGeometric Time Difference (GTD) because of different time of emission of the referenceranging signals. In the GSM network LMUs (Location Measurements Unit) are foreseen toovercome the synchronisation problem. LMUs are able to calculate the Relative TimeDifference between the BTSs involved in the terminal positioning calculation. LMUs performthe time measurements and, on the basis of their known precise position, RTDs values arecalculated and distributed (e.g. Cell Broadcast Services) to the user terminal. The density ofLMUs is variable in the range of one LMU every 3-5 BTSs. To obtain accurate triangulation,OTD measurements and, for non-synchronised network, RTD measurements are needed for atleast three geographically distinct BTSs. Based on such measurements, the location of theuser terminal can be calculated either in the network (MS-Assisted) or in the User terminalitself (MS-Based) by means of intersection of two hyperbola obtained with three BTSs andtwo GTDs. EMILY used for hybridisation at this level a simplified version of ExtendedKalman Filter (HEKF), probably deriving from a trade-off between implementationcomplexity and robustness.SIA analysis showed that the proposed solution, based on pseudoinverse solution for thedetermination of positioning errors to be used by a linear KF as input, can introduce a noisemultiplication (also amplified by the differential nature of the measurements, introducing afactor of two during the combination of measurement coming from each BTS).As a cumulative factor, the linearisation adopted for linear KF implementation imply a strongdependence on the input position error estimation. An initial position estimate (e.g. calculatedusing only OTD measurements or Cell-ID in the case the number of measurements are notsufficient in order to estimate the position) far from the real position can lead to a rapiddivergence of the Kalman Filter.It is proposed to use new algorithms (e.g. UKF) in order to perform very robust positiondetermination for non-linear systems. Those Enhanced Kalman Filtering techniques introducethe following improvements:
• Allows a robust treatment of Non-linear measurements, avoiding the linearisationprocess
• Covariance propagation is efficiently carried out through points sampling, instead ofusing classical matrix multiplication propagation expressions, implying an easiertracking of noise behaviour during manoeuvres (Using the EKF procedures, only thefirst two moments, mean value and variance, are considered during the stateestimation).
• Allows a reduction of computational complexity (due to the covariance propagationby points instead of by matrix multiplication)
Therefore, the study of improved KF (e.g. UKF) is highly recommended for the design ofhybridised sensors, considering the inherent non linearity introduced by the mobile trajectory(e.g. 90° car turning phases) and the noise characteristics and processing problems involvedinto the BTS ranging measurements to be fused with satellite ones.
Regarding the availability, the more direct way to show the improvement introduced by theuse of mixed ranging measurements is to report the Service Coverage constraints in terms of
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 18
Logica
minimum number of available measurements for position determination. The improvementsin terms of availability are the following:
• Tight Partial coupling solution:2-D: 2 GNSS satellites + 2 BTSs are sufficient for positioning3-D: 2(3) GNSS satellites + 3(2) BTSs are sufficient for positioning
• Tight Full coupling solution:2-D: 2(1) GNSS satellites + 1(2) BTSs are sufficient for positioning3-D: 1(3) GNSS satellites + 3(1) BTSs or 2 BTSs + 2 GNSS satellites are sufficientfor positioning
Similar considerations to what has been derived for GSM can be repeated for UMTSintegration. The basic difference is related to the fact that UMTS do not require RTDcalculation (from the network side) and utilisation in the position solution algorithm (from theterminal side). Same KF models can be implemented for UMTS hybridisation.
Hybridisation transition plan (level 3A)Hybridisation at ranging level 3A between two systems means to use measurements comingfrom different non-homogeneous sources of the considered systems, and merge them into aunique solution. The relevant improvement is in this case an increased coverage of thecombined positioning system. Typical options are, as we have reported above, thehybridisation of GALILEO and Mobile Communication systems ranging measurements. Inthis case the user terminal shall be able to receive signals coming from satellites and MobileNetworks Base Stations, and to perform the relevant ranging measurements. The GALILEOuser terminal shall foresee two different operation modes:
Basically the standard default mode should be the Assisted-GALILEO stand-alone one inorder to minimize power consumption and time to position calculation. The switch from theGALILEO stand-alone mode to the hybridized dual-mode shall be based on the followingrule:
1. The GALILEO user terminal automatically detects that GALILEO positionperformances are degraded due to shadowing problems and noise environments,especially in urban canyon environments. The UT in this case foresees a �monitoringfunction� of the GALILEO position performance and automatically activates thedual-mode status if the performances remain under a fixed quality-threshold morethan a given time out (Time out 1 in the figure below). The UT will come back to theGALILEO-stand-alone mode as the GALILEO performances come back to asatisfying quality level (over the threshold) for a time longer than a given time out(Time Out 2 in the figure below)
2. The User manually select the hybridized option on the GALILEO UT, in order toincrease the number of measurements and the position performances even if theGALILEO positioning service is available
In the following figure is represented the logical switching rule between the GALILEO stand-alone and the hybridized mode.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 19
Logica
T<Time out 1 T> Time out 1
GALILEO MODE
HYBRIDISED MODE
T< Time out 2
T> Time out 2
Threshold
GALILEO Quality
The relevant parameters used in the switching algorithm are:� The GALILEO performance quality-parameters representing the GALILEO quality of
service to be monitored (e.g. PDOP, number of visible satellites, SNR, measurementsnoise information, etc.)
� The threshold values: its choice is relevant in order to guarantee the service continuityand at the same time to minimize the power consumption and the waste of resources. Thethreshold value depends on the chosen quality parameter.
� The choice of the time-outs (in the figure indicated as TO1 and TO2): Time Out valuesare relevant to control the switching functionality between the different modes.
Hybridisation with secondary systemsBluetooth and other secondary systems are analysed at 3B level because the systems areconsidered Alternative for position determination, and not for ranging measurementshybridisation. This is due to the following reasons:
• GALILEO provides good position and ranging measurements statistics in outdoorand light indoor positioning through A-GALILEO and hybridisation with mobileoperators BTSs ranging measurements
• GALILEO signal is not available in deep indoor and very critical environment, whilethrough Assisted Navigation techniques it can provide bad accuracy (50 m-100 m)not comparable with secondary systems performances (e.g. UWB: decimetres level,Bluetooth and WLAN less than 10 m) if the respective infrastructures are present
• If Secondary systems are not available in indoor or critical environment situationsand satellite systems (or assisted one) cannot be used, alternative fixed solution shallbe developed (e.g. being within a geolocated buildings, simply the presence in thebuilding can be communicated)
The derived ranking can be represented in the following table, where in yellow arehighlighted the critical points (performance are qualitative in order to emphasise thedifferences between the different systems).
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 20
Logica
GALILEO/GPS A-GNSS HybridisedGSM/UMTS
Assisted GNSS
Bluetooth(***)
WLAN(***)
UWB TETRA
DeepIndoor/Tunnel
N/A N/A N/A 10m 10m 10-30cm
N/A
LightIndoor
N/A (very badperformances if
available)
20-100 m(*)
20-200 m(**)
10m 10m 10-30cm
N/A
UrbanCanyon
N/A (very badperformances if
available)
10-50 m(*)
10-50 m(**)
N/A N/A N/A N/A
Outdoor <10 m <10 m <10 m N/A N/A N/A N/A(*) = available with sufficient number of satellites (at minimum 3, e.g. urban canyons or near windows within buildings) trackedusing assisted navigation techniques (not usable through nominal receivers)(**) = higher availability compared to A-GNSS solution due to use of external range measurements (e.g. indoor environmentwith number of tracked satellites ≤ 2: needed hybridisation with GSM/UMTS BTSs ranging measurement for positioncomputation)(***)= the reported accuracy levels are depending on the availability of the short range systems infrastructures in the consideredenvironments
Level 3B Hybridisation at position solution levelDefinition: Interoperability at level 3B means hybridisation of position solutions coming fromdifferent systems using independent measurements (GALILEO, GSM through only E-OTDmeasurements, UMTS through only TDOA measurements, etc.).
Hybridisation of independent position solutions obtained by different systems (GNSS,GSM/UMTS ranging, Bluetooth, UWB, etc.) have been analysed, and new solutions havebeen proposed, as the Multiple Kalman Filtering option. Secondary systems (Bluetooth,UWB, etc.) solutions have been detailed and proposed as interoperable systems to be used inalternative mode wrt to GALILEO, mainly in indoor environment.In order to characterise the Data Fusion Process at position level, the following cases can beidentified:• Incomplete solution: only single variances are mixed in order to estimate the combined
solution• Complete solution: complete covariance matrixes are mixed in order to estimate the
combined solution• Switch (or Alternative) solution: the differences between the variances are so high (e.g. a
single solution is very much better than the other ones), that only one of the systems isused for the position determination, while the others are momentarily discarded
Bayesian techniques can be adopted at a first glance to fuse data coming from differentsensors. Quality reports (position estimation variances) are needed to perform data fusion.The Bayesian approach is simple and compact, but has principally two drawbacks:• It do not take into account the user dynamic• It is not able to carefully follow the changing characteristics of the environment (e.g.
multipath condition) and to correctly propagate the relevant estimateMultiple Centralised Kalman filter are the most useful techniques in this field. The basicprinciple of that technique is:
• To filter separately the outputs coming from each sensor to determine the positionand velocity or heading using a local Kalman Filter
• To combine the position and velocity coming from each sensor through a CentralKalman Filter
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 21
Logica
The main advantages of the above approach are the following:• Blunder detection: in the case a blunder in a single sensor processing appears, the
error is detected by the Local Kalman filter and the relevant measurements are notprocessed in the Centralised filter, while drifts and other slowly varying errors can beallowed to accumulate until the error can be detected and eliminated by theCentralised Kalman Filter
• Decrease the computational complexity: the number of ops (operation per second)decreases dramatically by segmenting the number of states. This is fundamental forthe most requiring computation, like matrix multiplication in state covariance matrixpropagation and matrix inversion in the KF Gain calculation. For instance,considering the complexity of a matrix multiplication (O(2n3)), if a 20 states KF,including all sensors, is segmented in local KF of about 6 states each, thecomputational load can be decreased by 16000 to 6250 ops.
• Sensor intermittences (e.g. GPS providing position information at 1HZ, while E-OTDproviding information at a lower rate) can be taken into account by the central KFthrough dynamic addition and removal of sensors during the processing
In the following scheme a functional scheme for Multiple Kalman Filtering is reported.
It is recommended to analyse into the user terminal design phase Multiple Kalman Filteringas Positioning Data Fusion technique.Navigation receivers are interfaced at present with the external equipments through NMEA0183, while NMEA 2000 protocols are emerging. These should be updated for fullcompliance with all Galileo services.Following the analysis previously carried out, the basic information to be transferred by eachsensor for the hybridised for each sensor is:
• Position: X, Y, Z in WGS-84 (or ITRF for GALILEO) or Lat, Long, Height• Quality Report: PDOP, GDOP as minimum for incomplete solution, Covariance
Matrix for a complete solution
In order to implement data fusion techniques, a new Quality report message is necessary,reporting the error covariance matrix elements to be used in a Bayesian or multiple Kalmanfiltering approach. Furthermore, Also GSM or UMTS BTS used in the position computationshould be identified within the message.We recommend the introduction in the NMEA 0183 standard of the following new GSTmessage dedicated to position data fusion:0 = Device (assigned code)
GSM E-OTD Kalman
Filter
UMTS TDOA/TOA
Kalman Filter
Central Kalman
Filter
Position Velocity
Position Velocity Heading
GPS/GALILEO Kalman Filter
Position Velocity
Position Velocity
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 22
Logica
1 = Mode: M=Manual, forced to operate in 2D or 3D A=Automatic, 3D/2D2 = Mode: 1=Fix not available 2=2D 3=3D3-20 = IDs of SVs used in position fix (null for unused fields), both GPS and GALILEO21-23 = IDs of the GSM/UMTS BTSs used in position fix (null for unused field), following apredefined coding (e.g. derived from SMSCB broadcast message)24-29 = elements of Error covariance Matrix. Depending on 2-D or 3-D position, some fieldscould be null. Being the covariance matrix symmetric, only 6 elements have to be passed
24 = σx2
25 = σxy
26 = σxz
27 = σy2
28 = σyz
29 = σz2
where x,y,z have to be intended as WGS84 or ITRF coordinates, while if 2-D positioning isinterested, it represents Lat and Long.An example is given in the following for the device 4.$--GST,4,M,2,19,28,14,18,27,22,31,39,,,�.,,46.3,1.2,24.2*35
NMEA 2000 is the following development of the NMEA 0183 standard. It starts from therequirements coming from the integration of different systems within the vehicle/mobile andenhances the NMEA 0183 for the definition of protocols from a network perspective. Thefollowing updatings are recommended:• GNSS Position statistic, reporting the elements of the error position Covariance Matrix
should be provided for the GALILEO+GPS system. The content of this message shouldbe similar to the above proposed GST message:
o A flag indicating 2-D or 3-D modeo A mask with 1s for the used satelliteso The elements of the Covariance Matrix
• GNSS/GSM DOP: At the moment GSM and future UMTS are not considered as sourcesof ranging. This new message has to be introduced in order to include also GSM E-OTDand UMTS TDOA measurements for DOP calculation. The relevant message for thehybridised GNSS/GSM positioning has to be foreseen in the new NMEA standard
Hybridisation with secondary systemsBluetoothBluetooth positioning service has the relevant goal to locate Bluetooth devices mainly inindoor environment. A Bluetooth device, by means of a specific positioning service, shouldbe able to collect information from surrounding devices acting as position servers, and tocalculate its own position exploiting these data. In order to improve the positioningperformances, the device can at least measure ranging distance from the surrounding devices.Hybridisation at position level between GALILEO and Bluetooth position solution can beforeseen only in the Alternative Use scenario. The two positioning systems operate in fact intwo different and complementary service environments. GALILEO position solution will beavailable only in clear sky environment and at least in satellite signal critical-environment(e.g. Urban Canyon) with degraded performances. In such environment, hybridisation withBluetooth has no sense because of the local and short-range nature of the Bluetooth network.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 23
Logica
Bluetooth position could be useful for deep indoor positioning and navigation, as theGALILEO UT is not able to perform the satellite-based position.Also in the case of Assisted GALILEO position-solution calculated in a light-indoor andBluetooth environment, hybridisation could have no sense if Bluetooth position is available.In fact, if a Bluetooth piconet is available and includes devices able to provide positionservice, it means that at least the GALILEO-Bluetooth interoperable device knows its positionwith an error that is limited by the maximum communication range available for Bluetooth(e.g. 10 m for class 3 devices).Short-range positioning service is the best options to guarantee availability of position andnavigation services also in such environments where the Satellite systems are not available.The following alternative switching rules can be given for hybridisation:� GALILEO terminals prioritise the GALILEO solution and switch its operational mode
from GALILEO to Bluetooth mode only when the GALILEO solution is not moreavailable and, at the same time, the GALILEO Terminal is able to connect to othersurrounding location aware Bluetooth devices. As the GALILEO solution becomesavailable, the operational mode changes again to the satellite mode.
� GALILEO terminal changes mode from GALILEO to Bluetooth positioning system,whenever a Bluetooth network is detected and a positioning service is available, even ifGALILEO position solution is available.
In order to establish new Bluetooth connections, necessary to use Bluetooth positioningfeatures, the procedures inquiry and paging are used. The response time of the devices is a bitlong and causes a delay while discovering the devices in the range. The time needed forcreating the connection has to also be taken into account. Connection forming time will taketypically average of 5.12 s. It takes only approximately 0.6 s when the frequency-hoppingscheme of the user unit is known and no inquiry is needed. The transition time from Bluetoothmode to GALILEO mode is strongly influenced by the Time to First Fix of the GALILEOterminal. In the case of Assisted GALILEO solution, in worst-case environment, GALILEOprovide a first fix in just a few seconds.
WLANWLAN positioning technologies are based on TOA and TDOA techniques and, as in theGSM case, can be network based or handset based. In order to calculate the position of themobile terminal, the time offset from more than three Geolocation Base stations (GBS) thatcan be implemented within the AP or in separated Geolocation Reference Unit (GRP) have tobe calculated. The WLAN position accuracy is in the order of some meters, while the meanranging measurements errors are in the order of 7.5 m, while the standard deviation is in theorder of 10m.It is recommended to use WLAN strictly in alternative mode with respect to theGALILEO/GPS solution (together with the Bluetooth one) for indoor applications equippedwith a suitable APs distribution.The use of NMEA GGA like for position exchange is here recommended.
UWBA network infrastructure of fixed position UWB nodes provides the means for preciselocation and tracking of mobile terminals using TOA/TDOA techniques: Localisercommunication and position technology are based on the transmission of PRN codedsequences of Gaussian impulses and selective reception using correlation. The time of flightis precisely measured by the phase shift of the codes. The receiver locks to the codedsequence of the transmitter within an accuracy of less than 100 picoseconds (about 30 cm).The relevant coverage of a UWB beacon is about 2 Km.From the above considerations, UWB offers a very important opportunity for indoor and verycritical environment (e.g. tunnels) positioning. In particular, it has the capability to provide a
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 24
Logica
very accurate positioning with lower infrastructures and receiver costs, allowing also a highrate transmission capacity. Due to the low cost, a network of UWB localiser for positioningpurposes can be implemented for very critical and indoor situation (tunnels, deep indoor) forsafety related purposes at the early stage of GALILEO development in completely Alternativeuse, in order to avoid any interference problem. GALILEO receiver should be able to switchto an UWB (and integrated WLAN or Bluetooth) positioning method and to pass the statisticinformation to the Central KF, which has in this case only the aim to evaluate the quality ofthe calculated position.Particularly of interest is the boundary region (exit from a tunnel, entry in a garage). Here aCentral KF has to be able to integrate UWB localiser position information untilGALILEO/GPS+GSM/UMTS are able to guarantee singularly the position. After this perioda complete switching to the available UWB should be decided until the beginning of tunnelexit. NMEA GGA (or GLL) plus Quality report (e.g. GST) is also here recommended.
TETRATETRA is a system currently developed for Police and Military Application, but in the futureit is foreseeable that such a system could be expanded and could cover urban areas and mainstreets.The positioning capability is currently performed through integration with GPS. Thesimilarity with GSM technology makes in principle possible the determination of OTDmeasurements between the user and the BTSs. At the moment there are no studies about thatpossibility. If this possibility will be developed, TETRA could be used, as additional rangingsource and positioning system within the more covered areas, like Urban Areas and highways.
DECTDECT support has been added in many office buildings to allow intercom system work freely.Therefore, existing infrastructure for guidance system purposes can already be found installedin many places. DECT network can be used to offer several simple services by utilising itsdata connection. The major disadvantage of DECT from the guidance system point of view isthat practically only phones support it. Also, DECT device functions only in local DECTnetwork.Thus, it is highly unlikely that a random user would carry device with the correct DECTsupport with him. Roaming between different DECT networks is not possible. Since DECTsupports connections in a radius of 300 m, it is really hard to get accurate locationinformation, thus making the guidance system inaccurate. A positioning capability is hard toenvisage in this case, also due to the low Market penetration and coverage of DECT.For those reasons, DECT it is not recommended for positioning and ranging hybridisation, outof particular coverage situation that could be covered by dedicated cards.
Hybridisation transition plan (level 3B)As far as the hybridization at Level 3B (Positioning hybridization) is concerned, theGALILEO UT should be able to perform both the GALILEO position and the NonNavigation Systems position and at least to hybridize them in order to improve the accuracyor use them in alternative mode in order to guarantee the service continuity where GALILEOservice is not available.The operational mode considered are:
� GALILEO stand-alone mode (A-GALILEO stand alone mode)� GALILEO-Non Nav System hybridised mode (or dual mode)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 25
Logica
The switch from the GALILEO stand alone mode to the hybridized mode should be foreseenin the following different cases:
� The GALILEO positioning performances are degraded and a threshold-basedalgorithm (PDOP, position estimation covariance matrix elements, etc..) couldmanage the switching function, in order to use a back up positioning system (EOTD,OTDOA, Local Positioning Systems). Typical scenario: clear-sky environmenttowards a high-density urban area (urban canyon) characterized by shadowingproblems (e.g. less than 3 satellites in visibility do not allows independent GALILEOpositioning)
� The GALILEO service is available and the user manually selects the hybridizedmode; in this case the position solution are merged on the basis of the quality reportof the single position solution
� The GALILEO UT, interoperable with Local Positioning Systems, (Bluetooth,WLAN, DECT) detects a Local Positioning Environment, as for instance a Bluetoothpiconet. In this case the GALILEO UT shall foresee the option to automaticallyswitch to the Local Systems by previously verifying the availability of the PositioningService. Typical scenario: the transition of the GALILEO user from an openenvironment (GALILEO available) towards a light indoor environment.
The figure showsthe transitionsscenarios for aGALILEO UThybridized at IOlevel 3 with NonNavigationSystems, whichmoves from a clearsky environmenttowards an indoorenvironment.
Level 4/5: Application and Vehicle level
Interoperability at system and terminal level between GALILEO and Non NavigationSystems has been analysed in order to identify the best candidate solutions for the integrationof the communication services into the GALILEO UT and Ground segment level forapplications development. Furthermore, standards for Augmentation and Assistance databroadcasting have been provided and relevant means for broadcasting have been studied interms of resources occupation.
Assisted NavigationThe basic idea of assisted satellite navigation is to provide the receiver with a partial or fullset of navigation data (usually broadcast through the satellite SIS) in order to allow thereceiver itself to skip the demodulation phase (difficult in urban canyon and indoorenvironments, due to low S/N and high multipath conditions) and reducing TTFF.
Clear Sky Sub Urban Urban Light Indoor Deep Indoor
GALILEO Stand-Alone
GALILEO-Mobile Networks Hybridized mode
GALILEO-Local Positioning Hybridized mode
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 26
Logica
The amount of data to be transmitted to the receiver depends on the technical solution to beimplemented:
1. Network Based solution: in this case the receiver has only to calculate pseudorangemeasurements and send them to the Mobile Network, that is in charge of calculatingthe receiver position, eventually applying differential corrections. In this case, theassistance data to be sent to the mobile are very short: visible satellite list, signalDoppler and code phase search window
2. Handset Based solution: in this case the receiver has to calculate by itself theposition. A full set of assistance data is needed, including the satellite ephemeris andclock corrections
ETSI developed standards for �assistance data� transmission and the compliance with theseexisting and foreseen standards is the core interoperability issue for GALILEO to beinteroperable with mobile communication systems.An extension of current ETSI standards for the provisioning of Assisted Navigation andDifferential correction has been proposed in order to take into account the future doubleconstellation scenario (also ciphering can be applied). A data capacity analysis for theGALILEO (+GPS) Augmentation and Assistance Data broadcasting has been performed.Almanacs can be optionally transmitted for Assistance.The SMSCB service is proposed for the broadcasting of such data (SMSCB service isavailable both for GSM and UMTS). The SMSCB service is able to transmit one message (82bytes) every two seconds. Therefore, 15 SMSCB messages can be transmitted every 30s,while 45 messages can be transmitted within 90s. A schedule message has to be sent beforethe data contends. The maximum schedule period is long 48 SMSCB message slots.Following the standards, the total amount of ephemeris and clock data (corresponding tosubframe 1 to 3 of the navigation message) is about 638 bits for 1 satellite, corresponding toabout 80 bits. Those data are necessary in a Handset Based solution. Therefore the ephemerisand clock information for one satellite is contained into 1 SMSCB message. The total amountof DGPS information (only peudorange corrections) is 48 bits per satellite with about 80 bits(10 bytes) of overhead information for GPS Reference Station only relevant data. The totalmessage size for 12 visible satellites is about 651 bits, corresponding to 82 bytes, which willfit within a single SMSCB message.One differential correction message should be transmitted every 30 s (maximum age of thecorrections: after SA removal, and considering that GALILEO will not contain SA, such amaximum age is acceptable), while the ephemeris and clock data can be broadcast every 90s,so that a complete ephemeris and clock message is transmitted in about 18 min for 12satellites in view.A data capacity analysis has been conducted considering the possible scenarios:
1. GALILEO only (Single frequency corrections)2. GALILEO+GPS (Single frequency corrections)3. GALILEO+GPS (Three frequencies corrections)
The results are: in the best case (only GALILEO, single frequency, without almanac), theutilisation factor of the SMSCB service is acceptable (15,5% through ephemeris every 30s,11% through ephemeris every 90s), while in the worst case (double constellation, threefrequency, with almanacs) 60% of utilisation is foreseen.A more compressed data set or a compression algorithm (e.g. the CBS compression algorithmreported by ETSI) is recommended (at least for the case of three frequencies corrections) inorder to allow the full interoperability between GALILEO and the Mobile operators for thedelivery of the applications.Otherwise, it has to be pointed out that in Urban Areas (where assisted navigation is reallynecessary), the satellite visibility is reduced due to shadowing, and a slot reserved for 12 onlyvisible satellites for the integrated GALILEO + GPS constellation should be sufficient.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 27
Logica
GALILEO Local Elements - GSM infrastructures InterfacesThe system/applications architecture interfaces description is performed identifying therelevant interfacing system entities and their specifications.In order to correctly identify the interfacing entities, the functional scheme of a LocationBased Services embedded into a GSM/UMTS framework is reported in the above figure.Interfacing entities for Assisted Navigation are:• GALILEO Ground Segment: it can provide the SMLC (Serving Mobile Location
Centre) with the basic satellite navigation data without the need to implement aworldwide Reference Station Network for the Mobile Operator or Service Provider. Datato be transmitted are constellation status, integrity information (no real-time), andnavigation assistance data (e.g. ephemeris and clock corrections). For GSM, standardinterfaces are not currently defined.
• GALILEO Local Elements: they can provide SMLC with the necessary data forintegrity information broadcasting and Differential correction. Furthermore, in this casepartnership could be carried out between mobile operators and GALILEO Local Elementsin order to share costs for the development of a dense differential Network throughout allEurope
In the following it is reported the interfacing structure between GALILEO sub-elements andGSM Mobile Operators infrastructures.
GALILEO Sat ephemeris
GALILEO LOCAL
ELEMENTS
GALILEOAugmentation Data
GALILEO GS
For the exchange of Assistance data and Augmentation data between GALILEO GroundSegment of Local Elements (e.g. through the GSC) and the GSM SMLC (in order to favouritein this way to the possibility to perform a direct tunnelling between GALILEO GSC and theuser). It is recommended the use of RLLP protocol.
GALILEO Local Elements - UMTS infrastructures InterfacesETSI derived standards also for the interfacing between UTRAN and external assistance dataproviders (see figure below) for GPS LCS applications. The SNRC (Service Radio NetworkControl), working as SMLC for GSM, receives authenticated request from LCS applicationsor LCS Client functions in the CN (Core Network) across the Iu interface. RNCs (RadioNetwork Control) manage the UTRAN resources, the User Terminal and the calculationfunctions to estimate the position and return the result to the CN. The SAS (Stand Alone A-GPS SMLC) provides GPS assistance data to the SRNC to be delivered through point-to-
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 28
Logica
point or broadcast channels to the UE, and acts as a location calculation server if the locationestimates are not calculated in the RNC.GALILEO system interface towards the UTRAN can be implemented through the ETSI Iupcinterface. The GALILEO interfacing point (e.g. Server which collect measurements from areference network and compute the assistance data) should act as an external SAS. In thiscase the GALILEO interfacing-point shall implement the PCAP (Positioning CalculationApplication Part) protocol over the Iupc interface in order to communicate with the UTRANSRNC.
Iub
LMU Type A
SRNC CN
Node B (LMU Type B) RNC
UE Node B (LMU Type B)
Iur
IuIub
Uu
SAS
Iupc
GALILEO GS / LE
External Interface
Benefits among different SystemsA Ranking Analysis has been performed in order to identify the benefits introduced by thehybridisation among different systems. In the following Table, a comparison of benefitsintroduced by hybridisation between GALILEO and Primary and Secondary systems isreported for navigation purposes. The Column �Hybridis. Mode� reports the kind ofhybridisation that is recommended for each environment. The options are:• Stand-Alone: GALILEO performs positioning by itself and by hybridisation with other
systems at position solution level (3B)• Dual Mode (Dual M): GALILEO can perform position solution in a hybridised mode,
both using ranging measurements coming from other systems (3A) or hybridising atposition solution level (3B). The hybridisation modes can be of two different types:• Alternative (Alt), when GALILEO is completely not available, or the independent
position solutions that an external system can provide (e.g. UWB or Bluetooth indeep indoor environment) leads to a complete switching to a secondary system
• Hybrid, when the hybridisation of two systems (both at measurement or positionsolution level) can improve the overall performances of GALILEO solution
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 29
Logica
Ranking between different systems is reported in the following tables.Communication Systems Coverage in different environments and GALILEO Augmentation has been characterised by threelevels:�*�: Low Availability�**�: Medium Availability�***�: High Availability
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 30
Logica
A parallel analysis considered Primary and Secondary systems as communication means. Theresults are summarised in the following table:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 31
Logica
Systems Features Communication Service Coverage
R
ange
Peak
Dat
a R
ate
Pric
e
GA
LIL
EO
Aug
men
tatio
n/A
ssist
anc
e
Dee
p In
door
Tun
nel
Lig
ht In
door
Urb
an C
anyo
n
Out
door
Bluetooth 10-100m 1 Mbps 5� (future); 9�(current) 200�
(card)
*** (indoor) *** *** * -
WLAN 10-100m 1-11Mbps(IEEE
892.11b)
100�(PCMCIA)
*** (indoor) *** *** * -
UWB 10m <1Gbps - * (indoor) ** ** - -
DECT 300m 1.152 Mbps >50� **(urban, lowmobility)
- ** *** -
GSM/UMTS Km 9.6 Kbps/2Mbps
100�/300� *** (outdoor,Urban, light
indoor)
- ** *** **
The overall conclusion of the ranking analysis are:1. An integrated GSM or UMTS phone with GALILEO inside implementing hybridisation
(both at ranging at positioning level) for Urban areas and light indoor environment plusBluetooth or WLAN interface used in alternative way in deep indoor (where Bluetoothand WLAN infrastructures are present) environment is the preferred way of hybridisationfor mass market and in-car applications. Augmentation and Applications are wellsupported by that systems integration. This result is obtained both in terms ofperformances and cost of the terminal.
2. S-UMTS systems can be used for augmentation data and multimedia application for ruraland remote areas in case of professional applications
3. TETRA integration can be performed for public interest applications (e.g. police and fire)already using such kind of transmission mean
Application InterfacesAs in the case of CS/UMTS, once a connection has been established, further protocols arerequired to service application layer communications with Galileo. One possible, and likely,scenario is the use of IP and WAP (or similar standardised mark-up language). In addition tothe PSTN interface, TCP/IP is foreseen to be used to facilitate communications with the UserTerminal. Applications on the User Terminal would includes:• A WAP browser or similar• An application framework such as J2ME (Java 2 Micro Edition)• Dedicated SIM applicationsThe WAP communications stack (or similar) provides a method of transporting applicationsand data across the link. Application environments such as J2ME and BREW provide theframework in which the applications may run in order to deliver the relevant Galileo features.Regarding the GSM terminal, it is likely to change significantly by 2008 and it is unlikely thatterminals will operate with the GSM service alone in the future. In order to receive the data anapplication is required to process the contents of a short message. Current developments withJava and BREW (Binary Runtime Environment for Wireless) application engines findingtheir way into the operating systems of handsets seems to indicate that an open standard will
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 32
Logica
be available for running applications that will process such information and perhapsinformation from the Galileo receiver.In order to develop an integrated Value Added Service, the OSA (Open Service Access)model is proposed to be used. The Open Services Access model may be summarised as threelayers that facilitate the interface between the user and their applications. The 3GPPdefinitions includes API to SMS interfaces, User status mapping, etc.. The mechanism thattake place between the framework and a new service is broadly as follows:1. Authentication; the application authenticates with the framework and vice versa. The
application must be authenticated before it may use any other OSA function.2. Authorisation; following authentication, authorisation determines the operations which an
application may perform.3. Discovery; at any time after authorisation the application may use the discovery function
to determine the network service capability features.4. Service agreement; this is an off-line or on-line process which must take place before an
application can interact with a network service capability5. Access; the framework provides access control functions for an application, using service
capability features, with the relevant security level.
Using OSA model, it appears particularly simple to implement a charging mechanism. OSAAPI are recommended to be implemented for the interfacing between OSA framework andthe User. An example of basic steps that could be applied are the following:1. The application creates a local object implementing the IpAppChargingSession interface.
This object will receive response messages from the IpChargingSession object.2. The application orders the creation of a session. No new object is created for the charging
session handling in this example implementation.3. The application requests to charge the user $0.10.4. The payment is acknowledged.5. The acknowledgement is forwarded in the application6. The application releases the session.
Furthermore, in most of the applications typical for the mass market (e.g. personal and roadusers) environment GALILEO Terminal will not have only position calculation functions butwill be also a Multimedia terminal able to receive Location Based Service from dedicatedservice provider. One of the relevant Interoperability aspects with GPRS/UMTS network,refers to the IP Multimedia subsystem (IMS), which highlights and investigates all theelements and procedures necessary to support IP multimedia services in UMTS.Relevant Interoperability interfaces for the GALILEO and UMTS-IMS Application levelinteroperability are:1. At GALILEO User Terminal level: through the implementation of IMS functionalities,
the GALILEO terminal shall be able to receive multimedia services (including LocationBased Services) provided by typical Internet multimedia service provider, MobileOperator, Service Provider for GALILEO related services.
2. At GALILEO system level, GALILEO Local Elements could be interfaced to the S-CSCFof the IP Multimedia subsystem through the UMTS standard ISC interface and thedefined SIP protocol (Session Initiation Protocol). Within this framework, IMS could bealso used for broadcasting of differential correction data in complement to SMSCBservice, for instance for more demanding GALILEO applications (TCAR, VRS, etc.).
Main conclusions about application level interoperability are the following:1. If a Galileo Service Centre is to operate as a service provider, then it is suggested to
implement the interface to connect to OSA framework elements using the OSA API.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 33
Logica
Applications should be implemented to support the API and thus benefiting from thefeatures that provide billing functionality, authentication, and security
2. If the Service Centre is to operate as a content provider then a similarly open standard isrequired. In this case the OSA model would not be suitable. A standard such as XMLwould be applied, given its increased use by government organisations and industry.Application data would be packaged in a relevant XML definition and distributed to thirdparties for use in providing navigation related applications.
3. The content provider model implies the need for a billing solution. Although billing to theend user would be managed by the third party service provider, a method is necessary tocharge the third party an appropriate amount. A flexible billing model, integrated with theXML method of distribution would be most appropriate. Interfaces for off-line and on-line reconciliation should be available, i.e. hard copy billing records should be producedas well as CDR�s of an appropriate format.
4. The USIM Interface should be examined in the context of navigation applications in theUMTS ICD. A SIMToolkit type interface has been defined between the USIM and theMS that allows the exchange of information between them. This interface should beincorporated into the ICD and extended to include navigation specific operations, such assending position data or authentication operations.
5. The Galileo Service Centre ICD should be extended to include a SIP interface for thedelivery of services directly to the user terminal. In addition to this the IETF should beengaged so that the SIP protocol may be extended to include navigation specificoperations such as those described in the previous section. Furthermore, IMS capabilityshould be interfaced by the GALILEO terminal.
Regarding map-matching hybridisation, it has to be pointed out that a vector map covering afew km2 may occupy less than 100 bytes (not including topological data). Such maps may bedownloaded or stored at the terminal and used for hybridisation without the knowledge of theuser, if necessary. Curve to curve matching method, where a number of positions aredetermined tracing a line that is then matched to a similar line in the vicinity. It seems toprovide an adequate trade-off between accuracy and data capacity requirements at theterminal and is therefore recommended for future automotive applications. Map-matchingshould be able to use GTRF reference frame and to integrate GPS positioning expressed inWGS-84 in case of positioning hybridisation.
Action PlanFollowing the study results, an overall action plan for the hybridisation between GALILEOand Non-Nav systems has been developed and it is reported in the following picture.
� Participation to the definition of ETSI-3GPP standards regarding LCS and A-GNSS
� Design of prototypes of GALILEO GSC/LE I/Fs toward GSM for LCS and A-GNSS
� Design of I/Fs of GALILEO GSC/LE I/Fs toward UMTS for LCS and A-GNSS
� Inclusion of GALILEO within NMEA 0183 and NMEA 2000 standards
� Launch of Commercial GALILEO enabled GSMterminals (hybrid NAV and COM)
� Launch of Commercial GALILEO enabled UMTS terminals (hybrid NAV and COM)
� Launch of Commercial LCS and A-GNSS commercial applications based on developed I/Fs
GALILEO FOC
GALILEO
Commercial Applications
2004 2008
DD&V Phase
2002
� Development and Test of interfaces betweenGALILEO prototypes of interfaces betweenGALILEO Local elements/Ground Segments and GSM using availableGALILEO satellites
� Development and Test of GALILEOprototypes of interfaces between GALILEOLocal elements/Ground Segments and UMTS networks using available GALILEOsatellites.
� Use of GSTB and other facilities facilities as a complement for simulation and testing purposes
� Participation to the definition of ETSI-3GPP standards regarding LCS and A-GNSS
� Design of prototypes of GALILEO GSC/LE I/Fs toward GSM for LCS and A-GNSS
� Design of I/Fs of GALILEO GSC/LE I/Fs toward UMTS for LCS and A-GNSS
� Inclusion of GALILEO within NMEA 0183 and NMEA 2000 standards
� Launch of Commercial GALILEO enabled GSMterminals (hybrid NAV and COM)
� Launch of Commercial GALILEO enabled UMTS terminals (hybrid NAV and COM)
� Launch of Commercial LCS and A-GNSS commercial applications based on developed I/Fs
GALILEO FOC
GALILEO
Commercial Applications
2004 2008
DD&V Phase
2002
� Development and Test of interfaces betweenGALILEO prototypes of interfaces betweenGALILEO Local elements/Ground Segments and GSM using availableGALILEO satellites
� Development and Test of GALILEOprototypes of interfaces between GALILEOLocal elements/Ground Segments and UMTS networks using available GALILEOsatellites.
� Use of GSTB and other facilities facilities as a complement for simulation and testing purposes
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 34
Logica
2 INTRODUCTION
2.1 SCOPE OF THE WORK
The present work has to derive the relevant impacts on MRD and SRD document regardingthe interoperability between GALILEO and Non-Navigation systems (e.g. Communication)starting from the MIA phase results and analysing the studies currently developed on thatmatter in order to complement the relevant results and identify drivers for futureimprovements.A Prioritarisation of the systems to be analysed has been performed in order to focus on themost important issues. The following Core Systems issues will be studied in detail:
Secondary Systems will be considered through a limited analysis performed for current andfuture systems for sake of completeness, detailing the main issues and trends relevant for thefuture integration of Navigation and Communication issues:
• Blueetooth• WLAN• UWB• Tetra• DECT
Depending on the constraints and future developments of those systems, different levels ofanalysis will be performed for different levels of interoperability.Communication Satellite Systems will not be considered in this analysis because the maininteroperability constraints are concentrated in Mass Market applications mainly in UrbanAreas environment, where interoperability and integration of different systems is essential inorder to overcome systems availability problems (in particular for E-112 applications).Use of Satellite Communication for Professional Users is well established in the major part ofapplications, where Visibility is not a constraints. The integration of INMARSAT withNavigation terminals for Maritime applications is a well fixed technology and interoperabilityconstraints are light (it is simply an external integration of two separate systems). Only mainissues regarding satellite systems interference will be investigated.
2.2 JUSTIFICATION OF THE WORK
The scope of this report is to analyse the Non Nav Systems that are the best candidates to beinteroperable with GALILEO, to identify and analyse the relevant interfaces for eachinteroperability level and evaluate the impacts on HLD and MRD documents. The work to bedeveloped will be performed following the steps hereinafter reported and mapped to the TableOf Contents of the dd081 document:
1. Review of the MIA phase results:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 35
Logica
MIA results will be reviewed, analysing important points that have not beenemphasised during MIA, as possible interoperable systems and interfaces andcorrespondent interoperability requirements
2. Identify System Interfaces at terminal and Systems level (e.g. terminal interfacebetween Navigation and communication parts, Architectural elements of GALILEOinterested by the interoperability with Non-Nav systems, as GSM/UMTS BSS-MSC)
3. Identify the impacts on the on HLD and MRD documents.4. Interfacing Requirements for each Interoperability level:
Interoperability Requirements for Non-Nav systems/terminals able to satisfyApplications needs will be derived.
The analysis is performed following three different scenarios: co-existence, alternative use,combined use.
Added Value for GALILEO MRD and SRD
This document will provide better details on the following section of GALILEO HLD andMRD documents.
High Level Document:• Par. 2.2 Local Components: identify the needed Interfaces and Architectural impacts on
Non-Nav and GALILEO systems for the implementation of Enhanced Positioning systemusing GSM/UMTS Mobile Networks. Network Assisted Navigation techniques will beparticularly here examined.
• Par. 2.7: Interoperability with Complementary systems: interfaces with Non-Nav systemswill be detailed
• Par. 3.3: Navigation related communication Services: interoperability requirements anddefinition of the best candidates systems for implementation of NRS
Mission Requirements Documents• Par. 3.1.3: Navigation Related Services and SAR:
o Definition of the commercial requirements for the implementation of NRS (e.g.MR-311), taking into account the transition plan analysed during the current work
o Definition of Best candidates systems and related requirements for theimplementation of NRS
• Par. 3.8: Navigation Related communication Services Requirements: review of MRDrequirements; feasibility analysis results will verify the provided requirements, updatethem and provide new ones if necessary
• Par. 4.4. User Terminals Requirements: identification of the best cost effective solutionsand requirements for the implementation of integrated Navigation and communicationterminals and relevant interface requirements at RF, receivers and terminal levels
• Par- 6.3.2: GALILEO-Wireless Communication systems combined services:interoperability and Architectural impacts analysis results
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 36
Logica
System Requirements DocumentImpacts on Par. 5.2.11, Par. 6.2.3 and SAR general interfaces
Projects whose results are used as input• EMILY
Projects who will profit from the results• EMILY• INSTANT Pilot Project if it will start in time• POLARIS Pilot Project• GALLANT Pilot Project
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 37
Logica
3 REFERENCES
3.1 DEFINITIONS
Location Estimate: the geographic location of an MS and/or a valid ME, expressed inlatitude and longitude data. The Location Estimate shall be represented in a well-defineduniversal format. Translation from this universal format to another geographic locationsystem may be supported, although the details are considered outside the scope of theprimitive services.
Mobile Assisted positioning: any mobile centric positioning method (e.g. E-OTD, GPS) inwhich the MS provides position measurements to the network for computation of a locationestimate by the network. The network may provide assistance data to the MS to enableposition measurements and/or improve measurement performance.
Mobile Based positioning: any mobile centric positioning method (e.g. E-OTD, GPS) inwhich the MS performs both position measurements and computation of a location estimateand where assistance data useful or essential to one or both of these functions is provided tothe MS by the network. Position methods where an MS performs measurements and locationcomputation without network assistance data are not considered within this category.
E-OTD Assistance Data Message: E-OTD Assistance Data contains the RTD and BTScoordinates of the neighbours that should be used in E-OTD measurements. This E-OTDAssistance Data is broadcasted using CBCH channel using SMSCB DRX service. Thereception of this broadcast message enables MS to calculate its own location.
LCS Client: software and/or hardware entity that interacts with a LCS Server for the purposeof obtaining location information for one or more Mobile Stations. LCS Clients subscribe toLCS in order to obtain location information. LCS Clients may or may not interact with humanusers. The LCS Client is responsible for formatting and presenting data and managing theuser interface (dialogue). The LCS Client may reside in the Mobile Station (UE). The LCSClient may reside inside or outside the PLMN.
LCS Server: a software and/or hardware entity offering LCS capabilities. The LCS Serveraccepts requests, services requests, and sends back responses to the received requests. TheLCS server consists of LCS components, which are distributed to one or more PLMN and/orservice provider.
LCS (LoCation Services): LCS is a service concept in system (e.g. GSM or UMTS)standardization. LCS specifies all the necessary network elements and entities, theirfunctionalities, interfaces, as well as communication messages, due to implement thepositioning functionality in a cellular network. Note that LCS does not specify any locationbased (value added) services except locating of emergency calls.
Location Based Service (LBS): service provided either by teleoperator or a 3 rd partyservice provider that utilizes the available location information of the terminal. Location
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 38
Logica
Application offers the User Interface for the service. LBS is either a pull or a push type ofservice (see Location Dependent Services and Location Independent Services).
Positioning method (/locating method): principle and/or algorithm, which the estimation ofgeographical location is based on, e.g. AOA, TOA, and TDOA. For example, GPS is basedon TOA, whilst OTDOA and E-OTD (on GSM) are based on TDOA
Positioning technology (/locating technology): technology or system concept including thespecifications of RF interfaces, data types, etc. to process the estimation of a geographicallocation, e.g. GPS, E-OTD (GSM), and OTDOA (WCDMA)
Standalone A-GPS SMLC (SAS): A logical node that interconnects to the RNC over theIupc interface via the PCAP protocol. This node provides GPS related data to the RNC, andmay perform the position calculation function.
Two way packet data service: This two way data service provides point-to-point datatransmission. As it uses the concept of a virtual circuit that may be established for a wholesession with out tying up network capacity, individual messages may be sent with no call set-up delay. It is therefore particularly useful when small messages are sent on a frequent basisor when a rapid delivery is required.
Two way circuit data service: The two-way circuit data service provides two-way, point-to-point data transmission capability. As physical network capacity is used for the duration of aconnection, connections are generally only established for the minimum duration necessary.The time taken to set up an individual connection is often of the order of 20 seconds and sothis service is more suitable for the transmission of large amount of data on a batch basis orfile transfer basis. When suitable file transfer protocols are used, error free file transfer ispossible.
Position Accuracy: Position accuracy performance is expressed as an error in metres and anassociated statistical value (95%). The error in metres is the difference between the trueposition, expressed in geodetic co-ordinates, and the radius of a circle that encloses 95% ofthe position estimates indicated by the GNSS terminal. The accuracy performance is verifiedby measurement at many points within the geographic area where service coverage isspecified.
Position Availability: Service availability is the percentage of the time that the system isoperating satisfactorily, e.g. the user terminal provides the required levels of accuracy andintegrity. Unavailability arises from apparently random unpredictable factors. It is measuredover a long time period (a month or more) in a local environment that is representative of thatnormally encountered. Furthermore, it is measured at the worst geographic point (specified inlatitude and longitude) within the coverage region of interest to the end user.
Position Integrity: Integrity is defined as the ability of a system to provide timely warningsto users when the system should not be used for the purpose for which it is intended. It is thelack of accuracy, in other words an accuracy failure, which normally prevents the systembeing used for the purpose for which it is intended. Hence, the term �integrity of accuracy�.Integrity is specified in terms of the following parameters (given a specified accuracyparameter):
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 39
Logica
� Time to alarm (TTA): the time that elapses between the reception by the user ofhazardously misleading information and the reception of a �don�t use� warningmessage.
� Integrity risk or Probability of HMI (Hazardously Misleading Information). This isthe probability that the GNSS terminal provides information which is incorrect in amanner that may result in a hazard to service users.
� Alarm limit: the position error (i.e. accuracy in metres) that should result in an alarmbeing generated.
Continuity: Continuity is defined as the probability that a system will provide the specifiedlevel of navigation accuracy and integrity throughout an operation of a specified period, giventhat navigation accuracy and integrity are available at the start of the operation.
3.2 ACRONYMS
AFTN Aeronautical Fixed Telecommunication NetworkANM Answer Message (ISUP)API Application Protocol InterfaceA-GPS Assisted GPSAS Application ServerBREW Binary Runtime Environment for WirelessBSC Base Station ControllerBSS Base Station SubsystemBTS Base Transceiver StationBSSAP-LE BSSAP LCS Extension for Lb, Lp and Ls interfacesBSSLAP BSS LCS Assistance ProtocolBSSMAP-LE BSSMAP LCS ExtensionBREW Binary Runtime Environment for WirelessCAMEL Customised Application Mobile Enhanced LogicCC SCCP Connection ConfirmCDR Call Data RecordsCN Core NetworkCS Circuit SwitchedPS Packet SwitchedCSC COSPAS SARSAT CouncilCSCF Call section Control FunctionCR SCCP Connection RequestCREF SCCP Connection RefusedDND Department of National Defence (Canada)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 40
Logica
DGPS Differential GPSDT1 SCCP Data Form 1 messageELT Emergency Locator Transmitter (aeronautical distress beacons)
EPIRBEmergency Position Indicating Radio Beacon (maritime distress
beacon)FEC Forward Error Correction
GEOSARGeostationary Earth Orbit Search and Rescue (satellite system at
406 MHz)GPRS General Packet Radio ServiceHSS Home Subscriber SegmentIAM Initial Address Message (ISUP)ICAO International Civil Aviation OrganizationI-CSCF Interrogating-CSCFIMO International Maritime OrganizationIETF Internet Engineering Task ForceIMS IP Multimedia SubsystemJ2ME Java 2 Micro EditionLEOSAR Low Earth Orbit Search and Rescue (satellite system in polar orbit)LIR Location Immediate RequestLDR Location Deferred RequestLCF Location Client FunctionLBS Location Based ServicesLCS LoCation ServicesLCCF Location Client Control FunctionLCAF Location Client Authorization FunctionLCCTF Location Client Coordinate Transformation FunctionLLP LMU LCS ProtocolLMMF LMU Mobility Management FunctionLMU Location Measurement UnitLOS Line Of SightLSCF Location System Control FunctionLSAF Location Subscriber Authorization FunctionLSPF Location Subscriber Privacy FunctionLSBcF Location System Broadcast FunctionLSBF Location System Billing FunctionLSOF Location System Operations FunctionLUT Local User Terminal (COSPAS SARSAT ground receiving station)MCC COSPAS SARSAT Mission Control CentreME Mobile EquipmentMO-LR Mobile Originating Location Request
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 41
Logica
MS Mobile StationMT-LR Mobile Terminating Location RequestMLC Mobile Location CentreMSC Mobile Switching CentreNI-LR Network Induced Location RequestNLK Network Location KnowledgeNLOS Non-Line Of SightNOAA National Oceanic and Atmospheric Administration (USA)OSA Open Service ArchitecturePRAF Positioning Radio Assistance FunctionPRCF Positioning Radio Coordination FunctionPCF Positioning Calculation FunctionPCSCF Proxy CSCFPSMF Positioning Signal Measurement FunctionRA Rate AdaptationREL Release (ISUP)RLC Release Complete (ISUP or SCCP)RLP Radio Link Protocol (GSM 04.22)RLSD SCCP Released messageRNC Radio Network ControlRRLP RR LCS Protocol to a target MS (defined in GSM 04.31)RTD Relative Time DifferenceSAR Search and RescueSARP Search and Rescue ProcessorSARSAT Search and Rescue Satellite-Aided TrackingSAS Stand-Alone A-GPS SMLCSCSCF Service CSCFSGSN Serving GPRS Support NodeSLPP Subscriber LCS Privacy ProfileSMLC Serving Mobile Location CentreSMLCPP SMLC Peer Protocol (messages on Lp interface in GSM 08.31)SIP Session Initiation ProtocolSPOC SAR Point of ContactSRNC Service Radio Network ControlSRR Search and Rescue RegionTA Timing Advance (between an MS and its serving BTS)TOA Time of ArrivalUE User EquipmentUT User Terminal
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 42
Logica
UDT SCCP Unit data messageVMSC Visited Mobile Switching Centre
3.3 APPLICABLE DOCUMENTS
A [1] Complementary Systems: Functions and Performance, GALILEIA [2] ETSI TS 101 724 V 8.4.0A [3] ETSI TS 101 527 V 8.8.0A [4] 3GPP TS 04.35 V 8.4.0A [5] TS 122.105 (V4.3.0): " Universal Mobile Telecommunications System (UMTS);
Service Aspects, Services and Service capabilities".A [6] GALILEO High Level Document - Issue 2A [7] GALILEO Mission Requirements Document - Issue 4A [8] GALILEO System Requirements Document - Issue 2A [9] GALILEO Interface Control Document - Draft 4A [10] Systems Interoperability Analysis - Receiver Issues for Navigation and Non
Navigation Systems - NAV/02/004621-00BA [11] GALILEI - Annex on GNSS simulations to DD-080A [12] ETSI TS 123 228 v 5.5.0 Release 5A [13] ETSI 3GPP TS 23.002A [14] ETSI TS 23.060 3GPP TS 23.060A [15] ETSI TS 125 305A [16] ETSI TS 125 331A [17] ETSI TS 123 171A [18] ETSI TS 125 453
3.4 REFERENCED DOCUMENTS
R [1] EMILY Project, External Review presentationR [2] Multimodal Interoperability Analysis for Personal Users, DD075, version 2.0,
18th April 2002.R [3] BTS Synchronisation Requirements and LMU update rates for E-OTDR [4] Evaluation of TDOA Techniques of TDOA Techniques for Position Location in
CDMA Systems, Muhammad Aatique, Master Thesis, Virginia PolytechnicInstitute and State University
R [5] A Data Fusion Architecture for Enhanced Position Estimation in WirelessNetworks, Thomas Kleine-Ostmann, Amy E. Bell, IEEE Communication letters
R [6] The Use of weighted RMS function to reliably represent the distribution oflocation measurements, J. Brice, T1P1.5/99-389
R [7] Introduction to the COSPAS SARSAT System, Issue 5 - Revision 1, October1999, 675
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 43
Logica
R [8] COSPAS SARSAT Glossary, Issue 1 - Revision 4, October 1999R [9] COSPAS SARSAT Guidelines on 406 MHz Beacon Coding, Registration and
Type Approval, Issue 2 - Revision 1, October 1999R [10] Specification for COSPAS SARSAT 406 MHz Distress Beacons, Issue 3 -
Revision 3, with Corrigendum 1, October 1999R [11] COSPAS SARSAT Local User Terminal Performance Specification and Design
Guidelines, Issue 3 - Revision 1, October 1999R [12] Description of the Payloads Used in the COSPAS SARSAT LEOSAR System -
Issue 3 - Revision 1, October 2001R [13] COSPAS SARSAT LEOSAR Space Segment Commissioning Standard, Issue 1 -
Revision 3, October 2001R [14] COSPAS SARSAT LUT Commissioning Standard, Issue 2 - Revision 1, October
October 1999R [20] Description of the 406 MHz Payloads Used in the COSPAS SARSAT GEOSAR
System, Issue 1 - Revision 3, October 2001R [21] COSPAS SARSAT GEOSAR Space Segment Commissioning Standard, October
2001R [22] COSPAS SARSAT Data Distribution Plan, Issue 4 - Revision 4, June 2001R [23] COSPAS SARSAT Mission Control Centres Standard Interface Description,
Issue 4 - Revision 4, June 2001R [24] COSPAS SARSAT System Monitoring and Reporting, Issue 1 - Revision 8,
October 2001R [25] COSPAS SARSAT System Exercising, Issue 1 - Revision 1, June 1998R [26] COSPAS SARSAT Mission Control Centre Performance Specification and
Design Guidelines, Issue 3 - Revision 1, October 2001R [27] COSPAS SARSAT Mission Control Centre Commissioning Standard, Issue 2 -
Revision 4, October 1999R [28] 1990 Exercise of the COSPAS SARSAT 406 MHz System, October 1992R [29] Annex C to COSPAS SARSAT Report on System Status and Operations No. 17
(Jan - Dec 2000), October 2001R [30] Summary Report of the 406 MHz Geostationary System Demonstration and
Evaluation, October 1999R [31] COSPAS SARSAT Phase-Out Plan for 121.5/243 MHz Satellite Alerting
Services, Issue 1 - Revision 1, October 2001
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 44
Logica
R [32] Procedure for the Notification of Association with the International COSPASSARSAT Programme By States Non-Party to the COSPAS SARSAT Agreement,December 1992
R [33] Guidelines for Participating in the COSPAS SARSAT System (Issue 3), April2000
R [34] Handbook of Regulations on 406 MHz and 121.5 MHz Beacons, August 2001R [35] System Data Document No. 27, December 2001R [36] SARGAL � Executive Report, Version 1.1, 9.2.2001 (including 7 Annexes)R [37] GLORIA (IST 1999-20600) - D4 �Intermediate Testing Report�, July 2001R [38] GALILEO System Requirements Document - ESA-APPNS-REQ-0001R [39] Réseaux GSM - 5e édition revue et augmentée - Xavier Lagrange, Philippe
Godlewski, Sami Tabbane - Hermes Science PublicationsR [40] Radio transmission and reception (Release 5) - 3rd Generation Partnership
Project; Technical Specification Group GSM/EDGE; Radio Access Network - 3GPPTS 45.005 V5.2.0 (2001-11)
R [41] UE Radio Transmission and Reception (FDD) (Release 5) - 3rd GenerationPartnership Project; Technical Specification Group Radio Access Networks - 3GPPTS 25.101 V5.2.0 (2002-03)
R [42] UE Radio Transmission and Reception (TDD) (Release 5) - 3rd GenerationPartnership Project; Technical Specification Group Radio Access Networks - 3GPPTS 25.102 V5.0.0 (2002-03)
R [43] BS Radio transmission and Reception (FDD) (Release 5) - 3rd GenerationPartnership Project; Technical Specification Group Radio Access Networks - 3GPPTS 25.104 V5.2.0 (2002-03)
R [44] BS Radio transmission and Reception (TDD) (Release 5) - 3rd GenerationPartnership Project; Technical Specification Group Radio Access Networks - 3GPPTS 25.105 V5.0.0 (2002-03)
R [45] Bluetooth Specification version 1.1; www.bluetooth.comR [46] Radio Equipment and Systems (RES), Wideband transmission systems, Technical
characteristics and test conditions for data transmission equipment operating in the2.4 GHz ISM band and using spread spectrum modulation techniques - EuropeanTelecommunication Standard - ETS 300 328 - November 1996 - Second Edition
R [47] �Kalman Filtering Techniques � Mission Planning and Analysis Division�,September 1985, NASA, Jonhson Space Center, William M.Lear
R [48] System Architecture Definition Report, Deliverable D6, EMILY Project, April2002
R [49] Open Service Access API Part 12 � Charging, 3GPP 29.198-12R [50] Digital Enhanced Cordless Telecommunications (DECT); Common Interface
(CI); Part 2: Physical Layer (PHL) - European Standard (Telecommunications series)- ETSI EN 300 175-2 V1.6.1 (2001-08)
R [51] Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 2: AirInterface (AI) - European Standard (Telecommunications series) - ETSI EN 300 392-2 V2.3.2 (2001-03)
R [52] Understanding GPS: principles and applications. Elliott D KaplanR [53] Innovative GNSS2 navigation signal, M. Monnerat, ASPI
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 45
Logica
R [54] ARINC 743 AR [55] RTCA DO-235, Assessment of Radio Frequency Interference Relevant to the
GNSSR [56] Interference of GPS signals: Influence of licensed transmitters on the GPS signal
quality in the Netherlands� Airspace. F Klinker. OBM PietersenR [57] An evaluation of the Radio Frequency Susceptibility of Commercial GPS
Receivers. IEEE AES Systems Magazine, October 1994. JK Daher � JM Harris � MLWheeler
R [58] GSM ETSI TR 101 115 v8.2.0 (2000-04)R [59] GPS risk assesment study � The Johns Hopskins University (1999-01)R [60] Bluetooth/802.11 and aviation - Intel corporation (2001-08)R [61] DO-246A, GNSS Based Precision Approach Local Area Augmentation System
(LAAS) - Signal-in-Space Interface Control Document
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 46
Logica
4 MIA RESULTS SUMMARY
In this paragraph the summary of the MIA results are reported. In the first subparagraph abrief summary of the relevant MIA phase outputs is given with the aim to clearly fix thestarting point of the Interoperability analysis between GALILEO and Non Nav systems. Inthe second subparagraph the identified and prioritised set of candidate interoperable Non Navsystems are presented with their Interoperability requirements and Interoperabilityconstraints.
4.1 CONSEQUENCES OF THE MIA ANALYSIS
The object of MIA has been to identify and prioritise a set of candidate interoperable systemsand respective Interoperability requirements and constraints for use in this SystemInteroperability Analysis phase. MIA phase has addressed five key multimodal sectors(Personal Users, Road, Rail, Maritime and Aviation) and has adopted two differentviewpoints:
• Interoperability analysis from the application viewpoint, looking at the five identifiedapplications sectors
• Interoperability analysis from the Receiver viewpoint
The MIA analysis basic procedure was organised as follows:
• For each application sector, IORs and IOCs have been established and allocated toInteroperability Topics and Levels; assessment of IORs against IOCs andidentification of the degree of constraint have been performed
• A similar work has been performed from the Receiver point of view. This analysis cutacross the application sectors to identify requirements from a receiver perspective.Although this approach is application sector-independent, it identified a series ofreceiver classes that mapped to the Application sector as well as to the IO Levels
• All IORs and IOCs have been cleaned-up, filtered, re-mapped and consolidated in theIO analysis. Furthermore, the consolidated IORs have been ranked and the prioritisedsystems sorted and extracted. The sorting procedure has been performed followingthree different criteria: Receiver priorities; Application sector priorities (assignedfrom each expert organisation concerned); Relevance to the GALILEO baseline.
Summary Issues and relevant systems, for each application sector, are reported in thefollowing:
AviationAs far as the aviation application sector is concerned, the relevant candidate systems forinteroperation with GALILEO include mainly navigation systems and only few NonNavigation systems have been identified and reported in the IORs table extracted from theMIA results.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 47
Logica
MaritimeIn the maritime sectors, as for the aviation sector, the interoperability between GALILEO andsecond-third generation Telecom Systems (GSM, UMTS) do not seem an opportunity to befurther explored due to the coverage of these systems (populated areas on land).Interoperability between GALILEO and COSPAS SARSAT system is the relevant option tobe investigated.
RailNo relevant issues come out from this application sector concerning the interoperabilitybetween GALILEO and Non Nav systems.
RoadDue to the GNSS system drawbacks in terms of availability of needed positioningperformances, especially in urban areas (e.g. multipath effects, signal shadowing�),interoperability between GALILEO and Non Nav systems is considered to be essential in thissector. For those applications with a low signal loss tolerance threshold, interoperability withmap matching algorithms and additional sensors (e.g. gyroscopes and odometers) could beuseful to overcome satellites shadowing problems.In the Road market sector, second- third generation Telecommunication systems (e.g.GSM/UMTS) are identified as a great interoperability opportunity. Interoperability with thesesystems can be analysed from different perspective:
• GSM/UMTS considered as communication systems for bearing of value addedservices data for location based services (e.g. info-mobility market)
• GSM/UMTS considered as communication systems for bearing of navigationapplications related data (e.g. Maps).
• GSM/UMTS considered as ranging sources (TOA) to be hybridised with GNSSranges.
• GSM/UMTS considered as positioning systems (network based positioning: Cell Id +TA, EOTD�) whose position can be hybridised with the GALILEO positionsolution.
• GSM/UMTS considered as communication systems for bearing of aiding data fornetwork assisted navigation solutions.
Personal UsersAs for the Road market sector, in the Personal Users sector, interoperability betweenGALILEO and second- third generation Telecommunication systems is essential. Followingthe US regulation concerning the mobiles emergency calls (E911) and the promising LBSmarket grow in the near future, interoperability between GSM/UMTS systems and GNSS willbe the relevant issue in order to:
• Provide Location Based Services related information• Provide Navigation applications related data• Guarantee the required navigation performance level also in the typical critical
environment for GNSS navigation (urban canyon, indoor):
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 48
Logica
1. GSM/UMTS considered as ranging sources (TOA) to be hybridised withGNSS ranges.
2. GSM/UMTS considered as positioning systems (network based positioning:Cell Id + TA, EOTD�) whose position can be hybridised with the GALILEOposition solution.
3. GSM/UMTS considered as communication systems for bearing of aiding datafor network assisted navigation solutions.
In the IORs table the relevant prioritised candidate systems and the relative interoperabilityrequirements are reported in terms of technical, operational and economic requirements.Interoperability between GALILEO and COSPAS SARSAT system is another option to beinvestigated for SAR personal user applications.
ReceiverAs far as the Terminal/Receiver aspects are concerned, interoperability at different levelsbetween GALILEO and GSM/UMTS systems should lead to:
• Communication devices delivering a large range of location based services (LBS,emergency call) by means of integrated communication and navigation capabilities.Network based pseudorange/positioning-solutions hybridisation (IOL 3; e.g. EOTD,OTDOA) or GNSS network assisted solutions (IOL 2/4) could be useful to guaranteethe suitable performances also in urban canyon and indoor environment.
• Stand alone GNSS devices whose performances could be augmented/complementedby means of telecommunication networks assistance (Assisted GNSS, DGNSS). TheInteroperability analysis between GALILEO and GSM/UMTS systems is, in thiscase, at level 2/4.
In the relevant cases of handheld devices, important design constraints to be taking intoaccount in the IO analysis are power consumption, weight, size and cost.
The final stage of the Interoperability Analysis was to prioritise the systems so as to promotea core set of systems for investigation by SIA Non Nav branch. The results of this processhave been captured as follows:
Based upon a figure of merit calculated for each system (DD070), the following arerecommended as the core systems or system classes for investigation by SIA phase among theInteroperability Options (IOOs).Sorted by priority, the promoted Non-Nav systems for interfaces are:
• GSM• UMTS• All RF Interfaces• Digital Maps
The other systems interfaces for which there were high-ranking requirements but a low figureof merit were:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 49
Logica
• Bluetooth (Short Range Communications)• SAR Systems (Cospas-Sarsat)
4.2 LIST OF MIA REQUIREMENTS
The final stage of the Interoperability analysis was to prioritise the systems in order topromote a core set of systems for investigation by SIA. The results of this process is resumedin the following tables which include all the Interoperability requirements organized onsystem basis and sorted by both receiver and sector priority criteria.Each promoted system is discussed below following a standard format:
• Brief introduction describing the system and maybe some context.
• Interoperability extracts selected from among the CTM entries for that system.
• Summary of key points for further consideration.
Tables have been used to present the extracted Interoperability Requirements (IORs) for eachsystem.
The entries have been selected on the basis of their Application Sector and ReceiverRankings. Thus, entries ranking low on both Sector (i.e. 4 or less) and Receiver (i.e. L =Low) have been excluded. The rankings are included in the table.
The entries have been sorted on the Interoperability Levels (IOL1 � IOL4) to which theyapply. The order is prioritised by level, thus IOL 1 first and IOL 4 last.
Other information provided in the table is the IOR ID, title, topic, type and applicable sectors(including Receiver). More details are reported in the MIA phase document.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 50
Logica
GSM
Table 4-1GSM IORs sorted by IO Level selected by Sector (4-7) & Receiver (H)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 51
Logica
UMTS
Table 4-2_UMTS IORs sorted by IO Level selected by Sector (4-7) & Receiver (H)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 52
Logica
ALL RF INTERFACES
Table 4-3_All RF Interfaces IORs sorted by IO Level selected by Sector (4-7) &Receiver (H)
DIGITAL MAPS
Table 4-4_Digital Maps IORs sorted by IO Level selected by Sector (4-7) & Receiver
AUGMENTATION SYSTEMS
Table 4-5_Augmentation Systems IORs sorted by IO Level selected by Sector (4-7) &Receiver (H)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 53
Logica
BLUETOOTH
Table 4-6_Bluetooth IORs sorted by IO Level selected by Sector (4-7) & Receiver (H)
SAR SYSTEMS
Table 4-7_SAR Systems IORs sorted by IO Level selected by Sector (4-7) & Receiver(H)
EXTERNAL AIDS
Table 4-8_External Aids IORs sorted by IO Level selected by Sector (4-7) & Receiver(H)
POTENTIAL IMPACT ON GALILEO BASELINE
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 54
Logica
Table 4-9 Non Nav system interfaces: Baseline Requirements sorted by Identity
4.3 RECOMMENDATIONS FROM MIA
Issues that are recommended for further consideration in the SIA Interoperability Analysisbetween GALILEO and Non Nav Systems are:
� The length of Galileo codes and bandwidth of signals should be considered tominimise the effect of multipath and RF interference from different sources.
� One observation from the analysis of IORs was that there did not appear to be anyrequirements related to time-based systems, even though there were timing relatedrequirements. GPS is already widely used for the purpose of supporting time-relatedapplications, for instance within the aviation community. It may be that no similarrole is foreseen for Galileo or that it is not considered a significant interoperabilityissue by any of the Application Sectors. However, it is recommended that subsequentanalyses consider the issue of interoperability with time-based systems andapplications.
� The update of RTCM SC 104 should be encouraged to ease the extension of currentlocal and commercial DGPS services to include Galileo, since these may be the basisfor high performance services.
� Systems at Level 3 are interfaced at present by using the NMEA 0183 or NMEA2000 protocols. These should be updated to full compliance with all Galileo services.
� Compatibility with SAR should be ensured for all Galileo service levels.
� Legal Issues:Privacy of location of user.Liability for location/data errors.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 55
This chapter aims at:• Investigating the interoperability between GALILEO and Non-Nav systems at the RF
processing level• Identifying the main factors impacting interoperability with the co-existence scenario• Providing recommendations and evaluating impacts on MRD/SRD Phase B2 from the
performed analysis, for the refinement of GALILEO baseline
5.1 DESCRIPTION OF THE FUNCTIONS AT THIS LEVEL
Our contribution to the global study is made at IOL1, defined as the RF processing level. Thislevel acquires the SIS in various environments and produces sampled signal for digitalprocessing. This IOL includes analogue and digital components, as explained on thefollowing Figure 1.
Figure 1 : Limits of the RF part in the receiver
NB: I,Q in-phase and quadraphase samples of the input signal, Fr reference frequency
5.1.1 APPLICABLE DEFINITIONS OF INTEROPERABILITY AT IOL1
The four definitions of interoperability given in A[7] are not all applicable to the study.
The non-applicable one is the following:• Two systems are considered Interoperable if they can be used independently to fulfil the
same task creating consistent results: navigation and non-navigation systems do notfulfill the same task.
The applicable ones are the following:
ADC AGC
FDAF I
Q
I
Q
Synthesiser Fr
SIS
Limits of the RF part
AGC control
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 56
Logica
• Compatibility is the non-interference in operation between any two systems.• Two or more systems are said to exhibit interoperability if one system provides an
advantageous function in some context when used in conjunction with the other.• Independence is the property of two or more system that operate together, each supplying
a result, in such a way that failure of one system does not result in failure of the other.
5.1.2 IOL1 INTERFACES AND MAIN FUNCTIONALITY
5.1.2.1 SIS interface with IOL1
The signal in space interface considered in our study are composed of the GALILEO SIS andthe following non-navigation systems (cf WP description):• GSM/GPRS• UMTS• Bluetooth• WLAN• DECT• TETRA
5.1.2.2 IOL1 interface with IOL2
The only interface in the receiver is between IOL1 and IOL2.
As shown on Figure 1, it is composed of:• High rate Sampled signal produced towards level 2• Reference clock for digital processing towards level 2
5.1.2.3 Main functionality of IOL1
The main functionality of IOL1 is explained through its components:• Antenna: SIS is acquired through an adapted antenna that realises a first level of filtering.
This antenna may be powered or not by the RF unit (the receiver shall provide apreamplifier power only for active antennas).
• Pre-filter/Preamplifier: SIS is first pre-filtered and pre-amplified at the input of thereceiver in order to enable hardware signal processing.
• RF/IF down-conversion: SIS is down-converted in one or two steps to frequencies thatallow its sampling for digital processing.
• IF filtering and IF amplifier: Useful SIS is extracted through IF filtering and amplified ata level matching the A/D converter.
• A/D conversion: SIS is digitised.• AGC: The sampling process includes generally automatic gain control loops to adapt
digital conversion parameters with the level of signals.• Frequency synthesiser provides the different frequencies useful for down-conversion
process.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 57
Logica
• Clock provides the reference time source for the driving of frequency synthesiser.• Optionally: Signal processing such as blanking, FDAF but this study is not the aim of our
work-package.
5.1.2.4 Others possible functionality of IOL1
• Antenna pattern control: This function dynamically increases the signal to jammer ratio.This function is not included in our work-package.
• Antenna cancelling: This function accomplishes the cancelling of one jammer. Severaljammers may be eliminated with a more complex solution but from a Civil point of view,the cases with several jammers is rare and if it exists, it does not significantly disturb thesystem for a long period.
5.1.3 DETAILED ANALYSIS SYSTEM INTERFACES
5.1.3.1 Propagations Equations
Most of the hypotheses to be taken for the signal-in- space are given in A [9]. The aim of thissection is to add the mathematical model to determine the received power. The signal-in-space power is attenuated by free-space loss and GALILEO receiver antenna gain. The linkbudget, between the emitter and the receiver, is the following:
Preceived: Power received in the receiver (after antenna)EIRP: Emitted Isotropic Radiated PowerGantenna_emitter: Antenna gain of the emitterLtransmission: Transmission lossesLfree-space_losses: Free-space lossesLdiffraction: Diffraction lossesGantenna_receiver: Antenna gain of the receiverλ: Wavelengthd: Distance between the receiver and the emitter
In our case, diffraction losses are negligible because antennas are in direct view.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 58
Logica
In addition, we take an antenna gain of 0dB for the GALILEO receiver. This is a realistichypothesis for marine, rail and road but pessimistic for aeronautics. The antenna gain for thenon-navigation emitter is already taken into account in the emission power given in thisdocument.The free-space loss equation mathematical model is representative for d>>λ.
5.1.3.2 CW interference
A CW interference can disturb or not GALILEO receiver. It depends on its frequency.First, it is important to outline that the spectrum of the GALILEO signal is not continuous inthe useful bandwidth. It is composed of line components spaced at 1kHz, because of the 1-mscode period on E5a, E5b and L1. If the CW frequency is at the exact frequency of a linecomponent of the GALILEO signal, the interference can �pass through correlation� anddegrade the post-correlation signal to noise ratio.If the CW frequency is not at the frequency of a line component of the GALILEO signal, theinterference is �unnoticed by correlation�.With the non-navigation systems hereinafter specified, there is little chance that this type ofinterference will disturb useful GALILEO signal.
5.1.3.3 NB interference
The same as CW case, it is important to outline that the spectrum of the GALILEO signal isnot continuous in the useful bandwidth. It is composed of line components spaced at 1kHz,because of the 1-ms code period on E5a, E5b and L1.Assuming NB interference (bandwidth>1kHz), each line component spread the interference.Then, the post-correlation signal to noise ratio can be modelled by the following equation:
c
Beq
sQRj
cnn
c
+=
00
1 (R[52])
with c carrier power, Bn0 thermal noise power density, s signal power, j jammer power, Qspread spectrum processing gain adjustment factor, Rc code chipping rate and
eqn0 equivalent
noise power density in the receiver.The gain adjustment factor Q is comprised between 1 and 2: 1 for a jammer with a 1kHz-bandwidth, 2 for a wideband Gaussian jammer.For our contribution, the dimensioning cases are for Q=1 with NB interference and Q=2 withWB interference. Indeed, the standards precise a maximum bandwidth for NB interferencebut a thinner spectrum is possible: 1kHz is then the dimensioning case. Otherwise thestandard gives the possibility of having several signals with NB spectrum side by side at thesame time: the dimensioning case is thus a wideband interference. These hypotheses will beconfirmed for each interference.The jammer power can be expressed as follows:
scwithnnc
sRj Beqc ≈−= )( 00
or
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 59
Logica
)/1
/1(
00 Beqc ncnc
sRj −=
5.1.3.4 WB interference
With an interference with a bandwidth higher than useful signal bandwidth, the signal to noiseratio can be modelled by the following equation:
JBeq nnc
nc
000 += , (R[15])
with c carrier power, Bn0 thermal noise power density, Jn0 noise power density of theinterference and
eqn0 equivalent noise power density in the receiver.
This equation is compatible with the equation given in 5.1.3.3 with Q=2 and a jammerbandwidth equal to the useful signal bandwidth.The jammer power density can be expressed as follows:
Beqj nnn 000 −=
5.1.3.5 Pulsed interference
• Long pulses are seen as continuous interference from the receiver if their duration ishigher than 1s. Short pulses are clipped by the ADC or blanked depending of the receiverdesign.
• With a blanking technique, the signal to noise degradation is given by the followingformulae:
�+−
−=
NBJeqPeak
WI
WIeq PRFTPKn
Bdc
Bdcnc
nc
0
2
00 11
)1(* , (R[53])
with c carrier power, eq
n0 equivalent noise power density in the receiver, WIn0 noise powerwithout interference, Bdc blanking duty cycle, K interference coefficient, Ppeak peak power ofthe interference, PRF Pulse repetition frequency and NBJ Non-blanked jammer.
In case of powerful interference, all the interference have a power above the blankingthreshold and the formulae can be reduced to the following:
( )WIeq n
cBdcnc
00
1 ∗−=
with c carrier power, eq
n0 equivalent noise power density in the receiver and Bdc blankingduty cycle.
5.1.3.6 Special aspect of interference
An intermodulation product is created if two interference signals are received at the sametime. Depending on the design/strategy/cost of the GALILEO receiver, the intermodulation
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 60
Logica
product is more or less powerful. The probability of receiving two interferences at the sametime should be studied on a case by case basis.
5.1.4 CRITERIA TO ENSURE IOL2 REQUIREMENTS
5.1.4.1 Generalities
To defined out-of-band compatibility, two parameters can be used:• The mask of non-navigation interference acceptance of the GALILEO receiver.• The distance between a non-navigation station and a GALILEO receiver antenna to
ensure this mask of interference.Two criteria should be considered:• The signal to noise degradation that disturbs the GALILEO receiver performance.• The signal to noise degradation that prevents the GALILEO receiver from workingThe power budget for E5 and L1 is the following (for the pilot and the data channels):
L1 E5
Minimum ReceivedPower in dBW -155 -155
Antenna gain in dBic -4.5(R[54])
-4.5(R[54])
ImplementationLosses in dB
-2(R[55])
-2(R[55])
Thermal Noise indBW-Hz -204 -204
Noise Factor in dB 4(R[54)
4(R[54)
Minimal C/N0available in dB-Hz 38.5 38.5
Table 10: Power budget for E5 and L1
For the previous Table 10, we use aeronautical standards (R[54] and R[55]).specification toevaluate the power budget. For non-aeronautical receiver, this power budget can be a realistichypothesis. But in practice, this evaluation will depend on each type of receiver developed.
5.1.4.2 Criteria to ensure compatibility without disturbance
An acceptable signal to noise ratio degradation is a 1dB-degradation.In accordance with 5.1.3.3, the dimensioning cases are for a 1kHz-interference and for awideband interference.
The interference requirements are calculated as followed with the figures of Table 10:
Thermal noise power: HzdBWn B /20042040 −=+−=
Interference NB power for E5a/E5b:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 61
Logica
scwithnnc
sRj Beqc ≈−= )( 00
dBWnnRj Beqc 87.135)( 00 −=−=
Interference NB power for L1:
dBWnnRj Beqc 87.139)( 00 −=−=
Interference WB noise power:
HzdBWnnn Beqj /87.205000 −=−=
This induces the following interference requirements:
NB interferenceE5a/E5b L1
WB interference
Maximum interference power -136dBW -140dBW -206dBW/Hz
Table 11: IOL requirements to ensure compatibility without disturbance
5.1.4.3 Criteria to ensure operational mode with degraded performances
R[55] establishes that a 31dBHz-signal to noise ratio criteria allows both acquisition andtracking when using future aeronautical receiver. R[56] gives the same order of magnitude formass-market receiver. Table 10 thus shows a 7.5dB margin available for all kind ofinterference (non-navigation interference, interference from the other navigation systems, TVharmonics etc). The probability that two types of interference disturb the signal at the sametime is to determine on a case by case basis. Here, we consider that the 7.5dB-margin is forthe non-navigation interference only: it might be optimistic for some scenario, that should bedetermined is to study in further studies.The interference requirements are calculated as followed with the figures of Table 10:Signal power at the input: dBWC 5.16125.4155 −=−−−=Thermal noise power at the input: HzdBWn B /20042040 −=+−=
Interference NB power for 31dBW/Hz for E5a/E5b:
dBWncnc
sRjBeq
c 35.123)/1
/1(
00
−=−=
Interference NB power for 31dBW/Hz for L1:
dBWncnc
sRjBeq
c 32.127)/1
/1(
00
−=−=
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 62
Logica
Interference WB noise power for 31dBW/Hz:
( ) HzdBWnnc
cn Bnacquisitio
J /35.193/ 0
00 −=−=
This induces the following interference requirements:
NB interferenceE5a/E5b L1
WB interference
Maximum interference power -123dBW -127dBW -193dBW/Hz
Table 12: IOL Requirements to ensure operational mode with degraded performances(non-working limit)
5.2 METHODOLOGY TO STUDY ELECTROMAGNETICCOMPATIBILITY
5.2.1 COMPATIBILITY PROBLEMS
Compatibility is associated to two ideas:• The non-navigation system should not disturb the GALILEO system.• The GALILEO system should not disturb the non-navigation system.
Each system is composed of an emitter and of a receiver. The compatibility problem thusinduces the following ideas:
GALILEO emitter Non-navigation emitterGALILEO receiver No problem (useful signal for
a GALILEO receiver).Problem to study
Non-navigation receiver No problem (Receives verylow GALILEO SIS power:
below -150dBW)
No impact on GALILEO/Nonnavigation systems
interoperability.
Table 13: Compatibility problems to solve in our study
Only analysis about the disturbance of non-navigation emitters, ground emitter and on-boardemitter, on GALILEO receiver are here carried out.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 63
Logica
5.2.2 DISTURBING SIGNALS
5.2.2.1 Generalities
The interference effect at IOL1 is different if the interference is pulsed or continuous, narrow-band or wide-band. Thus for each interference, a special attention has to be paid to describeits spectral and temporal characteristics and to determine the adapted mathematical model.
5.2.2.2 Spurious emission of non-navigation emitter on GALILEO receiver OR In-bandcompatibility
The spurious emission of interference in the GALILEO signal�s useful band is shown on thefollowing Figure 2 (typical scenario):
Figure 2 : Spurious emission of non-navigation system on GALILEO receiver
5.2.2.3 Emission of useful signal of the non-navigation emitter on GALILEO receiver Orout-of-band compatibility
According to the typical scenario we took, a useful signal, out of the GALILEO band, may bedisturbing if it is not enough attenuated by the out-of-band filtering as shown on the followingFigure 3.
Specified interferencelevel at GALILEO
receiver input
Interferencepower
Spurious emission onGALILEO receiver
In-bandcompatibility
analysis
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 64
Lo
Figure 3 : Emission of useful signal of the non-navigation emitter on GAL
Then, a trade-off has to be found between the out-of-band rejection achievaof interference that can be tolerated in the receiver.R[54] gives the following interference masks:
Figure 4: Interference rejection mask for aeronautics (R[54]) and for (R[57])
The rejection presented in the Figure 4 are taken from the aeronautical standfrom an example of mass-market receiver. The example of the mass-markeheld receiver) are dated 1994 (R[57]). With the use of the new compone
Specified interferencelevel at GALILEO
receiver input
I
Useful emission possibly attenuated by GALILEO
com
F0 F0+10 F0-10 F0-50
Thermal noise
dBW
TN
TN +110dB-6dB/octave
TN +60dB
ARINC/
-6dB/octave
Out-of-bandpatibility analysis
gica
ILEO receiver
ble and the level
mass-market
ard (R[54]) andt receiver (hand-nt generation of
nterferencepower
not enough receiver
F0-50MHz
-6dB/octave
MOPS
-6dB/octave
Hand-held
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 65
Logica
Surface Acoustic Wave filter (SAW), mass-market receiver can easily have the sameinterference mask rejection as an aeronautical receiver, even a better one (less performancesrequired), with cost effectiveness.The rejection mask given in Figure 4 does not take the antenna gain into account.
5.2.3 CRITERIA
The threshold to be respected are the following:
NB interferenceE5a/E5b L1
WB interference
Maximum interference power(limits of non-disturbance)
-136dBW -140dBW -206dBW/Hz
Maximum interference power(limits of non-working)
-123dBW -127dBW -193dBW/Hz
Table 14: IOL requirements – Maximum interference level admitted
5.3 METHODOLOGY TO STUDY INTEROPERABILITY
The performed analysis shows the possible co-operation or independence between aGALILEO receiver and a Non-navigation system at IOL1. The possible multiple use of thesame component aims at cutting costs of systems with multiple functions.Four level of co-operation can be envisaged and are presented on the following sections:• Common RF module• Common components• Alternate mode with separated filters• Common antenna• Possibility of a common RF moduleThis part analyses the possible design of a common module at RF level to reduce cost. Thisco-operation decreases the cost of two receivers but the independence between the twosystems is lost: if one component is broken, none of the two systems can fulfil their task.Moreover, interference disturbing one of the systems automatically disturbs the other system.
The main difficulty comes from the difference of power level between the navigation signal(very low) and the non-navigation signal with a larger dynamic (very low to high leveldepending on the distance from the base station).
For aeronautics receiver, the level of certification and the priority of navigation availabilityforbid this type of design. Indeed, the possibility of common failure mode (components) isseen as an excessive risk. Moreover, separated components would present high performancesfor interference treatment.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 66
Logica
For mass-market receiver, this type of design appears as a priority because it aims at costcutting.
• Possibility of common componentsSome components can be used for both systems like the frequency synthesiser, the ADC etc.The receiver cost could then be decreased but the independence is partial. If one of thesecommon components is broken, none of the two systems can fulfil their task. However, thesystem can be designed without any loss of performance.
For aeronautics receiver, the common components use can be hardly certified and is of verylow interest.
For mass-market receiver, this type of system is easier to design but maybe not the mostoptimal one from a cost point of view.
• Possibility of alternate mode with separated filtersThe systems can work one after the other, i.e. in an alternate operating mode. A commonreceiver can be used with filters, that alternate. This design ensures good interferencerejection and the loss of performance is minimum.
For aeronautics receiver, the design is not applicable because a GALILEO receiver shouldwork with the best performances to meet the specifications.
For mass-market receiver, this design is possible but less cost-effective than the previousdesigns.
• Possibility of a common antennaThe choice of a common antenna has no real impact on the performances but the design andproduction cost is higher. Moreover, the isolation between antenna of the non-navigationemitter and the GALILEO receiver is very limited.
For aeronautics receiver, this design is possible if a low isolation between antenna is requiredto ensure correct performances but communication system are not the best candidates: this hasto be studied case by case. The main advantage is to reduce the installation cost.
For mass-market receiver, this design is interesting to reduce cost and volume, assuming thesame technology is used for the two services.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 67
Logica
5.4 ELECTROMAGNETIC COMPATIBILITY STUDY
5.4.1 GSM/GPRS
5.4.1.1 Description of the systems
• The GSM (Global System for Mobile communications) system is the first cellular systemstandard of the second generation (fully digital). It is mainly dedicated to voicecommunications (13kbits/s). Data transmission is also possible, with a throughput of9.6kbits/s for data transmission and in addition, GSM enables the transmission of shortalphanumeric messages containing less than 160 characters (SMS). Supplementaryservices are provided on top of teleservices or bearer services, and include features suchas caller identification, call forwarding, call waiting, multi-party conversations andbarring of outgoing (international) calls, among others
• The GPRS (General Packet Radio Service) is a data service design for second-generationGSM and PCS networks. It is designed to support intermittent and bursty data transfersand occasional transmission of large volumes of data. Point-to-point and point-to-multipoint services are also supported. GSM network requires two new network elementsfor GPRS. The serving GPRS Support Node (GSN), which performs security functions,mobility management and access control. The Gateway GSN is used for interworkingwith external packet-switched networks.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 68
Logica
5.4.1.2 Main characteristics
Main characteristics of the GSM system are given on the following Table 15 (R[58]).
GSM 450 480 850 900 1800 1900Mobile station 450.4
457.6478.8480
824.9849
800915
17101785
18501910Frequency bands
(MHz) Base station 460.4467.6
488.6496
867894
925960
18051880
19301990
Mobile station 9 9 9 9 6 3Maximum EIRP(dBW) Base station 25 25 25 25 13 13
Mobile station(cas a)1
Mobile station(cas b)2
-66
-60
-66
-60
-66
-60
-66
-60
-66
-60
-66
-60Out-of-bandspecification
(dBW) Base station(cas a)3
Base station(cas b)4
-66
-60
-66
-60
-66
-60
-66
-60
-66
-60
-66
-60
Table 15: GSM main characteristics
The GALILEO frequency bands are similarly disturbed by the GSM for in-band compatibilityand out-of-band compatibility. For in-band compatibility, spurious emissions of the GSM arespecified to be the same for every GALILEO frequency (cf Table 15). For out-of-bandemission, the receiver rejection depends on the Non-navigation system�s useful frequencyband.
5.4.1.3 GALILEO in-band compatibility with GSM out-of-band emission
5.4.1.3.1 Dimensioning values
The dimensioning cases for both Mobile and Base Stations are thus:• Interference with a power of �60dBW• The case to consider is ∆f>30MHz, which implies a �125dBW/Hz power density WB
interference for the worst case
5.4.1.3.2 Separated navigation equipment and non-navigation equipment
If the GALILEO receiver is spatially separated from the GSM equipment, transmission lossesexits between them. 1 ∆f>6MHz, BW=100kHz, ∆f is the frequency gap between the useful Non-navigation frequency andthe considered frequency band used in the study.2 ∆f>30MHz, BW=3MHz, F∈ [1GHz;12.6 GHz]3 ∆f>6MHz, BW=100kHz4 ∆f>30MHz, BW=3MHz, F∈ [1GHz;12.6 GHz]
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 69
Logica
exits between them.With the mathematical model given in 5.2, we can calculate the received power in theGALILEO receiver:
10-1 100 101 102 103-160
-140
-120
-100
-80
-60
m
dBW
NB: In-band compatibility between GALILEO and GSM (Mobile and base stations)
E5aE5bL1
10-1 100 101 102 103-220
-200
-180
-160
-140
-120
m
dBW
/Hz
WB: In-band compatibility between GALILEO and GSM (Mobile and base stations)
E5aE5bL1
Figure 5: GSM maximum power possibly received in the GALILEO band versus thedistance (GSM mobile and base stations) – NB and WB interference
The previous Figure 5 induces the following conclusion for GALILEO in-band compatibilitywith GSM out-of-band emission:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 70
Logica
E5a/E5b L1Non-disturbing criteria:
• NB interference• WB interference
130m230m
150m170m
Non-working criteria:• NB interference• WB interference
30m50m
35m40m
Table 16: GALILEO in-band compatibility with GSM out-of-band emission – NB andWB interference
The previous Table 16 gives relatively low protection distance, in the order of magnitude of200m for non-disturbing and 50m for non-working. However, they represent a potential risk ifthe specifications in standards are confirmed in practice. A scenario of approach (aeronautics)may be disturbed by the systems if the base station specifications in standards are confirmedin practice.In case of disturbance of a mobile station, the percentage of time occupied may be low. AGALILEO receiver can treat them with clipping or better techniques such as blanking if thepercentage is not too high.In case of disturbance of a base station, two solutions can be combined:• The base station can be geographically located in a specified environment (in altitude in a
no-man land)• The GALILEO receiver can use complex mitigation technique such as adaptive antennaIn both cases, antenna isolation is a good way to reduce the protection distance.In addition, a detailed analysis based on the probability of received spurious emission shouldbe conducted in the GALILEO frequency bands. The conclusion may certainly conclude thatthe GSM equipment�s spurious emissions are largely below the standard specification in theGALILEO frequency bands. Indeed, the standard specifies the same level of spuriousemission for the �harmonics bands� than for the �non-harmonics bands�. No harmonics of theGSM are in the GALILEO frequency bands. The identified potential risk is probably over-evaluated: the standards are over-dimensioned in the GALILEO bands.
5.4.1.3.3 Navigation and non-navigation services on the same equipment
No transmission loss exists in this case. The question should be answered only for mobilestations.
NB interference 76dB 80dB 63dB 67dBWB interference 81dB 68dB
Table 17: Rejection required to insure interoperability
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 71
Logica
Even with antenna isolation, this level of rejection cannot be reached. First, the applicabilityof the standard specification has to be analysed in the GALILEO frequency bands. If it isrepresentative, an effort should be made in the design of the non-navigation equipment, toreach lower spurious emissions levels.
5.4.2 GALILEO OUT-OF-BAND COMPATIBILITY WITH GSM USEFUL EMISSION
5.4.2.1 Separated navigation equipment and non-navigation equipment
As explained in 5.2.2.3, a trade-off is made between the out-of-band rejection of the receiverand the acceptable level of interference. The out-of-band rejection taken in the simulation isgiven in Figure 4 (aeronautical rejection). Depending of the GSM mode, the out-of-bandcompatibility between GALILEO and GSM is given for the mobile stations on the followingfigure:
10-1 100 101-160
-150
-140
-130
-120
-110
m
dBW
E5aE5bL1
10-1 100 101-160
-150
-140
-130
-120
-110
m
dBW
E5aE5bL1
10-1 100 101-160
-150
-140
-130
-120
-110
m
dBW
E5aE5bL1
10-1 100 101-160
-150
-140
-130
-120
-110
m
dBW
E5aE5bL1
10-1 100 101-160
-150
-140
-130
-120
-110
m
dBW
E5aE5bL1
10-1 100 101-160
-150
-140
-130
-120
-110
m
dBW
Out-of-band compatibility between GALILEO and GSM (Mobile stations)
E5aE5bL1
GSM 450 GSM 480
GSM 850 GSM 900
GSM 1800 GSM 1900
Figure 6: Out-of-band compatibility between GALILEO and GSM (Mobile stations)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 72
Logica
Depending of the GSM mode, the out-of-band compatibility between GALILEO and GSM isgiven for the base stations on the following figure:
10-1 100 101 102-160
-150
-140
-130
-120
-110
m
dBW
E5aE5bL1
10-1 100 101 102-160
-150
-140
-130
-120
-110
mdB
W
E5aE5bL1
10-1 100 101 102-160
-150
-140
-130
-120
-110
m
dBW
E5aE5bL1
10-1 100 101 102-160
-150
-140
-130
-120
-110
m
dBW
E5aE5bL1
10-1 100 101 102-160
-150
-140
-130
-120
-110
m
dBW
E5aE5bL1
10-1 100 101 102-160
-150
-140
-130
-120
-110
m
dBW
Out-of-band compatibility between GALILEO and GSM (Base stations)
E5aE5bL1
GSM 450 GSM 480
GSM 850 GSM 900
GSM 1800 GSM 1900
Figure 7: Out-of-band compatibility between GALILEO and GSM (Base stations)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 73
Table 18: GALILEO out-of-band compatibility with GSM in-band emission – NB andWB interference – mobile station
The previous values show that the risk is negligible. Antenna isolation is sufficient to insureinteroperability. Moreover, the clipping of the receiver will increase the GALILEO receiverperformances if percentage of operational time of the GSM mobile station is low enough.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 74
Table 19: GALILEO out-of-band compatibility with GSM in-band emission – NB andWB interference – base station
The GSM standard specifies that the antenna gain may be higher for base station. The valuesgiven induces a 1.25 multiplication of the values factors on GSM 450, GSM 480, GSM 850and GSM 900 and a 7 multiplication factor on the values for GSM 1800 and GSM 1900. Buteven with these factors, the risk is negligible. Antenna isolation is sufficient to insureinteroperability.
5.4.2.2 Navigation and non-navigation services on the same equipment
No transmission loss exists in this case. The question should be answered only for mobilestations. With a �110dB-rejection (Figure 4, aeronautical rejection mask), the additionalrejection required is given in the following table:
Antenna isolation may be sufficient to insure interoperability.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 75
Logica
5.5 UMTS
5.5.1 DESCRIPTION OF THE SYSTEMS
UMTS (Universal Mobile Telecommunications system) is a so-called �third-generation(3G)�, broadband, packet-based transmission of text, digitised voice, video, and multimedia atdata rates up to and possibly higher than 2 megabits per second, offering a consistent set ofservices to mobile computer and phone users no matter where they are located in the world.Based on the GSM communication standard, UMTS, endorsed by major standards bodies andmanufacturers, is the planned standard for mobile users around the world by 2002 for basicservice (phase 1) and 2005 for full capabilities (phase 2).A UMTS network consists of three interacting domains: Core network (CN), UMTSTerrestrial Radio Access Network (UTRAN) and user equipment (UE). The UTRANprovides the air interface access method for user equipment.
5.5.2 MAIN CHARACTERISTICS
Main characteristics of the UMTS system are given on the following .
UTRA FDD Band I Band II Band IIIMobile station [1920-1980] [1850-1910] [1710-1785]Frequency bands
(MHz) Base station [2110-2170] [1930-1990] [1805-1880]Mobile station -6 -6 -6Maximum ERP
(dBW) Base station 13 13 13Mobile station5 -60 -60 -60Out-of-band
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 76
Logica
UTRA TDD Band I Band II Band IIIMobile station [1900-1920]
[2010-2025][1850-1910][1930-1990]
[1910-1930]Frequency bands(MHz)
Base station [2110-2170] [1930-1990] [1805-1880]Mobile station 0 0 0Maximum EIRP
(dBW) Base station 0 0 0Mobile station7 -60 -60 -60Out-of-band
specifications(dBW) Base station8 -60 -43 -43
Table 22: UTRA TDD main characteristics
5.5.3 GALILEO IN-BAND COMPATIBILITY WITH UMTS OUT-OF-BAND EMISSION
5.5.3.1 Dimensioning values
Issued from Table 21 and Table 22, the dimensioning cases are the following:• NB spurious emission: -43dBW for base station and �60dBW for mobile station.• WB spurious emission: -103dBW/Hz for base station and �120dBW/Hz for mobile
station
5.5.3.2 Separated navigation equipment and non-navigation equipment
5.5.3.2.1 UMTS mobile stations
With the mathematical model given in 5.2, we can calculate the received power in theGALILEO receiver:
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 77
Logica
100 101 102-160
-150
-140
-130
-120
-110
-100
-90
-80
-70
m
dBW
NB interference: In band compatibility between GALILEO and UMTS (Mobile stations)
E5aE5bL1
Figure 8: UMTS maximum power possibly received in the GALILEO band versus thedistance (UMTS mobile and base stations) – NB – Mobile station
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 78
Logica
100 101 102-220
-210
-200
-190
-180
-170
-160
-150
-140
-130
m
dBW
WB interference: In band compatibility between GALILEO and UMTS (Mobile stations)
E5aE5bL1
Figure 9: UMTS maximum power possibly received in the GALILEO band versus thedistance (UMTS mobile and base stations) – WB – Mobile station
Figure 8 and Figure 9 induce the following conclusion for GALILEO in-band compatibilitywith UMTS out-of-band emission:
E5a/E5b L1Non-disturbing criteria:
• NB interference• WB interference
130m400m
150m300m
Non-working criteria:• NB interference• WB interference
30m90m
35m70m
Table 23: GALILEO in-band compatibility with UMTS out-of-band emission – NB andWB interference – Mobile station
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 79
Logica
Even if the specified value for out-of-band WB spurious emissions �seems� to be the same forGSM and UMTS, the case is more dimensioning for UMTS because the WB spuriousemission are specified in 1MHz for UMTS and 3MHz for GSM. The UMTS is thus moreunfavourable.The previous table gives relatively low protection distance for mobile, in the order ofmagnitude of 400m for non-disturbing and 90m for non-working. However, they represent apotential risk if the specifications in standards are confirmed in practice. A scenario ofapproach (aeronautics) may be disturbed by the systems if the base station specifications instandards are confirmed in practice.In case of disturbance by a mobile station, the percentage of time occupied may be low. AGALILEO receiver can treat them with clipping or better techniques such as blanking if thepercentage is not too high.In both cases, antenna isolation is a good way to reduce the protection distance.This case is almost the same as the GSM case.In addition, a detailed analysis based on the probability of received spurious emission shouldbe conducted in the GALILEO frequency bands. The conclusion may be that the UMTSequipment�s spurious emissions are largely below the standard specification in the GALILEOfrequency bands. Indeed, the standard specifies the same level of spurious emission for the�harmonics bands� as for the �non-harmonics bands�. No harmonics of the UMTS are in theGALILEO frequency bands. The identified potential risk is probably over-estimated: thestandards are over-dimensioned in the GALILEO bands.
5.5.3.2.2 UMTS base stations
The in-band compatibility is illustrated by the following figures:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 80
Logica
101 102 103-150
-140
-130
-120
-110
-100
m
dBW
E5aE5bL1
101 102 103-150
-140
-130
-120
-110
-100
m
dBW
NB interference: In band compatibility between GALILEO and UMTS (Base stations)
E5aE5bL1
Band I
Band I and band II
Figure 10: UMTS maximum power possibly received in the GALILEO band versus thedistance (UMTS mobile and base stations) – NB – Base station
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 81
Logica
101 102 103-210
-200
-190
-180
-170
-160
-150
m
dBW
E5aE5bL1
101 102 103-210
-200
-190
-180
-170
-160
-150
m
dBW
WB interference: In band compatibility between GALILEO and UMTS (Base stations)
E5aE5bL1
Band I
Band II and band III
Figure 11: UMTS maximum power possibly received in the GALILEO band versus thedistance (UMTS mobile and base stations) – WB – Base station
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 82
Logica
E5a/E5b L1Non-disturbing criteria:
• NB interferenceBand IBand II and Band III• WB interferenceBand IBand II and Band III
130m900m
400m2870m
150m1070m
300m2140m
Non-working criteria:• NB interferenceBand IBand II and Band III• WB interferenceBand IBand II and band III
30m200m
90m640m
35m240m
70m480m
Table 24: GALILEO in-band compatibility with UMTS out-of-band emission – NB andWB interference – Base station
The risk is non-negligible. A detailed analysis with probability of disturbance should beconducted to determine the real risk. If the risk is confirmed, the base station should begeographically located in a specified environment (in altitude in a no-man land).
5.5.3.3 Navigation and non-navigation services on the same equipment
No transmission loss exists in this case. The question should be answered only for mobilestations.
Even with antenna isolation, this level of rejection cannot be reached. . First, the applicabilityof the standard specification has to be analysed in the GALILEO frequency bands. If it isrepresentative, an effort should be made in the design of the non-navigation equipment, i.e.lower spurious emissions.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 83
Logica
5.5.4 GALILEO OUT-OF-BAND COMPATIBILITY WITH UMTS USEFUL EMISSION
5.5.4.1 Separated navigation equipment and non-navigation equipment
As explained in the previous paragraphs, a trade-off is made between the out-of-bandrejection of the receiver and the acceptable level of interference. The out-of-band rejectiontaken in the simulation is given in Figure 4 (aeronautical rejection mask).
10-1 100 101-160
-150
-140
-130
-120
-110
m
dBW
E5aE5bL1
10-1 100 101-160
-150
-140
-130
-120
-110
m
dBW
E5aE5bL1
10-1 100 101-160
-150
-140
-130
-120
-110
m
dBW
Out-of-band compatibility between GALILEO and UMTS (Mobile stations)
E5aE5bL1
Band I
Band II
Band III
Figure 12: Out-of-band compatibility between GALILEO and UMTS (Mobile stations)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 84
Logica
E5a/E5b L1Non-disturbing criteria:
• Band I• Band II• Band III
<<0.1m<<0.1m<<0.1m
<<0.1m<<0.1m<<0.1m
Non-working criteria:• Band I• Band II• Band III
<<1m<<1m<1m
<1m<1m<1m
Table 26: GALILEO out-of-band compatibility with UMTS in-band emission – NB andWB interference – mobile station
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 85
Logica
10-1 100 101 102-160
-150
-140
-130
-120
-110
m
dBW
E5aE5bL1
10-1 100 101 102-160
-150
-140
-130
-120
-110
m
dBW
E5aE5bL1
10-1 100 101 102-160
-150
-140
-130
-120
-110
m
dBW
Out-of-band compatibility between GALILEO and UMTS (Base stations)
E5aE5bL1
Band I
Band II
Band III
Figure 13: Out-of-band compatibility between GALILEO and UMTS (Base stations)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 86
Logica
E5a/E5b L1Non-disturbing criteria:
• Band I• Band II• Band III
<1m<1m<1m
1.8m1.8m2.0m
Non-working criteria:• Band I• Band II• Band III
<<1m<<1m<<1m
<1m<1m<1m
Table 27: GALILEO out-of-band compatibility with UMTS in-band emission – NB andWB interference – base station
Considering the previous results, the risk is negligible.
5.5.4.2 Navigation and non-navigation services on the same equipment
No transmission loss exists in this case. The question should be answered only for mobilestations. With a �110dB-rejection (cf. Figure 4, aeronautical rejection mask), the additionalrejection required is given in the following table:
Antenna isolation is sufficient to insure interoperability.
5.6 BLUETOOTH
5.6.1 DESCRIPTION OF THE SYSTEM
Bluetooth is a protocol for wireless connectivity of diverse set of devices ranging from mobilephones, laptops, to cooking oven, fridge, thermostat etc. in home-like and office environment.In this environment, each device in the home is connected to each other. It uses a universal,open-standard, low-cost radio link, without the need to buy, carry and connect cables ormanage infrared connections.
5.6.2 MAIN CHARACTERISTICS
Main characteristics of the Bluetooth system are given on the following Table 29:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 87
Logica
Frequency band (MHz) [2400-2483.5]Maximum EIRP (dBW)
(for the dimensioning class: class 1)-10dBW
-10dBW/100kHz for frequency hopping-20dBW/MHz for other modulation
Out-of-band specification (dBW)9 -60dBW for CW-110dBW/Hz for WB noise
Table 29: Bluetooth main characteristics
5.6.3 GALILEO IN-BAND COMPATIBILITY WITH BLUETOOTH OUT-OF-BANDEMISSION
5.6.3.1 Dimensioning values
The dimensioning cases are the following:• NB interference: -60dBW• WB interference: -110dBW/Hz.
5.6.3.2 Separated navigation equipment and non-navigation equipment
100 101 102 103 104-180
-160
-140
-120
-100
-80
-60
m
dBW
NB: In-band compatibility between GALILEO and BLUETOOTH
E5aE5bL1
100 101 102 103 104-220
-200
-180
-160
-140
-120
m
dBW
/Hz
WB: In-band compatibility between GALILEO and BLUETOOTH
E5aE5bL1
Figure 14: Bluetooth maximum power possibly received in the GALILEO band versusthe distance (Bluetooth mobile and base stations) – NB and WB interference
9 f∈ [1GHz;12GHz] except for f∈ [1.8GHz;1.9GHz] and f∈ [5.15GHz;5.36GHz]
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 88
Logica
The previous Figure 14 induces the following conclusion for GALILEO in-band compatibilitywith bluetooth out-of-band emission:
E5a/E5b L1Non-disturbing criteria:
• NB interference• WB interference
130m1280m
150m960m
Non-working criteria:• NB interference• WB interference
30m290m
35m210m
Table 30: GALILEO in-band compatibility with Bluetooth out-of-band emission – NBand WB interference
The previous table gives relatively high protection distance, in the order of magnitude of 1kmfor non-disturbing and 290m for non-working. Problems are envisaged in this case. Twosolutions have to be combined:• Blanking should be used in the GALILEO receiver if the time of disturbance is not too
high.• The standard for Bluetooth should be more precise in the GALILEO frequency bands.
Spurious emission should be less powerful, for WB in particular. It is recommended thatthis topic enters ITU discussions.
5.6.3.3 Navigation and non-navigation services on the same equipment
No transmission loss exists in this case. The question should be answered only for mobilestations.
Even with antenna isolation, this level of rejection can not be reached. The WB spuriousemission of blue tooth should be reviewed by standards in the GALILEO frequency bands.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 89
Logica
5.6.4 GALILEO OUT-OF-BAND COMPATIBILITY WITH BLUETOOTH USEFULEMISSION
5.6.4.1 Separated navigation equipment and non-navigation equipment
As explained in 5.2.2.3, a trade-off is made between the out-of-band rejection of the receiverand the acceptable level of interference. The out-of-band rejection taken in the simulation isgiven in Figure 4 (aeronautic rejection mask).
10-2 10-1 100-170
-165
-160
-155
-150
-145
-140
-135
-130
-125
-120
m
dBW
Out-of-band compatibility between GALILEO and BLUETOOTH
E5aE5bL1
Figure 15: Out-of-band compatibility between GALILEO and bluetooth
Table 32: GALILEO out-of-band compatibility with bluetooth in-band emission – NBand WB interference
The previous values show that the risk is negligible.
5.6.4.2 Navigation and non-navigation services on the same equipment
No transmission loss exists in this case. The question should be answered for mobile stationsonly. With a -110dB rejection (cf. Figure 4), the additional rejection required is given in thefollowing table:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 90
Antenna isolation may be sufficient to insure interoperability.
5.7 WLAN
5.7.1 DESCRIPTION OF THE SYSTEM
Wireless Local Area Networks (WLAN) technology is a mean for providing local areaconnectivity between computers and associated network resources using wireless rather thanwireline links. It allows access to wired resources, such as servers, by mobile users. WLANstandard defines the media access control (MAC) and physical (PHY) layers for a LAN withwireless connectivity. It addresses local area networking where the connected devicescommunicate over the air to other devices that are within close proximity to each other.
5.7.2 MAIN CHARACTERISTICS
The same standard gives the characteristics of the WLAN system and of Bluetooth system.The study is thus the same 5.6.
5.8 DECT
5.8.1 DESCRIPTION OF THE SYSTEM
DECT (Digital Enhanced Cordless Telecommunications) is a flexible digital radio accesstechnology for cordless communications in residential, business and public environments.Designed for short-range use as an access mechanism to the main networks, DECT offerscordless voice, fax, high-speed data and multimedia communications, wireless local areanetworks.
5.8.2 MAIN CHARACTERISTICS
Main characteristics are given on the following Table 34:
Frequency band (MHz) [1880;2025] and [2400;2483.5]Maximum EIRP (dBW) 6
Out-of-band spurious emission (dBW)10 -60
Table 34: DECT main characteristics
The frequency band is [1880MHz;2025MHz]. 10 f>1GHz, ∆f>30MHz: BW=3MHz
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 91
Logica
5.8.3 GALILEO IN-BAND COMPATIBILITY WITH DECT OUT-OF-BAND EMISSION
5.8.3.1 Dimensioning values
The dimensioning cases are the following:• NB interference: -60dBW• WB interference: -120dBW/Hz
5.8.3.2 Separated navigation equipment and non-navigation equipment
If the GALILEO receiver is spatially separated from the DECT equipment, transmissionlosses exit between them.The received power is shown on the following figure:
100 101 102 103 104-180
-160
-140
-120
-100
-80
-60
m
dBW
NB: In-band compatibility between GALILEO and DECT
E5aE5bL1
100 101 102 103 104-240
-220
-200
-180
-160
-140
-120
m
dBW
/Hz
WB: In-band compatibility between GALILEO and DECT
E5aE5bL1
Figure 16: DECT maximum power possibly received in the GALILEO band versus thedistance (DECT mobile and base stations) – NB and WB interference
The previous Figure 8 induces the following conclusion for GALILEO in-band compatibilitywith DECT out-of-band emission:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 92
Logica
E5a/E5b L1Non-disturbing criteria:
• NB interference• WB interference
130m400m
150m300m
Non-working criteria:• NB interference• WB interference
30m90m
35m70m
Table 35: GALILEO in-band compatibility with DECT out-of-band emission – NB andWB interference
The previous table gives relatively low protection distance, in the order of magnitude of 400mfor non-disturbing and 90m for non-working. However, they represent a potential risk if thespecifications in standards are confirmed in practice. A scenario of approach (aeronautics)may be disturbed by the systems if the base station specifications in standards areconfirmed in practice.In case of disturbance of a mobile station, the percentage of time occupied may be low. AGALILEO receiver can treat them with clipping or better techniques such as blanking if thepercentage is not too high.In case of disturbance of a base station, two solutions can be combined:• The base station can be geographically located in a specified environment (in altitude in a
no-man land)• The GALILEO receiver can use complex mitigation technique such as adaptive antennaIn both cases, antenna isolation is a good way to reduce the protection distance.In addition, a detailed analysis based on the probability of received spurious emission shouldbe conducted in the GALILEO frequency bands. The conclusion may certainly conclude thatthe DECT equipment�s spurious emissions are largely below the standard specification in theGALILEO frequency bands. Indeed, the standard specifies the same level of spuriousemission for the �harmonics bands� than for the �non-harmonics bands�. No harmonics of theGSM are in the GALILEO frequency bands. The identified potential risk is probably over-estimated: the standards are over-dimensioned in the GALILEO bands.
5.8.3.3 Navigation and non-navigation services on the same equipment
No transmission loss exists in this case. The question should be answered only for mobilestations.
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 93
Logica
Even with antenna isolation, this level of rejection can not be reached. First, the applicabilityof the standard specification has to be analysed in the GALILEO frequency bands. If it isrepresentative, an effort should be made in the design of the non-navigation equipment, i.e.lower spurious emissions.
5.8.4 GALILEO OUT-OF-BAND COMPATIBILITY WITH DECT USEFUL EMISSION
5.8.4.1 Separated navigation equipment and non-navigation equipment
As explained in 5.2.2.3, a trade-off is made between the out-of-band rejection of the receiverand the acceptable level of interference. The out-of-band rejection taken in the simulation isgiven in Figure 4 (aeronautical rejection mask).
10-1 100-160
-155
-150
-145
-140
-135
-130
-125
-120
-115
-110
m
dBW
Out-of-band compatibility between GALILEO and DECT
E5aE5bL1
Figure 17: Out-of-band compatibility between GALILEO and DECT
Table 37: GALILEO out-of-band compatibility with DECT in-band emission – NB andWB interference
The previous value show that the risk is negligible.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 94
Logica
5.8.4.2 Navigation and non-navigation services on the same equipment
No transmission loss exists in this case. The question should be answered only for mobilestations. With a �110dB-rejection (cf. Figure 4), the additional rejection required is given inthe following table:
Antenna isolation may be sufficient to insure interoperability.
5.9 TETRA
5.9.1 DESCRIPTION OF THE SYSTEM
TErrestrial Trunked RAdio (TETRA) is the modern digital Private Mobile Radio (PMR) andPublic Access Mobile Radio (PAMR) technology for police, ambulance and fire services,security services, utilities, military, public access, fleet management, transport services,closed user groups, factory site services etc.With support of the European Commission and the ETSI members, the TETRA standard hasbeen developed over a number of years by the co-operation of manufacturers, users, operatorsand other experts, with emphasis on ensuring the standard will support the needs ofemergency services throughout Europe and beyond.
5.9.2 MAIN CHARACTERISTICS
Main characteristics of the TETRA system are given on the following:
Frequency band (MHz) [380-400] (Emergency services)[410-430] (Civil users)
Mobile station 15dBWMaximum ERPBase station 16dBWNarrowband -66dBW (CW)
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 95
Logica
5.9.3 GALILEO IN-BAND COMPATIBILITY WITH TETRA OUT-OF-BAND EMISSION
5.9.3.1 Dimensioning values
The dimensioning cases are the following:• NB interference: -60dBW• WB interference: -130dBW/Hz
5.9.3.2 Separated navigation equipment and non-navigation equipment
A trade-off is made between the out-of-band rejection of the receiver and the acceptable levelof interference. The out-of-band rejection taken in the simulation is given in Figure 4(aeronautical rejection mask).The in-band compatibility between GALILEO and TETRA is given on the following figure:
100 101 102
-140
-120
-100
-80
m
dBW
NB: In-band compatibility between GALILEO and TETRA (Mobile and base stations)
E5aE5bL1
100 101 102-220
-200
-180
-160
-140
m
dBW
/Hz
WB: In-band compatibility between GALILEO and TETRA (Mobile and base stations)
E5aE5bL1
Figure 18: TETRA maximum power possibly received in the GALILEO band versus thedistance (DECT mobile and base stations) – NB and WB interference
The Figure 18 induces the following conclusion for GALILEO in-band compatibility withTETRA out-of-band emission:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 96
Logica
E5a/E5b L1Non-disturbing criteria:
• NB interference• WB interference
130m130m
150m100m
Non-working criteria:• NB interference• WB interference
The previous table gives relatively low protection distance, in the order of magnitude of 130mfor non-disturbing and 30m for non-working. However, they represent a potential risk if thespecifications in standards are confirmed in practice. A scenario of approach (aeronautics)may be disturbed by the systems if the base station specifications in standards are confirmedin practice.Moreover, the third harmonics of the TETRA equipment is in the E5 band. The level ofspurious emission will be probably at the maximum power allowed by standards. Detailedanalysis based on the probability of received spurious emission should be conducted.In case of disturbance of a mobile station, the percentage of time occupied may be low. AGALILEO receiver can treat them with clipping or better techniques such as blanking (cf.5.11.1.3) if the percentage is not too high.In case of disturbance of a base station, two solutions can be combined:• The base station can be geographically located in a specified environment (in altitude in a
no-man land)• The GALILEO receiver can use complex mitigation technique such as adaptive antennaIn both cases, antenna isolation is a good way to reduce the protection distance.
5.9.3.3 Navigation and non-navigation services on the same equipment
No transmission loss exists in this case. The question should be answered only for mobilestations.
Even with antenna isolation, this level of rejection can not be reached. As the third harmonicis in the E5 band, the value given by standard may not be over-dimensioned in this band.However, the applicability of the standard specification may have to be analysed in the E5
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 97
Logica
frequency bands. If it is proved, an effort should be made in the design of the non-navigationequipment to lower spurious emissions.
5.9.4 GALILEO OUT-OF-BAND COMPATIBILITY WITH TETRA USEFUL EMISSION
5.9.4.1 Separated navigation equipment and non-navigation equipment
As explained before, a trade-off is made between the out-of-band rejection of the receiver andthe acceptable level of interference. The out-of-band rejection taken in the simulation is givenin Figure 4 (aeronautical rejection mask).
100 101-160
-155
-150
-145
-140
-135
-130
-125
-120
-115
-110
m
dBW
Out-of-band compatibility between GALILEO and TETRA (Mobile stations)
E5aE5bL1
Figure 19: Out-of-band compatibility between GALILEO and TETRA – Mobile station
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 98
Table 43: GALILEO out-of-band compatibility with TETRA in-band emission – NBand WB interference - Base station
The previous values show that the risk is negligible. The clipping of the receiver will increasethe GALILEO receiver performances if percentage of operational time of the TETRA mobilestation is low enough.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 99
Logica
5.9.4.2 Navigation and non-navigation service on the same equipment
No transmission loss exists in this case. The question should be answered only for mobilestations. With a �110dB-rejection (cf. Figure 4, aeronautical rejection mask), the additionalrejection required is given in the following table:
Table 44: Rejection required to insure interoperability
Antenna isolation may be sufficient to insure interoperability to be in accordance with thenon-working criteria.
5.10 CO-OPERATION WITH A NON-NAVIGATION SYSTEMSTUDY
The methodology for this part is explained in 5.3. As easily understandable, this analysis isonly conducted for mobile station. As explained in 5.3, the possible co-operation can be madeat the following levels:• Common (totally or partially) receiver RF module• Common components: antenna, analogue components, chips.
The following table shows the possibility of co-operation on the same equipment with onenavigation function and one non-navigation function:
Legend : ++ very easy
+ easy
Common RFreceivermodule(total)
Common partof receiverRF module
(partial)
Commonreceiver RFmodule with
separatedfilter
Commonantenna
Commonchips
GSM/GPRS450/480/850/
900
+ ++
GSM1800/1900
+ ++ ++ + ++
UMTS + ++ + + ++DECT + + ++
Bluetooth + + ++TETRA +
Table 45: Possible co-operation at IOL1 between navigation receiver and non-navigation mobile station
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 100
Logica
The capability of co-operation is mainly dependent of operating frequency of non-navigationsystem for the technology, the useful bandwidth for the type of filter and the overallspecifications.The optimal co-operation depends of many constraints, so only a general point of view can bedone.The use of common RF modules and common antenna is possible when the useful frequencybands are not too far and is entirely dependent of the technology.The use of common parts of receiver RF module is a good solution for mass-market likecommon part between receiver and emitter in GSM user device.For professional and aeronautical applications, the best performances are obtained withindependence of the two functions.
5.11 MODULES IN THE IOL1 PART THAT CAN BE ADDED TOINCREASE INTEROPERABILITY
This chapter describes the modules that can be added to the standard IOL1 part in order toincrease interoperability. Its aim is to make a list rather than to detail these additionalmodules. Their use will depend on the receiver manufacturer strategy.
5.11.1 MODULE AGAINST IN-BAND INTERFERENCE
5.11.1.1 Antenna isolation
Antenna isolation should be implemented in order to insure isolation between the GALILEOantenna and the non-navigation antenna.The level of isolation depends on:• The distance between the two antennas• The signals� polarisation• The antenna implementation.This technique is interesting because it is efficient but the design is user dependant.
5.11.1.2 Antenna processing
5.11.1.2.1 Generalities
A variety of adaptive antennas have been developed over the past two decades. Among theseare beam forming antennas and null-steering antennas.These techniques could be used for aeronautical receivers but are too complex for mass-market receivers.
5.11.1.2.2 Beam forming antenna
This antenna aims at forming a beam in the direction of the satellite.This technique implies knowing the angular co-ordinates of the satellites with respect to anantenna fixed reference system. This actually means knowing the attitude of the antenna withrespect to the earth, since the direction of the satellite line of sight is known thanks to
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 101
Logica
ephemeris. This can be provided thanks to an attitude and heading reference system, based oninertial sensors or others types.This method also requires distinct treatments for each tracked satellite, with differentcombination gain, which thus increases the computation burden.This technique is advantageous since it increases the power of useful signal while decreasingthe power of interference, assuming it is not in the direction of the satellite line of sight.This technique makes no assumption on the interference characteristic.However the attenuation of interference is not so great and the cost is high..
5.11.1.2.3 Null steering antenna
This antenna aims at making a hole in the antenna radiation pattern in the direction of ajammer and uses a patch array.This technique uses the received signals of every antenna. It determines the combinationgains that minimise the interference power at the output, while keeping a sufficient power ofuseful signal. It traditionally uses Appelbaume or Capon algorithm, which requires a highcomputation power for matrix inversion.This technique provides very high rejection gains. The level of rejection depends on thequality (and cost) of the components and on the computational capabilities.If N is the number of antenna patch, this technique can eliminate at least N-1 interferencesources simultaneously.This technique is suited for limited continuous interference source number. In case of pulsedinterference it needs higher computational power. In case of many pulsed interferencesources, it is no more efficient.
5.11.1.3 Polarisation discrimination
The technique operates at RF and uses a detection and tracking/control channel to identifyand track the interfering signal and a hybrid junction to null the interference components ofthe interfering signal. It is fairly inexpensive product that is effective against both wide bandand narrow band interference.
5.11.1.4 Clipping Blanking
The aim of this device is to zero out the input signal when its power exceeds a giventhreshold. This method may increase the clipping performances of the GALILEO receiver andis not complex to implement either in mass-market receivers or in aeronautical receivers.
5.11.1.5 Adaptive filtering
This technique is based on a �frequency blanking�. In other word each corrupted frequency iseliminated. It proceeds in three phases:• Spectral analysis of the received signal to characterise the power spectral density and
make difference between corrupted and uncorrupted frequency bands.• Choice of frequency bands to be blanked, by comparing the power spectral density with a
threshold that characterises the ambient thermal noise.• Applying the spectrally differentiated blanking to the signal
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 102
Logica
It enables the rejection of in band interference by filtering. In order not to filter the wholeuseful band it only rejects the affected band, which are detected by spectral characterisation ofreceived signal in real time.This technique is complex and is less adapted to low-cost mass-market receivers. On the otherhand, it may be implemented in aeronautical and professional receivers.
5.11.1.6 Co-operation
Co-operation between the two system can be envisaged if availability is very difficult at level1. This may be the case for mass-market receiver but not for aeronautical receivers. This typeof co-operation could be put in place in the frame of international dedicated forumdiscussions such as ITU or standardisation bodies.
5.11.2 MODULE AGAINST OUT-OF-BAND INTERFERENCE
5.11.2.1 Antenna isolation
See 5.11.1.1.
5.11.2.2 Antenna processing
The choice of the antenna has a significant impact in the out-of-band rejection. The choiceshould be made depending on the polarisation of the signal and the bandwidth we want to getin the receiver.For aeronautical receivers and specific professional receivers, the choice of the antenna has tobe made considering low temperature conditions and the possibility of ice on the antenna.
5.11.2.3 Filtering
The attenuation of out-of-band interference in the RF part of the receiver is essential to ensurea good digital coding with the lowest useful sampling frequency (no spectrum aliasing in theband). If the out-of-band attenuation is not high enough, the in-band mitigation techniquescan help to mitigate the aliased out-of-band interference. A trade-off has to be reachedbetween the out-of-band rejection and the acceptable aliased interference.The components to use depend on the level of rejection to achieve. The combination ofcomponents depends of the technology used. New generations of SAW components maybecome very useful in this domain for mass-market receivers and aeronautical receivers forvolume and cost reasons. The techniques and technologies improve with the stress created bythe increasing frequency cluttering.
5.11.2.4 Co-operation
See 5.11.1.6.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 103
Logica
5.12 FROM THEORY TO PRACTICE
As it can be seen in chapter 18, practical results do not seem to match theoretical resultscoming from chapter 5.4. Thus, it is important to identify why this gap does exist and how itcan be explained.When analysing more in depth the Non-Navigation emission levels hypotheses taken in thecompatibility study (section 18) and when comparing them to the operational evaluationsavailable today, it appears that they are over-dimensioned. Indeed, they are most of the casesbased on worst cases analysis that are not confirmed by operational observations.In addition, at GNSS receiver level this time, �typical� characteristics hypotheses (mainlybased on standards) seem also to be pessimistic in that way receiver manufacturers are todayable to optimise design choices in order to enhance receiver capabilities beyond the requestsof the standards. These two types of �over-dimensioning� sources are listed hereafter.
5.12.1 EMISSION OVER-DIMENSIONNED HYPOTHESES
It is very important to keep in mind the main hypotheses taken in the calculations:• Spurious emission power levels are based on ESTI Specifications and ITU
recommendations. These recommendations are the same in harmonics� frequency bandsand in other frequency bands.
• Non-navigation antenna gain for in band interference frequency is assumed to be 0dB.• Worst case model hypothesis concerning spurious emission (time and frequency):
continuous in all the GALILEO frequency bandwidth.
To highlight the effect of these pessimistic hypotheses, let�s take an example:• The non-navigation antenna gain for in-band interference frequency for Bluetooth is
�25dB at 1.5GHz (instead of 0dB), R[60]• The TDMA aspect of communication device probably involves pulse spurious
interference, so the clipping function of the receiver drastically increases the acceptablelevel of interference in a ratio related to the �occupation� time of the interference.
• Standards are over-dimensioned: they are not based on a reality but on ITUrecommendations.
Taking into account those factors and their impact on theoretical results, it can be understoodthat the practical data obtained for �non-disturbing� area are less than one meter.
5.12.2 RECEIVER OVER-DIMENSIONED HYPOTHESES
The GNSS receiver characteristics taken in the study also over-dimension the theoreticalapproach:• Maximum spurious emission considered in the study but in practice, the power used for
communication between a mobile station and a base station is adapted to the distancebetween them.
• GALILEO receiver antenna gain of 0dB for the interference frequency: in practice, foraeronautical navigation receiver, the antenna gain may be comprised between �10dB and�20dB for a �30° elevation, R[59]
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 104
Logica
• Interference mask rejection taken from R [54] � It can be improved case by case by thereceiver manufacturer, taking into account a risk analysis and the mission to which thereceiver is dedicated
• Direct view between navigation and non-navigation receivers (no shadow). According tothe application, this statement can be really over-dimensioning
• Non-navigation antenna gain for emitter frequency taken into account in the standards(even if not written explicitly). No precise antenna diagrams are available for non-navigation equipment : a 0dB-gain hypothesis is probably over-dimensioned for thetransmission of the spurious emission on GNSS bands.
• Typical antenna isolation accessible : 40dB � Optimised design can provide betterisolation
For all that, it appears clearly that, because all this �over-dimensioned� approach, there couldbe an important gap between theoretical results and operational measures. Nevertheless, thetheoretical approach remains the ultimate limit that can be encountered until nothing is doneat standardisation level to guaranty a full compatibility between GNSS and Non-Navigationsystems.
5.13 CONCLUSIONS
This paragraphs report the basic results of the analysis. Available studies on GPS interferenceare reported in ANNEX F.
5.13.1 MAIN RESULTS ON ELECTROMAGNETIC COMPATIBILITY STUDY
5.13.1.1 Separated navigation equipment and non-navigation equipment
The dimensioning protection distance between equipment are synthesised in the followingTable 46:
Table 46: Dimensioning protection distance between GALILEO receiver and non-navigation system to insure interoperability at IOL1
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 105
Logica
Of course, the results presented above can only be interpreted with respect to the operationalrequirement expression. Thus, as far as operational requirements are not standardised for allapplications, it is not easy to assess the criticality of these results. Nevertheless, for whatconcerns aeronautical application, some standards exist and are available (R[61]): from thesestandards, it is clear that the theoretical protection distances presented above could be toorestrictive and could jeopardise the opportunity to perform landing using GNSS (evenaugmented) as primary means.
But are the Non-Navigation characteristics presented in ETSI standards confirmed inpractice? Probably not! Thus, a detailed analysis based on measure samples and statisticgeneralisation should be conducted in the GALILEO frequency bands.
Note also that the use of mitigation techniques as simple as clipping/blanking or morecomplex such as adaptive antenna may drastically increase compatibility possibilities. Aspecific study should be conducted on the subject addressing both interference resistanceimprovement and non-regression.For what concerns base stations, protection distances are relatively low and acceptable, exceptfor UMTS for which installation precaution should be taken to preclude GNSS receiverperturbations.
5.13.1.2 Navigation and non-navigation services on the same equipment
The dimensioning additional rejection is synthesised in the following table:
Even with antenna isolation, this level of rejection can not be reached (a typical rangeaccessible is from 30 to 50dB, depending on configurations). But as a unique manufacturerwill probably design both GALILEO and Non-Navigation part of its equipment, there is noneed to impose any standard at that level. It is the manufacturer responsibility to insure that
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 106
Logica
the two systems can co-exist inside and be operational inside its product, otherwise, he won�tsell it�Nevertheless, it should be recommended to pay attention to the level of the spuriousemissions of the non-navigation equipment and to try to lower it as far as possible (forexample: emission filtering, etc.) .
Main results on co-operationFor mass-market receivers, the co-operation at IOL1 between GALILEO and Non-navigationsystems is an interesting mean to reduce the costs. Depending on the strategy of themanufacturer, several technical solutions (common component, common antenna etc) andoperational solutions (sequential operation etc) can be taken into account.
For professional and aeronautical receivers, the safety, which requires material independenceto disable common mode of failure, seems to forbid co-operation at IOL1.
Additional remarksThis study has been conducted following the work-package description. However, TV/FM,UWB and military communications seems very disturbing and have not been identified by thework-package description. Thus a special attention must be paid to them and specific studiesshould be conducted.
SynthesisAs a final conclusion, one should say that the theoretical results trying to assess compatibilitybetween GALILEO and Non-Navigation systems appears to be at the same time critical butvery pessimistic. In particular, for GPS, that should have a similar behaviour than GALILEO,the major outages reports do not show problems with the studied Non-Nav systems but withother devices (TV, Military communications, etc.). Nevertheless, a risk study and amanagement process have to be put in place (why not in the frame of frequency regulationentities, such as ITU ?) to follow evolutions of standards and to try to reduce Non-Navigationspurious emissions level.
5.14 SUMMARY OF LEGAL ISSUES
None currently identified at IO level 1 but this issue should be further investigated inGALILEI Task I.
5.15 MRD & SRD RECOMMENDATIONS AT INTEROPERABILITYLEVEL 1
Recommendations for MRD• MRD-1301
o It is recommended to put more in evidence the problem of integration ofGALILEO antennas with Primary and Secondary systems (GSM and UMTS)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 107
Logica
antennas and relevant interference problems, considering the identifiedminimum distances parameters obtained by the present analysis. A sentencelike �Interference problems at Antenna and RF Front �End level� should beadded
o It is recommended to perform an on-field campaign during GALILEO IOVPhase and Pilot Projects in order to build an extensive database of primaryand secondary systems measurements for further investigations on userterminal integration. At MR-1401b a requirement should be added inserting asentence like: �Validation shall include on field interference measurementscampaign between GALILEO receiver and external communication systems(GSM, UMTS, Bluetooth, etc.)
• Recommendations on MR-303 / MR-331 / MR-369 / MR-370 / MR-2232 : Forsome applications, compatibility with interfering systems may represent a biginteroperability constraint at the receiver level. The future combined GNSS systemsshould be able :
o to guarantee that the availability of GALILEO signals will not be too muchimpacted by some undesired interfering sources.
o to verify that, when necessary, simple interference mitigation techniques canbe implemented within the receiver to deal with these interfering sources.
Recommendations for SRDSRD par. 5.2.5 and 7.7Include interference levels into the nominal environment definitions in terms of minimumdistances between GALILEO and communication systems antennasAdd dedicated requirements related to the analysis of interference for an integrated navigationand communication equipment for Test Receiver assisted navigation and augmentationapplications. Add requirements related to the operation in dual-mode (reception of GALILEOsignal, transmission of application related data through mobile communication systems).Add requirements related to the rejection mask and interference mitigation techniques at userterminal level between navigation module RF Front End and communication RF Front End.
5.16 IMPACTS ON GALILEO OS AND CS
• Mass-Market: the possibility to implement Assisted Navigation and broadcastAugmentation data (both implemented by external Service Providers or by GALILEOLocal Elements Service Centres) depends on the availability of the Mobile Networkssignal on the terminal and the possibility to operate with them not only in alternativemode (alternative reception of Augmentation message and implementation of thecomplete RRLP protocol, see dedicated paragraphs after) also in coexistence mode(reception of augmentation/assistance data and GALILEO signal and transmission ofapplication related data).If smart, light and integrated GALIELO-GSM/UMTS (+secondary systems) terminal will be not studied and implemented, GALILEO couldloose the opportunity to extract any revenues from such huge market
• Professional Market: in this case the size and weight constraints are more relaxed.Otherwise, the integration with communication links is essential for theimplementation any professional application. Not considered interference problemscan lead to loose Service Guarantee and Integrity services coming from GALILEO
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 108
Logica
signal and Local Elements broadcast in safety critical situation (e.g. inland waterwaysnavigation low depth zones, hazardous goods transportation, etc..)
At this aim it is strongly recommended to launch Pilot Projects for interference analysiscampaigns and to develop dedicated study on GALILEO/external systems integrated userterminal design.
5.17 ISSUES FOR OTHER GALILEI TASKS AND OTHER STUDIES
Task FIt is recommended to analyse interference at user terminal between GALILEO and Primary(GSM/UMTS) and Secondary (TETRA, DECT, Bluetooth, WLAN, etc..) systems.
5.18 GENERAL RECOMMENDATIONS FOR GALILEO DESIGNAND DEVELOPEMNT PHASE
The main recommendations issued from this study are recalled hereafter:• ETSI/ITU standards should be improved to protect aeronautical GNSS bands with the
support of user organism such as EUROCAE/RTCA, IMO etc.• The current risk of non-navigation system should be analysed through studies based on
measure campaigns and statistic approach during the GALILEO DD&V phase• A monitoring should be implemented to detect and alert geographical area with
unacceptable risks• User Segment requirements should take into account an opportunely defined rejection
mask.• Precautions have to be taken in the deployment and installation of non-navigation base
stations• Mitigation techniques at receiver level should be designed and implemented during
GALILEO DD&V phase in last resort. The complexity/cost and regression onperformances may not be acceptable, especially for mass-market receivers
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 109
Logica
6 NAVIGATION SYSTEM-INTEROPERABILITY LEVEL3A: HYBRIDISATION OF GNSS AND NON NAVPSEUDORANGES
The aim of this chapter is to analyse the integration of GALILEO and Non-Nav positioningsystems at ranging measurements level.The focus is to analyse already existing studies and identify improvements to be carried outand alternative solutions.In particular, navigation processing algorithms for integrated measurements (e.g. GSM TimeDifferences and UMTS ranging measurements) will be evaluated, giving inputs for theapplication of new methods (e.g. Improved Kalman Filtering techniques for robust non-linearprocessing measurements).
6.1 DESCRIPTION OF THE FUNCTIONS AT THIS LEVEL
The interoperability between Galileo and different Non-Nav-Systems will be evaluated at IO-Level 3A (interoperability in terms of hybridisation at pseudorange level).
Functions at processing level 3A are:1. GALILEO measurements pre-processing and filtering for hydridisation purposes2. TOA measurements3. Hybridisation with other TOA measurements4. Differential corrections of NON-NAV system measurements
Input Systems at this level will be mainly other ranging sources to be hybridised with theGNSS ranging sources coming from the GALILEO receiver data processing (e.g.Aided/Assisted/Enhanced GALILEO ranging source). The output system of the rangeshybridisation process is the Navigation Terminal in which the position can be hybridised withothers positioning sources.
The task aims:
• At identifying the main factors impacting interoperability between GALILEO andrelevant Non Nav systems in terms of hybridisation at pseudorange level (mix ofpseudorange)
• At providing recommendations and evaluate impacts on MRD/SRD Phase B2 based onthe performed analysis for the refinement of GALILEO�s baseline.
In the following paragraphs, general descriptions of interoperability analysis at 3A-level andrelevant results are presented, mainly in terms of impacts on GALILEO MRD/SRD.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 110
Logica
6.2 SYSTEM INTERFACES
The particular system interfaces that should be analysed have to be deduced from the rankedRequirements table produced by MIA.The main objective of the task is to report the general results coming from the interoperabilityanalysis at 3A-Level between Galileo and different Non Nav systems to the following level ofdetail:
1. Detailed analysis• GSM/GPRS• UMTS
2. Limited analysis• Bluetooth• WLAN• Tetra
For each identified system interface, relevant results are reported coming from the followingIO analysis tasks:
• Review and elaboration of results of relevant other projects concerning thehybridisation between GNSS measurements and Non-Nav pseudoranges andmeasurements
• Interoperability analysis between GALILEO and Non Nav systems concerning thehybridisation of Non-Nav pseudoranges and measurements (mix of GALILEO TOAmeasurements and Non Nav systems TOA measurements), as detailed in thefollowing:
1. Detailed Analysis for GSM/UMTS ranging using time-differences aspseudorange measurements
2. The possibility of using secondary systems (Bluetooth, WLAN, TETRA) asranging sources will be explored through a Limited Analysis. Only mainrelevant issues and recommendations will be provided
6.2.1 DETAILED ANALYSIS: GSM/UMTS SYSTEM INTERFACES
6.2.1.1 GALILEO-GSM Hybridisation at level 3A
Only relevant issues and results of the IO analysis are reported in the paragraph. EMILYProject basic starting points are hereinafter reported in order to focus on the improvementsthat will be presented in the following paragraphs by interoperability SIA phase.Interoperability at level 3A represents the hybridisation at pseudorange level betweenGALILEO pseudorange measurements and measurements coming from communication-network ranging sources. At this Interoperability level, different type of ranging sources haveto be considered (Satellite and Terrestrial) and correspondent ranging measurementscombined together in order to improve the positioning performances (e.g. better accuracy,increased availability) mainly in typical satellite critical environments, as urban canyon andindoor. Mobile Communication Systems are the best operative candidate systems to be
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 111
Logica
interoperable with GALILEO at level 3A and 3B (hybridisation at position level). Thestarting point of the Interoperability analysis between GALILEO and GSM are previous andparallel relevant studies as for instance the EMILY project, whose main features andobjectives are hereinafter briefly reported.
EMILY aims at building a terminal prototype able to exploit both satellites and MobileTerrestrial Network ranging capabilities. In the EMILY terminal architecture both E-OTDmeasurements and the Assisted GPS measurements are combined at different levels in orderto improve the positioning performances.The options identified by EMILY Projects are briefly reported in the following rows. Theseoptions will be critically analysed and relevant improvements will be given.Three options are foreseen for the measurement combination purpose:
3. In the first option (Loose coupling) the hybridisation is performed at position levelbetween the GPS position solution and the E-OTD (Enhanced Observed TimeDifferences) one. This option corresponds to the Interoperability Level 3B asidentified in the SIA IO analysis.
GPS
E-OTDhybridization
Loose coupling
GPS meas.
OTD meas.
Min 3
Min 3
RTD
GPS
E-OTDhybridization
Loose coupling
GPS meas.
OTD meas.
Min 3
Min 3
RTD
Figure 6-1; Hybridisation at position level
4. In the second option (Tight coupling-partial), positions are derived fromhybridisation of OTDs measurements both from Satellite (derived by rangingmeasurements) and from GSM Base Stations (BTSs). OTDs (Observed TimeDifference) measurements are considered separately for Satellites and BTS and nomixing solution are considered.
5. In the third option (Tight coupling-full) position is derived from hybridisation ofOTDs measured both from Satellite and GSM network Base Stations as well frommix OTDs measurements between satellites and reference BTS.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 112
Logica
hybridization
Tight coupling
GPS meas.
OTD meas.Min 3/4
RTD
Measurement quality report
� Tight Coupling
� Partial� Full hybridization
Tight coupling
GPS meas.
OTD meas.Min 3/4
RTD
Measurement quality report
hybridization
Tight coupling
GPS meas.
OTD meas.Min 3/4
RTD
Measurement quality report
hybridization
Tight coupling
GPS meas.
OTD meas.Min 3/4
RTD
Measurement quality report
� Tight Coupling
� Partial� Full
Figure 6-2; Hybridisation at ranging-measurements level
Tight coupling solutions improve overall positioning system availability, especially the fulloption. For the full option, in fact, three ranging sources (irrespective of Satellite or GSMBTS) are enough for the 2D positioning.
In the ETSI standardised E-OTD for GSM network, the position computation requires themeasurements of OTDs coming from different ranging sources (BTSs), that need to besynchronised each other. In the GSM network, BTSs are not synchronised and OTDsmeasured at GSM MS side do not correspond to the Geometric Time Difference (GTD)because of different time of emission of the reference ranging signals. In the GSM networkLMUs (Location Measurements Unit) are foreseen to overcome the synchronisation problemby calculating the Relative Time Difference between the BTSs involved in the MSpositioning calculation. LMUs perform the time measurements and, on the basis of theirknown precise position, RTDs values are calculated and distributed (e.g. Cell BroadcastServices) to the MS. The density of LMUs is variable in the range of one LMU for 3-5 BTSs.To obtain accurate triangulation, OTD measurements and, for non-synchronised network,RTD measurements are needed for at least three geographically distinct BTSs. Based on suchmeasurements, the location of the MS can be calculated either in the network (MS-Assisted)or in the MS itself (MS-Based) by means of intersection of two hyperbola obtained with threeBTSs and two GTDs.
As other kinds of ranging sources are considered besides the BTSs ones (e.g. OTD Satellitemeasurements), it comes out the necessity to right hybridise different-nature measurements ashighlighted in the EMILY project.
The following main points comes out from EMILY study which are relevant aspects to beconsidered in Interoperability analysis at 3A level between GALILEO and GSM:
• In the �Tight coupling-partial� solution, the main interoperability issue is theimplementation of a suitable Extended Kalman Filter (HEKF), adequate for movingand non-moving scenarios. GTDs measurements between BTS-BTS and SAT-SATare the input of the HEKF, and the interoperability investigation focus on thedefinition of a filter capable to estimate the MS position starting from different natureinput-data. In the Mobile-based solution, no additional data have to be exchangedbetween the MS and the GSM Network besides those ones exchanged for the ETSIstandardised E-OTD. The Hybridisation is fully carried out at Navigation Terminallevel as is presented in the following figure.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 113
As it can be seen, Covariance Matrix 11 is used as a Quality report for hybridisation purposes.
Details about covariance errors will be given in the following paragraphs
• In the �Tight coupling-full� solution, the main interoperability issues are:
1. Observed Time differences BTS-SAT definition and calculation. In thehandset based positioning methods, the MS has to be able to perform such anhybrid time difference measurements between the GPS frame and the BTSframe. In the Terminal Hybridisation architecture there is a BTS-SAT module,which is able to compute the OTD BTS-SAT and correct the measurements
11 Covariance Matrix is commonly expressed as in the following:
])')([()cov(^^xxxxEx −−=
where )(^xx − represent the measurements error, depending on the technical solution to be
implemented. More. For instance, for a two dimensional input vector (x and y representingtwo different time difference measurements errors statistics):
��
�
�
��
�
�=
οοο
ο2
2
)cov(yyx
xyxx
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 114
Logica
in order to give GTD BTS-SAT and covariance values as input for theExtended Kalman filter.
2. Relative Time Differences BTS-SAT calculation and distribution. The GSMLMU has to calculate such hybrid Relative Time Differences measurementson the basis of the BTS positions and Satellites positions (ephemeris) and ofthe observed BTS-SAT time differences as defined in the previous point.Processing upgrade of LMUs (equipped with a GALILEO/GPS receiver inorder to provide a common time reference) has to be considered for RTDBTS-SAT computation and Signalling and processing upgrade have to beconsidered to distribute the RTD BTS-SAT values to the MS. As far as thelatter point, LLP, SMLCPP and RRLP protocols do not require upgrading ifSatellite ranging source are considered as �virtual BTSs”. The only upgradingis the reservation of identification codes for these virtual base stations. RTDBTS-SAT values are inputs for the BTS-SAT module in the Terminalhybridisation architecture.
3. In the �Tight coupling-full� solution, the main interoperability issue is theimplementation of a suitable Extended Kalman Filter (HEKF), adequate formoving and non-moving scenarios. GTDs measurements between BTS-BTS,SAT-SAT and BTS-SAT are the input of the HEKF.
In the following figure the Emily �Tight coupling-full� terminal hybridisation architecture ispresented; in blue are highlighted the differentiation compared to the partial solution terminalarchitecture.
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 115
Logica
SIA Interoperability analysis and improvements
This SIA Interoperability Analysis, starting from the results and consideration made in theEMILY project, aims at better investigating relevant interoperability issues and proposepossible alternative solutions to be deepen in further studies. The following interoperabilityissues have been identified and will be analysed in detail:
� At interoperability level 3B, hybridisation at position level, data fusion mechanismsare investigated in the next chapter in order to get more precise position estimatescombining different position estimates carried out by means of different techniques.
� At Interoperability level 3A (hybridisation at pseudorange measurements level),hybridisation mechanisms are investigated and relevant issues are extracted in orderto combine ranging measurements carried out by means of both GALILEO satelliteand BTSs ranging sources. The SIA will provide relevant issues for the followingaspects:
1. Kalman Filter for measurements-hybridisation in a Emily-like solution.(partial and full solution)In order to improve the reported concept, Kalman filtering techniques (EKFand the innovative improved KF) can be applied. In particular, the problemsrelated to non-linerity and noise propagation shall be kept into account intothe design process in order to avoid divergence of the Kalman filter indynamic situations (e.g. car turning phases)An hybridised Kalman filter, able to perform data fusion using inputs comingfrom different ranging sources should include added states (out of theclassical ones including MS position and velocity for a basic linear KF), suchas NLOS/multipath parameters (also if Network Location Measurements,NLK information, can be used at this purpose) to be inserted within theoverall system model and the relevant E-OTD measurements model with therespective variance in the covariance matrices elements. This allows toimprove measurements estimation accuracy and filter robustness in non-nominal conditions. Tight full coupling solutions (involving mixed BTS-SATmeasurements), will imply a statistic correlation and the relevantmeasurements (sat i, BTSj-Sati, BTSi-BTSi), if the relevant covariances andparameters are estimated and propagated within the KF, shall be processed inparallel in a single KF step (instead of processing sequentially one by one therelevant ranging measurements, as in classical navigation EKF). This impliesan increased computational effort due to the operations with sparsecovariance matrix
2. New KF algorithms, such as Unscented Kalman Filter (see as an overallintroduction �The Unscented Kalman Filter for Nonlinear Estimation", E.A.Wan, R. van der Merwe), due to their property to work in a very robust waywith non-linear systems, can be usefully applied to the implementation of thehybridised receiver.. Heading information are important, especially for roadapplications and should be inserted into the position and velocity estimationprocess
� EMILY Solution can be improved and updated through BTSs Synchronisation bymeans of GALILEO reference time. In this GSM network design, the clock of all theBTSs are synchronised by using the GALILEO common clock source, and the
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 116
Relative Time Differences reports could become unnecessary information for GTDscalculation. Relevant impacts will be carried out in the next issue of the document.
6.2.1.2 EKF Data Fusion approach for full coupling solutions
The data fusion process is based the integration of E-OTD measurements and NavigationSatellite measurements, as reported in EMILY.EMILY uses a simplified version of the EKF in order to process the E-OTD data, combiningboth BTS-to-BTS SAT-to-SAT differences and BTS-to-SAT differences.
Measurementstransformation
Measurements input
Dimensionalityreduction
Instantaneous GTD MeasurementsNBTS + NSAT - 1
From SATELLITES& BASE-STATIONS
Pre
Instantaneous positioning er r (innovation)
NBTS + NSAT - 2
Full
Partial
Measurementstransformation
Measurements input
Dimensionalityreduction
Instantaneous GTD MeasurementsNBTS + NSAT - 1
From SATELLITES& BASE-STATIONS
Pre
Instantaneous positioning er r (innovation)
NBTS + NSAT - 2
Full
Partial
(Architectural Scheme from
SIA interpreted the functional scheme proderived in the following relevant detail anaThe details and characterisation of modelsthis file, but some considerations can bimprovement of the Kalman Filter.
The basic points for the analysis and impro• Identification of the Model of the • Identification of the noise characte• Considerations about computation
Box 2 (indicated by a box within the positioning purposes. The simplest modethe applied Kalman Filtering and Extended
k
k
k
k Guxx
kkxx
+��
���
�+Φ=�
�
���
�
+
+
+
+ ),1(1
1
1
1
��
where x is the mobile position (2-D or 3-DOn the other hand, the output of the filter i
2
1 Linear Kalman
2 or 3 (altitude)
vious estimate
Linear Kalman
2 or 3 (altitude)
vious estimate
EMILY External Review
vided only in EMILY hlysis and improvements. were not available at thee carried out in order
vement of the Kalman FLinear Kalman Filter userising the E-OTD and RTal efficiency and robustn
picture) is the classical l to be applied is the fol Kalman filtering can be
kwk +)(
), depending on the numbs the estimated position i
roro
Logica
PositionestimationPositionestimation
presentation)
igh level presentation and
moment of the writing ofto start the analysis and
ilter are the following:d in the EMILY approachD measurements
ess
Linear Kalman filter forlowing (an introduction to found in R[47]):
er of measurements.tself.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 117
Logica
��
���
�=
+
+
1
1
k
k
xx
Hy�
Main issues regarding Box 1 (see Architectural Scheme above)
This function takes in input the OTDi and Delta GPS measurements and calculate the positionerror wrt the previous step estimate.If we express the measurements in the following way:
Where X is the true User position, Bi the ith BTS and BR the reference BTS, while
Where X is the true User position, Si the ith GPS/GALILEO satellite and SR the referenceGPS/GALILEO satellite.
For the mixed measurements:
We can find, using measurements linearisation, that (e.g. see R[47]):
Where:
is the position error wrt to the previous Kalman estimate.
We can express the Jacobian of the measurements as:
Rii BXBXOTD −−−=
Rii SXSXGALILEOGPS −−−=∆ /
ε^
^*
XXfYY
∂∂=−
^XX −=ε
RR SXBXGALILEOGPSBTS −−−=−∆ /
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 118
Logica
)(
.......
...............
^1
1
1
1
1
1
1
^XF
SXSy
SXBy
SXSx
SXBx
SXSy
SXSy
SXSx
SXSx
SXSy
SXSy
SXSx
SXSx
BXBy
BXBy
BXBx
BXBx
BXBy
BXBy
BXBx
BXBx
Uf
R
R
n
R
R
R
n
R
R
R
n
n
R
R
n
n
R
R
nR
R
R
R
n
n
R
R
n
n
R
R
R
R
X
=
��������������
�
�
��������������
�
�
−−−
−−
−−−
−−
−−−
−−
−−−
−−
−−−
−−
−−−
−−
−−−
−−
−−−
−−
−−−
−−
−−−
−−
=∂∂
Applying the pseudoinverse of the Jacobian, we can express the output of box 1 as:
The previous pseudoinverse reduces the problem from the measurement space (NXN) to thestate space (2X2), allowing a reduction in the complexity of matrix operations..
Noise Propagation(SIA Analysis)
The variance of the measurements can be expressed as:
in the case of OTD measurements, while:
in the case of satellite measurements.
(the multiplier is due to the time difference nature of the measurements, implying the sum oftwo equivalent variances).
The case of mixed measurements is more stringent, because the relevant noise variances canbe expressed as:
It can be seen how the mixed measurement introduce a mix of noises and should be treatedcarefully.
��
���
� −=��
���
� −=− −− )(*)(')'(^
*^
*1^
XYYFXYYFFFXX
)(2 22_
2MultipathCLKBTSY σσσ +=
)(2 22_/
2MultipathclockGALILEOGPSY σσσ +=
222_/
2MultipathBTSclockGALILEOGPSY σσσσ ++=
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 119
Logica
It can be concluded that the first box introduces a noise with std deviation proportional to√2the single measurements std deviation plus the std deviation due to the non linearityintroduced by the position solution algorithm.Due to the linearisation, the Box 1 solution strictly depends on the error of the positionestimate wrt to the real position of the mobile user. An high error in the position estimate,introduces an high error into the output of box 1 that can lead to a divergence of thesubsequent Kalman Filter.In particular, an initial position estimate (e.g. calculated only using OTD measurements orCell-ID in the case the number of measurements are not sufficient in order to estimate theposition) far from the real position can lead to a rapid divergence of the Kalman Filter in box2 starting from the bad outputs of box 1.
Emily suggests that Weighted pseudoinverse can be used (pre-whitening block in R[1]) inorder to balance the different variances introduced by the different measurements (E-OTD,GPS, mixed BTS-Sat).
Box 2 (see Architectural Scheme above)
(SIA Analysis)
It is a linear Kalman Filter operating with the position error estimate coming from the Box 1as measurement and producing the new position estimate.
The system is characterised by a simple model (this is a classical approach for sequentialKalman Filter; details and applications in R[47]):
Where ∆ is the sampling step.
The real measurement in input is the position error, that can be easily converted before the KFtime update phase into the estimated measurement (in this case the position estimate) in thefollowing way:
Where ∆ is the sampling step.
����
�
�
����
�
�
∆∆
=+Φ
10000100
010001
),1( kk
^^^
0X
IXHY �
�
���
�==
^** XYY +=
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 120
Logica
It is evident that the state estimate is dependent on the accuracy of the related measurementcoming from box 1 (position error estimate).
An important issue to be pointed out for car application is that heading information areimportant. They have a relevant impact in the turning phase of a car, where covarianceestimate could fail due to the sudden change in the position (high dynamics).
At this aim, the state estimate should contain the heading information (extracted throughGPS/GALILEO velocity measurements12 or external sensors, like dead reckoning systems).The heading information are significant in particular during high speed manoeuvres and theiruse within the filter can be used into the filter
Recommendations elaborated by SIA phase:
(The following recommendations are obtained by SIA analysis and are provided to EMILYand external projects):1. Non-linearity and differences introduce errors that can imply divergence of the Kalman
filter. New more robust algorithms are necessary, taking into account the not good initialposition estimates available in Urban Areas, ranging from 50 m for the GPS/GALILEOonly case to 10-200 m for the OTD-only cases, to several Km in the case the initialnumber of measurements is not sufficient to perform the initial estimate and the Cell-IDhas to be taken as initial estimation
2. Heading information should be inserted into the Kalman filter estimate in order to takeinto account for the high dynamics during the vehicles turning phases
3. The error propagation has a relevant impact , due to the fact that we are operating withdifferential measurements and the standard deviation are propagating at least with a √2law and the linearisation introduces further errors. At the aim at reducing the effect of thiserror, it seems to try to model at least multipath errors if not yet developed . Many studieshave been developed on this field (e.g. in R[9]) in order to estimate the NLOS error (NonLine Of Sight)
4. Use of new KF algorithms (see Improved Kalman Filter in the following paragraph) ableto operate in a robust way with non linear systems and highly reducing the CovarianceMatrix propagation errors and the relevant computational complexity are recommended
5. A further source of error could be due to RTD measurements noise, due essentially to thesingle BTS clock accuracy and to the age of the RTD corrections, that can lead to a drift(30 sec update rate is recommended). Both those source of error can be reduced if themobile networks will be synchronised with the GALILEO time (see followingparagraphs)
12 Starting from the component of velocity along the North (vn) and along East (ve), the hading
information is defined as ���
����
�=
n
e
vva tanϕ
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 121
Logica
6.2.1.2.1 OTD and RTD measurements noise characterisation
(SIA complement to the EMILY analysis)
OTD measurement noise propagation is an important issue to be taken into account for theconvergence of the filter. In particular, the Noise that characterise the Output of Block 1 hasto be highly analysed, being the input to the Linear Kalman Filter (implying the linearisationof the equations to be solved for position estimation purposes).
The other point to understand is if into the block 2 the measurements noise are characterisedand in which degree.
Regarding RTD measurements, It has to be pointed out that the frequency accuracy of thesingles BTS is irrelevant for E-OTD measurements, being it only based on relative stability ofgroups of nearby BTSs. It determines, furthermore, the rate at which LMU-RTD have to becommunicated.
A LMU is able to observe RTD after they have been corrupted by multipath and randomnoise in the receiver.The variance of the observation can be defined as:
)(2 222_ σσσσ
MSMPBTSobsOTD ++=
where σ 2
BTS is the BTS timing noise, σ 2
MP is the multipath noise and σ 2
MS the radio
propagation noise. Only σ BTS is relevant for E-OTD measurements, while the others arecommon errors and can be averaged away in the LMU measurement.
Some trials (see R[3]) showed that σ 2
_ ObsOTD amounts to about 27 m in an typical urban
environment solution.The other point to be better exploited in EMILY is the behaviour of the RTD estimation andtheir broadcasting time to the Mobile. RTD measurements are characterised by drifts and therelevant update time has an impact on the Kalman filter position estimation accuracy. Somestudies (R[3]) about that issue gives an estimation of the RTD measurements parameters:
• Standard deviation: of E-OTD measurements are in the order of 20-80 m• Drift: -1.26m/s
These average values. RTD drifts and Standard deviation are depending on the BTS networksbehaviours.
In EMILY it is not evident if RTD drift parameter is estimated within the Kalman Filter. Incase it is not considered in that solution, a state should be added in order to estimate relevantdrifts and allows a more accurate estimation of its effect on the Kalman filter measurementspassed as input from the Measurement transformation block. The above values can be used asinitial estimation of variance and drift state.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 122
Logica
The block Measurement Transformation in R[1] is derived from the combination of E-OTDmeasurements. This leads also to the combination of errors and has an impacts on theprecision of the innovation process for the Kalman filter.
6.2.1.3 Improvements of EKF
(SIA Phase Analysis)
New algorithms have been developed during recent years in order to perform very robustposition determination for non-linear systems.Those Enhanced Kalman Filtering techniques introduce the following improvements:
• Allows a robust treatment of Non-linear measurements, avoiding the linearisationprocess
• Covariance propagation is efficiently carried out through points sampling, instead ofusing classical matrix multiplication propagation expressions
• Allows a reduction of computational complexity (due to the covariance propagationby points instead of by matrix multiplication)
Kalman Filters for the non-linear systems are essentially based on the linearisation of stateequations and measurements. For the propagation of the Covariance matrix in the followingway:
Where Φ is the Jacobian of the state transition equation (nonlinear) and Q is the StateCovariance Matrix of the KF state noise.
Similarly, the Observation equation is expanded around the state estimate and is truncated atthe first order Taylor expansion-
Using the EKF procedures, only the first two moments (mean value and variance) areconsidered during the state estimation.
This propagation procedure implies errors that introduce computational complexity and canlead to a bad estimation of the state, as in the case of mobiles tracking, where the largestuncertainty of the position and heading of a car or a person (e.g. during a 90° turning) bring toan incorrect covariance estimation. This can lead to very low performances in the case of BTSand GPS/GALILEO measurements fusion as foreseen in HEKF (R[2]), where Box 1linearisation is the starting point.
For this reason, some extension of EKF have been carried out, allowing very robust behaviourand avoiding the high computational complexity and non-linearity introduced by Jacobiancalculation. They are essentially based on the propagation of Covariance Matrix by points,avoiding the calculation of the state transition matrix.
QkkPkkP +ΦΦ=+ ')|()|1(
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 123
Logica
Therefore, the use of this KF extension is highly recommended, considering the inherent nonlinearity introduced by the mobile trajectory and heading and the noise characteristicsinvolved into the BTS ranging measurements to be fused with satellite ones.
Recommendations from SIA Phase to external projects:• Analyse the behaviour of HEKF in nominal and Critical situation (straightforward,
turning left/right)• Introduce and develop Advanced Navigation Kalman Filter techniques (UKF) able to
operate with the inherent non-linearity involved in mobile tracking.
The 3A analysis showed that:• The main performance improvement derived from the hybridisation of GSM and
UMTS ranging measurements is due to the increase on availability. GSM and UMTSranging hybridisation can, infact, provide higher availability and accuracy whereGALILEO (integrated with GPS) cannot: Urban Canyons, light indoor, etc.
• Secondary systems (used in alternative mode) can provide a positioning solution alsoin environments in which GALILEO positioning is not available. They will beevaluated at level 3B and are summarised at par. 6.2.1.5
Availability Improvements
The Assisted GALILEO solution integrated with hybridisation issues can provide highavailability improvements. A detailed availability study is necessary in order to extractnumerical values for availability improvements. Availability depends of course on BTSsgeographical distribution and GSM/UMTS service failures statistics information (e.g. MTBFand MTRR). A high improvement is particularly foreseen in urban environment, where thelack of visible satellites due to shadowing can be overcame by the use of GSM/UMTS BTSranging signals. The more direct way to show this improvement is to report the ServiceCoverage constraints in terms of minimum number of available measurements for positiondetermination:
• Tight Partial coupling solution:2-D: 2 GNSS satellites + 2 BTSs are sufficient for positioning3-D: 2(3) GNSS satellites + 3(2) BTSs are sufficient for positioning
• Tight Full coupling solution:2-D: 2(1) GNSS satellites + 1(2) BTSs are sufficient for positioning3-D: 1(3) GNSS satellites + 3(1) BTSs or 2 BTSs + 2 GNSS satellites are sufficientfor positioning
This clearly introduces a great improvement in availability wrt the satellite only solution,allowing positioning also with respectively 2 or 1 GNSS satellites
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 124
Logica
Accuracy Improvements
• Tight Coupling Partial: The accuracy performances of a hybridised GNSS arecomparable with the ones obtainable in a current assisted GPS + hybridised solution:50 m � 200 m are typical ranges for urban canyons and indoor positioning. Theimprovements in geometry (higher PDOP) with respect to nominal satellitenavigation systems in critical environment cannot compensate the errors introducedby the less accurate BTSs ranging measurements
• Tight Coupling Full: in this case a new mixed measurement BTSs-SAT has a badrange accuracy (e.g. 146 m, as reported in R[1] analysis) It is expected that this willimpact mainly on the availability, while the relevant position accuracy will remain atthe same levels as in the Tight Partial
• Proposed KF techniques: new techniques, avoiding the calculation of the Jacobianmatrix for Covariance Matrix propagation, allows to highly reduce errors due to nonlinearity, e.g. introduced during 90° turning phase of a vehicle and allows a veryrobust solution, also starting from an initial bad positioned estimation
6.2.1.5 GALILEO-UMTS Hybridisation at level 3ASimilar considerations to what has been derived for GSM can be repeated for UMTSintegration. The basic difference is related to the fact that UMTS do not require RTDcalculation (from the network side) and utilisation in the position solution algorithm (from theterminal side). Same KF models can be implemented for UMTS hybridisation
6.2.2 “LIMITED ANALYSIS” SYSTEM INTERFACES
Bluetooth and other secondary systems are analysed at 3B level because the systems areconsidered Alternative for position determination, and not for ranging measurementshybridisation. Details about secondary systems can be found at paragraph 7.2.3. Theconsideration follows from the fact that:
• GALILEO provides good position and ranging measurements statistics in outdoorand light indoor positioning through A-GALILEO and hybridisation with mobileoperators BTSs ranging measurements.
• GALILEO signal is not available in deep indoor and very critical environment, whilethrough Assisted Navigation techniques it can provide bad accuracy (50 m-100 m)not comparable with secondary systems performances (e.g. UWB: decimetres level,Bluetooth and WLAN less than 10 m) only in light indoor
• If Secondary systems are not available in indoor or critical environment situationsand satellite systems (or assisted one) cannot be used, alternative fixed solution shallbe developed (e.g. being within a geolocated buildings, simply the presence in thebuilding can be communicated)
The derived ranking can be represented in the following table, where in yellow arehighlighted the critical points (performance are qualitative in order to emphasise thedifferences between the different systems).
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 125
Logica
Positioning systems based on TETRA are not available at the moment.Otherwise, being the system operating in a similar way to GSM, time differencesmeasurements can be developed in that case. A detailed analysis is needed in order to performthe feasibility of that possibility and the analysis of relevant hybridisation is recommended forfuture studies.On the other hand, ranging measurements, based on time differences, could be developed inthe future and a hybridisation at ranging level is foreseeable in the future in order to augmentthe availability of GALILEO in urban areas. It is expected that the relevant obtainableaccuracy can be comparable with the E-OTD one.Therefore, it is foreseeable that the TETRA could, if the time difference measurability will bedemonstrated, in the future complement GSM for urban areas and main roads coverage interms of ranging measurements.
Mapping of Positioning Systems vs. Environments
GALILEO/GPS A-GNSS HybridisedGSM/UMTS
Assisted GNSS
Bluetooth(***)
WLAN(***)
UWB TETRA
DeepIndoor/Tunnel
N/A N/A N/A 10m 10m 10-30cm
N/A
LightIndoor
N/A (very badperformances if
available)
20-100 m(*)
20-200 m(**)
10m 10m 10-30cm
N/A
UrbanCanyon
N/A (very badperformances if
available)
10-50 m(*)
10-50 m(**)
N/A N/A N/A N/A
Outdoor <10 m <10 m <10 m N/A N/A N/A N/A
Table 6-1- Mapping of Positioning Systems vs. Environments
(*) = available with sufficient number of satellites (at minimum 3, e.g. urban canyons or near windows within buildings) trackedusing assisted navigation techniques (not usable through nominal receivers)(**) = higher availability compared to A-GNSS solution due to use of external range measurements (e.g. indoor environmentwith number of tracked satellites ≤ 2: needed hybridisation with GSM/UMTS BTSs ranging measurement for positioncomputation)(***)= the reported accuracy levels are depending on the availability of the short range systems infrastructures in the consideredenvironments
Interoperability Levels
GALILEO/GPS A-GNSS
HybridisedAssisted
GNSS/GSM/UMTS
Bluetooth WLAN UWB TETRA
DeepIndoor/Tunnel
N/A N/A N/A 3B 3B 3B N/A
Light Indoor 3A 3A 3A/3B 3B 3B 3B N/AUrban
Canyon3A 3A 3A/3B N/A 3B 3B N/A
Outdoor 3A 3A 3B N/A N/A N/A N/A
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 126
Logica
6.2.3 TRANSITION AMONG SYSTEMS (DUAL MODE/STAND-ALONE MODE)
Hybridization at Level 3 is the relevant Interoperability issue for GALILEO in order toimprove the positioning service performance mainly in terms of position solution accuracyand service coverage.As we have highlighted in the previous paragraphs, hybridization at ranging level 3A betweentwo systems means to use measurements coming from different non-homogeneous sources ofthe considered systems, and merge them into a unique solution. The relevant improvement isin this case an increased coverage of the combined-system. Typical options are, as we haveseen above, the hybridization of GALILEO and Mobile Communication systems rangingmeasurements. In this case the UT shall be able to receive signals coming from satellites andMobile Networks Base Stations, and to perform the relevant ranging measurements. TheGALILEO UT shall foresee two different operation modes:
Basically the standard default mode should be the (A)-GALILEO stand-alone one in order tominimize power consumption and time to position calculation. The switch from theGALILEO stand-alone mode to the hybridized dual-mode shall be considered if:
3. The GALILEO UT automatically detects that GALILEO position performances aredegraded due to shadowing problems and noise environments, especially in urbancanyon environments. The UT in this case foresees a �monitoring function� of theGALILEO position performance and automatically activates the dual-mode status ifthe performances remain under a fixed quality-threshold more than a given time out(Time out 1 in the figure below). The UT will come back to the GALILEO-stand-alone mode as the GALILEO performances come back to a satisfying quality level(over the threshold) for a time longer than a given time out (Time Out 2 in the figurebelow)
4. The User manually select the hybridized option on the GALILEO UT, in order toincrease the number of measurements and the position performances even if theGALILEO positioning service is available
In the following figure is represented the logical switching rule between the GALILEO stand-alone and the hybridized mode.
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 127
Logica
The relevant parameters used in the switching algorithm are:
� The choice of the GALILEO performance quality-parameters to be monitored: thequality-parameter (e.g. PDOP, number of visible satellites, SNR, measurements noiseinformation, etc.) represents the GALILEO quality of service and its choice has an impacton the overall service performances, mainly in terms of service continuity in theTransition Areas. Factors that influence the quality parameter are mainly the number ofavailable measurements (e.g. at least 3 satellites for 2-D positioning: if less than 3satellites are available, adding rangings from GSM or UMTS BTSs are needed) andPDOP values.
� The choice of the threshold values: its choice is relevant in order to guarantee the servicecontinuity and at the same time to minimize the power consumption and the waste ofresources. The threshold value depends on the chosen quality parameter.
� The choice of the time-outs (in the figure indicated as TO1 and TO2): Time Out valuesare relevant to control the switching functionality between the different modes. Theirchoice has to be done in order to guarantee the stability of the system and at the sametime the service continuity in the transition areas.
As far as the hybridization at Level 3B (Positioning hybridization) is concerned, theGALILEO UT should be able to perform both the GALILEO position and the NonNavigation Systems position, and at least to hybridize them in order to improve the accuracyor use them in alternative mode in order to guarantee the service continuity where GALILEOservice is not available.
The operational mode considered are:� GALILEO stand-alone mode (A-GALILEO stand alone mode)� GALILEO-Non Nav System hybridised mode (or dual mode)
The default mode should be the GALILEO stand-alone mode in order to minimize the UserTerminal consumption and resource utilizing. If GALILEO position service is available withsatisfying quality of service, there are no reasons to calculate other position solutionscharacterized by similar performances and to use them in combination with the GALILEOone.The switch from the GALILEO stand alone mode to the hybridized mode should be foreseenin the following different cases:
� The GALILEO positioning performances are degraded and a threshold-basedalgorithm (PDOP, position estimation covariance matrix elements, etc..) couldmanage the switching function, in order to use a back up positioning system (EOTD,OTDOA, Local Positioning Systems). This case is the typical one that occurs whenthe terminal moves from a clear-sky environment towards a high-density urban area(urban canyon) characterized by shadowing problems (e.g. less than 3 satellites invisibility do not allows independent GALILEO positioning)
� The GALILEO service is available and the user manually selects the hybridizedmode; in this case the position solution are merged on the basis of the quality reportof the single position solution.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 128
Logica
� The GALILEO UT, interoperable with Local Positioning Systems, (Bluetooth,WLAN, DECT) detects a Local Positioning Environment, as for instance a Bluetoothpiconet. In this case the GALILEO UT shall foresee the option to automaticallyswitch to the Local Systems by previously verifying the availability of the PositioningService. If this service is available, the short-range features of such systems shouldguarantee a satisfying accuracy level. Typical scenario is in this case the transition ofthe GALILEO user from an open environment (GALILEO available) towards a lightindoor environment.
The figure below shows the transitions areas for a GALILEO UT hybridized at IO level 3with Non Navigation Systems, which moves from a clear sky environment towards an indoorenvironment.
Clear Sky Sub Urban Urban Light Indoor Deep Indoor
GALILEO Stand-Alone
GALILEO-Mobile Networks Hybridized mode
GALILEO-Local Positioning Hybridized mode
Figure 6-6- Transition Scenario among systems
6.3 SUMMARY OF CERTIFICATION AND STANDARDISATIONISSUES
The introduction of new ranging measurements for position calculation will impact mainly oncertification and standardisation. In particular, the Safety of Life application will be moreaffected by the introduction of new ranging measurements.For the Aviation sector, the presence of a new constellation implies the start of a newcertification process as an extension of the EGNOS case (see Legal issue for level 3Bconsiderations regarding the hybridisation of different positioning solutions). Performancesderiving by an integrated system shall be tested accurately, in order to guarantee the requiredaccuracy level. Having an added ranging measurement to be integrated in the positioncalculation do not seems to be the right solution, while reliability can improve due to the factthat an independent constellation (by which independent measurements can be derived) isavailable. Otherwise, the possibility to have two independent systems, acting one as backupof the other, should be investigated by Aviation Authority (ICAO), so that a complete datafusion at measurements level could be not the baseline. At least, a switch to alternative mode(level 3B) should be foreseen in the case one system should decrease its global performances
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 129
Logica
due to overall systems failure or during crisis situation. It is recommended for GALILEO tofollow and give support to the Aviation Certification Process, e.g. through dedicated conjointPilot Projects in the field of ranging.For Maritime, the basic recommendation is related to the inclusion of GALILEO in RTCMstandards so that Maritime equipment can use also differential corrections coming fromGALILEO Local elements.Regarding Mass-Market and Emergency Services, no basic constraints are foreseeable, out ofthe E-911 and E-112 requirements satisfaction. This should not be a problem, due to the highforeseen performances of GALILEO and the improvements that an integrated A-GALILEO+A-GPS system can introduce in terms of availability and accuracy.More relevant issues related to position hybridisation and standardisation will be reported atlevel 3B (Par. 7.3).
6.4 MRD & SRD RECOMMENDATIONS AT INTEROPERABILITYLEVEL 3A
6.4.1 GSM AND UMTS SYSTEMS
• Comment on MRD 1301 Navigation – Communication user equipmentIntegrated solution for satellite navigation (GPS) and Communication systems (GSM)assisted solutions exists yet now (e.g. Snaptrack solution).A point regarding Assisted-Navigation shall be explicitly added into the requirement(e.g. adding � and to implemented Assisted-GALILEO solutions).GALILEO will be independent from any other navigation satellite systems.Otherwise, the possibility to complement GALILEO with GPS at user terminal inorder to improve visibility in urban canyons is recommended.
1. Time synchronisationFor a full tight hybridisation (integrating also BTS-SAT measurements), timesynchronisation between GSM frame and Satellite code pulses are fundamental. Atthis aim it is important to design the GALILEO signal and chip rate in order to beeasily usable within a tight/full terminal for the mixed ranging solutions. This isparticularly important for LMUs implementations, which should be equipped withGALILEO receivers. These recommendations will have an impact for the use of E-OTD measurements and for the implementation of BTS-Sat mixed time differencesolutions.In case a full synchronisation between GALILEO time and GSM Network time willbe implemented (each BTS having the same synchronised time reference withGALILEO), the necessity to calculate RTD will decade. This NetworkSynchronisation solution has to be investigated with GSM Mobile Operators atrelevant Standard Forums, being a recommendation more related to Mobile operators,but having high impact on GALILEO Revenues and on LBS servicesexploitation.
A new requirement is recommended:
MR-312a: Time alignment with External NetworksThe design of the GALILEO code has to be developed in order to be aligned withGSM frame and to allow an easy use of mixed time differences between satellites andmobile communication systems
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 130
Logica
2. Terminal HybridisationLow Cost integrated Navigation and Mobile Communication Receiver have to bedesigned, able to perform mixing of ranging solutions, using GALILEOmeasurements, GPS measurements and Mobile communication systemsmeasurements and able to perform A-GALILEO solutions. Relevant integratedsolutions of GPS within GSM terminals able to hybridise GSM E-OTD measurementsnow exists. GALILEO shall be integrated in those solutions. The present analysisdemonstrated that the tight/partial solution integration (use of only separate timedifferences between satellite and between BTSs, without calculating mixed rangingbetween BTSs and satellites) is the easiest one to be implemented by now, especiallyfor the problems related to the alignment between GSM and GPS/GALILEO signals.A tight/full integration is foreseeable in a completely integrated GSM/GALILEOchipset and in the case MR-312 requirement will be implemented
MR-1301a Terminal Hybridisation at measurements levelGALILEO navigation module shall be integrated at low cost in an enhanced mobileterminal able to process mixed measurements from mobile systems (e.g. E-OTD,TDOA) and satellite systems (GALILEO and GPS) for positioning purposesMR-1301b – Minimum Terminal Hybridisation levelFuture hybridised GSM/GALILEO-GPS terminals will be able at least to processseparately time differences from GSM BTSs and ranging differences betweensatellites for positioning purposes. If time synchronisation between GSM andGALILEO will be implemented, a tight full solution using also mixed BTSs-satelliteranging measurement shall be developed
3. Augmentation Messages processingGALILEO navigation module will be integrated within a mobile phone for manyapplications (e.g. Personal emergency). At this aim GALILEO navigation moduleshall be able to process E-OTD Assistance data (e.g. RTD) in an ETSI standardformat. New requirement:MR-1301c: ETSI standard processingGALILEO navigation module shall include the option to process E-OTD Assistancedata in an ETSI format
6.5 ISSUES FOR OTHER GALILEI TASKS AND OTHER STUDIES
Pilot Projects1. Future Pilot Projects shall validate the integration of GALILEO, GPS and GSM
measurements in a tight configuration2. Future Pilot Projects shall study the integration of external sensors (odometers, dead-
reckoning, etc.) measurements within the previous hybridised terminal and to studythe relevant performances improvements
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 131
Logica
6.5.1 RECOMMENDATIONS FOR B2 ICDS
6.5.1.1 Impacts on Galileo to UMTS ICD ID/GAL/0085/GLI
Hybrid positioning solutions:1. The ICD does not analyse the hybridisation of GALILEO with UMTS at ranging
measurements (through OTDOA) and position determination levels. In particular, it isrecommended to include hybridisation techniques into the ICD. Various aspects havebeen here examined from the point of view of terminal integration (separate RF-frontend are needed, improvements in Kalman Filtering ranging measurements integration,etc..). The improvements in terms of GALILEO system availability shall beinvestigated during the design phase. Furthermore, GSM E-OTD measurements datafusion shall be investigated
2. The definition of Interfaces between GALILEO Local Elements and UMTS networkis essential for the provision of the future GALILEO CS services
3. GSM is not considered in any B2 ICD, while it is foreseeable that UMTS will bedelayed and GSM will continue to exist as complementary system to UMTS: An ICDabout GSM-GALILEO integration including E-OTD measurements hybridisation isrecommended
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 132
Logica
7 NAVIGATION SYSTEM-INTEROPERABILITY LEVEL3B: HYBRIDISATION OF GNSS AND NON-NAVPOSITIONS
7.1 DESCRIPTION OF THE FUNCTIONS AT THIS LEVEL
The interoperability between Galileo and relevant Non-Nav-Systems will be evaluated at IO-Level 3, for various systems.Functions at processing level 3B are:
1. Hybridisation at position level2. Adaptation to transmission protocol
Input Systems at this level will be mainly other Non Nav positioning sources (e.g. E-OTD,OTDOA) to be hybridised GALILEO positioning solution. The output systems are thecommunication User terminal (e.g. GSM Mobile Station, UMTS user equipment)
The objectives are to:• Define the hybridisation options between the GNSS position and the Non Nav
systems based position. Hybridisation is considered at positioning level (level 3B)• Provide recommendations and evaluate impacts on MRD/SRD Phase B2 based on the
performed analysis work for the refinement of GALILEO�s baselineIn the following paragraphs, general descriptions of interoperability analysis at 3B-level andrelevant results are presented, mainly in terms of impacts on GALILEO HLD/MRD. Detailsof the analysis are reported in the DD-080 deliverable.
7.2 SYSTEM INTERFACES
The particular system interfaces that should be analysed have to be deduced from the rankedrequirements table produced by MIA.In the paragraph relevant results coming from IO analysis are reported concerning thehybridisation option at position level for the following system interfaces:
• GSM/E-OTD• UMTS/O-TDOA• A Limited Analysis is performed to carry out relevant issues for Other Secondary
systems (e.g. Bluetooth, Tetra)
For each identified system interface, relevant results are reported coming from the followingIO analysis tasks:
• Review and elaboration of results of relevant other projects concerning thehybridisation between GNSS and Non-Nav positions.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 133
Logica
GALILEO
Accuracy (metres)
Cellular Positioning
1 3 10 30 100 300 1K 3K 10K 30K
Bluetooth
Local Positioning
Rural
Urban
eg E-OTD
Cell I.D.
GPS
City/Indoor
Remote
0.1 0.3
PrecisionLocal
Positioning(UWB)
• Interoperability analysis between GALILEO and Non Nav systems concerning thehybridisation of Non-Nav and GNSS positions (combination of GALILEO and NonNav systems calculated position) with the aim to:
1. Describe the Navigation User Terminal interfaces, identifying the relevantinterfacing system entities and their specifications
2. Investigate the main Interfacing system entities identified.3. Report the outputs of the IO analysis at User Terminal level, in terms of
System Interfaces requirements.
7.2.1 GSM/UMTS SYSTEM INTERFACES
In the following paragraphs the aspects related to the algorithms and elements to be used forhybridisation of position solutions among different navigation sensors at system level will bedetailed.
7.2.1.1 E-OTD Hybridisation at IO Level 3B: positioning system level
In order to introduce the hybridisation at position level, it is important to briefly report theaccuracy of the positioning systems that will be examined against the environment. In thefollowing a Scheme showing the relevant performances of current positioning systems isreported.
Figure 7-1- Overview of Systems accuracy vs. Environments
7.2.1.1.1 Bayesian Estimation
(SIA Phase Analysis: relevant EMILY docs came after the delivery of this paragraph: thechoice of a similar approach confirms the right choice of both studies).Bayesian Estimation is a data fusion technique based on the combination of the statisticalinformation of different process in order to obtain an improved solution.Different Bayesian solutions are possible:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 134
Logica
• Incomplete solution: only single variances are mixed in order to estimate the combinedsolution
• Complete solution: complete covariance matrixes are mixed in order to estimate thecombined solution
• Switch (or Alternative) solution: the differences between the variances are so high (e.g.a single solution is very much better than the other ones), that only one of the systems isused for the position determination, while the others are momentarily discarded
In order to provide the framework of the hybridisation at position level, in the most importantpositioning systems are reported.
E-OTD (Enhanced � Observed Time Differences) techniques for positioning has beenanalysed in detail in R [1] and has been used in 3A analysis. Hereinafter only the relevantpoints for interfaces definition will be pointed out.E-OTD (in the hyperbolic location version) is based on the determination in the MobileStation (e.g. receiver) of the Observed Time differences between the receptions of a normal ordummy burst coming from two Base Stations (BTSs in case of GSM). At least 3 BTSs signalsare needed to perform a 2-D positioning. Measurements can be calculated by the MS (MobileStation) without any additional hardware (handset based solution), or can be calculated by theNetworks itself using the measurements acquired by the MS (network based solution)
The basic factor that affects the implementation of such a solution is the presence of asynchronised or unsynchronised network. In an unsynchronised network, frames fromdifferent BTSs are not transmitted synchronously. This implies the need to know thesynchronisation differences between two BTSs in order to allow MS to calculate the correctOTD measurement and therefore the accurate positioning. Those measurements are namedRTDs (Relative Time Differences) and are performed by dedicated Network elements, LMU(Location measurements Unit), whose location is known.
The hyperbolic positioning can be implemented in the following way:
1) Calculation of OTDs by MS: this imply the calculation of time differences between burstscoming from pairs of BTSs
2) Calculation of RTD: this means the calculation of the relative Time synchronisationdifferences between two the observed BTSs performed by LMU and broadcasted to theMS
3) Calculation of GTD (Geometrical Time Difference) between the bursts as received by theMS. GTD is the real measurement to be used in the positioning calculation and is relatedto the previous one by the following relationship:
GTD=OTD-RTD
Only OTDs measurements are not sufficient for positioning calculation and RTD is necessaryat this aim.This imply the presence of LMUs in a ratio of about 1 LMU every 3/5 BTSs.E-OTD accuracy as standalone system is in the order of hundreds of meters.Other relevant GSM positioning methods are the following:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 135
Logica
• Cell-ID: can lead to a positioning accuracy ranging from hundreds of meters toseveral Km, depending on the Cell size: it can be used only for very draft positionestimation and where other systems are not available
• AOA (Angle of Arrival): This method involves analysis of the angle of arrival (AOA)of a signal between the mobile phone and the cellular antenna using antenna sectorinformation (estimated accuracy 150 m)
Hybridisation with GALILEO (both at position and measurement level) can lead to higheraccuracies as reported in R [1].
For UMTS, hybridisation at position level can be obtained using data fusion processingtechniques. This kind of data fusion has been studied in previous researches for TDOA andTOA (see R[4], R[5]).
For interoperability purposes the focus of the investigation mainly concern �Data Fusion�aspects with the aim to combine position data obtained from different source, and relateinformation by accessing relevant database, to achieve better accuracies and more specificinferences compared to the �one source� solution.
Regarding Secondary systems, they mainly operate with similar systems (time differences orAccess Point Location).
The incomplete solution is reported hereinafter.The starting point of the data fusion process is the intuitive fact that gathering the same datafrom independent sources should results in a statistical gain compared to the single-sourcesolution. One possible �data fusion� architecture was elaborated by the data-fusion workinggroup established by the Joint Director of Laboratories (JDL). This data fusion architecture isa conceptual model, which identifies and categorizes the functions and techniques applicableto generic data fusion. In order to make the generic model applicable to position locationproblem, hereinafter is reported the Kleine-Ostmann and Bell proposed model, based on fourfusion levels of the available data. In the figure the model is applied to the TOA and TDOAdata, obtained independently.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 136
Logica
Hybridisation at Level 3A
Hybridisation at Level 3B
Figure 7-2; Position-Data fusion hierarchyAs reported in the data fusion architecture, raw measurements data fusion is made as well asfinal position estimation fusion, where position estimation is performed by two differentmethods, with different error biases and variances. In the latter case the independent positionsfusion has to take into account precise weight of the two estimations according to theirquality, at least in terms of their variances. The following fusion levels are foreseen:
1. The first fusion level consists of combination of raw data coming from differentsources, as we have seen in the previous chapter at 3A interoperability level. Data tobe combined need to be converted in the same typology and format before they arehybridised together. In this case we have an over-determined system of equations andthe weighted least-square (WLS) estimator could be employed to minimize the sumof the weighted square of the errors.
2. The second level data fusion uses the Bayesian Inference to improve an estimate withknown statistic once new data are available. The probability distribution of the oldestimate is updated through the new data probability distribution. In the followingfigure, xc is the centre of mass as an improved estimate over x0 and xm, and thevariance of the new distribution indicates the weight of reliability of the improvedestimate.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 137
If x0 and σ20 are the mean and the variance of one position estimation and xm and σ2
m
are the respective values for the other position estimation, then xc and σ2c will be the
mean and variance of a single estimate using the Bayesian Inference. If we form thehypothesis that both the position estimation distribution are Gaussian, then the meanand variance of the fused position estimate will be:
220
2
0220
20
0
220
220
111
)(11
m
c
mm
m
m
mc
c xxx
xx
x
σσ
σ
οσσ
σσ
σσ
+=
−+
+=+
+=
The second level of data fusion is that one which refers to the 3B interoperabilitylevel.
3. The fourth level of fusion is the final choice level, where the decision is made amongthe different position estimation (starting position estimates, level 1and level 2 fusionposition estimates). The decision is made evaluating the variances of each positionestimator.
A complete hybridisation solution follows the same process, but using the whole covariancematrices instead of the single variances.
The relationship can be expresses in the following way:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 138
Logica
11)( −−+= SatBTSSatSat RRRC ;
11)( −−+= BTSBTSSatBTS RRRC
BTSBTSsatSat xCxCx ��� +=
This solution can be used as it is in a WLS (Weighted Least Square) solution technique, or asa data preprocessor for a Kalman Filter.
7.2.1.1.2 Multiple Kalman Filtering
(SIA Phase Analysis)
The Bayesian approach is simple and compact, but has principally two drawbacks:• It do not take into account the user dynamic• It is not able to carefully follow the changing characteristics of the environment (e.g.
multipath condition) and to correctly propagate the relevant estimate
At this aim, advanced data fusion techniques have been developed concerning differentsensors measurements.In particular, Centralised Kalman filter are the most useful techniques in this field. The basicprinciple of those techniques is:
• To filter separately the outputs coming from each sensor to determine the positionand velocity or heading using a local Kalman Filter
• To combine the position and velocity coming from each sensor through a CentralKalman Filter
The main advantages of the above approach are the following:• Blunder detection: in the case a blunder in a single sensor processing appears, the
error is detected by the Local Kalman filter and the relevant measurements are notprocessed in the Centralised filter, while drifts and other slowly varying errors can beallowed to accumulate until the error can be detected and eliminated by theCentralised Kalman Filter
• Decrease the computational complexity: the number of ops (operation per second)decreases dramatically by segmenting the number of states. This is fundamental forthe most requiring computation, like matrix multiplication in state covariance matrixpropagation and matrix inversion in the KF Gain calculation. For instance,considering the complexity of a matrix multiplication (O(2n3)), if a 20 states KF,including all sensors, is segmented in local KF of about 6 states each, thecomputational load can be decreased by 16000 to 6250 ops.
• Sensor intermittences (e.g. GPS providing position information at 1HZ, while E-OTDproviding information at a lower rate) can be taken into account by the central KFthrough dynamic addition and removal of sensors during the processing
The relevant Centralised KF architecture, applied to the current case, is reported in thefollowing pictureOther Techniques have been developed, allowing the possibility to return information fromthe Central Filter to the Local KFs (Federated Filter). In this case, the dynamic models areseparated, but the KFs driving noise statistical information are in some degree shared amongthe Local KF through the Central KF. As far as we know, this technology has not beenstudied by now in the mobile positioning systems as data sensor fusion.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 139
Logica
Figure 7-4; Multiple Kalman Filter
Using this approach, integration is expandable also to other sensors, like UMTS. It isparticularly useful where there are an insufficient number of available satellites for positiondetermination. Integration at position level could improve performances of the separatesystems also in critical environment.It has to be taken into account that the achievable performances for GSM and UMTS are thefollowing (from Cambridge Positioning Systems evaluations using CURSOR system):
Positioning Method GSM UMTSTDOA/E-OTD 50-160m 5-20mTOA N/A 50-100 m
Considering the higher position error variances introduced into GALILEO measurements bythe critical environment situation (like Urban Canyons, where PDOP is high), it can be seenthat the level of GPS/GALILEO position accuracy will be comparable with the UMTS one.This can lead to a useful sensor fusion with high improvements in availability and not adramatic degradation of positioning performances. The use of less accurate GSM E-OTDsystems will induce the Kalman filter to properly weight the relevant measurement, but theavailability improvement will be significant, at least in the first period of GALILEOoperation, when UMTS could be not completely developed and covering the territory.
Integration of external car sensors is easy to implement due to the modularity and flexibilityof the centralised Kalman filter solution. It will be of particular interest in the future, due tothe fact that some external sensors (like odometers integrated through ABS system) will beembedded by car manufacturers.
GSME-OTDKalman
Filter
UMTSTDOA/TOA
Kalman Filter
CentralKalman
Filter
PositionVelocity
PositionVelocityHeading
GPS/GALILEOKalman Filter
PositionVelocity
PositionVelocity
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 140
Logica
Multiple Kalman Filter solution are the preferred navigation solution mean in the case of highdynamic and are therefore recommended for car and road applications, in particular throughintegration with external sensors like odometers and dead-reckoning systems.The light solution developed in R[1] is considered an optimal trade-off, but could suffer dueto non-linearity problems and relevant covariance propagation effects, especially in case ofhigh dynamics situation and cannot properly manage sensor measurements intermittences(different output rates coming from each sensor).Furthermore, heading information as reported in the previous paragraphs, are important insituation like 90° turn and should be integrated into the position solution. It is thereforerecommended to follow on with the analysis of multiple Kalman Filter and to integrateexternal car sensors into the position solution.
7.2.1.2 OTDOA Hybridisation at IO Level 3B
Identical considerations can be carried out for the development of hybridisation with GSM atposition level. Also in this case, the main difference is related to the fact that RTD values arenot necessary. Similar KF structures can be implemented in this case and integrated into theoverall position solution, as showed above.
7.2.2 ADAPTATION PROTOCOLS
Systems at Level 3 are interfaced at present by using the NMEA 0183, while NMEA 2000protocols are emerging. These should be updated for full compliance with all Galileo services.
Following the analysis previously carried out (e.g. in R[1]), the basic information to betransferred by each sensor for the hybridised for each sensor is:
• Position: X, Y, Z in WGS-84 (or ITRF for GALILEO) or Lat, Long, Height• Quality Report: PDOP, GDOP as minimum for incomplete solution, Covariance
Matrix for a complete solution
7.2.2.1 NMEA-0183 updatings
Following the above analysis, the preferred NMEA-0183 messages containing the basicinformation for positioning purposes, to be sent are basically GGA and GLL in the case ofGPS.
7.2.2.1.1 GGA messageGGA classical message is expressed in the following format:
Name ExampleData Description
Sentence Identifier $GPGGA Global Positioning SystemFix Data
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 141
Logica
Time 170834 17:08:34 Z
Latitude 4124.8963, N 41d 24.8963' N or 41d 24'54" N
Horizontal Dilution of Precision (HDOP) 1.5 Relative accuracy ofhorizontal position
Altitude 280.2, M 280.2 meters above meansea level
Height of geoid above WGS84/ITRF (to beindicated at the beginning of the session) ellipsoid -34.0, M -34.0 meters
Time since last DGPS/DGALILEO update Blank No last updateDGPS/DGALILEO reference station id Blank No station idGSM/UMTS serving BTS ID Blank No station id
Checksum*75 Used by program to check
for transmission errors
Considering that the number of satellites in view could be with a double constellation in theorder of 15-20 in clear sky conditions, and that the positioning will be implemented usingboth the constellations, a GGA sentence including GALILEO in the number of satellite fieldand in the HDOP field is recommended to sent both GALILEO and GPS positioningsolutions.The only Quality information present in this message is the HDOP. X, Y, X should beexpressed both in WGS-84 or ITRF within the GGA. Also serving GSM/UMTS and servingBTS is included. So the field Number of satellites is suggested to be changed in �Number ofMeasurements�.
7.2.2.1.2 GLL message
GLL message has the following structure:$--GLL,lll.ll,a,yyyyy.yy,a,hhmmss.ss,A llll.llThe only available quality information is the HDOP in this case, as you can see.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 142
Logica
7.2.2.1.3 GSA message
Quality Report information is contained is the GPGSA or GLGSA, indicating respectively thefirst the GPS DOP and active satellites, while the second including only GLONASS satellites.1 = Mode: M=Manual, forced to operate in 2D or 3D A=Automatic, 3D/2D
2 = Mode: 1=Fix not available 2=2D 3=3D
3-14 = IDs of SVs used in position fix (null for unused fields)15 = PDOP16 = HDOP17 = VDOP
These messages are related to the GPS case. An identical message can be used in order toprovide GALILEO information. Otherwise, being in the future in presence of a doubleconstellation, a unique message is recommended in order to include both GALILEO and GPS.
7.2.2.1.4 Quality Report messages
The latest version of the NMEA standard is 2.3. It adds a mode indicator to several sentenceswhich is used to indicate the kind of fix the receiver currently has. This indication is part ofthe signal integrity information needed, for instance, by the FAA. The value can beA=autonomous, D=differential, E=Estimated, N=not valid.As an example, in the following there is the recommended GLL sentence.
$--GLL,4916.45,N,12311.12,W,225444,A,*31
Where: GLL Geographic position, Latitude and Longitude 4916.46,N Latitude 49 deg. 16.45 min. North 12311.12,W Longitude 123 deg. 11.12 min. West 225444 Fix taken at 22:54:44 UTC A Data valid or V (void) *31 checksum data
It adds a validity indicator, but seems not sufficient for the data fusion purposes we areconsidering. The range of data validity should be widened in order to include more levels andgive more quality information. The use of this indicator could be useful only with less performant sensors, not able to provide more detailed quality information.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 143
Logica
7.2.2.1.5 GST: proposed new message
A new Quality report message is necessary for data fusion purposes (at least by GPS andother advanced positioning sensors), reporting the error covariance matrix elements.We recommend the introduction in the new NMEA standard of the following messagededicated to position data fusion:
0 = Device (assigned code)1 = Mode: M=Manual, forced to operate in 2D or 3D A=Automatic, 3D/2D
2 = Mode: 1=Fix not available 2=2D 3=3D
3-20 = IDs of SVs used in position fix (null for unused fields), both GPS and GALILEO
21-23 = IDs of the GSM/UMTS BTSs used in position fix (null for unused field), following apredefined coding (e.g. derived from SMSCB broadcast message)
24-29 = elements of Error covariance Matrix. Depending on 2-D or 3-D position, some fieldscould be null. Being the covariance matrix symmetric, only 6 elements have to be passed
24 = σx2
25 = σxy
26 = σxz
27 = σy2
28 = σyz
29 = σz2
where x,y,z have to be intended as WGS84 or ITRF coordinates, while if 2-D positioning isinterested, it represents Lat and Long.
An example is given in the following for the device 4.
A new message can be introduced in order to provide separate information aboutGSM/UMTS alone measurements and position determination into the NMEA standard. Asimilar structure to
Recommendations:• It is recommended for the sensors to be fused to use
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 144
Logica
o GGA or GLL NMEA messages, depending on the needs of the application tobe served (to be communicated at the position sensor before the beginning ofthe session)
o A dedicated message for position error statistic the new proposed GST (orwhere not available the simple GSA message)
• It is recommended for the lowest class of GALILEO sensors to include at least Datavalidity indicator also into GGA message in order to avoid the use of not validpositions and to allow the correct weighting of augmented or not augmentedsolutions.
7.2.2.2 NMEA 2000
NMEA 2000 is the following development of the NMEA 0183 standard. It starts from therequirements coming from the integration of different systems within the vehicle/mobile andenhances the NMEA 0183 for the definition of protocols from a network perspective.At the basic level NMEA 0183 (IEC 61162-1) provides serial-data distribution from a singletransmitter to multiple receivers. Operating at 4800 bits/second this protocol has thecapability of delivering approximately ten messages, or sentences, per second. This hasgenerally proven adequate when a single device is broadcasting data for use by otherequipment. But it quickly reaches a limit when systems start to combine data, as we areanalysing in this interoperability level. However, its use is expected to continue well into thefuture for simpler applications, redundant or backup data connections, and when directdevice-to-device connections are needed.NMEA is a standard starting from the marine sector requirements, but it express in generalthe real needs of future embedded systems present in a vehicle (e.g. trucks or cars). Modernmarine electronic equipment requires data from multiple sources to enable the host of featuresand function that can be available to the mariner. Without a network standard to provide thisdata integration, equipment designers must provide multiple data inputs, which involveexpense and additional wiring, or use devices that �merge� data into a single channel.Individual systems on a vessel, such as engine machinery or navigation systems, performrelatively dedicated functions, often have real-time requirements measured in milli-seconds,and need fewer connected nodes.The NMEA 2000 standard contains the requirements for the minimum implementation of aserial-data communications network to interconnect marine electronic equipment onboardvessels. Equipment designed to this standard will have the ability to share data, includingcommands and status, with other compatible equipment over a single signalling channel.Data messages are transmitted as a series of data frames, each with robust error checking andconfirmed frame delivery. Data frames contain, in addition to control and error-checking bits,an 8-bytes data field and a 29-bit identification field that sets message priority and identifiesthe data message, the source, and the destination. More than 8 bytes data field can betransmitted through a fast-packet transmission mode (up to 256 bytes). This standard isprimarily intended to support relatively brief data messages, which may be periodic,transmitted as needed, or on-demand by use of query commands. Typical data includesdiscrete parameters such as position latitude and longitude, steering commands to autopilots,finite parameter lists such as waypoints, and moderately sized blocks of data such aselectronic chart database updates. This standard is not necessarily intended to support high-bandwidth applications such as radar, electronic chart or other video data, or other intensivedatabase or file transfer applications.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 145
Logica
NMEA 2000 is going to detail the solutions for all the formats for the main OSI levels (fromthe Physical layer to the application layer). CAN technology (Controlled Area Network) isone of the focuses for the implementation of such a standard.Currently, the most important messages relevant for interoperability purposes defined atapplication level are the following:• GNSS Control Status• GNSS High Output Position• GNSS Position Data• GNSS DOPs• GNSS Sats in View• GPS Almanac Data• GNSS Range Residuals• GNSS Pseudorange Noise Statistics
The GNSS DOP message should contain the current DOP, while GNSS pseudorange noisestatistics should contain information about the pseudoranges estimation and noise statistics.
Recommendations:Some messages are recommended to be added, at the light of future positioning systemsintegration, including GALILEO:• A separate message has to be foreseen for each sensor: the sensor ID has to be contained
within the identification field• GNSS Position statistic, reporting the elements of the error position Covariance Matrix
should be provided for the GALILEO+GPS system. The content of this message shouldbe similar to the above proposed GST message:
o A flag indicating 2-D or 3-D modeo A mask with 1s for the used satelliteso The elements of the Covariance Matrix
• GNSS/GSM DOP: At the moment GSM and future UMTS are not considered as sourcesof ranging. This new message has to be introduced in order to include also GSM E-OTDand UMTS TDOA measurements. The relevant message for the hybridised GNSS/GSMpositioning has to be foreseen in the new NMEA standard
7.2.3 “LIMITED ANALYSIS” SYSTEM INTERFACES
Only basic relevant results about secondary systems analysis are reported hereinafter. Adescription of Secondary systems is reported in ANNEX E.
7.2.3.1 Bluetooth
Interoperability between Bluetooth and GALILEO at level 3BAs remarked above, the Bluetooth positioning service has the relevant goal to locateBluetooth devices mainly in indoor environment. A Bluetooth device, by means of a specificpositioning service, should be able to collect information from surrounding devices acting asposition servers, and to calculate its own position exploiting these data. In order to improvethe positioning performances, the device can at least measure ranging distance from thesurrounding devices.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 146
Logica
Hybridisation at position level between GALILEO and Bluetooth position solution can beforeseen only in the Alternative Use scenario. The two positioning systems operate in fact intwo different and complementary service environments. GALILEO position solution will beavailable only in clear sky environment and at least in satellite signal critical-environment(e.g. Urban Canyon) with degraded performances. In such environment, hybridisation withBluetooth has no sense because of the local and short-range nature of the Bluetooth network.GALILEO operational environment and Bluetooth operational environment do not overlap.On the other hand, Bluetooth position could be useful for indoor positioning and navigation,as the GALILEO UT is not able to perform the satellite-based position.Also in the case of Assisted GALILEO position-solution calculated in a light-indoor andBluetooth environment, hybridisation could have no sense if Bluetooth position is available.In fact, if a Bluetooth piconet is available and includes devices able to provide positionservice, it means that at least the GALILEO-Bluetooth interoperable device knows its positionwith an error that is limited by the maximum communication range available for Bluetooth(e.g. 10 m for class 3 devices).
7.2.3.2 WLAN
WLAN positioning technologies are based on TOA and TDOA techniques and, as in theGSM case, can be network based or handset based. In order to calculate the position of themobile terminal, the time offset from more than three Geolocation Base stations (GBS) thatcan be implemented within the AP or in separated Geolocation Reference Unit (GRP) have tobe calculated. Time measurements are derived from the round-trip delay of MAC frames (2ms each). It has to be pointed out that, in order to measure TOA from different APs, forcedhandover are needed. This imply the need of significant coverage overlap and propergeometric distribution of APs. TDOA measurements can be performed using a reference time(coming from an AP) and the time differences of the MAC burst sent by the mobile to twodifferent GRPs through a Direct Mode connection. Also signal strength from APs can be usedas positioning method.The WLAN position accuracy is in the order of some meters, while the mean rangingmeasurements errors are in the order of 7.5 m, while the standard deviation is in the order of10m.The statistic levels are comparable with the ones obtained with the standard positioningmethods. The point to be remembered is that this kind of results depends on the APsdistribution and coverage.For this reasons, it is recommended to use this solution strictly in alternative mode withrespect to the GALILEO/GPS solution (together with the Bluetooth one) for indoorapplications equipped with a suitable APs distribution.. As reported above, two levels ofpositioning can be used at level 3B for positioning data fusion purposes:
• First Level: the simple APs position (assigned after the latest handover) should becommunicated used for indoor application in the weakest situation (one APs for eachfloor) and the other sensors are not available or reveal a bad statistic, this has to beused as completely alternative positioning mean, switching off the other sensors (e.g.in deep indoor environment):
• Second Level: when statistics are nominal derived from an APs completeconfiguration (it shall be signalled by the WLAN to the entrant user through adedicated message), the other sensors can be switched off and the positioninginformation derived completely from WLAN (or relevant Bluetooth information)
• It is possible to conclude that, despite of boundary situations (e.g. being in theneighbours of a building in WLAN connection) Alternative use is recommended forWLAN use
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 147
Logica
• NMEA GGA message is recommended for the exchange of position
7.2.3.3 UWBA network infrastructure of fixed position UWB nodes provides the means for preciselocation and tracking of mobile terminals using TOA/TDOA techniques: Localisercommunication and position technology are based on the transmission of PRN codedsequences of Gaussian impulses and selective reception using correlation. The time of flightis precisely measured by the phase shift of the codes. The receiver locks to the codedsequence of the transmitter within an accuracy of less than 100 picoseconds (about 30 cm). Inparticular, UWB positioning techniques allows determining azimuth and elevation, usingTOA/TDOA solutions based on round trip delay from localiser or simply the distance fromthe nearest UWB beacon (single measurement). The Localiser network shall be timesynchronised at this purpose (Localizers track each other�s clock frequencies). Codesequences can be data modulated (Antipodal, Time-shift, M-ary codes) to transmitinformation). The relevant coverage of a UWB beacon is about 2 Km.From the above considerations, without considering FCC and GALILEO interference issues,UWB offers a very important opportunity for indoor and very critical environment (e.g.tunnels) positioning. In particular it has the capability to provide a very accurate positioningwith lower infrastructures and receiver costs, allowing also a high rate transmission capacity.Due to the low cost, a network of UWB localiser for positioning purposes can beimplemented for very critical and indoor situation (tunnels, deep indoor) for safety relatedpurposes at the early stage of GALILEO development in completely Alternative use, in orderto avoid any interference problem.GALILEO receiver should be able to switch to an UWB (and integrated WLAN or Bluetooth) positioning method and to pass the statistic information to the Central KF that has inthis case only the aim to evaluate the quality of the calculated position.Particularly of interest is the boundary region (exit from a tunnel, entry in a garage). Here theCentral KF has to be able to integrate UWB localiser position information untilGALILEO/GPS+GSM/UMTS are able to guarantee singularly the position. After this perioda complete switching to the available UWB should be decided until the beginning of tunnelexit. NMEA GGA (or GLL) plus Quality report (e.g. GST) is also here recommended.
7.2.3.4 TETRA
TETRA offers the option to interface numerous peripherals and applications such asrecording devices, Private Branch Exchange (PABX) equipment, GPS, cartography,administrative data processing.TETRA is a system currently developed for Police and Military Application, but in the futureit is foreseeable that such a system could be expanded and could cover urban areas and mainstreets.The positioning capability is currently performed through integration with GPS. Thesimilarity with GSM technology makes in principle possible the determination of OTDmeasurements between the user and the BTSs. At the moment there are no studies about thatpossibility. If this possibility will be developed, TETRA could be used as additional rangingsource and positioning system within the more covered areas, like Urban Areas and highways.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 148
Logica
7.2.3.5 DECT
DECT support has been added in many office buildings to allow intercom system work freely.Therefore, existing infrastructure for guidance system purposes can already be found installedin many places. DECT network can be used to offer several simple services by utilising itsdata connection.The major disadvantage of DECT from the guidance system point of view is that practicallyonly phones support it. Also, DECT device functions only in local DECT network.Thus, it is highly unlikely that a random user would carry device with the correct DECTsupport with him. Roaming between different DECT networks is not possible. Since DECTsupports connections of 300 m, it is really hard if even possible, to get accurate locationinformation, thus making the guidance system inaccurate.A positioning capability is hard to envisage in this case, also due to the low Marketpenetration and coverage of DECT.At this aim, DECT it is not recommended for positioning and ranging hybridisation, out ofparticular coverage situation that could be covered by dedicated cards.
7.2.4 TRANSITION TIME ANALYSIS
As remarked above, short-range positioning service are the best options to guaranteeavailability of position and navigation services also in such environments where the Satellitesystems are not available. In particular, Bluetooth position interoperability solution considersGALILEO and Bluetooth as complementary systems to be used following an �alternativelogic�. Two different options of interoperability can be followed in order to switch from asystem to the other, in order to guarantee the needed service performances in eachenvironment:
� In the first option the GALILEO terminals prioritise the GALILEO solution and switchits operational mode from GALILEO to Bluetooth mode only when the GALILEOsolution is not more available and, at the same time, the GALILEO Terminal is able toconnect to other surrounding location aware Bluetooth devices. As the GALILEOsolution becomes available, the operational mode changes again to the satellite mode.
� In the second option the GALILEO terminal changes mode from GALILEO to Bluetoothpositioning system, whenever a Bluetooth network is detected and a positioning service isavailable, even if GALILEO position solution is available.
The relevant drawback of such interoperability solution lies in the necessity of a Bluetoothinfrastructure of fixed access points and devices, which can share their position if acquiredvery recently. Thus, the deployment of Bluetooth fixed access points is required.For location services, the main issue is that Bluetooth fix infrastructure is expected to be setup in city centres, shopping malls, railway stations and airports, tourist attractions, themeparks and museums, etc. These areas are the most problematic ones in GALILEO positioningaccuracy issues. Hence, a Bluetooth solution in these areas could provide a highly accuratelocation positioning if the Bluetooth fixed infrastructure is implemented properly.Performance of an Interoperable solution between GALILEO and Bluetooth are characterisedby an improvement of the system coverage compared to the GALILEO-alone one and are alsoconstrained by the transition time from one system to another.The transition time from GALILEO mode to Bluetooth mode is strongly influenced by theBluetooth set-up connection time.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 149
Logica
In order to establish new Bluetooth connections, the procedures inquiry and paging are used.The inquiry procedure enables a unit to discover which units are in range, and what theirdevice addresses and clocks are. With the paging procedure, an actual connection can beestablished. Only the Bluetooth device address is required to set up a connection. Knowledgeabout the clock will accelerate the set up procedure. A unit that establishes a connection willcarry out a page procedure and will automatically become the master of the connection. Theresponse time of the devices is a bit long and causes a delay on the discovering the devices inthe range. The time needed for creating the connection has to also be taken into account.Connection forming time, from standby state through inquiry to the paging and finally to theconnected state will take typically average of 5.12 s. It takes only approximately 0.6 s whenthe frequency-hopping scheme of the user unit is known and no inquiry is needed.New technology has been developed for shortening the communications link-setting timeincluding the first-stage recognition of mutual communication partners between Bluetooth-capable equipment to two seconds at the longest and one second on average.Other time latency to consider is the time required by the decision module, which is in chargeto decide the switching operation on the basis of the GALILEO position quality report or ofthe detection of a Bluetooth network. This time should be short compared to the Bluetoothconnection time.The transition time from Bluetooth mode to GALILEO mode is strongly influenced by theTime to First Fix of the GALILEO terminal. In the case of Assisted GALILEO solution, inworst-case environment, GALILEO provide a first fix in just a few seconds. In that caseGALILEO position solution has a higher priority level compared to the Bluetooth one (firstoption), the switching time is reduced if the GALILEO receiver is able to perform satellitemonitoring operations, even in the Bluetooth operation mode
7.3 SUMMARY OF LEGAL AND CERTIFICATION ISSUES
Main legal issues regarding interoperability at position level are related to:� The receiver certification process. This is an issue that differs from application to
application, but basically is really constraining in Safety of Life environment. Inthose kinds of applications, not only accuracy is fundamental, but also integrity playsan important role. Receiver certification process covers the following aspects whichcan impact on the interoperability choice between GALILEO and other systems:
• The two interoperable modules in the hybridised receiver need tocoexist without interfering each other (mainly at RF level). Theperformance of each system considered as a stand alone system, has tobe guaranteed
• Performances improvement of the hybridised receiver compared to thestand-alone solution of each navigation receiver can impact on thereceiver certification process. It has to be taken into account thathybridised receiver can guarantee a minimum level of performancealso in typical GALILEO environment critical for GALILEO alone.
� The Liability chain definition. The GALILEO terminal able to performhybridisation of non-homogeneous measures or position solutions receivespositioning service from different systems. A clear definition of liability in case ofsystems outages need to be investigated, mainly when the terminals receive acombined positioning service. In this case in fact services inefficiencies are difficultto award to a specific systems operators.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 150
Logica
In such cases the terminals receive a positioning service by using different systems inalternative mode (e.g. A-GALILEO for clear sky and Urban Canyon / Bluetooth forindoor positioning and navigation service) liability process can be more easilyidentified due to the complete separation of the different operational modes.
� The interactions of Intellectual Property Rights on the hybridised navigationreceiver have to be clearly defined between the different manufacturers (e.g. phonemanufacturers and chip manufacturers). A cross-licensing mechanism is suggested inorder to optimise the royalty flows
General Consideration on the certification aspects:
Aviation is clearly the most requiring application. EGNOS is going to be certified in someyears for GPS. Integrity is the most hard requirement to be respected within this framework(TTA<6s) The introduction of GALILEO will imply for ICAO a new certification process forthe integrated GPS+GLONASS + satellite receiver system that constitute the current EGNOS,in order to include GALILEO. At this aim, the introduction of a complete Quality Report,from all the navigation systems could offer an improvements for Service and receivercertification, considering that the three satellite navigation systems to be fused at positionlevel will be similar in the way to determine position. Furthermore, the eventually integrityinformation embedded within the GALILEO Navigation message shall be inserted into thecertification process and used for position report purposes
Maritime and Inland waterways application: this application is regulated by IMOrequirements and integration with existing systems is one of the important requirementscoming from the Maritime sector. Due to the low dynamic and the limited presence of addednoises (multipath coming from the sea surface can be shadowed elevating the cut-off angle,while multipath due to building can only impact in the very late phase of the approach) thesolution proposed above (both the Bayesian and the multiple Kalman filter) can improve theperformances of the overall navigation system. Furthermore, the introduction of quality reportcan help in the certification process.
Personal Emergency Services: FCC E-911 and E-112 requirements are currently driving theapplications for personal emergency applications. The major problem is related on theliability side and on the fact that the declared service levels (at 1σ or 2 σ levels) have to beguaranteed also in critical environments, like Urban Canyons and indoor. At this aim,interoperability with external systems is fundamental. For outdoor and light indoorapplications, the use of mobile networks time difference, both for stand-alone positioning oras added ranging sources, have to guarantee the requirements. Currently some mobileoperators are introducing hybridised E-OTD and GPS technologies for the compliance toFCC requirements. It is recommended to carry on the E-112 process, inserting allowing thetransmission of a quality report together with the position information and to includesecondary systems (UWB) for deep indoor applications
Regarding secondary systems, the most important problem to be solved is how to regulate theswitching between light indoor and deep indoor environments in terms of positioningstandards (e.g. E-911/112) and liability purposes (to define when A mobile operator has toexit from the liability chain and how the Service provider is liable during the transition time).Also in this case the data fusion process can help in the transition process also from a legalpoint of view. Data quality threshold can be defined in order to switch (in an alternativemode), for instance, the positioning g mean from GALILEO+E-OTD to Bluetooth or UWB.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 151
Logica
The problem of liability is much more sensible where the mobile operator is also the ServiceProvider: in this case he will be also responsible for positioning with other (not GALILEO,GPS and mobile network based) positioning systems results. Definitively, data fusion andQuality report can help in defining the way to proceed from the legal point of view.
7.4 MRD & SRD RECOMMENDATIONS AT INTEROPERABILITYLEVEL 3B
Recommendations for MRD• Recommended loose hybridised solutions
The GALILEO terminal shall be able to hybridise GALILEO position and otherposition solutions generated by other systems. GALILEO navigation processor shallbe able to take in input different single position solutions, each considered with anassociated Quality report, and to hybridise them. The GALILEO processor uses theQuality Reports in order to correctly weight the single position solutions and tocalculate the hybridised position. It has to be able to switch between different systemsor to properly weight the solutions according to the Quality report. Terminal shall beable to process also Network based positioning solutions (e.g. Cell-ID) and tointegrate them into the final solution.MRD-1301d: Positions hybridisationGALILEO navigation module shall be able to properly hybridise position solutionscoming from different sensors and systems. The final position solution shall bederived using proper weighting algorithms for the single position solutions (at leastthe alternative mode, selecting the best quality solution and discarding the others)
• High dynamics situation and external sensorsIt is important to assure the maximum of flexibility in the GALILEO Navigationsolution. External automotive sensors and other sensors that are important to improvethe robustness of the position solutions in critical environment and high dynamicsituations, are going to be integrated by manufacturers into the car in the future (anexample is given by odometers-like sensors that can be derived by the current ABSmeasurements). In order to allow the maximum of flexibility in the integrated positionsolution in the future and to improve the robustness of the solution in high dynamicssituations, the analysis of new algorithms for interoperability of different systems isrecommended (e.g. multiple Kalman filter and new improved Kalman filter solutions)
• Integration with BluetoothBluetooth can be used as alternative positioning system especially for deep indoorenvironment. The recommendation is therefore for the GALILEO terminal to beinteroperable at position level with Bluetooh as alternative system for indoorenvironment.At this aim the requirement MRD-2232 has to be modified in the following way:MRD-2232 Requirement Title: Interface with wireless communications systemsGalileo system shall allow adequate interface to wireless communications systems(e.g. GSM,UMTS, Bluetooth) for combined services
Recommendations for SRD• In order to implement position data fusion, Quality report from each sensor it is
necessary. NMEA 0183 includes only PDOP information associated to the position
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 152
Logica
calculation, and other quality indicators are developed in the basic messages (e.g. 4levels of position validity). Furthermore, GSM and UMTS BTSs as ranging sourcesare not currently included into the standard. On the other hand, NMEA 2000 islooking forward to find new �network� standards able to allow efficient exchange ofinformation between different sensors. Also in this case Quality reports are limited toDOP information and measurements statistics. It is recommended:
o To extend the Quality indicator of NMEA 0183 to GGA basic messageo To improve current GGA and GLL messages in order to include GALILEO
and GSM/UMTS BTSso To include the dedicated proposed Quality report messages (GST) both in
NMEA 0183 and NMEA 2000 named GNSS Position statistic reporting theposition errors covariance matrix elements
7.5 ISSUES FOR OTHER GALILEI TASKS AND OTHER STUDIES
Other Studies and Pilot Projects• Analyse SIA proposed improved Kalman Filtering techniques (UKF) for the
integration of external automotive sensors (odometers, dead-reckoning) within thenavigation solution
• Task F: study the interference problem between GALILEO and UWB systems andefine the standardisation process between GNSS and terrestrial mobile futuresystems
• Participate to NMEA and RTCM conferences and standards in order to insertGALILEO and external ranging sensors within those standards
Task G• Analyse impacts of hybridisation at measurements and position level within an
integrated terminal for Safety of Life and Personal Emergency applications
7.6 IMPACTS ON GALILEO OS AND CS
Main impacts on GALILEO OS and CS are related to the improvements that GALILEO canintroduce with respect to the current situation, on which already integrated terminals aregoing to be developed and introduce into the market.GALILEO Open Services are going to provide similar level accuracy with respect to the GPSmodernised ones. Hybridised solution integrating GPS, Assisted Navigation and E-OTDmeasurements have already be implemented and are going to be commercialised (e.g. seeGellguide Products).Mobile Operators and Service Providers can be reluctant to develop their business without aclear liability sharing between the different actors (e.g. basic systems providers for LBSmobile communication providers, content providers). This is particularly true for PersonalEmergency Services.Two basic points will have an impact on the success of OS
• The lack of availability in Urban Areas and Indoor environments• The basic lack of these systems is the lack of certification and service guarantee,
especially for emergency services. This could slacken the introduction of thosesystems into the markets
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 153
Logica
As analysed above, the improvements in terms of service coverage and availability due to theintegration of external sensors in the position calculation are high: BTS ranging integrationinto an UKF can allow a very robust 2D solution also using only 2 GALILEO satellites onlyand 1 GSM or UMTS BTS.Assisted navigation allows to track satellites with low SNR (not used with a normal terminal),e.g. in noisy and very shadowed environments and light indoor environments. In this sense,integration with Mobile Operators has to be considered fundamental at terminal level for animprovement of GALILEO OS availability performance (without considering the well knownreduction of power consumption due to assisted techniques) and shall be deeply investigatedin the future, also in terms of common billing structure implementation, as will be detailed inthe following paragraphs.Regarding augmentation, it has to be pointed out that solutions able to provide an accuracy inthe order of 5m are already available now through integration of GPS with on-board sensorsand algorithms (odometers, map-matching, etc.), so this will not be the real improvement forin car applications.On the other hand, GPS signal is not currently guaranteed against failure (without consideringhealth status, suffering an high delay of about 15 min, and future EGNOS capability).GALILEO will offer, through its integrity and service guarantee services, the possibility todefine a clear liability model, but also in nominal situations, in critical environment such asurban canyons, GALILEO cannot guarantee in a stand-alone mode (due to visibilityconstraints) the positioning solution availability (for instance, if 3 satellites are visible andone of them is in failure, GALILEO standalone solution is not available). Therefore, also ifCommercial Services can provide improvements in terms of integrity, the system availabilitycannot be guaranteed (remember also that the classical availability parameter is calculated innominal, clear sky conditions). Also in this case, complementing GALILEO CommercialServices with External systems, both at ranging and position solution level, is a fundamentalissue for the real exploitation of that service. Stand-alone or dual-mode switching modality, asdescribed above, shall be developed in order to provide a complete positioning serviceguarantee.Furthermore, the possibility to broadcast GALILEO integrity message through Mobilecommunication system is another solution that can improve the availability of CS (solutionsfor EGNOS data broadcasting has been investigated also within ESA studies).Regarding Secondary Systems positioning solutions (like Bluetooth, WLAN and UWB), theywill be fundamental to extend navigation capability where satellite is absolutely notaccessible (deep indoor) and mobile communication systems cannot guarantee coverage (e.g.tunnels, garages). Furthermore, Commercial Services information (e.g. Satellite maintenancebulletins, status information, precise ephemeris for Assisted Navigation) can be downloadedin indoor environment for pre-trip planning purposes.It has to be of course pointed out that integration within mobile phones is the starting point forLocation Based Services and Value Added Services development, as will be pointed out inthe following chapters.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 154
The interoperability between Galileo and different Non-Nav Systems will be investigated atIO-Level 4/5.
Non-Nav Input systems at this IO level 4/5 (Navigation-Communication system) areconsidered:
• As Communication system for differential GNSS data transmission• As Communication system for assistance data transmission in the Assisted-GALILEO
solution• As Communication systems to distribute value-added data for location based services
implementation• As SAR Systems (COSPAS SARSAT)
The main functions at level 4/5 are:
1. Connection control to interface external systems (selection of the physical interfaceand logical interface protocol, signalling of control information)
2. User control (User identification, Authentication, authorisation)3. Privacy policy (Identification of the relevant privacy issues)4. Application functions:
• Export of user related information (PVT)• User interface handling• Navigation applications related data• Hybridisation at application level• Charging data generation/export
IO Analysis is performed with different detail levels, looking at these relevant functions.Objectives of the IO Analysis at this level are the following:
• Provide recommendations for the interfacing between GALILEO and Non-NavCommunication systems
• Provide recommendations for the interfacing between GALILEO and COSPASSARSAT system
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 155
Logica
• Provide recommendations on GALILEO High Level Documents (MRD, SRD, ICD)to refine GALILEO baseline
• Investigate possible migration scenarios for the interoperability with relevant NonNavigation systems
• Highlight relevant Legal Issues
Output systems at level 4/5 are �Higher-level systems� for Location Based Services,emergency call services and other communication services, charging systems.
8.2 SYSTEM INTERFACES
The particular system interfaces that should be analysed have to be deduced from the rankedRequirements table produced by MIA.The following systems shall be considered at IO level 4/5 with the correspondent level ofdetail:
For the selected systems interfaces, the User Terminal interfaces description is performedidentifying the relevant interfacing entities and their specifications (e.g. UMTS User Terminalspecifications and interfacing entities with GALILEO). For each identified system interface,the following IOL 4/5 aspects will be analysed:
• System/application interfaces between GALILEO and GSM/UMTS communicationsystems
• System/application interfaces between GALILEO and SAR-Cospas Sarsat system• Network assisted GALILEO: System architecture interfaces between GALILEO and
GSM/UMTS
8.2.1 GSM COMMUNICATION SYSTEM INTERFACE
The main issues relating to interoperability are the following:
• Interfacing to external systems, including consideration of the physical andlogical interfaces
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 156
Logica
• Operational control of the user, e.g. identification, authentication andauthorisation
• Protecting the privacy of the user while providing an adequate service
• Galileo services and applications for the user. They may reside either on theterminal or in the network but they interface with Galileo to deliver a service insome way.
In the following sections we proceed to analyse our findings in further detail. We examinehow the methods of interoperability identified at levels 4 and 5 may actually be implementedon a systems level in the GSM network. Where possible in the following analysis, referencesshall be made to the relevant section.
8.2.1.1 Interfacing entitiesThe typical elements of a GSM network are outlined in Figure 8-1. The diagram is notintended to be complete but to identify the main elements of a generic network. The figureillustrates the two elements of network subsystem and the base station subsystem. Thenetwork subsystem contains a number of base transceiver stations and a base stationcontroller, which through them manages the radio resources such as the handover of calls,their set-up and tear-down. The network subsystem contains the elements of interest whenconsidering interoperability with Galileo. These include:
• The Mobile services Switching centre � manages the call routing andestablishment, authentication and connection to fixed networks.
• The Home Location Register � a database that stores and manages informationfor the all subscribers in a given network.
• The Visitor Location Register � a database used for the temporary storage ofsubscriber data for those subscribers currently in the service area of theassociated MSC.
• The Billing Platform � a generic system used for collecting Call Data Recordsfrom the MSC and SMSC amongst other elements of the network. This systemnormally forms one of the primary interfaces to the network operator�scustomer care service.
• The Short Message Service Centre � manages the storage and delivery ofalphanumeric short messages to and from the MS and external messagingentities.
Additional elements in the following figure that are worth noting include Subscriber IdentityModule and the Mobile Equipment. Collectively these are termed the Mobile Station andcomprise the handset that a subscriber uses to access network services, such as making calls,sensing short messages and browsing WML pages. The SIM contains the unique subscriberidentity and a secret key for the authentication and encryption of transmitted information.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 157
Logica
ME
SIM
DataNetworks
PSTN
HLR
MSC
VLR
BSC
BSC
BTS
BTS
SMSC
Base Station Subsystem Network Subsystem
BillingPlatform
MobileStation
Figure 8-1; The Typical Architecture of a GSM Network.
8.2.1.2 Interoperability analysis for the system architecture interfacesOne of the most significant differences between the GSM network and the UMTS/GPRSnetwork is the lack of a standardised interface for application related communications. WAPis one option but it is one based predominantly on the browsing model with push technologycurrently being introduced. Consequently, the lack of standardisation extends to theoperations that relate to the applications, such as billing, authentication and privacy. Weidentify two options for integrating Galileo services with GSM: via the PSTN network andvia the short message service.During the MIA study a number of specific issues were identified as important to theinteroperability of GSM and Galileo. These were highlighted in the following requirements:
PE_26 Privacy constraints
PE_38 LBS Standardization process regarding privacy guarantee
PE_31 Mobile Communication Standardization process
The issue of the users privacy was also found to be a high priority, as summarised in PE_26.The final two requirements, PE_38 and PE_31 dealt with the standardisation of services andtheir effect on the overall business model. The remainder of this analysis will examine theseissues and the implications on Galileo and the GSM network described above. We will alsoexamine interoperability in the light of:
• Connection control,
• User control,
• Privacy,
• and Application functionality.
We look first at the business model, as it implies the overall standardisation that we require.The high level interactions between the end user, network operator and service provider
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 158
Logica
(which can be the same as the operator) are illustrated the following figure. It may be seenthat the LBS provider is key to the overall service as they provide the means of distributinginformation, for billing mediation and for managing user privacy. Authentication is alsoinherent in this role as it would be a pre-condition of the interactions shown in the figure.
MVNO Payment Facilitator
Mobile Portal
Sponsor
Network Operator
LBS Provider
End User Linkage
LBS
Advertisement
Billing Service
LocationInformation
Linkage
Location Information
Roles seized by the operator
Roles generating operator revenues
Advertisement
Location Broker
Location Information
LocationInformation
EMILY Project
Figure 8-2; The Value Added Services Business Model.
Our analysis assumes that a Galileo service centre is performing the role of the location basedservice provider. For the billing of services a mediation interface is required, as in the UMTSanalysis above. An appropriate mediation interface would allow for the reconciliation ofcharges between the service provider and the network operator.As mentioned, two methods of service provision exist in GSM, PSTN and SMScommunications. The use of an appropriate framework allows the issues of authentication,privacy and applications to be handled appropriately.
PSTN InteroperabilityAs in the case of CS/UMTS, once a connection has been established, further protocols arerequired to service application layer communications with Galileo. One possible, and likely,scenario is the use of IP and WAP (or similar standardised mark-up language). Figure 8-3shows the WAP protocol, as it is used in GSM networks today. It may be seen that inaddition to the PSTN interface, TCP/IP is used to facilitate communications with the MS.Applications on the MS would include but not be limited to:• A WAP browser or similar• An application framework such as J2ME (Java 2 Micro Edition)• Dedicated SIM applications
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 159
Logica
Figure 8-3; An illustration of the various protocol stacks involved in carrying bearertraffic to the MS.
J2METhe above items provide for a flexible platform for mobile applications that may includenavigation functionality. The WAP communications stack provides a method of transportingapplications and data across the link. WAP deals with connection control, authentication andprivacy and can deal with billing- In order to benefit from these features, a service providerwould be required to support a WML/IP interface for communication via a WAP Proxy.The Java 2 Platform, Micro Edition (J2ME) implements Java support for various consumerand embedded devices such as mobile phones, PDAs, Internet screen phones, automotiveentertainment and navigation systems, network switches, home automation components, etc.The J2ME Platform consists of virtual machines and core APIs specified in "Configuration"documents, plus application- and market-specific "Profiles" (APIs and implementations) builtto sit on top of an underlying Configuration.
SMS InteroperabilityThe delivery of data via SMS implies a number of interfaces and requirements forstandardisation. The following figure is a schematic of the likely method of integrationbetween a Galileo Service Centre and a GSM network. The systems that would be impactedwhen considering interoperability with Galileo are illustrated and discussed below.
ServiceCentre GCS
BillingData
MobileNetwork SMSC
Service Interface
SCI
MS
Figure 8-4; A Schematic of the GSM interfaces with Galileo.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 160
Logica
Service Centre InterfaceSome provision is required in the SCI to allow the distribution of service data in theappropriate format and the relevant frequency. In order to guarantee quality of service it isnecessary that the information is prepared in a standard format such that further processing isnot required. The use of encryption/security should also be considered for the distribution ofthe information.
The SMSCThe SMSC would not be impacted directly as it simply provides the transport for the relevantinformation. It is likely that an application would be required that would connect to theSMSC and deliver the data to the subscriber in the relevant format. Such an applicationwould reside in the domain of the network operator.
The TerminalThe GSM terminal is likely to change significantly by 2008 and it is unlikely that terminalswill operate with the GSM service alone, if at all. In order to receive the data an applicationis required to process the contents of a short message. Current developments with Java andBREW (Binary Runtime Environment for Wireless) application engines finding their wayinto the operating systems of handsets seems to indicate that an open standard (or semi-openin the case of BREW) will be available for running applications that will process suchinformation and perhaps information from the Galileo receiver. Further consideration of theterminal properties is outside the scope of this analysis, which does not attempt to address theintegration with the Galileo terminal below the application level.
Billing/Reconciliation PlatformThe billing platform we consider here is that of the service centre. In order to billappropriately for the information some record is required. This is best achieved with arepository that works together with the service interface to keep track of all recipients ofinformation. This may be individuals or corporate entities depending on the business modelin question.
Service InterfaceThe service interface is the connection between the network operator and the Galileo servicecentre. It marks the limit of the Galileo technical solution but not of the business model. Theconstraints of the model depend on whether the service is being marketed directly toindividuals or to network operators. A third alternative is possible where the information issent to a third party that sells the service to the users (this was discussed in more detail in theprevious section). It is necessary for this interface to allow communication with an SMSC forsending data directly or with a server for distribution to a third party (network operator orother service provider).
Interoperability SummaryIn the following analysis we consider the following scenarios, for the GSM communicationssystem interfaces.1. The coexistence of the two architectures, i.e. GSM with Galileo integration and without
operating side by side.2. Alternative use; this is where the scenario including Galileo is used instead of the original
architecture3. Combined use, where the two scenarios are used together as one.
Co-existenceSince GSM is an open architecture, interoperability does not affect the co-existence ofsystems as long as it does not interfere with the low level GSM protocols. In this case we are
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 161
Logica
considering a method of interoperability at the application level, which does not impact theseGSM protocols.
Alternative useFor the above reason, alternative use does not present an impact on the existing GSMarchitecture.
Combined useAs with co-existence and alternative use the open nature of GSM ensures that combined usewill not impact the interoperability.
8.2.1.3 System Interfaces requirementsIn this section we list the explicit requirements implied by the discussions in previoussections. The aim is to focus on the following:• System interfaces at application level and their high level definition• Areas where benefit may e gained by interacting with similar studies, e.g. other Galilei
tasks and ESA phase B2.• The legal and commercial impacts of the interoperability in question
Ultimately the goal is to identify any impact on the Galileo MRD and SRD and to make theappropriate recommendations based on the above analyses.The following requirements are identified when considering the interoperability of Galileoand GSM for the purpose of distributing application data.
1. The GALILEO Service Centre shall support an interface at application leveldirectly to an SMSC for the provision of a service directly to the individual. Theinterface should be of an open nature such as SMPP (Short Message Peer To Peer)
2. A mechanism for recording all information sent to an SMSC is required. This maybe used to produce billing records and to reconcile all transactions when providinga service.
3. A standard open protocol such as XML should also be used as the method ofcarrying the application information.
4. A standard form of XML must be produced and maintained by Galileo to enhancethe accessibility of the service to third parties.
5. An IP billing interface is required to monitor information streamed to third parties.A flexible billing model is required that will accommodate changes to the service.One based on XML/IP would currently be the most appropriate.
6. The accessibility of the service to third parties.7. An IP billing interface is required to monitor information streamed to third parties.
A flexible billing model is required that will accommodate changes to the service.One based on XML/IP would currently be the most appropriate.
8.2.2 UMTS COMMUNICATION SYSTEM INTERFACE
In this analysis we investigate the interoperability, at application level, of Galileo and UMTS.For completeness, we re-iterate here the MIA requirements that relate to UMTS. These are:
PE_31 Mobile Communication Standardization process
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 162
Logica
PE_18 Integration of Galileo with VAS-data
We therefore focus our analyses on the potential for interoperability between Galileo and thevarious nodes of a UMTS network. The aim being to meet the requirements for deliveringinformation that will compliment Galileo based services and the creation of a standardmethod of delivering these services. The requirements identified during the MIA phase wereat a high level and in some cases encapsulated multiple scenarios, as in the case of PE_31. Inthe following analysis we attempt to focus on a number of functional areas in order to breakdown the interfaces in to a number of logical way.
In particular we focus on the following issues:
• The relevant interfaces between Galileo and standard protocols used in UMTS.
• User privacy and authentication in the context of using Galileo services on a UMTSnetwork.
• General application functions including the export of navigation application data, theexport of user related information and billing issues.
These items are analysed with varying levels of detail based on their relevance to Galileo.
8.2.2.1 Interfacing entitiesWhen considering the interfaces between Galileo and UMTS networks we must also bear inmind the functionality of the terminal. Layer 4/5 interfaces may not be adequately servicedwithout the relevant functionality or application in the terminal. As an internationalpartnership project, UMTS relies on the use of open protocols and specifications. In thisanalysis we focus on the interfaces and standards that will provide Galileo interoperability atlayer 4/5 and are open. We avoid the definition of proprietary services that will ultimatelyundermine interoperability with Galileo. UMTS architecture is reported in ANNEX D
PSTN InteroperabilityThe CS network interface requires a PSTN modem for connectivity. Further protocols wouldthen be required to service application layer communications with Galileo. One possible, andlikely, scenario is the use of IP and WAP (or similar standardised mark-up language). Thefollowing figure shows the WAP protocol, as it would be with the use of a WAP Proxy. Itmay be seen that in addition to the PSTN interface, TCP/IP is used to facilitatecommunications with the MS. Applications on the MS would include but not be limited to:• A WAP browser or similar• An application framework such as J2ME or BREW• Dedicated USIM applications
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 163
Logica
Figure 8-5; an illustration of the various protocol stacks involved in carrying bearertraffic to the MS.
The above items provide for a flexible platform for mobile applications that may includenavigation functionality. The WAP communications stack (or similar) provides a method oftransporting applications and data across the link. Application environments such as J2MEand BREW provide the framework in which the applications may run in order to deliver therelevant Galileo features.
Packet Switched InteroperabilityThe illustration in the following figure shows the protocol stack for the Gi interface (on theright) in the context of the end-to-end communications between the user and an Internet basedapplication. The logical elements of GGSN, SGSN and BSS are all involved in provided acommunications channel to the MS. It may be seen that in this case, as with PSTN, theapplication level interface is IP. As before, the network provides a backbone on which furtherapplications support is obtained only by use of a framework that will overlay the IP layer.
Relay
Network Service
GTP
Application
IP / X.25
SNDCP
LLC
RLC
MAC
GSM RF
SNDCP
LLC
BSSGP
L1bis
RLC
MAC
GSM RF
BSSGP
L1bis
Relay
L2
L1
IP
L2
L1
IP
GTP
IP / X.25
Um Gb Gn GiMS BSS SGSN GGSN
Network Service
UDP / TCP
UDP / TCP
GSM TS 03.60
Figure 8-6; The Protocols Supported for PS Communications with the MS.The 3GPP has also addressed the issue of delivering services to an MS and defined aframework for the management, delivery and operation of value added services. It has beentermed the Open Service Access model.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 164
Logica
The Open Services Access ModelThe Open Services Access model may be summarised as three layers that facilitate theinterface between the user and their applications (typically value added services). Thefollowing figure shows the high level concept of the OSA.
framework User Location Call control
HSS CSE S-CSCF Servers
E.g. Location server MExE server
SAT server
Service capability
Interface class
OSA APIOpen
Service Access
discovery
Application
Applicationserver
OSA internal API
Figure 8-7; The OSA Model is Divided Into Three Basic Layers.
The top layer is the application layer. It is typically used by third parties to provide specificapplications for use by subscribers.The middle layer is the service capability layer. It is a UML definition of the external API foruse by applications and the internal API for the intercommunication of different services. It isdeliberately abstract in order to avoid the implication of proprietary products or solutions.The bottom layer is the network layer. It contains the components that make up the mobilenetwork. Examples include, an MSC, a SMLC, etc.The efforts of the 3GPP working group, responsible for the OSA, are summarised in R [48].Much of the remaining effort is now being focused on stage 3. It is at this level that theinterface with the physical network is defined. Some of the definitions, of interfaces withnetwork protocols, so far include:
1. API to SMS mapping2. INAP mapping3. User status mapping
The OSA is significant in the context of this analysis as it provides features such asconnection control, user control and privacy, amongst other things. These features come fromthe OSA framework. Referring to Figure 8-7, the OSA model may contain any number ofinterfaces, as shown in the middle layer, but the framework is an essential part that mustfeature in every implementation of the OSA model. The mechanism that takes place betweenthe framework and a new service are broadly as follows:
1. Authentication; the application authenticates with the framework and vice versa. Theapplication must be authenticated before it may use any other OSA function.
2. Authorisation; following authentication, authorisation determines the operationswhich an application may perform.
3. Discovery; at any time after authorisation the application may use the discoveryfunction to determine the network service capability features.
4. Service agreement; this is an off-line or on-line process which must take place beforean application can interact with a network service capability.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 165
Logica
5. Access; the framework provides access control functions for an application, usingservice capability features, with the relevant security level.
The end users security and privacy may be managed by the framework. It permits the user todecide on things such as:
• Whether PVT information may be made available to other users.• Whether information, such as augmentation data, may be pushed to the terminal.• The ability to use a particular service control feature
Given the activities of the 3GPP in defining the OSA, it would be appropriate for any Galileoservices or applications to conform to the model. By doing so, the numerous operationsrelating to authentication, authorisation and privacy are addressed.
8.2.2.2 IMS servicesInteroperability analysis between GALILEO and Communication Systems (e.g. GSM, GPRS,UMTS) at level 4/5 has the relevant objective to identify and analyze the interfacing entitiesof the systems, mainly focusing at GALILEO User Terminal Level Interface. As alreadyhighlighted, the Mobile Communication Systems could interoperate with GALILEO in thesense they could provide communication capabilities to the GALILEO Terminal with therelevant aim to communicate navigation related data and other information useful for theprovision of Location Based Service and IP based Multimedia Applications. In most of theapplications typical for the mass market (e.g. personal and road users) environmentGALILEO Terminal will not have only position calculation functions but will be also aMultimedia terminal able to receive Location Based Service from dedicated service provider.At GALILEO UT side, the relevant key interoperability issue is the compliance with MobileCommunication System standards. The GALILEO Terminal shall foresee the option toimplement specific Mobile Communication Protocols in order to receive the communicationand multimedia services following open standards, without the typical constraints thatcharacterize the proprietary-logic solutions.At GALILEO system level, the GALILEO architecture elements, which generate anddistribute the information for the GALILEO user terminals (e.g. GALILEO Local Element,GALILEO SPs), need to be interfaced to the proper Mobile Network Elements in charge tocollect and route the information towards the UTs.Focusing on the GALILEO UT multimedia capabilities, one of the relevant Interoperabilityaspects with GPRS/UMTS network, refers to the IP Multimedia subsystem (IMS) whosefeatures are described in A[12], which highlights and investigates all the elements andprocedures necessary to support IP multimedia services in UMTS. Following the ETSIstandards, in order to align IP multimedia applications, wherever possible, with non-3GPP IPapplications, the general approach is to adopt non-3GPP specific based solutions.The IP Multimedia core network subsystem enables PLMN operators to provide theirsubscribers with multimedia services based-on and built-upon Internet applications, servicesand protocols. The IMS should enable convergence of different kind of services (e.g. voice,video, messaging, web based services), through the implementation of GPRS evolved corenetwork and specific functional elements of the IM Core Network subsystem.The IMS uses the Packet Switched domain to transport multimedia signalling and bearertraffic.The IP Multimedia CN (Core Network) subsystem comprises all CN elements for provisionof multimedia services. This includes the collection of signalling and bearer related networkelements as defined in A [13]. IP multimedia services are based on an IETF defined sessioncontrol capability, which, along with multimedia bearers, utilizes the PS domain.In order to achieve access independence and to maintain a smooth interoperation withwireline terminals across the Internet, the IP multimedia subsystem attempts to be conformant
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 166
Logica
to IETF �Internet standards�. Therefore, the interfaces specified conform as far as possible toIETF �Internet standards� for the cases where an IETF (Internet Engineering Task Force)protocol has been selected, e.g. SIP.The functional architecture for the provision of IP multimedia services in the IMS ishereinafter reported:
Figure 8-8 – IMS Architecture
The IP multimedia Subsystem Service Control interface (ISC) is the interface between theSCSCF (Serving-Call Section Control Function) and the Application Server offering IMservices, that resides in the users home network or in a third party location. The protocol to beused on the ISC shall be SIP.It shall be possible for an operator to offer access to services based on OSA for its IM CNsubsystem subscribers. This shall be supported by an OSA API between the ApplicationServer (AS) and the network.Before the UE can request IM services, a PDP (Packed Data Protocol) context must beactivated to carry IM subsystem related signalling. As a PDP context and an IMS signallingare activated, the procedure to discover the local CSCF is triggered in order to obtain the IPaddress of the proxy-CSCF (P-CSCF discovery procedure). After reception of domain nameand IP address of a P-CSCF, the UE may initiate communication towards the IM subsystem.When the UE attaches and makes itself available for access to IMS services by explicitlyregistering in the IMS, a S-CSCF shall be assigned to serve the UE. The assignment of an S-CSCF is performed in the I-CSCF (Interrogating-CSCF) on the basis of different parameters(e.g. required capabilities for subscriber services, operator preference on a per-user basis).The main procedures that are used for the provision of services in the IP Multimedia system,are all described in the document A[12], regarding Procedures related to CSCF, Applicationlevel registration and de-registration in the IMS, IP Multimedia session set-up and release,emergency session.The IP protocol foreseen for the IMS is the IPv6. According to the procedures defined in3GPP TS 23.060 (�General Packet Radio Service (GPRS); Service description; Stage 2),when a UE is assigned an IPv6 prefix, it can change the global IPv6 address it is currentlyusing via the mechanism defined in RFC 3041 (�Privacy Extensions for Stateless AddressAuto configuration in IPv6"), or similar means. When a UE is registered in the IM CN
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 167
Logica
Subsystem, any change to the IP address that is used to access the IM CN subsystem shalltrigger automatic registration in order to update the UE�s IP address.It should be noted that, due to different capabilities of the originating and terminatingterminals, it might not be possible to establish all the media suggested by the originator for aparticular session. In addition, the destination user may have different preferences on type ofmedia to use, depending on who is the originating part and on the particular situation (e.g.being in a meeting or driving a car). In order to fulfil requirements coming from differentterminals capabilities and configurations, and to guarantee the optimization of the utilizing ofresource available, it is needed that the destination user can be pre-alerted before the bearerestablishment and negotiation, and PDP context activation has take place.Relevant Interoperability interfaces for the GALILEO and UMTS-IMS Application levelinteroperability are:3. At GALILEO UT level: through the implementation of IMS functionalities, the
GALILEO terminal is able to receive multimedia services (including Location BasedServices) provided by typical Internet multimedia service provider, Mobile Operator,Service Provider for GALILEO related services. In the following figure the scenario forthe provision of IP multimedia services is shown.
Multimedia Applications Environment (Internet Users Community, no mobility)
Mobile Operator Multimedia Services Providers and Galileo Multimedia Services Providers
Figure 8-9 – IP Multimedia-GALILEO interrelation Scenario
4. At GALILEO system level, GALILEO Local Elements could be interfaced to the S-CSCFof the IP Multimedia subsystem through the UMTS standard ISC interface and thedefined SIP protocol (Session Initiation Protocol)
Within this framework, IMS could be also used for broadcasting of differential correctiondata in complement to SMSCB service, for instance for more demanding GALILEOapplications (TCAR, VRS, etc.).
8.2.2.3 Interoperability analysis for the system architecture interfaces
In the following analysis we consider the following scenarios, for the UMTS communicationssystem interfaces.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 168
Logica
1. The coexistence of the two architectures, i.e. UMTS with Galileo integrationand without operating in conjunction.
2. Alternative use; this is where the scenario including Galileo is used instead ofthe original architecture
3. Combined use, where the two scenarios are used together as one.In this part of the analysis, the above three scenarios have similar implications forinteroperability. Because the 3GPP standards are based on openness and inter-working,coexistence, alternative use and combined use are all catered for by the OSA. If an applicationwere to be implemented separately from the OSA it would still be within the framework of aUMTS network with open standards.Provision of a service is based upon network operator enabling the appropriate framework forthat user. Co-existence within the framework relies on OSA architecture and its features. Co-existence between networks is not an issue as they are mutually exclusive. Alternative use, inthis context, simply means a network that does not support GALILEO service. Combined usewould mean that some subscribers are using integrated services and others not and thenetwork is able to provide the combination of the two services. Once again, for the reasonsstated above, no conflict results from these scenarios.By way of a case study we examine the way in which an application would interface with theOSA to implement a charge, perhaps for navigation related data such as a map. The followingfigure shows an application, in blue, communicating with the IpChargingManager object ofthe charging SCF. This communication has been established as a result of a discoveryoperation performed by the application, which revealed the charging SCF. Further details areavailable in R[49].
Figure 8-10; A Charging Session for a One-off Charge.
Let us assume that this interaction is for mapping services being provided to the user. A mapwith a value of 10 cents is purchased. The exchange between the charging SCF and theapplication is as follows:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 169
Logica
7. The application creates a local object implementing the IpAppChargingSession interface.This object will receive response messages from the IpChargingSession object.
8. The application orders the creation of a session. No new object is created for the chargingsession handling in this example implementation.
9. The application requests to charge the user $0.10.10. The payment is acknowledged.11. The acknowledgement is forwarded in the application.12. The application releases the session.The operations prior to the �release� may be repeated as many times as required.
8.2.2.4 The Session Initiation Protocol
The Session Initiation Protocol (SIP � RFC 2543) is a signalling protocol originallydeveloped to establish, modify and terminate multimedia sessions over the Internet. As such itforms a key component of IETF-based Voice over IP (VoIP) solutions and, because it is IP-based, challenges traditional telephony signalling mechanisms (largely based on SS7signalling). A related protocol, the Session Description Protocol (SDP � RFC 2327), is usedin conjunction with SIP to describe the media session to be established.SIP is an application level protocol, which can be supported on UDP or TCP, although UDPis usually preferred as it reduces state complexity. Reliability mechanisms are built into SIP toovercome the inherent unreliability of the UDP layer. Application of SIP to a genericnavigation service is therefore simply as shown in Figure 8-1.
IP SAP
SIP/SDP UDP
End user device
Galileo Service Centre
IP SAP
SIP/SDP
UDP
Figure 8-1: SIP stack
A number of groups are examining extending SIP to increase its feature richness and therange of services to which it can be applied. In the case of the SIP SIMPLE version of SIP,modifications have already been proposed to carry multimedia messages over SIP. We wouldpropose similar extensions for the transmission of Galileo specific information.In the example shown in Figure 8-2 we demonstrate the way in which subscriber registrationcould be modified to request an unspecified �Galileo� service. Here we modify the standardREGISTER method defined in RFC 2543 to enable the subscriber to request Galileo services.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 170
Domain name = gsc1.Galileo.com IP Address = 201.202.203.204 UDP port = 5060User Identity = +870761234567
SIP_401 (Authentication Request)
SIP REGISTER (Re -register with Authentication Response)
SIP_200 (OK)
Figure 8-2: SIP REGISTER example
SIP provides an almost unique opportunity to deliver services direct to the user,circumnavigating all other systems of the network operator. We recommend the definition ofnew SIP messages in a similar way to that illustrated in the above example. These couldinclude but would not be limited to
• The exchange of position information• Delivery of maps• Transmission of other navigation related data, e.g. waypoints.
8.2.2.5 System Interfaces requirements
The interfaces that should be considered for Galileo interoperability with UMTS are reportedin the following.In general, open and standard method of transmitting information should be used to minimisethe impact on the terminal. The limitations of the terminal will provide constraints for anyservice. The EU funded EMILY project (see R[1]) is investigating terminal features but isunlikely to examine the implications at application level. Further investigation may berequired, based on the results of the analysis, but the use of an open standard based on J2ME,or something similar, will ensure compatibility and popularity in the long term. Recentestimates suggest that approximately 500 developers are using the BREW platform to createand distribute applications, whereas approximately 200, 000 are using J2ME.The commercial aspects of Galileo integration may be distinguished in two different ways,each with an implication on the technical interfaces. Firstly, a service centre may operate as aservice provider, interacting directly with the user. The service centre would be responsiblefor all aspects of the relationship with the customer, including billing, privacy, authentication,etc. The second method of integration would be for a Galileo Service Centre to operate as a
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 171
Logica
�content� provider, where the content would be information for use by Galileo applications.Such a service would typically be for mobile network operators and value added serviceproviders. The commercial relationship would be directly with these entities and would notextend to the end user. These two methods of operation imply the following system interfacerequirements:1. If a Galileo Service Centre is to operate as a service provider then the relevant interface is
required to connect to OSA framework elements using the OSA API. Applicationsshould be implemented to support the API and thus benefiting from the features thatprovide billing functionality, authentication, and security
2. If the Service Centre is to operate as a content provider then a similarly open standard isrequired. In this case though the OSA model would not be suitable. A standard such asXML would be relevant given its increased use by government organisations andindustry. Application data would be packaged in a relevant XML definition anddistributed to third parties for use in providing navigation related applications.
3. The content provider model implies the need for a billing solution. Although billing tothe end user would be managed by the third party service provider, a method ofreconciliation is necessary to charge the third party an appropriate amount. A flexiblebilling model, integrated with the XML method of distribution would be mostappropriate. Interfaces for off-line and on-line reconciliation should be available, i.e.hard copy billing records should be produced as well as CDR�s of an appropriate format.
4. The USIM Interface should be examined in the context of navigation applications in theUMTS ICD. A SIMToolkit type interface has been defined between the USIM and theMS that allows the exchange of information between them. This interface should beincorporated into the ICD and extended to include navigation specific operations, such assending position data or authentication operations.
5. The Galileo Service Centre ICD should be extended to include a SIP interface for thedelivery of services directly to the user terminal. In addition to this the IETF should beengaged so that the SIP protocol may be extended to include navigation specificoperations such as those described in the previous section. Furthermore, the GALILEOterminal should interface IMS capability, as described in previous paragraphs.
8.2.3 HYBRIDISATION AT THE APPLICATION LEVEL (MAP MATCHING SOLUTIONS)
Of the different types of information that may be downloaded to the terminal, maps are ofparticular interest for road and personal application because of the benefits offered by mapmatching algorithms for position solution. We distinguish between the typical user orientedmaps and vector representations used in map matching as shown in Figure 8-3.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 172
Logica
Figure 8-3. Map matching data.
Map matching effectively serves the function of hybridisation at application level. A vectormap covering a few km2 may occupy less than 100 bytes (not including topological data).Such maps may be downloaded or stored at the terminal and used for hybridisation withoutthe knowledge of the user, if necessary.The different techniques that may be used for map matching include:
• Point to curve matching, where a position determined using Galileo is mappedto the closest point on a line
• Curve to curve matching, where a number of positions are determined thattrace a line. This line is then matched to a similar line in the vicinity.
• Variations of point to point and point to curve that include topological data.Some studies on this matter have found that curve to curve matching provides an adequatetrade-off between accuracy and data capacity requirements at the terminal. Accuracy wasfound to improve with more topological information.Main requirements about the implementation of map-matching algorithms regard thestandards for position data acquisition from the visualisation tool. It is recommended for mapsposition reporting systems implementing map matching to be able to read position data fromthe GALILEO receiver in GTRF (out of being able to read WGS-84 GPS position solution)
8.2.4 SAR-COSPAS SARSAT SYSTEM INTERFACE
The Interoperability analysis between GALILEO and COSPAS SARSAT focuses on thefollowing aspects:
• Analysis of IOR requirements for SAR (COSPAS SARSAT)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 173
Logica
• Analysis of relevant Projects results related to SAR systems (COSPAS-SARSAT)• Analysis of Interfaces between GALILEO and COSPAS SARSAT, at system as well
as at application level: the relevant interoperability elements of the systemsarchitecture have to be highlighted and analysed looking at the inputs coming fromthe results of other related studies.
• The interfaces between GALILEO and COSPAS-SARSAT is analysed and also datacapacity for GALILEO SAR return link is investigated.
• Main issues about position exchange formats for SAR application (COSPASSARSAT data formats) are discussed.
8.2.4.1 Interfacing entities
The activities performed by COSPAS SARSAT to enhance the system e.g. by theimplementation of 406 MHz. beacons (partly using GPS position data), the extension to theGEOSAR System, etc. as well as general and specific description of the space-, ground-, anduser segment are described in the documents referred in this report. Most of these reports arepublicly available and can be downloaded at the COSPAS SARSAT website: www.cospas-sarsat.org.
The key document for the work performed within the COSPAS SARSAT analysis in the TaskE SIA-phase is the executive report of the SARGAL Study (R[36]), including seven annexesrepresenting the six technical notes worked out by the SARGAL-team:
1. An analysis of the potential contribution from GEO satellites, including theimplementation of feedback links
2. A summary of the Galileo system impact of integrating a COSPAS-SARSAT-likedetection/location service in Galileo
3. A discussion of the evolution of the SAR equipment market segmentation in respect ofexisting and new services, foreseen technical evolutions, and a assessment of therespective sizes of the corresponding user equipment populations
4. A consolidated feasibility analysis of replacing the existing LEO-based detection/locationfunction by a MEO-based one
5. A description of existing and potentially new SAR services, their operational performancerequirements, the operational benefits expected from them, and their impact on theGalileo system architecture
6. An analysis of legal/regulatory issues
As well as the SARGAL Team has prepared a SAR Mission Requirement Document, in orderto provide SAR-related material to the Mission Requirement consolidation work conducted inthe GalileoSat and GALA projects. This SAR MRD paper is added as annex 7 to theSARGAL executive report (R[36]).
The studies identified above have been analysed within the framework of the SIA-phase ofTask E and the main findings related to the interoperability of COSPAS SARSAT withGalileo will be highlighted below.
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 174
Logica
Although it is not the task of this report to give a description of the COSPAS SARSATsystem the basic system function and some background information will be addressed in thenext paragraphs to allow readers unfamiliar with the COSPAS SARSAT system to understandthe conclusions derived from the analysis. Nevertheless the descriptive part is kept to aminimum and for further information. Please note that the COSPAS SARSAT nomenclaturehas a lot of specific abbreviations, which are usually not well known within the Galileocommunity, for this reason an extended list of abbreviation was added to this report. Thedescriptive part will also focus on aspects with relevance for interoperability (which is aweakness of COSPAS SARSAT) and today�s use of GPS within COSPAS SARSAT.
COSPAS SARSAT is a satellite based (LEO and GEO) global Search and Rescue (SAR)system for aviation, maritime, and land users. Since 1982, more than 11 000 people have beenrescued worldwide. The COSPAS SARSAT user devices, called beacons, operate at:
The use of the first modus is limited by a not continuous coverage (person in distress musthave a simultaneously LoS to the LEO satellites and the LUT, the footprint of the LEOs is~3000km (radius)). The use of the later frequency in combination with a Search and RescueProcessor (SARP) (not valid for the use of a Search and Rescue Repeater (SARR)) includes amemory-function onboard the satellites, which helps to overcome this problem. The SARPchannel (2400 bps) transmits the position information (derived by the Doppler measurement)plus an identification number of the aircraft/ship/vehicle and a time tag. In addition, 406 MHzbeacons can use satellite global positioning systems to obtain a very accurate position (butdepending on GPS with all connected disadvantages like missing integrity information, noservice guarantee in times of crisis and war, vulnerability to interference/jamming/spoofing,etc.), which can then be transmitted as part of distress messages.
The LEOSAR waiting time is below 1hour in mid latitudes (4satellites), but the users of the121.5 MHz system have to wait for a satellite which provides a communication link for aminimum of 4 minutes (With simultaneous visibility of the radio beacon and a LUT asmentioned above) this constraint may increase the waiting time to several hours if thetransmitting beacon is at the edge of the LUT coverage area.
The level of accuracy provided by the Doppler-measurements of the LEOs is in the order of afew nautical miles (if no additional GPS-receivers are involved like mentioned above), this ishelpful e.g. in open sea environment under good weather conditions but does not fulfil theSAR user requirements for operations in difficult environment and bad weather conditions. Inaddition to that, the Doppler location provides ambiguous (two) positions solutions. Theambiguity can be easily detected in some cases (large distances between the two solutions ande.g. known course of a ship/aircraft/vehicle) but in other cases (small distances between thetwo solutions and no additional information on course of the ship/aircraft/vehicle) this isdifficult or even impossible. In such cases a second pass of the LEO is required to resolve theambiguity, which increases significantly the time until position determination.
Another disadvantage of the COSPAS SARSAT system derived from the analysis of otherstudies is the fact that the system cannot distinguish between a 121.5 MHz distress beacon
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 175
Logica
transmission and other 121.5 MHz signals. This results in a large number of processinganomalies, which could cause false alerts.
Due to the disadvantages of the LEOSAR system all the COSPAS SARSAT users of the121.5/243 MHz beacons will have to switch over to the use of 406 MHz beacons until 2009completely.
A potential advantage provided by COSPAS SARSAT for an interoperable COSPASSARSAT / Galileo system is the complementary coverage of LEOs compared to MEOs inpolar regions, due to the fact that the Galileo-MEOs circle on inclined orbits whereas theCOSPAS SARSAT LEOs are in polar orbits. Especially in extreme northern and southernlatitudes the availability of a satellite based SAR system is of high importance, due to thefacts that the use of terrestrial communication infrastructure as well as terrestrial navigationinfrastructure is very limited in such regions and the chance that a distress event will bediscovered by passing planes/ships/vehicles is also reduced in comparison with the moredensely populated mid-latitudes.
The following information is given for the understanding of the COSPAS SARSATarchitecture without further analysis within this chapter:
Three types of user transmitters are in use:
• Emergency Locator Transmitters (ELTs) � used on aircraft• Emergency Position Indicating Radio Beacons (EPIRBs) � used on boats• Personal Locator Beacons (PLBs) � used by land-based personnel
The COSPAS SARSAT ground segment consists of:• 23 Mission Control Centres (MCCs)• 39 Local User Terminals in the LEOSAR System (LEOLUTs)• 7 Local User Terminals in the GEOSAR System (GEOLUTs)
All MCCs in the system are interconnected through appropriate networks for the distributionof system information and alert data. To ensure data distribution reliability and integrityCOSPAS SARSAT has developed MCC performance specifications and MCCcommissioning procedures (see reference documents). Reports on MCC operations areprovided by MCC Operators on an annual basis. Worldwide exercises are performed fromtime to time to check the operational status and performance of all LUTs and MCCs, and dataexchange procedures (see reference documents).
8.2.4.2 Interoperability analysis for the system architecture interfaces
The three options: alternative use, co-existence, and combined use will be discussed for theinteroperability of Galileo and COSPAS SARSAT on the architectural level:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 176
Logica
Co-existence:The co-existence of both systems Galileo (including an autonomous SAR service includingcommunication links, dedicated ground segment, and interfaces to relevant rescue authorities)and COSPAS SARSAT will allow the user to select one of both for his purposes. Thisdecision will depend on various factors e.g. existing equipment (COSPAS SARSAT),investment for change to Galileo SAR equipment, advantages of Galileo compared toCOSPAS SARSAT (e.g. higher accuracy (<10m instead of 5-20nm), reduction of latency, usefor other purposes (e.g. navigation, fleet management, etc.), etc. The decisions will be drivenby user specific requirements and financial backgrounds:
a) To keep existing COSPAS SARSAT equipment or move to Galileo SARb) Implement SAR (if not already available) and opt for Galileo (instead of COSPASSARSAT)
Maritime: The equipment of ships with SAR devices is regulated by the SOLAS convention,to allow the user a decision between COSPAS SARSAT and Galileo SAR equipment thecertification of Galileo as means of SAR for maritime applications is the first hurdle to becleared. The next barrier for a decision for Galileo SAR instead of COSPAS SARSAT is theprice of the equipment. Due to high market competition in the maritime sector the price of theequipment, which is sufficient to fulfil SOLAS requirements is the key argument for decision-making. Even if Galileo provides a better performance it is expected that ship owners will optfor COSPAS SARSAT if Galileo SAR equipment is even a little more expensive thanCOSPAS SARSAT devices. The price of an EPIRB (Emergency Position Indicating RadioBeacons) is ~ 1000 Euro (type: Sailor), the additional cost for the integrated GPS receiver is250 Euro (INMARSAT C SAR devices for maritime users cost ~3500E plus acommunication costs). Such equipment is carried today mostly by ships, which are obliged bythe SOLAS convention to be equipped with SAR facilities. If Galileo SAR devices can beoffered at price levels in the order of today�s GPS receivers for leisure shipping, fishing, orsmall commercial ships a huge market can be exploited. The exploitation of this �unregulatedmarket� could enable GALILEO to be competitive in the �SOLAS-regulated market�.
Another option for reducing the pressure on receiver prices in the SAR market would be theinteraction with assurance companies. Similar examples are already known in the automotivemarkets. Transferring such models into the maritime SAR world would mean that a shipowner who install the �enhanced� Galileo equipment (better accuracy, reduced time to alarmbetween moment of distress and call reception in the rescue central (10 minutes instead of>1hour), acknowledgement of call reception to the victim, etc.) will pay reduced insurancepremiums, because the financial damage in case of an accident will be (statistically) lowerdue to significant reduction of rescue time.
Aviation: The situation is similar to the maritime sector to some extend (also both regulatedand unregulated markets for SAR equipment) but less stringent, e.g. in Germany 20-50% ofthe General Aviation aircrafts (~20 000) are equipped with ELTs (Emergency LocatorTransmitter, Source: AOPA Germany). The General Aviation represents the biggest marketpotential for SAR equipment (e.g. Germany: 20 000 GA aircraft / < 1000 commercialaircraft). The price for ELTs is in the order of some 1000 Euros.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 177
Logica
Alternative use:
Alternative use of either Galileo SAR or COSPAS SARSAT would implicate redundantequipment of ships, additional investments in the COSPAS SARSAT and Galileoinfrastructure, and additional effort on harmonisation with rescue forces without significantimprovements for the users (the only benefit is position determination with Doppler if lessthan 4 Galileo-satellites are in view, but Doppler-positioning also requires a LoS to onesatellite for a certain period of time). For this reason this option will not be discussed in moredetail.
Combined use:
Following approaches for the combined use of Galileo with COSPAS SARSAT can beidentified:
• Migration from the use of GPS to Galileo for a certain amount of COSPASSARSAT terminalsThis includes the following options:- replacement of GPS by Galileo- parallel use of Galileo and GPS- use of combined Galileo/GPS receivers
• �Assisted-Galileo� data made available at the LUTs (reduce TTFF, usedifferential corrections, integrity information) either by own reference receiverson-site or communication links to Galileo Ground Segment
• Acknowledgement of received distress calls to the users
The above proposed interoperability interfaces correspond to a large extend to the descriptionof the Galileo SAR service as described in the Mission High Level Definition (Issue: April 3,2001, page 27):
�The GALILEO Search and Rescue service shall be co-ordinated with the existing COSPAS-SARSAT service and be compatible with both GMDSS and Trans European TransportNetwork guidelines. GALILEO will allow improving the time to detection and the accuracyof location of distress beacons with respect to current search-and-rescue system performance.
Search and Rescue Service (SAR)Capacity Each satellite shall rely signals from up to 300 simultaneous
active beaconsForward System Latency Time The communication from beacons to S&R ground stations shall
allow detecting and locating a distress emission in less than 10mn. The latency time goes from beacon first activation to distresslocation determination.
Quality of Service Bit Error Rate < 10-5 for communication link: beacon to S&Rground station
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 178
Logica
Acknowledgment Data Rate 6 messages of 100 bits each, per minuteCoordination Messages Data Rate 18 messages of 420 bits each, per minuteAvailability > 99%
Table 8-1 - GALILEO service performances for Search and Rescue Service 13
The position determination of the distress beacons is carried out by COSPAS-SARSAT on thebasis of the signals and data provided by the GALILEO Search and Rescue Service.Performances of position determination will be in the range of 5 km for the current beacons,to less than 10 meters for advanced beacons equipped with GALILEO receivers.�
8.2.4.3 System Interfaces requirementsThis chapter specifies the outputs of the IO analysis at system architecture level made in thechapter above. Due to the facts that the �co-existence-scenario� do not require an interfacebetween both systems and the �alternative use scenario� was excluded this chapter will focuson the �combined use-scenario�. Interfaces have to be defined for following interoperabilityapproaches:
• Migration from the use of GPS to Galileo for a certain amount of COSPASSARSAT terminals
Relevant issues:- Format of position data has to correspond to COSPAS SARSAT requirements- Dedicated Galileo receivers (e.g. integration into buoys)- Hardware interface- Software interface
• �Assisted-Galileo� data made available at the LUTs (reduce TTFF, usedifferential corrections, integrity information) either by own reference receiverson-site or communication links to Galileo Ground Segment
Relevant issues:- special receivers with pseudorange-output instead of position data- higher data rates to broadcast �raw data� to the LUT- Global reference stations network- communication links between reference stations and LUT- hardware modification at LUTs- Software specifications at LUT
• Acknowledgement of received distress calls to the users
Relevant issues:
13 Mission High Level Definition, Issue: April 3, 2001, page 27
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 179
Logica
- Communication link: LUT -> Galileo MCC- Galileo message uplink capability- Galileo �acknowledgement down link�- message reception capability at CASPAS SARSAT beacon
Considerations on downlink capacity:
High-level statistics on the amount of SAR calls are shown in the following figures 14:
Figure 8-11; Number of SAR events assisted by COSPAS-SARSAT (January-December2000)
Figure 8-12; Number of person rescued in SAR events assisted by COSPAS-SARSAT(January-December 2000)
14 Source: COSPAS SARSAT, System Data, No. 27, December 2001
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 180
Logica
Figure 8-13; Number of SAR events in which COSPAS-SARSAT was used(January1989-December 2000)
For a calculation on the required data capacity of the acknowledgement channel detailedstatistics (distribution per time, geographical distribution, etc.) were requested from theGerman Federal Ministry of Transport, Building, and Housing as well as from the COSPASSARSAT secretary.An important issue for the interoperability of Galileo with COSPAS is the position exchangeformats for SAR application. The available documents do not contain a description of theCOSPAS SARSAT data format. A request for that information was forwarded to the GermanFederal Ministry of Transport, Building, and Housing as well as from the COSPAS SARSATsecretary.
8.2.5 GSM/UMTS ASSISTED-GALILEO SYSTEM INTERFACE
The analysis of Interoperability between GALILEO and GSM/UMTS as bearer ofassistance/enhancing data, is organised as follows:
• Analysis of relevant Projects results related to interoperability of GNSS and MobileTelecommunication systems for GALILEO Network assisted applications (e.g. GSM,UMTS). Other projects results are elaborated as input for the IO analysis
• Analysis of interfaces between GALILEO and Communication systems forAssistance data transmission
• Analysis of interfaces between GALILEO and Communication systems forDifferential data transmission.
• A detailed IO analysis will be performed for the relevant systems identified as �CoreSystems� (GSM, UMTS)
• Relevant interfaces for Secondary Systems will be investigated to a less detail:limited analysis and appropriate mapping to other studies
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 181
Logica
8.2.5.1 Assisted Navigation requirements
Within this paragraph only relevant requirements for Assisted navigation will be reported (adetailed description of Assisted navigation is reported in R [1]).The output of this analysis will be an input for GALILEI Task D in order to define theCustomised Architecture of the GALILEO network assisted solution.The basic idea of assisted satellite navigation is to provide the receiver with a partial or fullset of navigation data (usually broadcast through the satellite SIS) in order to allow thereceiver itself to skip the demodulation phase (difficult in urban canyon and indoorenvironments, due to low power and high shadowing). This leads to a reduction of Time Tofirst Fix (TTFF). In fact, knowing approximate mobile positioning, it is possible to determinevisible satellites and Doppler shift, leading to a relevant reduction of the search window forthe receiver and power consumption (only a snapshot of data is sufficient in this case tocalculate the position).
The amount of data to be transmitted to the receiver depends on the technical solution to beimplemented:
3. Network Based solution: in this case the receiver has only to calculate pseudorangemeasurements and send them to the Mobile Network, that is in charge of calculatingthe receiver position, eventually applying differential corrections. In this case, theassistance data to be sent to the mobile are very short: visible satellite list, signalDoppler and code phase search window. Furthermore, in this case the assistance dataare valid for a few minutes. Only reduced receiver architecture is necessary,consisting on RF section, code generator and correlators to calculate pseudorangemeasurements.
4. Handset Based solution: in this case the receiver has to calculate by itself theposition. A full set of assistance data is needed, including the satellite ephemeris andclock corrections. The receiver has to be equipped with computation resources forsatellite position calculation and finally mobile position estimation. Also in this case,differential correction can be transmitted to the receiver for higher accuracypositioning
The basic points rising from the above description are the following:1. A GALILEO Reference Network is needed in order to monitor the overall satellite
ephemeris and being able to send them to the mobile (in broadcast or on-demand).An interoperability with GALILEO Local Element is here clearly envisaged for theprovision of assisted navigation data trough terrestrial link from GALILEO groundsegment to the BSC/NTSs
2. A common transmission protocol for Assistance data, DGPS/DGALILEOcorrections and RTD measurements is recommended.
ETSI developed standards for �assistance data� transmission and the compliance with theseexisting and foreseen standards is the core interoperability issue for GALILEO to beinteroperable with mobile communication systems. Assisted GPS option is an alreadystandardised position technique and the relevant recommendation for A-GALILEO definition
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 182
Logica
and implementation by means of GSM/UMTS networks is to be compliant with thesestandard from the outset.
8.2.5.2 GSM Interfacing entities
The system/applications architecture interfaces description is performed identifying therelevant interfacing system entities and their specifications.
GALILEO Sat ephemeris
GALILEO LOCAL
ELEMENTS
GALILEOAugmentation Data
GALILEO GS
Figure 8-14; Interface entities between GSM Network and GALILEO
In order to correctly identify the interfacing entities, the functional scheme of a LocationBased Services embedded into a GSM/UMTS framework is reported in the above figure.
Interfacing entities for Assisted Navigation are:
• GALILEO Ground Segment (OSS): it can provide the SMLC with the basic satellitenavigation data without the need to implement a worldwide Reference Station Network.Data to be transmitted are constellation status, integrity information (no real-time), andnavigation assistance data (e.g. ephemeris and clock corrections). For GSM, standardinterfaces are not currently defined. For UMTS, a description of the relevant interface isdescribed in par.8.2.5.5.
• GALILEO Local Elements: they can provide SMLC with the necessary data forintegrity information broadcasting and Differential correction. Furthermore, in this casepartnership could be carried out between mobile operators and GALILEO Local Elementsin order to share costs for the development of a dense differential Network throughout allEurope
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 183
Logica
8.2.5.3 Interoperability analysis for User Terminal-Processing interfaces
The relevant interoperability aspects are:
� Analysis of interface between the SMLC and GALILEO Ground Segment network.Through this interface, the precise data coming from the GALILEO referencenetwork can be distributed to the GSM/UMTS network.
� Analysis of interface between the SMLC and GALILEO Local Elements. Throughthis interface, augmentation data coming from the GALILEO Local elements can bedistributed to the GSM/UMTS network
� Standard Procedures for Assisted-GNSS and Augmentation data communication areprovided. Application of that protocol to GSM and UMTS broadcasting channel hasbeen provided. The short messaging services are the preferred transmission modalityfor Mass Market Assistance data broadcasting. Concerning differential correctionsand augmentation data, broadcasting is the preferred way. On-demand services (userrequesting data on traffic channel) can be envisaged, especially for professionalservices, requiring high data rate for reference stations measurements transmission.They can be implemented taking into account RTCM only standards. This is thenormal procedure applied currently. Proposed standards are irrespective of thetransmission channel.
� Considerations on the Assisted GALILEO aiding data-format and protocols andrecommendation for proposal for future standards (e.g. RRLP protocol: data capacityevaluation to support a double (GPS/GALILEO) constellation assistance/differentialdata).
� Considerations on Mobile Networks Synchronisation: future development andrequirements for the exploitation of integrated systems (GALILEO BTSssynchronisation allows the solutions of the problems related to RTD calculation forhybridised GALILEO/E-OTD positioning)
The starting point of the IO analysis is the ETSI (GSM/UMTS) standardisation processconcerning the interoperability for LCS services A [2], A [3], A [4]. This interoperabilityanalysis starts in particular from the standardised procedure for Assisted Navigation in orderto evaluate the relevant IO issues for A-GALILEO and D-GALILEO procedures, focusing onassistance/differential data format and protocols to be implemented in order to exploit theMobile Communication Network communication capability.In the following figure the general ETSI standardised position measurements procedure isreported A [4], which represent the basic procedure to follow also for GALILEO assistedposition technique.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 184
Logica
Figure 8-15; Position Measurements procedure
The RRLP Measure Position Request can also include possible assistance data to the MS.The assistance data delivery Procedure enables the SMLC to send assistance data to the MSrelated to position measurements and/or location calculation. The MS does not use the RRLPprotocol to request assistance data, only to receive these data from the SMLC.
Figure 8-16; Assistance data delivery procedure
In the present standardisation, assistance data for network assisted navigation can bedistributed by means of this assistance procedure and also through SMSCB DRX service,which foresees the broadcasting of the GPS assistance data. The SMSCB service allows thebroadcasting of 82 bytes messages in length. The Assistance data message contains three datasets: differential correction, ephemeris and clock correction, almanac and other datainformation. The ephemeris, clock correction, almanac and other data are obtained from GPSnavigation messages. The relevant interoperability option for GALILEO is to provide theSMLC with these precise data gathered by means of GALILEO network and GALILEOLocal Elements and to insert these data in the Assistant data message together to the GPSassistance data. Data capacity problems need to be investigated taking into account theupdating rate of the assistance information.As far as the GALILEO and GSM Network interfacing aspects are concerned, GALILEOdesign and implementation have to take into account the existing GSM standards in order tofacilitate the Systems Interoperability. Furthermore, recommendations have to be done withthe goal to include the GALILEO positioning method in the Standardisation process. Inparticular, GALILEO GS and GALILEO LE should be able to communicate with mobilenetworks elements, and transfer assistance-data to the GSM/UMTS elements preposed to LBSservices delivery (e.g. SMLC, UMTS) in order to provide augmentation and assistance in the
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 185
Logica
position calculation function. Furthermore, using this approach, a direct tunnelling to UserTerminal is possible without any protocol conversion (in case the mobile operators acts assimple broadcaster of GALILEO augmentation, without a service and billing structure forthat).In the existing standard for LCS implementation in GSM, assistance and augmentationservice needed for the A-GPS and DGPS positioning services are considered in the form ofpoint-to-point and broadcast service of assistance data on dedicated channel. The SMLC inthe GSM LCS architecture is in charge to manage the positioning procedure and to deliver theassistance data to the UTs. Assistance data are collected in the SMLC and delivered on-request or broadcasted to the GPS receivers that implement the LCS protocols stack. ExternalInterfaces and protocols for the communication between GSM networks and ExternalPositioning elements (e.g. A-GPS external server, DGPS reference stations) are not alreadydefined. If GALILEO External Elements needs to be interfaced to the GSM network forassistance service provision, the natural choice can be to start from GSM standardisedprotocol defined for GSM internal LCS procedure and evaluate the possible changes would berequired in order to adapt the protocol to this particular case. The RRLP protocol, whichimplements both the Assistance data delivery procedure and the positioning proceduresbetween the SMLC and the MS, is the logical choice. In both the procedures data assistanceformat is already defined for the GPS case, and no relevant difference should be made for theGALILEO case in the Assisted or Differential mode. Furthermore RRLP messages used forthe Assistance Data Delivery procedure between the SLMC and the MS could be adapted inorder to support the GALILEO assistance data transmission from the GALILEO GS to theSMLC in the GSM Network.In the following a general overview of the standardised assistance data format is given,differentiating assistance data for differential positioning and assistance data for assistednavigation. Starting from this data format, investigation of data capacity requirements will beperformed and feasibility issues through GSM/UMTS broadcast data service will be carriedout. The general data format for the assistance data (interpreted both as DifferentialCorrections, Ephemeris, Clock corrections, Almanac and others) is the following, where thedata field could be both assistance and differential data.
Parameter Bits Resolution Range Units Occurrences PresenceCipherOn/Off
1 --- 0 – 1 --- 1 M
CipherControl
CipheringKey Flag
1 --- 0 – 1 --- 1 M
Ciphering Serial Number 16 --- 0 - 65535 --- 1 CData 638 --- - --- --- M
Table 8-2; General data format for the assistance dataCiphering is also foreseen for relevant data.
8.2.5.3.1 Differential corrections data format
Differential Data have to be implemented into the SMS-CB DRX messages (82 bytes).
This format is related to GPS and is derived from RTCM standard. In that case, sub frames 1to 3 (containing ephemeris and clock corrections) shall be transmitted at 90 s rate.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 186
Logica
This message is built to allow for broadcast rates that more closely match the time ofapplicability of the contained data.In the case of Differential corrections, the following format is recommended for DGPS.
Parameter Bits Resolution Range Units Occurrences Presence RefGSM (GALILEO)Time
Updatings for of GALILEOThe total amount of DGPS information is 48 bits (6 octets) per satellite with about 80 bits (10bytes) of overhead information for GPS Reference Station only relevant data. Those data arebolded into the above table. The total message size for 12 visible satellites is about 651 bits,corresponding to 82 bytes, which will fit within a single SMSCB message.ETSI includes also relevant information needed for a hybridised E-OTD time differencepositioning, like �Reference Time�, reporting the GSM Frame Number (FN), TimeslotNumber (TN) and Bit Number (BN), out of the GPS TOW.
Considering that, with a double constellation GALILEO+GPS, also the number of visiblesatellites could be doubled at least in clear-sky environments, probably two SMS-CBmessages will be necessary to transmit Differential corrections for both the constellations.
The message structure will be the same, starting from the fact that in the future the Referencestations should provide integrated data (GPS+GALILEO).
The maximum acceptable age for a differential range correction is about 30 s. This boundwas set mainly because of the effects of latency on SA correction. After SA removal, andconsidering that GALILEO will not contain SA, degradation of accuracy vs differentialcorrections age is minor. In that case a 30 s value seems to be more than sufficient formedium accuracy solutions.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 187
Logica
Considering this bound, at least the following messages shall be sent every 30 s:
• 1 SMSCB message for DGALILEO corrections (12 GALILEO satellites), containingoverhead data
The above analysis is carried out for a single frequency case. In the case three openfrequencies will be provided, the previous requirements have to be modified. In that case, thenumber of bits to be transmitted for each satellite will be:144+80 bits overhead. In that case,about 1808 bits will be needed to transmit differential corrections for a satellite system,Therefore, 3 SMSCB messages will be needed to transmit DGALILEO corrections for a threefrequency constellation. For the double constellation case, about six SMSCB messages every30 s are needed.
8.2.5.3.2 Assisted Navigation ProtocolTwo alternative procedures can be used to determine when and what assistance data is sent:
• Send all the data (Almanac and Initial location) for every fix � This procedure issimple and supported by A[3], but wastes bandwidth resources.
• Send Assistance Data only when required, but sending is initiated by LCS client �This procedure is bandwidth efficient and supported by A[3]. LCS client must keep adatabase of the last time Assistance Data was sent to every subscriber, and determinethe next sending time.
The following functions have to be exploited at protocol level:• Position Measurement Procedure• Assistance Procedure• Monitoring and command of the A-GALILEO/GPS module
In the following the details for the three Assistance functions will be defined.The general Protocol for assisted positioning shall contain the following fields:
Element Description Presence
Positioning Instructions Express the allowed/required
location methods and to provide
information required QoS
Mandatory
GPS Almanac Data Almanac Data Optional
Initial Position Data Location Information Optional
GALILEO Ephemeris Data
(Phase II)
GALILEO Ephemeris Data Optional
Table 8-4; Assisted positioning data format
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 188
Logica
Positioning Instructions can be required with the following protocol:
No. Field Type Description Range Units1 Positioning
methodEnum Which location method
should be used
2 Response Time Ulong Desired response time Seconds
3 Multiple Sets Boolea
n
Whether the MS is allowed to
send multiple measurements
sets
0- allowed
1-not allowed
4 Periodic Tracking
Mode
(Optional � not
supported by the
standard)
Boolea
n
Whether the MS requested to
perform periodic tracking and
send its position after
Response Time
0-not requested
1-requested
Table 8-5; Assisted Positioning protocol
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 189
Logica
8.2.5.3.3 Assistance Data
Ephemeris and clock corrections
Parameter Bits Resolution Range Units Occurrences PresenceTransmission
The total amount of ephemeris and clock data (corresponding to subframe 1 to 3 of thenavigation message) is about 638 bits for 1 satellite, corresponding to about 80 bits. Thereforethe ephemeris and clock information for one satellite is contained into 1 SMSCB message.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 190
Logica
The ephemeris and clock information have to be transmitted at least 1 each 90 s. this impliesthat, for 12 satellites, the transmission time for all the visible satellites is 12*90/60 = 18 min.
Updatings for GALILEOGALILEO ephemeris will be identical to GPS ephemeris, as reported in R[38]. Therefore, anidentical message to the above one has to be sent.It can be assumed that another GALILEO Ephemeris and Clock message every 90 s will besent, so that the following ephemeris and clock messages have to be sent every 90 s:
� GALILEO ephemeris and clock message� GPS ephemeris and clock message
An Assisted Navigation receiver can download assistance data from the mobile network at 90s intervals, and entering in idle mode (with low power consumption) between downloads.When a position is requested, the receiver executes a �snapshot� measurement using thereceived assistance data without demodulating the navigation message and then enters idlemode.
Almanac Data
Almanac and other data are not time critical and shall be broadcast at a lower rate (e.g. inseveral hours or transmitted on demand). Almanac can be used in Network based applicationsallowing a limitation of the amount of data to be transmitted.
In the GPS case, ETSI suggests that the relevant information can be transmitted in 4 hours,using only a subset of valid data (against the total 35 sub frames of the GPS data). Therefore,12 SMSCB messages are needed to deliver the entire data set. If the data have to be sent infour hours, this implies 1 SMSCB message every 20 min. The Almanac message does notconstitute the bottleneck of the assistance information, but it is used in some currentapplications instead of the ephemeris and clock information.
The almanac data shall be provided for the GPS case through the broadcasting of theequivalent of GPS sub frames 4 and 5. The relevant format is reported in the following table.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 191
Logica
Parameter Bits Resolution Range Occurrences PresenceTransmission TOW 20 1 0 - 604799 1 M
GALILEO almanac is not defined in R[38]. Reference data can be taken from GALA.The relevant Almanac data reported for GALILEO are the following:
err_flag xdr_u_int n.a.Integer flag, describing an eventual error conditionoccurred.
err_flag = 0 � �No error occurred�
NOTE: the following fields will exist only if ”err_flag” equals 0
new_data_set xdr_u_char n.a.
Tells if new almanac data will be transmitted,being available a new set, more recent than date�MJD_t_alm_last�
new_data_set = 0 � no almanac data istransmitted by GCS
new_data_set = 1 � new almanac data follows
The following data is packed inside the message, only if “new_data_set” flag equals 1
MJD_t_alm xdr_double day Time tag of almanac data set transmitted
toa xdr_bytes(1) 212 s
Almanac Reference Time
Elapsed time, since start of week, discretized witha quantization of 212 = 4096 s.
Shall be truncated at toa (max) = 602112.
NOTE: the following fields shall be repeated for each Orbit Plane of Galileo Constellation,
thus 3 times
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 192
Logica
sqrt_smja xdr_u_int TBDSquare-root of Mean Semimajor axis for Plane #
Truncated on 24 bit
ecc xdr_u_int 2-21 Mean Orbit eccentricity for Plane #
Truncated on 16 bit
inc xdr_u_int TBDMean Inclination for Plane #
Truncated and two�s complemented on 16 bit
raan xdr_u_int TBDRight Ascension of Ascending Node for Plane #
Truncated and two�s complemented on 24 bit
omega_1st xdr_u_int TBDArgument of Perigee of 1st SV in the Plane #
Truncated and two�s complemented on 24 bit
NOTE: the following fields shall be repeated for each Galileo Space Vehicle,
thus 30 times
m_anom xdr_u_int TBDMean Anomaly of the Space Vehicle
Truncated and two�s complemented on 24 bit
degraded_af0 xdr_u_int 2-20 s�Degraded� coefficient af0 for SV clock errorcorrection
Truncated and two�s complemented on 15 bit
degraded_af1 xdr_u_int 2-38�Degraded� coefficient af1 for SV clock errorcorrection
Truncated and two�s complemented on 11 bit
health_status xdr_u_int n.a.
Predicted SV health status. Interpretation ofinteger status flag values is still TBD. Such a�predicted� information, may not be in agreementwith the actual integrity data, refreshed with highrate for �connected � satellites.
Truncated on TB bit
In this case, the entire information can be broadcast in 10 SMSCB messages. The sameconsiderations reported for GPS can be here repeated.
Almanacs can be broadcast or sent on demand. They do not constitute the real bottleneck ofthe system and will be not considered in the whole data capacity calculation.
Considerations on E-OTD/A-GALILEO assistance data broadcast service
In order to be compliant with the trends in terms of Standards, E-OTD assistance data shall bedelivered with a minimum impact on GSM Network and Handset.ETSI has delivered detailed standards for the broadcasting of E-OTD assistance data.Also in this case, SMSCB DRX services are proposed for that, as for the GPS assistance data.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 193
Logica
In general the following information are included:
• Reference Time• Neighbour Channel Time slot Scheme• Information about sectored neighbour channels• RTD values and relevant drifts• Serving cell and neighbour cells location
In general one SMS-CB message is sufficient to transmit such information.
Following that, the hybridised terminal (GNSS/E-OTD), has to be able to process andinterpret the SMSCB messages in ETSI format. Furthermore, both GPS and GALILEOmeasurements and mixed ones have to be processed within the hybridised receiver.
E-OTD message processing shall be merged with assistance data broadcasting and processingthrough SMSCB service in order to fulfil the interoperability purposes.
8.2.5.4 Augmentation Data and Assistance Data Broadcasting: Data Capacity for GSMand UMTS
A data capacity analysis for the GALILEO (+GPS) Augmentation and Assistance Databroadcasting is necessary in order to identify the requirements for the Interoperabilitybetween GALILEO and Mobile Networks.The SMSCB service is able to transmit one message every two seconds. Therefore, 15SMSCB messages can be transmitted every 30s, while 45 messages can be transmitted within90s. A schedule message has to be sent before the data messages. A schedule message cancover 48 successive SMSCB message slots.One differential correction message has to be transmitted every 30 s, while the ephemeris andclock data can be broadcast every 90s, so that a complete ephemeris and clock message istransmitted in about 18 min for 12 satellites in view.
GALILEO Single frequency caseData to be transmitted are:• 1 Schedule message at the beginning of the 90 s period• 1 SMSCB DGALILEO message every 30s• 1 SMSCB GALILEO ephemeris and clock message every 90 s• 1 SMSCB message for the Almanac (optional)
GALILEO+GPS Single frequency caseData to be transmitted are:• 1 Schedule message at the beginning of the 90 s period• 1 SMSCB DGALILEO message every 30s + 1 SMSCB DGPS message every 30s• 1 SMSCB GALILEO ephemeris and clock message every 90 s + 1 SMSCB GPS
ephemeris and clock message every 90 s• 1 SMSCB message for the GALILEO Almanac (optional)• 1 SMSCB message for the GPS Almanac (optional)
The situation is represented in the following figure
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 194
Logica
30s
60s 90s
DGALILEO corrections
DGPS corrections
GALILEO Eph.+Clk
GPS Eph+Clk
DGALILEO corrections
DGPS corrections
GPS Eph+Clk
GALILEO Eph.+Clk
30s
DGALILEO corrections
DGPS corrections
GPS Eph+Clk
GALILEO Eph.+Clk
Schedule Message
GALILEO Almanc GPS
Almanc
Considering that the data capacity available for an SMSCB service in a period of 90 s is 45messages, the utilisation factor of the SMSCB data capacity for a BTS for the broadcasting ofdifferential corrections and Assisted Data is the following:
• Without Almanacs and Single constellation
• %56,15457
451
452*3 ==+ of the total SMSCB service capacity (ephemeris and
clock corrections every 30s)
• %11,11455
451
451
453 ==++ of the total SMSCB service capacity (ephemeris
and clock corrections every 90s)
• Without Almanacs and Double constellation (GALILEO+GPS)
• %89,284513
451
454*3 ==+ of the total SMSCB service capacity (ephemeris and
clock corrections every 30s)
• %20459
451
452
452*3 ==++ of the total SMSCB service capacity (ephemeris
and clock corrections every 90s)
• With Almanacs and Double Constellation (GALILEO+GPS):
• %33,334515
451
452
454*3 ==++ of the total SMSCB service capacity
(ephemeris and clock corrections every 30s)
• %44,244511
451
452
452
452*3 ==+++ of the total SMSCB service capacity
(ephemeris and clock corrections every 90s)
As can be seen, the utilisation is quite high also in the single frequency case.The analysis of format compression is recommended in order to decrease the overall SMSCBresources allocation.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 195
Logica
GALILEO+GPS Three frequency caseData to be transmitted are:• 1 Schedule message at the beginning of the 90 s period• 3 SMSCB DGALILEO message every 30s + 3 SMSCB DGPS message every 30s• 1 SMSCB GALILEO ephemeris and clock message every 90 s + 1 SMSCB GPS
ephemeris and clock message every 90 s• 1 SMSCB message for the GALILEO Almanac (optional)• 1 SMSCB message for the GPS Almanac (optional)The previous diagram can be applied in order to calculate the utilisation factor:
• %604527
452
451
453*2
456*3 ==+++ of the total SMSCB service Capacity
(ephemeris and clock corrections every 30s)
• %11,514527
451
452
452
456*3 ==+++ of the total SMSCB service Capacity
(ephemeris and clock corrections every 90s)
The above analysis is referred to the worst case in which it is necessary to transmit separatelydifferential corrections for each carrier frequency (this is the case of significantly differentcorrections values, e.g. sensibly different impacts of ionosphere error on the pseudorangemeasurements).
As it can be seen, in the best case (only one constellation, single frequency, without almanac),the utilisation factor is acceptable (15,5% through ephemeris every 30s, 11% throughephemeris every 90s), while in the worst case (double constellation, three frequency, withalmanacs) 60% of utilisation is foreseen.
Therefore, a more compress data set or a compression algorithm (e.g. the CBS compressionalgorithm reported by ETSI) is recommended in order to allow the full interoperabilitybetween GALILEO and the Mobile operators for the delivery of the applications.
UMTS has a similar SMSCB service whose standard is under consolidation. The overallcapacity per cell is too small (lower than 1 kbit/s at maximum) in the given GSMimplementation. For the UMTS implementation an overall capacity per cell about 20 kbit/s isrequired. Therefore, the same considerations reported above can be repeated within thisframework for UMTS case.
This lead to the following SMSCB utilisation factor:
%224510
451
453*3 ==+ For a GALILEO+GPS constellation without Almanac data.
(ephemeris and clock corrections every 90s)
%89,8454
451
453 ==+ for a GALILEO+GPS constellation without Almanac data.
(ephemeris and clock corrections every 90s)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 196
Logica
This could be an acceptable occupation also without compression.
8.2.5.5 UMTS interfacing entities
Positioning methods standardisations in UMTS
In Europe, the European Telecommunications Standards Institute (ETSI) with its 3GPartnership Project (3GPP) is responsible for the standardisation of the Location Services andthe location techniques for UMTS and different positioning solutions are being studied widelyby the network operators and research institutes. Currently, there are three 3GPP standardisedlocation techniques supported by the UMTS Terrestrial Radio Access Network (UTRAN):
1. The cell-ID2. The OTDOA with optional Idle Period DL (IPDL) assistance by the network and3. The network-assisted GPS (AGPS).
The general architecture for the UMTS positioning service is reported in the following figure:
Iub
LMU Type A
SRNC CN
Node B (LMU Type B) RNC
UE Node B (LMU Type B)
Iur
Iu Iub
Uu
SAS
Iupc
The SNRC is a network element of UTRAN and contains functionalities required to supportLCS in one PLMN. The relevant functions performed by the SNRC are:
1. To request information from other RNCs.2. To manage and control the flow of simultaneous positioning request3. To select the position method to use4. To calculate the UE position and the correspondent accuracy5. To provide UE positioning assistance data
Another kind of RNC is the CRNC (Controlling RNC), which is in charge of resourcemanagement functions and broadcasting of system information. The broadcast informationmay be encrypted to ensure its availability only to the subscribers of the services. The
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 197
Logica
information to be broadcasted could include for example differential correction for DGPSapplications (also DGALILEO in the future) and assistance data for A-GPS (also A-GALILEO in the future).
Node B and LMU are network element of UTRAN that may provide measurements results forposition estimations and make measurements of radio signals and communicate thesemeasurements to the CRNC (on request or autonomously).
The SNRC, works as SMLC (Serving Mobile Location Centre) and receives authenticatedrequest from LCS applications or LCS Client functions in the CN (Core Network) across theIu interface. RNCs manage the UTRAN resources, the UE and the calculation functions toestimate the position of the UE and return the result to the CN.
The SAS (Stand Alone A-GPS SMLC) provides GPS assistance data to the SRNC to bedelivered through point-to-point or broadcast channels to the UE, and acts as a locationcalculation server if the location estimates are not calculated in the RNC.
The SAS communicates with the SRNC over the Iupc interface. By means of this interfacethe SAS is able to forward assistance data to the UEs and to receive UE positioningmeasurements data from the SRNC.In the network-assisted GPS positioning method, an example of the end-to-end call flow ishereinafter reported (A [15]):
UE Positioning related signalling between an SRNC and a target UE is supported by theRRC protocol as specified in A [16].The SRNC determines assistance data and sends it in the RRC ASSISTANCE DATADELIVERY message to the UE. In networks that include an SAS, the UE Positioningassistance data is generated within in the SAS and passed to the SRNC over the Iupcinterface.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 198
Logica
The positioning request to UE signalling flow is generic for all UE-based or UE-assistedpositioning methods (OTDOA and Network-assisted GPS).For OTDOA and GPS, UTRAN may broadcast assistance data to the UE. The broadcastchannel that is used for the OTDOA and GPS assistance data makes use of the commonUTRAN broadcast service specified in A [16].
The network-assisted GPS methods rely on signalling between UE GPS receivers and acontinuously operating GPS reference-receivers network. GPS reference receivers may beconnected to the UTRAN to enable derivation of UE assistance data.Assistance data transmitted in the UTRAN network concerning the GPS positioning includedifferential correction coming from a GPS Reference Station and Assistance Data for the A-GPS solution (i.e. reference time, reference position, DGPS corrections, ephemeris and clock-corrections, almanac and other data). Both in the case of A-GPS and DGPS options,computation of the position fix can either be performed in UTRAN (SRNC) for UE assistedor in the UE in the UE-based. The Information Elements that may be transferred fromUTRAN to UE and from UE to SRNC are described in detail in the A [15] document.The major recommendations that comes from the analysis of the interfacing with UMTSnetwork are the following:
� GALILEO system need to be included in the Wireless Systems standardisationprocess since the beginning (3GPP, LIF) as GPS is already considered a standardpositioning method, and the delivery procedures for assistance-augmentation GPSdata have been already defined in the GSM and UMTS standards. The relevantimpact on existing standards in order to take into account also GALILEO, concernsthe data capacity needed to support the broadcasting of both GPS and GALILEOrelated data. This activity has been started within GALILEI .
� As GALILEO will be included in the Standardisation Process, A-GALILEO/DGALILEO terminals shall foresee the option to implement theUMTS Standardised Protocols for LCS in order to receive assistance andaugmentation data from the Mobile Networks and provide LCS standardised servicesto the GALILEO end users. General LCS protocols description for each layer isreported in A [17] Functional stage 2 description of location services in UMTS
� As GALILEO will be included in the 3GPP standardisation process, GALILEO GS /GALILEO Local Elements should be designed and developed in order to be ableto be interfaced to the UMTS network; for example, GALILEO should be able todeliver Assistance and Augmentation data coming from a reference network (Local,Regional, Worldwide), to UMTS network elements that are in charge to manage anddistribute them (i.e. SRNC).The necessity of such interface is becoming evident in the most recently GPSAssisted Options; Worldwide networks have been designed and deployed to collectprecise GPS ephemeris-data that can be distributed to the UEs through the wirelessnetwork. Also in this case, the A-GPS server, which collects the measurements fromthe Reference Network and computes the assistance data, needs to be interfaced to theproper GSM/UMTS network elements (i.e. SMLC) that are in charge to forward themby means of an LCS point-to-point or broadcasting service.More precisely, a network of reference stations is located around the world so that allsatellites can be seen at all times by the network. By means of data gathered from thenetwork, the long-term orbit and satellite clock models are computed. The orbit andclock models are then distributed to servers, which can be located anywhere in theworld. These servers will often be part of an SMLC (Serving Mobile LocationCenter) or will be standalone elements external to the Mobile Networks architectureand interfaced with it.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 199
Logica
Consideration on Assistance data delivery through UMTS standardised-protocols in theA-GALILEO and DGALILEO positioning techniques.
GALILEO design and implementation have to take into account the existing GSM/UMTSstandards in order to facilitate the Systems Interoperability, and Recommendations have to bedone with the goal to include the GALILEO positioning method in the Standardisationprocess since the beginning. In particular, GALILEO GS and GALILEO LE should be able tocommunicate with mobile networks elements, and transfer them assistance data in order toprovide augmentation and assistance in the position calculation function.
In the existing standard for LCS implementation in GSM and UMTS, assistance andaugmentation service for GPS positioning solution is considered in the form of point-to-pointand broadcast of assistance data on dedicated channel. The SMLC in the GSM/UMTS LCSarchitecture is in charge to manage the positioning procedure and to deliver the assistancedata to the UTs. Assistance data are collected in the SMLC and delivered on-request orbroadcasted to the GPS receivers that implement the LCS protocols stack. External Interfacesand protocols definition for the communication between GSM/UMTS networks and ExternalPositioning elements (e.g. A-GPS external server, DGPS reference stations) are not alreadydefined.
Data delivering procedure from an External Positioning element (e.g. Aiding Serverwhich collects measurements from a local/regional/worldwide Network of reference stations,and compute assistance data to be distributed to the UTs), to the UTRAN SRNC, could beperformed through the Iupc interface by implementing PCAP (Positioning CalculationApplication Part) protocol at the External element.
As far as the GALILEO system interface towards the UTRAN is concerned, the Iupc interfacecan be considered as a possible way of interfacing. In this case the GALILEO interfacing-point should implement the PCAP protocol over the Iupc interface in order to communicatewith the UTRAN SRNC. The GALILEO interfacing point (e.g. Server which collectmeasurements from a reference network and compute the assistance data) should act as anExternal SAS, contributing to decrease the network functionalities and to distribute the LCSfunctionality to the network edge. Following this approach, the following configurations arepossible in the future LCS architecture:
1. SAS considered as part of the UTRAN element, able to compute assistance data to bedelivered to the UTs (Point-to-Point or broadcast). The SRNC is in charge of thePosition Calculation Function.
2. SAS considered as part of the UTRAN element, able to compute assistance data to bedelivered to the UTs (Point-to-Point or broadcast) and to perform the positioncalculation function.
3. SAS considered as an External Element (e.g. GALILEO GS), able to computeassistance data to be delivered to the SRNC in the UTRAN. The SRNC performs theposition calculation function and the distribution (Point-to-Point or broadcast) ofassistance data to the UTs.
4. SAS considered as an External Element (e.g. GALILEO GS), able to computeassistance data and to perform itself the position calculation function. In this caseboth the assistance data and the position data are sent from the SAS to the SRNC inorder to implement the LCS services.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 200
Logica
Iub
LMU Type A
SRNC CN
Node B (LMU Type B) RNC
UE Node B (LMU Type B)
Iur
IuIub
Uu
SAS
Iupc
GALILEO GS / LE
External Interface
Figure 8-17 – UMTS GALILEO System Interfaces
As seen in the LCS architecture, in order to support the A-GPS positioning within UTRAN, aStand-alone A-GPS SMLC (SAS) has been introduced, and an open interface between theSMLC (SAS) and the SRNC has been defined. This interface is analogous to the Lb interfacedefined in the GSM LCS specifications. In this case, dedicated GPS Assistance functionalityis separated from the other SRNC ones (LCS support functions) and the SRNC is interfacedto the SAS by means of an Iupc open interface. From a logical standpoint, the Iupc is a point-to-point signalling interface between an RNC and SAS within the UTRAN, even though theremay not be a direct physical connection between these two nodes. The Iupc interface enablesan RNC to request specific GPS related data from an SAS on demand, on modification, or atregular intervals.The SCCP (ITU-T Recommendation Q711/12/13/14) is used to transport messages betweenthe SRNC and SAS. One user function of the SCCP, called Positioning CalculationApplication Part (PCAP), is defined in A [18]. Both connectionless and connection-orientedprocedures are used to support PCAP.
PCAP descriptionPCAP provides the signalling services between RNC and SAS that are required to fulfilthe PCAP functions. PCAP services are categorized as follows:
� Position Calculation Service: They are related to a single UE and involve the transferof GPS measurement data and UE position estimate data over the Iupc interfacebetween the SRNC and the SAS. They utilisation connectionless signalling transportprovided by the Iupc signalling bearer.
� Information Exchange Service: They involve the transfer of GPS related data over theIupc interface between the RNC and the SAS on demand, on modification, or atregular intervals. They utilise connection-oriented signalling transport provided bythe Iupc signalling bearer.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 201
Logica
PCAP consists of Elementary Procedures (EPs). An Elementary Procedure is a unit ofinteraction between the RNC and the SAS. An EP consists of an initiating message andpossibly a response message. Two kinds of EPs are used:
� Class 1: Elementary Procedures with response (success or failure).� Class 2: Elementary Procedures without response.
In the following table the PCAP elementary procedures are reported:
ElementaryProcedure
InitiatingMessage
Successful OutcomeResponse message
Unsuccessful OutcomeResponse message
PositionCalculation
POSITIONCALCULATIONREQUEST
POSITIONCALCULATIONRESPONSE
POSITIONCALCULATIONFAILURE
InformationExchangeInitiation
IINFORMATIONEXCHANGEINITIATIONREQUEST
INFORMATIONEXCHANGEINITIATIONRESPONSE
INFORMATIONEXCHANGEINITIATIONFAILURE
Table 8-8; CLASS1 Elementary Procedure
Elementary Procedure Message
Information Reporting INFORMATION REPORTInformation Exchange Termination INFORMATION EXCHANGE
TERMINATION REQUESTInformation Exchange Failure INFORMATION EXCHANGE FAILURE
INDICATIONError Indication ERROR INDICATION
Table 8-9; CLASS2 Elementary Procedure
As an example, hereinafter are reported the messages flow diagram of different elementaryprocedures implemented in the PCAP:
Figure 8-18; Information Exchange Initiation procedure, Successful Operation
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 202
Logica
The procedure is initiated with an INFORMATION EXCHANGE INITIATION REQUESTmessage sent from SRNC to SAS. If the Information Type IE is set to 'Implicit', the SAS isresponsible for selecting the type of assistance data.Upon reception, the SAS shall provide the requested information according to the parametersgiven in the request. If the Information Report Characteristics IE is set to 'On-Demand', theSAS shall report the requested information immediately.If the Information Report Characteristics IE is set to "Periodic", the SAS shall periodicallyinitiate the Information Reporting procedure for all the requested information, with therequested report frequency.
Figure 8-19; Information Reporting procedure, Successful Operation
If the requested information reporting criteria are met, the SAS shall initiate an InformationReporting procedure.The detailed description of all the elementary procedures of the PCAP protocol and thedetailed description of the different exchanged messages (fields contents) is reported in theETSI TS 125 453 document.
8.2.6 LBS AND INTEROPERABILITY BETWEEN GALILEO AND MOBILECOMMUNICATION SYSTEMS
Location Based Services include all those services built on user location information andcommunication capabilities, with the aim of assisting users (personal or professional users) intheir movements (e.g. drivers), by providing them information related to their location, toimprove their security by means of dedicated emergency applications.Interoperability between GALILEO and Mobile Communication systems is one of therelevant key issues in order to implement Location Based Services (LBS).On one side, GALILEO positioning services (standard positioning service and augmentedservice) will play a key role in order to satisfy high position service requirements (e.g.accuracy, coverage, reliability, integrity) typical of different LBS applications. On the otherside, Mobile Communication systems provide reliable and high-quality communicationservices, and LBS standardised procedures (e.g. LBS administration and control functions)useful to guarantee a common and easy accessible layer for the LBS services provision.
Thanks to Interoperability between GALILEO and GSM/GPRS/UMTS systems, GALILEOUT will be not only a terminal for position determination but also a LBS UT. Relevant issuefor GALILEO UT will be the implementation of Mobile Communication protocol for LCS inorder to receive Location based standardised service (3GPP TS 22.071). Following this
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 203
Logica
approach the GALILEO UT will be able to receive both reliable and secure communicationservices for LBS (circuit or packed switched) typical of mobile communication systems, andstandardised administration and control functions already planned for LBS implementation inthe Mobile Operators environment. These functions will be useful for service authorisationand authentication procedures, quality of service parameters negotiation, privacy guarantee,and security and reliability provision. Furthermore the Interoperability with MobileCommunication Systems will allow GALILEO UT to receive communication serviceeverywhere roaming agreements exist between the Home PLMN and other PLMNs coveringdifferent regions.
In the following figure are shown how GALILEO and Mobile Communication systems caninteroperate in order to implement standard Location Based Services.
Standard LBS Service Implementation
Standard Positioning Service Augmented Positioning Service (DGALILEO, AGALILEO) Service Guarantee
Standard Communication service Reliable and Secure Communication LBS Satisfying Data Rate and Delay Handover functionality Roaming functionality
Standard Procedures for LBS administration and control functions
Authentication and Service authorisation Quality Parameter negotiation Privacy guarantee Priority service functionalities
GALILEO
MOBILE COMMUNICATION SYSTEMS
INTEROPERABILITY
Figure 8-20 – LBS interoperability Scenario
Compliance with 3GPP LCS standards for LBS is the relevant recommendation forGALILEO, mainly looking at the functionalities and interfaces of the GALILEO LocalElement UT. Following this necessity, hereinafter are reported the relevant constraints andrequirements identified in the 3GPP TS 22.071 document for the LCS description, withrelevant focus on LBS.
3GPP standards shall support location service features, to allow new and innovative locationbased services to be developed. It shall be possible to identify and report in a standard format(e.g. geographical co-ordinates) the current location of the user�s terminal and to make theinformation available to the user, ME, network operator, service provider, value added serviceproviders and for PLMN internal operations.The standard shall support both GERAN and UTRAN to facilitate determination of thelocation of a mobile station.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 204
Logica
Accuracy, coverage, privacy and transaction rate may be considered the primarydistinguishing attributes that define a value-added service and in the 3GPP standards arebriefly described as follows:� Accuracy is the difference between actual location and estimated location,� Coverage is an expression of the geographic area in which the UE user will receive an
adequate perceived quality of service,� Privacy describes the user�s perception of confidentiality of the location information,
and� Transaction rate indicates how frequently network messaging is required to support
the service.
The accuracy for location services can be expressed in terms of a range of values that reflectthe general accuracy level needed for the application. Different services require differentlevels of positioning accuracy.
The majority of attractive value added location services are enabled when locationaccuracies of between 25m and 200m can be provided.
· Location-independent Most existing cellular services, Stock prices, sports reports· PLMN or country Services that are restricted to one country or one PLMN· Regional (up to
· District (up to 20km) Local news, traffic reports· Up to 1 km Vehicle asset management, targeted congestion avoidance advice· 500m to 1km Rural and suburban emergency services, manpower planning,
information services (where are?)· 100m (67%)· 300m (95%)
U.S. FCC mandate (99-245) for wireless emergency calls usingnetwork based positioning methods
· 75m-125m Urban SOS, localized advertising, home zone pricing, networkmaintenance, network demand monitoring, asset tracking,information services (where is the nearest?)
· 50m (67%)· 150m (95%)
U.S. FCC mandate (99-245) for wireless emergency calls usinghandset based positioning methods
Response Time is one of the negotiable QoS parameters. Support of response time by aPublic Land Mobile Network (PLMN) is optional. The LCS Server may allow a LCS Clientto specify or negotiate the required response time either at provisioning or when the request ismade. The LCS Server may optionally ignore any response time specified by the LCS Clientthat was not negotiated. If response time is not ignored, the LCS Server shall attempt tosatisfy or approach it as closely as possible when other quality of service parameters are notin conflictFor immediate location request response time options are as follows:
� �No delay�: the server should immediately return any location estimate that itcurrently has. The LCS Server shall return either the Initial or Last Known Locationof the Target UE. If no estimate is available, the LCS Server shall return the failure
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 205
Logica
indication and may optionally initiate procedures to obtain a location estimate (e.g. tobe available for a later request).
� �Low delay�: fulfilment of the response time requirement takes precedence overfulfilment of the accuracy requirement. The LCS Server shall return the CurrentLocation with minimum delay. The LCS shall attempt to fulfil any accuracyrequirement, but in doing so shall not add any additional delay (i.e. a quick responsewith lower accuracy is more desirable than waiting for a more accurate response).
� �Delay tolerant�: fulfilment of the accuracy requirement takes precedence overfulfilment of the response time requirement. If necessary, the server should delayproviding a response until the accuracy requirement of the requesting application ismet. The LCS Server shall obtain a Current Location with regard to fulfilling theaccuracy requirement.
The LCS Server may allow different location requests to be assigned different levels ofpriority. A location request with a higher priority may be accorded faster access to resourcesthan one with a lower priority and may receive a faster, more reliable and/or more accuratelocation estimate.For Emergency Services (where required by local regulatory requirements) the locationrequest shall be processed with the highest priority level.
Position information should be safeguarded against unapproved disclosure or usage, andshould also be provided in a secure and reliable manner that ensures the information isneither lost nor corrupted. Audit records should be maintained of positioning requests andresponses to facilitate resolution of security violations.
Only authorized LCS Clients shall be able to access the LCS Server. Before providing thelocation of a Target UE to any authorized LCS Client, the LCS Server shall verify both theidentity and authorization privileges of the LCS Client.
The Target UE Subscriber shall be able to restrict access to the Location Information(permanently or on a per attempt basis). The LCS Client access shall be restricted unlessotherwise stated in the Target UE Subscription Profile. The home network shall have thecapability of defining the default circumstances in which the Target UE�s LocationInformation is allowed to be provided as required by various administrations and/or networkrequirements.
The user may wish to differentiate between privacy requirements, depending on whichservice the user requests from this LCS client or which service the LCS client offers to theuser
The standardized LBS services Types to be used in privacy checking are listed in the tablebelow.It should be noted that only the names and identities (number) of the Service Types arestandardized.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 206
Roadside AssistanceEnhanced Call RoutingRouting to NearestCommercial EnterpriseNavigationCity SightseeingLocalized Advertising
Location BasedInformation Services
Mobile Yellow PagesService ProviderSpecific Services
To maximize the adoption of location services, the service activation process must be simple.Three types of service package, may be distinguished, each of which may require a differentservice activation process:
� On Demand: the user accesses services only when required.� Period Subscription: the subscriber requires periodic availability of the service� Mixed: some services provided on subscription and the remainder on-demand.
In general an UE user should be able to access a location service anywhere within theoperator�s coverage area, or within the roaming area. Three levels of coverage may beconsidered:
� Home Network - Complete� Home Network - Partial� Roaming Networks
Considering network topography and dynamically varying environmental factors, a networkoperator may not be able to guarantee homogeneous service quality across the entire homenetwork geographic area, or roaming partners' networks.
With respect to roaming, specific local, national, and regional privacy regulations must becomplied with, and multiple layers of permissions may be required.
Relevant LBS description
Emergency services
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 207
Logica
In this category are included all the services related to the public safety. The relevantapplication is the location based emergency call (e.g.E112) whose relevant positionrequirements can be deduced by the US E911 already existent emergency call service. One ofthe relevant points in this kind of service is that they have to be available without requiring apre-subscription.
Location Based Charging allows a subscriber to be charged different rates depending on thesubscriber's location or geographic zone, or changes in location or zone. The rates chargedmay be applicable to the entire duration of the call, or to only a part of call's duration. Thisservice may be provided on an individual subscriber basis, or on a group basis (Locationsmay be defined for business groups to include corporate campuses, work zones or businesszones with different tiers of charging rates)Additionally, different rates may be applied in different zones based on the time of day orweek.
Fleet and Asset Management services allow the tracking of location and status of specificservice group users. Activation of Fleet and Asset Management services could be performedvia subscriber provisioning by the service provider, as well as by offering subscriber-basedservice activation codes to the service group user/subscriber
Traffic MonitoringMobiles in automobiles on freeways can be anonymously sampled to determine averagevelocity of vehicles. Congestion could be detected and reported.Congestion, average flow rates, vehicle occupancy and related traffic information can begathered from a variety of sources including roadside telematic sensors, roadside assistanceorganizations and ad-hoc reports from individual drivers. In addition average link speeds canbe computed through anonymous random sampling of UE locations
Location-Based Information services allow subscribers to access information filtered andtailored based on the location of the requesting user. Service requests may be initiated ondemand by subscribers, or automatically when triggering conditions are met, and may be asingular request or result in periodic responses.
Navigation: The purpose of the navigation application is to guide the handset user to his/herdestination. The destination can be input to the terminal, which gives guidance how to reachthe destination. The guidance information can be e.g. plain text, symbols with textinformation (e.g. turn and distance) or symbols on the map display. The instructions may alsobe given verbally to the users by using a voice call.
Location Dependent Content Broadcast: The main characteristic of this service category isthat the network automatically broadcasts information to terminals in a certain geographicalarea. The information may be broadcast to all terminals in a given area, or only to members ofspecific group.
Mobile Yellow Pages services provide the user with the location of the nearest service point,e.g. Italian restaurant. The result of the query may be a list of service points fulfilling thecriteria (e.g. Italian restaurants within three kilometers). The information can be provided tothe users in text format (e.g. name of the restaurant, address and telephone number) or ingraphical format (map showing the location of the user and the restaurants).
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 208
Logica
Network Enhancing Services:
1. The location of the handset may be used for more intelligent handovers and moreefficient channel allocation techniques.
2. The network operator may be able to use location services to improve the Quality ofService of the network. The location system may be used to track dropped calls toidentify problematic areas. The system may also be used to identify poor qualityareas.
3. The network operator may be able to use location information to aid networkplanning. The operator may be able to locate calls in certain areas to estimate thedistribution of calls and user mobility for network planning purposes. Theseapplications may be used for hot spot detection and user behaviour modelling.
8.3 SECONDARY SYSTEMS ANALYSIS
Relevant interfaces for Secondary Systems will be investigated to a less detail: limitedanalysis and appropriate mapping to other studies.Limited analysis of the following system interfaces is presented:
• Bluetooth• WLAN• TETRA• DECT
The uses of secondary systems at application level have to be considered characterising theenvironment in which they have to be inserted. The basic applications of the systems will be:
• the transmission of application relevant information• the broadcast of augmentation data
Two basic environment have to be considered, when systems can be used probably inalternative way: Outdoor and Indoor. Clearly, in deep indoor environment, GALILEOAugmentation and Assistance data are not necessary (no usable signals), so that only theapplication related data are of relevance in this case, like user position related information.Some applications can be:
• Within building guidance (shortest path toward a room)• Emergency location (precise position of user in case of emergency situations)
This kind of services cannot be covered by a satellite positioning systems, so that indoorsystem shall cover the whole set of applications needs in the future.In outdoor, the classical parameters for the estimation of the suitability can be carried out,while for the Indoor systems (Bluetooth, WLAN, UWB) a different evaluation have to becarried out, considering that the constraints of density and availability is important in thatenvironment.
Indoor environment The most important aspect to be covered is related to the possibility to interface differentcommunication systems in order to have a complete coverage for navigation related services
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 209
Logica
purposes. The following picture shows an important parameter (available bits/square meters)that can help in the analysis of the systems
As can be seen the widest capacity will be offered by UWB systems (about 1Mbps/m2), whilea lower capacity (some Kbps) is offered by Bluetooth and WLAN.Considering that UWB is also the most performing positioning system in deep indoorenvironment, it seems that, if FCC interference and standardisation problems will be solved,UWB can be a promising candidate for deep indoor solutions.For light indoor environment, the use of Communication systems as Augmentation databroadcasting can assume a more important value. Within this framework, application relatedto navigation, both for real time (light indoor positioning) and pre-planning (Almanac datadownloading for a planned Network based Assisted navigation) can to be carried out.Within this framework, interfacing with Bluetooth, WLAN and UWB is useful for GALILEOAugmentation data acquisition. Otherwise, considering the fact that in this case at least a 1BTS is in visibility, data for real time positioning can be directly acquired in idle modethrough SMSCB GSM and UMTS service.
Outdoor EnvironmentTETRAIn this case, TETRA is covering urban areas and is able to broadcast data through call groupsand reserved service without acknowledge. Being currently the system particularly addressedtoward public authorities and military application, at least at the beginning only those actorswill use such augmentation data. Otherwise, an open broadcasting service could be foreseenin urban areas for GALILEO augmentation purposes.A broadcast message is a one way point-to-multipoint communication between a calling partyand several called parties.Broadcast messages can be originated either by a line connected terminal or a mobile. Therecipients of a broadcast message are called a broadcast group. The broadcast group canconsist of both mobiles (i.e. radio connected terminals) and line connected terminals. Thebroadcast message service will use a maximum of one traffic channel on each site.TETRA can be used by professionals and military for on-demand requests of augmentationdata.Regarding pure data communication features, TETRA is dedicated for the moment toprofessional and military application. So it is foreseeable that it will be used as primaryapplication mean only for that kind of applications.
DECT
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 210
Logica
DECT system provides 32Kbps bearer capacity that can be used in Urban Areas for .thebroadcasting of augmentation data. A DECT base station is continuously transmitting on atleast one channel, thus providing a beacon function for DECT portables to lock on to. Thetransmission can be part of an active communication link with a portable or a dummy bearertransmission. Portables locked on to a beacon transmission will analyze the broadcastinformation to find out if the portable has access rights to the system (only portables withaccess rights are allowed to setup a communication link), determine whether systemcapabilities match with the services required by the portable and, if a communication isrequired, whether the base station has free capacity for a radio link with the portable. AlsoDECT can be used for on-demand Augmentation data download from equipped usersDECT is therefore a good candidate for Augmentation data broadcasting, where mobilenetworks are not achievable or are not providing such services in local areas, such as UrbanAreas. Regarding application data communication purposes, DECT is not strictlyrecommended but can be used as backup, when other systems are not available.
BLUETOOTHBluetooth is a short range (<10m) frequency hopping radio link that may be used to connectdevices with each other. The protocol stack may be made up of up to thirteen differentmodules but is essentially a core specification which defines the basic communicationsfunctionality and a set of supplementary specifications which provide enhanced support forspecific operations. These �supplementary specifications� have already been defined forapplications such as:
• Cordless telephony• Intercom• Headset• Dial up networking• Local Area Networking• Generic Object Exchange• File Transfer• Synchronisation• Serial communications
An abstraction of the Bluetooth protocol stack is shown in the following figure. The corelayers may be seen overlaid by the applications, such as those listed above. The SDP layer isthe service discovery profile. This layer allows Bluetooth devices to detect other Bluetoothelements in the vicinity and determine the services offered by them in order to establishcommunications. This is necessary in order to avoid the need for intervention from the user.It is also necessary since a headset device is likely to have very different requirements to thatof a LAN adapter.Bluetooth is also characterised by its low power requirements, which distinguishes it fromWi-Fi when considering the needs of small portable devices.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 211
Logica
Bluetooth is likely to have a number of implications for Galileo interoperability, dependingon the way it is used. Possible uses may include:
1. A source of ranging data for position enhancement in urban environments.2. A source of augmentation data, distributed via appropriate terrestrial interfaces.3. An interface between the Galileo terminal and other devices such as
GSM/UMTS terminals.Existing interfaces and protocols, such as RRLP discussed above, may be reused to determinea method of interoperability with Bluetooth. In other cases it may be necessary to consider thedefinition of new Bluetooth profiles.The use of protocols such as IP in the Bluetooth stack make it possible to translate services,such as the distribution of augmentation data, to other environments such as Wi-Fi, thuscreating a wider potential market.The definition of further Bluetooth profiles, for example to pass position information betweena Galileo terminal and a mobile phone, is recommended. Further analysis of this nature isidentified as an important differentiating factor for Galileo.
8.4 SATELLITES AND S-UMTS
The basic inherent characteristics of communication satellite (global/regional coverage,independence from terrestrial infrastructures), determine the future direction of these systems.These future directions are:(1) Direct Broadcast Systems (DBS).(2) Mobile Satellite Systems (MSS).(3) Fixed Services Systems (FSS).DBS can be useful for augmentation data for transport applications in a commercialenvironment. MSS are at the beginning of the venture (e.g. IRIDIUM and GLOBALSTAR),but are expected to grow if handheld systems will be available and thanks to the introductionof the future S-UMTS system. The application of S-UMTS could help to solve coverageproblems in remote areas and could be the preferred solution for dangerous goodstransportation (e.g. inland waterways, maritime) and emergency services, as bearer of alarmsand position information through the low rate service.Fixed Services Systems (currently based on systems like VSAT) can be substituted by newKu and Ka band multimedia system systems. A particular application for that could be related
Figure 8-21;. The Bluetooth Protocol Stack.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 212
Logica
to the implementation of the communication networks GALILEO-Mobile Operators andService Providers commercial data exchange (examples are �Spaceways� by Hughes and�VoiceSpan� by AT&T, which are Ka-band geosynchronous systems).The UMTS approach is in favour of a full integration between satellite and terrestrialnetworks (S-UMTS, based on a MEO constellation). This is in view of the great potential andsystem requirements of personal mobility, which can only be implemented by a smart mix ofwireless and wireline technologies, as pointed out in the previous above.In the consumer market, access to the S-UMTS network will be seen as an optional featureextending the capabilities of the mobile phone and it will be difficult to convince people thatthey need to carry a secondary terminal for this. Therefore, UMTS terminals supporting thesatellite component will only be a commercial success when the terrestrial component is alsoavailable with the same phone.Although current standardization efforts are focussed towards a highly integration of bothcomponents, different terminal functionality is unavoidable due the specific nature of thesatellite environment e.g. large propagation delays, low S/N ratios etc. Also from the point ofview of terminal integration, the needed flexibility to support both satellite and terrestrialcomponents of UMTS should be analysed.Future S-UMTS services are represented in the following table:
S-UMTS potential service requirements based
Servicemedia
Type Applications B.E.R. Max End-to-EndDelay[ms]
User Data Rate [Kbps] Terminal Type
Speech Real Time Telephony
10-3 400 Up to 8 Hand-held,Portable,Transportable,Vehicular
Data Non Real Time 10-5 to 10-6 500 Up to 64 on Forward Link,Up to 16 on Return Link Hand-heldInternet Access,
News Distribution,Electronic mail withattachments,Facsimile, Broadcastapplications (*), tele-banking, e-commerce
(*):Broadcast Applications including Data and Video Services (Sport, News, etc.) are specified with data rates up to 400Kbps.
Text services, comparable to the SMS, can be used in the future as data bearer of applicationdata. Currently some EC Projects, like GAUSS, are studying the application of S-UMTS fornavigation related services. It is recommended that links are established with the GAUSSproject.Data services can be used for broadcasting of data needed for application purposes, asassistance data (e.g. ephemeris and clock) in one shot as a complement to SMSCB services,for group of users (e.g. Fleet Management Operators).
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 213
Logica
8.5 COMPARISON OF BENEFITS AMONG DIFFERENTSYSTEMS (RANKING ANALYSIS)
Ranking between different systems is reported in the following tables.Communication Systems Coverage in different environments and GALILEO Augmentationhas been characterised by three levels:· �*�: Low Availability· �**�: Medium Availability· �***�: High Availability
Systems Features Communication Service Coverage
Ran
ge
Peak
Dat
a R
ate
Pric
e
GA
LIL
EO
Aug
men
tatio
n/A
ssist
anc
e
Dee
p In
door
Tun
nel
Lig
ht In
door
Urb
an C
anyo
n
Out
door
Bluetooth 10-100m 1 Mbps 5� (future); 9�(current) 200�
(card)
*** (indoor) *** *** * -
WLAN 10-100m 1-11Mbps(IEEE
892.11b)
100�(PCMCIA)
*** (indoor) *** *** * -
UWB 10m <1Gbps - * (indoor) ** ** - -
DECT 300m 1.152 Mbps >50� **(urban, lowmobility)
- ** *** -
GSM/UMTS Km 9.6 Kbps/2Mbps
100�/300� *** (outdoor,Urban, light
indoor)
- ** *** **
Table 8-10; Communication Systems Benefits Comparison Table
The main results are that:• TETRA and DECT can be used as a backup for Augmentation and Assistance data
bearer for outdoor and indoor environment• Bluetooth can be used as Augmentation bearer in indoor situation (assistance data for
pre-planning purposes in Network assisted application)• TETRA and DECT can be used as a backup for Communication purposes
(professional application and emergency) in outdoor environment• Bluetooh is the preferred way for application related data communication purposes in
indoor environment and as standard common platform for a multi-systemenvironment
• S-UMTS and satellite system can be used both as Augmentation data broadcasting(ephemeris and clock) and as Communication data link for application purposes inoutdoor environment. In particular, future S-UMTS services (both Short messagingsystems and Data services for Internet and high rate connections) is a good candidatefor Fleet Management operations
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 214
Logica
In the following Table, comparisons of benefits introduced by hybridisation betweenGALILEO and Primary and Secondary systems are reported. The Column �Hybridis. Mode�reports the kind of hybridisation that is recommended for each environment. The options are:
• Stand-Alone: GALILEO performs positioning by itself and be hybridised with othersystems at position solution level (3B)
• Dual Mode (Dual M): GALILEO can perform position solution in a hybridised mode,both using ranging measurements coming from other systems (3A) or hybridising atposition solution level (3B). The hybridisation modes can be of two different types, asdescribed in par. 7.2.3:
o Alternative (Alt), when GALILEO is completely not available, or theindependent position solutions that an external system can provide (e.g.UWB or Bluetooth in deep indoor environment) leads to a completeswitching to a secondary system
o Hybrid, when the hybridisation of two systems (both at measurement orposition solution level) can improve the overall performances of GALILEOsolution
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 215
Logica
A-GNSS
Hybridised GSM/UMTS +Assisted GNSS
Bluetooth/WLAN UWB
Ava
ilabi
lity
Acc
urac
y
Hyb
ridi
s. M
ode
Ava
ilabi
lity
Acc
urac
y
Hyb
ridi
s. M
ode
Ava
ilabi
lity
Acc
urac
y
Hyb
ridi
s. M
ode
Ava
ilabi
lity
Acc
urac
y
Hyb
ridi
s. M
ode
Deep IndoorTunnel
N/A - - N/A - - *** 10m Dual M(3B): Alt
*** 10-30cm Dual M(3B): Alt
Light Indoor * 50 m - ** 50m Dual M(3A/3B):Hybrid
** 10m Dual M(3B): Altor Hybrid
** 10-30cm Dual M(3B): Altor Hybrid
Urban Canyon ** <50 m - *** <50m Dual M(3A/3B):Hybrid
GALILEO hybridisation withSRS for Indoor. (e.g. Insidea shopping moll) GALILEOhybridisation with MobileCommunication Systems foropen environment (Urban,Rural)
GALILEO hybridisationwith SRS for Indoorassistance datacommunication. (e.g. Insidea shopping moll, Inside acar) GALILEOhybridisation with MobileCommunication Systemsfor open environment(Urban, Rural)
GALILEO hybridisationwith SRS for IndoorNavigation and LBS. (e.g.Inside a shopping moll,Inside a car) GALILEOhybridisation with MobileCommunication Systemsfor open environment(Urban, Rural)
GALILEO hybridisationwith SRS for localIndoor multimediaapplications. (e.g. Insidea shopping moll, Inside acar) GALILEOhybridisation withGPRS/UMTS for openenvironment(Urban,Rural)
Bluetooth chip has lowercost compared to the otherSRS ones. GALILEO UT isexpected to integrate aBluetooth chip forLocal/indoor positioningand short rangecommunication. GALILEOUT is expected to integrateGPRS/UMTSfunctionalities only if highdata rate multimediaapplications have to beimplemented
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 217
Logica
The basic conclusion of the analysis is:1. An integrated GSM or UMTS phone with GALILEO inside implementing hybridisation
(both at ranging at positioning level) for Urban areas and light indoor environment plusBluetooth or WLAN interface used in alternative way in deep indoor (where Bluetoothand WLAN infrastructures are present) environment is the preferred way of hybridisationfor mass market and in-car applications. Augmentation and Application are wellsupported by that systems integration. This result is obtained both in terms ofperformances and cost of the terminal.
2. S-UMTS systems can be used for augmentation data and multimedia application for ruraland remote areas in case of professional applications
3. TETRA integration can be performed for public interest applications (e.g. police and fire)already using such kind of transmission mean
8.6 MIGRATION CONSIDERATION
Future interoperability scenarios evolution and recommendations are reported in thefollowing time schedule graph.
2004 20082002GALILEO inclusion into ETSI standards
UMTS
Bluetooth
GSM
WLAN, UWB
GALILEO
2005 FCC E-911
mandate
TETRA, DECT(?)
Figure 8-22 – Migration Plan
GALILEO interoperability migration plan shall be inserted within the general environment ofthe Market trends.In the future, mobility will be the driver: PDA, mobile multimedia platform, UMTS, MobileIP techniques will be the drivers for the Market.GALILEO will have to be inserted in that situation in which a mobile platform will be wellestablished and probably also mobile operators will have developed their own positioningsystems based on time differences, integrated with GPS, in order to met E-911 mandate by2005.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 218
Logica
GSM will probably continue to be maintained also after the UMTS introduction as acomplementary system at least for voice and data broadcasting services. UMTS market entryis foreseen for 2004, but at the beginning only dense urban areas will be covered and thesystem will take about 1-2 years to enter in a nominal phase.Bluetooth will probably be the standard interface for mobile phones and external devices andwill provide the possibility to embed a system into another in a wireless way. Car applicationwill be probably highly impacted by this technology, allowing a hand-free integration ofdifferent sensors within the vehicle.UWB and WLAN will enter the Market and could be used as a positioning mean in deepindoor situation.TETRA will be probably relevant for emergency and military applications, while the future ofDECT is very uncertain in some European countries.The risk of GALILEO is to enter a market completely saturated by GPS and Mobileoperators. The best chance of GALILEO is to currently establish by now links with mobileoperators and to participate actively into ETSI Forum in order to be inserted into LCSstandards before the IOV phase. After that, the market can be stimulated through pilotprojects and so the field will be prepared for the GALILEO FOC. During this period, alsopartnership and Joint Venture with mobile operators will be useful, in order to establish thefuture link for the development of the common platform for LCS Services development.
8.7 LEGAL ISSUES AT INTEROPERABILITY LEVEL 4/5
The main aspects relevant for legal purposes when interoperability at application level isconsidered between GALILEO and Non Navigation systems, are hereinafter reportedconsidering the different interoperability scenario:
1. Interoperability between GALILEO and Wireless Networks (GSM, UMTS), where thewireless networks communication services are exploited to transfer navigation relateddata for the provision of Location Based value added services.
2. Interoperability between GALILEO and Wireless Network (GSM, UMTS), where thewireless networks communication services are exploited to transfer GALILEOAssistance and Augmentation to the GALILEO user terminals.
Relevant Interoperability issue concerning Legal aspects mainly focus on:
� Data security aspects� Privacy aspects� Liability chain
Data Security aspectsSpecific local, national, and regional security regulations must be complied with. Positioninformation should be safeguarded against unapproved disclosure or usage. Positioninformation should also be provided in a secure and reliable manner that ensures theinformation is neither lost nor corrupted. Records shall be maintained of positioning requestsand responses to facilitate resolution of security violations.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 219
Logica
The interoperability scenario investigated, considers that an External Galileo Entity (e.g.GALILEO Service Centre, GALILEO Local Component) should be able to interact withNetwork elements of the GSM and UMTS architectures in order to forward them Assistanceand Augmentation data computed from local, regional or worldwide gathered measurements.In the Interoperability scenario, at least, the GALILEO External Entity could be requested tocompute itself the position and pass it to the Wireless Networks in that cases they are notdesigned and developed to support positioning calculation functions. In this scenario,assistance data and positions data can be shared by different Systems� entities and securityaspects have to be guaranteed not only in the data transferring and storing process of eachsingle system, but also in the data transmission from one system to another. The protocol tobe used in the interface between the Wireless Network and the GALILEO External Entityneed to include a security plan in order to guarantee the data transmission in the forward andreturn communication links.
LCS services are currently defined in ETSI and the core of the systems is based on the SMLCentity. An LCS server has to be able to guarantee to pass assistance and augmentation datareceived by GALILEO Service Centre only to �authorised� customers. Currently, cipheringcan be used in order to encrypt such augmentation data.Galileo Service Centre has to be able to perform audits in order to guarantee the level ofsecurity of the transferred data (e.g. reading only particular field of the position records) heldby the LCS server).In order to be protected from unauthorised access to GALILEO system data that GALILEOService Centre has to sell, an authentication process has to be defined between ServiceProviders, Mobile Operators and GALILEO. Only authorised clients can have access toGALILEO data.From the LCS service provider�s point of view, only authorized LCS Clients shall be able toaccess the LCS Server. Before providing the location of a Target UE to any authorized LCSClient, the LCS Server shall verify both the identity and authorization privileges of the LCSClient.For Emergency Services and for liability purposes, transmitted augmentation and assistancedata have to be recorded for a period of time (e.g. 1 day) both from Mobile Operator andGALILEO Service Centre, in order to be able to demonstrate the correctness of thebroadcasted data.The augmentation information shall be provided to the Emergency Services Network andLocation Based Network in a secure and reliable manner, so that the location information isnot lost, corrupted, or made available to any unauthorized third party.Regarding the Communication, quite all the systems provide encryption algorithms (e.g. WEPsystem for WLAN). It is therefore recommended to preserve the security level from GalileoService Centre to the Mobile Operator and Service Provider in order to guarantee a completesecurity chain.
Privacy aspectsSpecific local, national, and regional privacy regulations must be complied with, and multiplelayers of permissions may be required for the delivery of Galileo Service Centre�s data.Main legal issues are in this case related to the final service Provider that sells and operatesposition related data and to the Mobile Network operator, that provides the communicationlink on which client position data are transmitted. In general, a service provider has toguarantee the following capability related to privacy:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 220
Logica
• Location information must always be available to the network service provider.• Means shall be provided for the subscriber to control privacy for value added
services.• The user shall be able to change the setting of the privacy exception list at any time.
Unless required by local regulatory requirements, or overridden by the user, the user may bepositioned only if allowed in the UE subscription profile.GALILEO Service Centre will be at the top of the Value Chain. It will act as a LocationContent Provider for the mobile operator or the service provider. So these are the customersthat GALILEO Service Centre has to protect in terms of Privacy. Mainly commercial relevantdata (as developed services and requirements for augmented and assisted navigation services)have to be compliant to the same privacy constraints and have to be agreed in the contractualframework.Additionally, specific privacy exceptions may exist for compliance with mandated locationbased services (such as for emergency services or lawful intercept), which are required bynational or local regulatory requirements.GALILEO Service Centre shall be able to stop the provision of service in non-nominalsituations (e.g. war, crisis).For Emergency Services (that shall be clearly marked, e.g. through and ID at the beginning ofthe download session) the Service Provider or Mobile Operator shall be able to access toGALILEO Assistance and Augmentation data regardless of the privacy authenticationprocedure.
Liability chainAs far as the Liability chain is concerned, legal impacts coming from the interoperabilitybetween GALILEO and Wireless Networks (considered as bearer of assistance data) mainlyfocus on the clear identification of the responsibilities in the Assisted GALILEO andDifferential GALILEO positioning services.In the considered interoperability-scenario:
� The External GALILEO entity is in charge to compute assistance data and at least toperform the position calculation function in that case Wireless Network does not havePCF functionality.
� The Wireless Operator is in charge of implementing standard Location based service(at least also the PCF is performed in the network SMLC) and to deliver assistancedata, by means of standard point-to-point or broadcast services, with the neededperformances mainly in terms of delivery delay and information integrity.
The relevant legal impact mainly concerns therefore with the precise definition of theresponsibilities boundary between the Actor that is in charge to compute and provide theassistance data (GALILEO External Entity) and the Actor that is in charge to use theassistance data in order to implement standardised LCS (Wireless Operator).
COSPAS-SARSAT legal issuesLegal and commercial impacts on interoperability of Galileo with COSPAS SARSAT mustbe clarified between the future Galileo Operating Organisation and a number of countries andorganisations participating in the operation of the COSPAS SARSAT system. The countriesparticipating to the COSPAS SARSAT International Programme Agreement are Canada,France, Russia and the USA. In addition to that 20 ground segment providers, 9 user statesand 2 participating organisations are involved in COSPAS SARSAT operations. For futureinteroperability operations also organisations, which stated their interest in the COSPAS
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 221
Logica
SARSAT Programme e.g. IMO, ICAO, ITU, ICS (International Chamber of Shipping), theInternational Radio Maritime Committee (CIRM), and the International Federation of AirLine Pilots Associations (IFALPA), will have to be taken into account.COSPAS SARSAT was initially developed under a Memorandum of Understanding amongAgencies of the former USSR, USA, Canada and France, signed in 1979. Following thesuccessful completion of the demonstration and evaluation phase started in September 1982, asecond Memorandum of Understanding was signed on 5 October 1984 by the Centre Nationald'Etudes Spatiales (CNES) of France, the Department of National Defence (DND) of Canada,the Ministry of Merchant Marine (MORFLOT) of the former USSR and the National Oceanicand Atmospheric Administration (NOAA) of the USA. On 1 July 1988, the four Statesproviding the space segment signed the International COSPAS SARSAT ProgrammeAgreement that ensures the continuity of the System and its availability to all States on a non-discriminatory basis. In November 1988 the Conference of Contracting Governments to theInternational Convention for the Safety of Life at Sea (SOLAS) on the Global MaritimeDistress and Safety System (GMDSS) adopted several amendments to the 1974 SOLASConvention whereby, inter-alia, carriage of satellite EPIRBs on all convention ships of 300tons and over became mandatory from 1 August 1993. Various national requirements alsoexist for the carriage of ELTs/EPIRBs on different types of craft not otherwise subject tointernational conventions, and some countries have authorised the use of Personal LocatorBeacons (PLBs), 406 MHz emergency beacons for use on land, in remote or rugged areas. InJanuary 1992, the Government of Russia assumed responsibility for the obligations of theformer Soviet Union. A number of States, Non-Parties to the Agreement, have also associatedthemselves with the Programme. The mentioned MoUs, the International COSPAS SARSATProgramme Agreement, the various associations, and the SOLAS Convention are the basis fora legal and commercial framework for future interoperability regulation between Galileo andCOSPAS SARSAT.
8.8 MRD & SRD RECOMMENDATIONS AT INTEROPERABILITYLEVEL 4/5
8.8.1 MRD
• GALILEO user terminal shall be able to be interfaced with wireless communicationsystems for the implementation of the following basic services:
o Value Added services, based on position, in which the wireless communicationcapability acts as bearer of user position information and transmission of locationrelated data
o GALILEO Augmentation services, based on the broadcasting or on-demandtransmission of GALILEO and GPS differential corrections
o GALILEO Assisted navigation services, based on the broadcasting or on-demandassistance data delivery (GALILEO ephemeris, clock corrections, etc..). Twooptions shall be considered:
� Network Based: in this case the wireless communication network acts asbearer of reduced assistance data and raw measurements from theterminal and the position is calculated within the Network
� Handset Based: in this case the wireless communication network acts asbearer of assistance data and position is calculated within the handset
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 222
Logica
The Location Based Services applications are currently standardised at ETSI level.Therefore, new requirement should be added:
MR 2232a: GALILEO compliance to wireless standardsGALILEO services shall be compliant with ETSI standards concerning theimplementation of Location Based Services (LCS standard)
MR-2232b: GALILEO involvement into future Wireless communicationStandardisationGALILEO shall participate to the definition of the future standardisation for wirelesscommunication network services (i.e. ETSI)
• GALILEO Local Components shall be interfaced to the Wireless communicationNetwork for the provisioning of augmentation and assistance data necessary for theimplementation of standardised navigation and positioning services able to penetrate awide range of applications. Future Services will be based on the double constellation(GALILEO+GPS). At this aim Local components shall be able to provide augmentationdata for both the systems. New requirements:MR-2232c: GALILEO Local Components interface with Wireless CommunicationNetworkGALILEO Local component shall be interfaced with wireless communication networkelements for Augmentation and Assisted Data distribution through dedicated standardinterfacesMRD-2232d: Combination of GALILEO Local Components with GPSGALILEO shall be able to provide Augmentation and Assisted data for both GALILEOand GPS data
• Integration with Bluetooth:Bluetooth is commonly considered as the future platform for the interoperation ofnavigation, communication and other external sensors. Specifically, they are consideredone of the most promising platforms for automotive sensors integration. Bluetooth shortrange communication capability shall be integrated in the GALILEO terminal in order toallow the exchange of position related between different modules of an embeddedplatform.MRD-2232e: GALILEO Bluetooth interfaceGALILEO terminal shall be complaint to Bluetooth standards for position informationdistribution in an embedded platform
8.8.2 SRDPar 5.2.10 Locally assisted Navigation servicesIn this Paragraph only a �Normal� Locally Assisted navigation service is defined. Assistednavigation has to cover �Non-Nominal� environment, like Urban Canyons, in which the lowSNR (e.g. 10 dB lower than nominal signal power), the multipath and the shadowing do notallow to demodulate navigation data. So in this case a �normal� service has no meaning.Furthermore, in indoor environment, the signal power can decrease by 30 dB.In the present interoperability Analysis we further declare the two modality of assistanceservices (Network based and Handset Based) reported the navigation messages to bebroadcast for both of the modalities. The same distinction should be noted in the SRD.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 223
Logica
Furthermore, for availability reasons, GPS navigation data should be contemporary provided.It is recommended to distinguish the two levels of Locally Assisted Navigation Service and tobetter detail Assistance data to be provided:For commercial purposes, GOC shall foresee the interfacing vs. Network operators in order toprovide the navigation data necessary for the Assisted Navigation.
GALILEO Service Centre Interface with Mobile NetworksGALILEO Service Centre shall be able to be interfaced to the Wireless Network operatorsCentre (i.e. SMLC) in order to provide the following Services:
• Handset Assisted Navigation Services:GALILEO Service Centre shall provide at least satellite ephemeris and clockcorrections (all the Navigation message in the best case) or all of the satellites thatmight be visible
• Network Based Navigation Services:GALILEO Service Centre shall provide at least the list of visible satellites (the wholeAlmanac in the best case) and the Doppler Corrections to the User Receiver in orderto allow the receiver to calculate only pseudorange and send them back to the ServiceCentre in charge to calculate the related position
Par. 5.2.11 Local Augmented Availability Navigation ServiceIn critical environments the use of Assisted Navigation Services leads to an availabilityimprovement. Following the previous recommendations, it is recommended to add the accessto Assisted navigation to the requirement reported in par. 5.2.11.
Par. 6.1.2. Ground Segment FunctionsAdd a bullet regarding the interface between GALILEO GS and Mobile Networks SMLC
Par. 7.7.4.3 Galileo Locally-Assisted Test ReceiversChange �Mobile telephone systems� in �Mobile Communication systems� (e.g. alsoBluetooth may be considered as bearer)
Par. 14.1.2.2: Navigation DataFollowing the previous recommendations, it is recommended to provide NavigationAssistance data through Wireless Communication systems at least at a rate of 1 message (persatellite) every 30 s using SMSCB (or equivalent) services
Par. 14.1.2.3: Snapshot Satellite SignalsThis is the solution named « Network based ». It is recommended to change the name, to addexplicitly the reference to the Par. 5.2.10 I (in order to show the link with GALILEO ServiceCentre) and to add a list of Communication systems to be used. Wireless communication hasto added explicitly
Par. 14.2.2. Local Component -Ground SegmentAdd a requirement regarding the interface between GALILEO GS and Mobile NetworksSMLC
Par. 14.2.6 Protocol for Assisted Navigation interface between Local Component andUserLocal Component shall communicate with the user terminal in an LCS ETSI standard whenoperating through wireless Communication systems
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 224
Logica
8.9 ISSUES FOR OTHER GALILEI TASKS AND OTHER STUDIES(TASKS A TO I, GALILEO B2 ICD, PILOT PROJECT)
8.9.1 ICDS
8.9.1.1 Impacts on Galileo to UMTS ICD ID/GAL/0085/GLI
General commentsThe declared ICD describes the possibility to use UMTS for assistance data broadcasting butdo not specify the data format and the channel for the development of such service.Furthermore, in the future UMTS shall broadcast both GALILEO and GPS assistancemessages. Furthermore, the length of an Assistance message is declared to be 50 bytes. Thisis due to the fact that Network Assisted solution is used in UMTS ICD. In SIA, Handset-based techniques are also examined. This solution transfers the algorithmic load for thecalculation of the position from the Network to the user terminal. Furthermore, differentialcorrections (Augmentation messages intended as pseudorange corrections) are not detailed.SIA analysis starts from ETSI recommendations on Augmentation and Network Assistedanalysis. This is due to fact GSM and UMTS will be in the future the drivers for LCS servicesdevelopment. It is foreseeable that UMTS (GSM) terminals with GALILEO embedded willbe the bases for LCS services. At this aim the compliance with ETSI standards should be abasic driver for hybridisation, considering that GALILEO will enter a well-established marketin 2008.
The following recommendations are given from the SIA Analysis:
Data exchange protocols and formats1. It is recommended to use SMSCB channel for UMTS Assisted Navigation and
differential data broadcasting2. It is recommended to study Handset Based Assisted Navigation solution3. It is recommended to detail the data formats for both Network Assisted and
Differential Corrections provisioning. The results of the dd081 are:� SMSCB service (available both for GSM and UMTS), based on 82
bytes messages, is recommended to be used as broadcasting mean for Assistednavigation and Differential data
� It is recommended to transmit both GALILEO + GPS ephemeris anddifferential corrections for availability improvement reasons using ETSIstandards described in par. 8.2.5 of the present document:
� Ephemeris and clock corrections message: using standards, 638 bits(82 bytes) per satellite (e.g. total 18 minutes of broadcasting for 12satellites in view sending an SMSCB message every 90 s)
� Differential Corrections: Differential corrections standard ETSImessages (for one frequency) are about 48 bits per satellite, so that, addingpreambles, one SMS-CB message every 30 s can be sufficient to broadcastdifferential corrections. It is recommended to study compressionalgorithms for DGALILEO data broadcasting
4. It is recommended to transmit ephemeris and clock corrections for both the satellitesevery 90 s, while pseudorange differential corrections (RTCM #1 like) every 30 s(maximum age acceptable after SA switch off and due the absence of SA onGALILEO SIS)
5. It is recommended to implement the RLLP protocol as a standard interface for:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 225
Logica
o the exchange of Assistance and Augmentation data between SMLC and UserTerminal
o the exchange of Assistance data and Augmentation data between GALILEOGround Segment of Local Elements (e.g. through the GSC) and the GSMSMLC (in order to favourite in this way to the possibility to perform a directtunnelling between GALILEO GSC and the user). See Par. 8.2.5.3 for details.
6. It is recommended to apply UMTS compression algorithm (e.g. the CBS compressionalgorithm reported by ETSI) or develop other studies for data format compression
GALILEO Local Elements-UMTS interfacesThe interfacing elements between UMTS and GALILEO have been identified and should beput within the B2 ICD.The elements identified for interfacing are the following:
• The SAS (Stand Alone A-GPS SMLC) provides GPS assistance data to the SRNC tobe delivered through point-to-point or broadcast channels to the UE, and acts as alocation calculation server if the location estimates are not calculated in the RNC
• The SAS communicates with the SRNC over the Iupc interface. By means of thisinterface the SAS is able to forward assistance data to the User terminal and toreceive User Terminal positioning measurements data from the SRNC
• The SNRC, receiving requests from LCS applications or LCS Client functions in theCN (Core Network) across the Iu interface. SRNC is equivalent to SMLC.
• It is recommended for GALILEO Local Element or Ground Segment (acting as aSAS element) to implement the interface with the UMTS SRNC through the lupcinterface,
See par. 8.2.5.5 for details.In the future the applications will be based on multimedia Services. In particular, UMTS willbe able to provide such services through IMS (IP Multimedia Subsystem).It is recommended to include in the UMTS ICD the following considerations:
• It is recommended to implement an IMS interface within the hybridizedUMTS/GALILEO terminal in order to be able to receive multimedia services(including Location Based Services) provided by typical Internet multimedia serviceprovider, Mobile Operator, Service Provider for GALILEO related services.
• At GALILEO system level, GALILEO Local Elements shall be interfaced to the S-CSCF of the IP Multimedia subsystem through the UMTS standard ISC interface andthe defined SIP protocol (Session Initiation Protocol)
Within this framework, IMS could be also used for broadcasting of differential correctiondata in complement to SMSCB service, for instance for more demanding GALILEOapplications (TCAR, VRS, etc.).Regarding the Interoperability at application level, the following recommendations are givenfor UMTS:
• It would be appropriate for any Galileo services or applications to conform to theOSA model. By doing so, the numerous operations relating to authentication,authorisation and privacy are easily addressed following the related standard
• It is recommended to consider the WAP as one option for the applicationsdevelopment. The WAP communications stack provides a method of transportingapplications and data across the link. Application environments such as J2ME and
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 226
Logica
BREW provide the framework in which the applications may run in order to deliverthe relevant Galileo features (see par. 8.2.1 for details)
8.9.1.2 Recommendations for a GSM ICDThe basic interfaces between GALILEO system and GSM networks for Service Provisioningare not defined in any B2 ICD. A dedicated ICD on GSM interfaces should be produced byB2. The present analysis recommended that:
• An Interface between GALILEO Ground Segment and GSM Network elementsdevoted to LCS services should be designed and implemented for the provision ofephemeris and clock corrections for Assisted Navigation Services
• GALILEO status information (e.g. maintenance bulletins) should be provided byGSC to GSM Network for Broadcasting
The present study recommends to use the SMLC (Serving Mobile Location Centre) GSMNetwork Element as interfacing element with GALILEO Ground Segment or Local Elements(eventually through GSC) and to detail the relevant communication protocols.
As reported above, it is recommended to use the RLLP protocol for the interfacing betweenSMLC and GALILEO Ground Segment and Local elements for the provision of Assistanceand Augmentation data.
The present Analysis also showed how synchronisation of GSM Network trough a uniquetime reference can reduce the E-OTD infrastructures implementation costs. A fine NetworkSynchronisation can, in fact, avoid the development of LMU for RTD measurementsbroadcasting. It is recommended to give indications during the design phase about thesynchronisation of GSM Network using GALILEO receivers installed in each BTS or higherlevel elements (e.g. BSC).
At the moment an ICD on impacts on GSM has not been developed in B2 phase. Due to thefact that UMTS Operational phase could be delayed by some years and GSM could be alreadythe primary mobile system in 2008, it is recommended to the B2 phase to produce aGALILEO-GSM ICD and to identify the Interfaces to SMLC analysed above.
8.9.1.3 Impacts on Service Centres ICD (EXTICD-Part e)
In the ICD it is not foreseen an interface toward the Mobile Operators for ServiceProvisioning. As stated before, SMLC for GSM and SRNC for UMTS will be the referenceelement of interface between GALILEO and Mobile Operators.Basic Recommendations are the following:
1. An External Interface between GSC and SMLC or SRNC for LCS services should beprovided in the ICD, using the same interfaces defined before
2. If a Galileo Service Centre has to operate as a service provider, then the relevant interfaceis required to connect to OSA framework elements using the OSA API. Applicationsshould be implemented to support the API and thus benefiting from the features thatprovide billing functionality, authentication, and security
3. If the Galileo Service Centre has to operate as a content provider then a similarly openstandard is required. A standard such as XML could be used, given its increased use by
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 227
Logica
government organisations and industry. Application data would be packaged in a relevantXML definition and distributed to third parties for use in providing navigation relatedapplications
4. The content provider model implies the need for a billing solution. A flexible billingmodel, integrated with the XML method of distribution would be the most appropriate.Interfaces for off-line and on-line reconciliation should be available, i.e. hard copy billingrecords should be produced as well as CDR�s of an appropriate format
5. The Galileo Service Centre ICD should be extended to include a SIP interface for thedelivery of services directly to the user terminal. In addition to this the IETF should beengaged so that the SIP protocol may be extended to include navigation specificoperations such as those described in the previous section. Furthermore, IMS capabilityshould be interfaced by the GALILEO terminal, as described in previous paragraphs
6. The GALILEO Service Centre shall support an interface at application level directly to anSMSC for the provision of a service directly to the individual. The interface should be ofan open nature such as SMPP (Short Message Peer To Peer)
7. A mechanism for recording all information sent to an SMSC is required. This may beused to produce billing records and to reconcile all transactions when providing a service
8.9.2 TASK B, TASK G AND TASK C
• Study the extension of current Assisted-Navigation and Augmentation data broadcastingstandards to GALILEO
• Task B to coordinate activities between Tasks concerning Standardisation (Task G andTask B2) and tasks interested by their impacts (Task C and D). Analyse proposedinterfaces and insert them into GALILEO Local Elements Architecture documents andother relevant ICDs documents
8.9.3 TASK I
SAR applicationsThe following questions should be addressed by Task I (Legal Issues) of Galilei:
• in case of malfunction with consequences to a rescue operation:- has the user to prove that a system failure occurred?- has the system operator to prove that no system failure occurred?- which operator is liable for which part in case of interoperable systems?- who has to make a decision on the questions mentioned above?- on which technological guidelines should the investigations be based?
• related to the handling of confidential data:- what kind of data can be stored?- who has access to that data?- how long will the data be stored?- is the user informed that his location data are stored?- can the user be tracked without notice?- can the user deny tracking? can the user deny storage of the location data?
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 228
Logica
8.9.4 TASK H
Financial aspects:- what kinds of investments are necessary for interoperability between Galileo andCOSPAS SARSAT for the different participants (e.g. operators, users)?- how much investment is necessary?- who will pay for the investments (share between involved user communities,between involved states? (Galileo participants, COSPAS SARSAT participants, thirdstates)- which could the return (if any) e.g. license fee on equipment, per rescue operation,etc.?
8.10 IMPACTS ON OS (OPEN SERVICES) AND CS(COMMERCIAL SERVICES)
Application levels will drive in the future the use of GALILEO. Mobile operators willprobably play an important role in the development of Location Based Services, usingdeveloped standards (e.g. ETSI) and infrastructures (e.g. LCS infrastructures, as detailed inthe previous paragraphs). With this aim, the impact for Commercial Services developmentshould be dedicated to the interfacing between GALILEO Service Centre infrastructuresproviding CS and Mobile operators infrastructures.Galileo Service Centres shall be interfaced to mobile operators infrastructures for theprovision of CS services (Service Guarantee, Bulletins, Augmentation and Assistance dataetc.). GALILEO Service Centre shall comply with ETSI standard interfaces for the provisionof such services through the mobile operators acting as bearers. The main impacts are:
• GALILEO Service Centre should operate through RRLP protocol for theimplementation of Location Based Services (in particular in Assisted Navigationfunctioning)
• GALILEO Service Centre to be interfaced to GSM SMLC through a dedicatedprotocol for the provision of Augmentation/assistance Data
• GALILEO Service Centre acting as a SAS (Stand Alone A-GNSS SMLC) has to beto be interfaced to UMTS network element deputed to the processing of Assistancedata and LBS information broadcasting (SRNC) through lupc interface
• GALILEO user terminal shall be able to output data using standard protocols (RRLP)and emerging languages for application development (XML)
At application level, the future Market in which GALILEO operates will be dominated by theconvergence of services and systems in a unique mobility platform based on Internet. UMTSwill provide such potentiality for mobiles through IMS. GALILEO Local Elements could beinterfaced to the S-CSCF of the IP Multimedia subsystem through the UMTS standard ISCinterface and provide interfacing to UMTS network for general-purpose multimediaimplementations. Commercial services based on the 500 bit slot in the navigation messageshould be only used for general public interest information broadcasting, due to the very lowamount of available data. Service Providers intended to perform Location Based Servicesshall base their business on a 2 way system: UMTS (or GSM in the early stage of GALILEOdevelopment phase) will allow 2 way communication capabilities and standard interfaces forthat. In this way UMTS infrastructure can be the right complement to CommunicationCommercial Services.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 229
Logica
Integrated Billing structures between GALILEO Service Centres and Mobile Operatorsshould be envisaged, in particular considering Location Based Charging applications, inwhich location is the essential information for both mobile operators and GALILEO ServiceCentres functionalities.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 230
Logica
9 SUMMARY OF MRD & SRD UPDATERECOMMENDATIONS
9.1 MRD
• Update of MRD 1301 Navigation – Communication user equipmentIntegrated solution for satellite navigation (GPS) and Communication (GSM) existscurrently (e.g. Snaptrack solution), so that this requirement can be easily met. In orderto exploit the improvement in availability, GPS has to be added in this requirement. Itis recommended to add explicitly GPS as system to be integrated at user terminallevel.
• Proposed requirement: MR-1301a - Terminal Hybridisation at measurementslevelGALILEO navigation module shall be integrable at low cost in an enhanced mobileterminal able to process mixed measurements from mobile systems (e.g. E-OTD,TDOA) and satellite systems (GALILEO and GPS) for positioning purposes
• Proposed requirement: MR-1301b – Minimum Terminal Hybridisation levelFuture hybridised GSM/GALILEO-GPS terminals will be able at least to processseparately time differences from GSM BTSs and ranging differences betweensatellites for positioning purposes. If time synchronisation between GSM andGALILEO will be implemented, a tight full solution using also mixed BTSs-satelliteranging measurement shall be developed
• Augmentation Messages processingGALILEO navigation module will be integrated within a mobile phone for manyapplications (e.g. Personal emergency). At this aim GALILEO navigation moduleshall be able to process E-OTD Assistance data (e.g. RTD) in an ETSI standardformat. New requirement:
Proposed Requirement: MR-1301c: ETSI standard processingGALILEO navigation module shall include the option to process E-OTD Assistancedata in an ETSI standard format
• Recommended loose hybridised solutionsThe GALILEO terminal shall be able to hybridise GALILEO position and otherposition solutions generated by other systems. GALILEO navigation processor shallbe able to take in input different single position solutions, each considered with anassociated Quality report, and to hybridise them coherently. It has to be able to switchbetween different systems or to properly weight the solutions according to the Qualityreport. The use and development of the emerged new Kalman Filtering technologiesfor high dynamic solutions and non-linear systems, instead of the simple proposedHEKF, is recommended to be studied in the following Pilot Projects
Proposed Requirement: MRD-1301d: Positions hybridisationGALILEO navigation module shall be able to properly hybridise position solutionscoming from different sensors and systems. The final position solution shall be
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 231
Logica
derived using proper weighting algorithms for the single position solutions (at leastthe alternative mode, selecting the best quality solution and discarding the others)
• Integration with BluetoothBluetooth is recommended to be used as alternative positioning system for deepindoor environment. The recommendation is therefore for the GALILEO terminal tobe interoperable at position level with Bluetooh as alternative system for indoorenvironment.At this aim the requirement MRD-2232 has to be modified in the following way:
Updating: MRD-2232 Requirement Title: Interface with wirelesscommunications systemsGalileo system shall allow adequate interface to wireless communications systems(e.g. GSM,UMTS, Bluetooth) for combined services
• The Location Based Services applications are currently standardised at ETSI level(both for Augmentation and Assistance Services) Therefore, a new requirementshould be added:• New Requirement MR 2232a: GALILEO compliance to wireless standards
GALILEO services shall be compliant with ETSI standards concerning theimplementation of Location Based Services (LCS)
• New Requirement MR-2232b: GALILEO involvement into future Wirelesscommunication StandardisationGALILEO shall participate to the definition of the future standardisation forwireless communication network services (i.e. ETSI)
• GALILEO Local Components shall be interfaced to the Wireless communicationNetwork for the provisioning of augmentation and assistance data necessary for theimplementation of standardised navigation and positioning services able to penetratea wide range of applications. Future Services will be based on the doubleconstellation (GALILEO+GPS). At this aim Local components shall be able toprovide augmentation data for both the systems. New requirements:
o MR-2232c: GALILEO Local Components interface with WirelessCommunication NetworkGALILEO Local component shall be interfaced with wireless communicationnetwork elements for Augmentation and Assisted Data distribution throughdedicated standard interfaces*/a standard interface has been proposed within the document
o MRD-2232d: Combination of GALILEO Local Components with GPSGALILEO shall be able to provide Augmentation and Assisted data for bothGALILEO and GPS data
• GSM Network Time synchronisation for position hybridisation purposes:considerationFor a full tight hybridisation (integrating also BTS-SAT measurements), timesynchronisation between GSM frame and Satellite code pulses are fundamental. Atthis aim it is important to design the GALILEO signal and chip rate in order to beeasily usable within a tight/full terminal for the mixed ranging solutions. This isparticularly important for LMUs implementations, which should be equipped withGALILEO receivers. These recommendations will have an impact for the use of E-
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 232
Logica
OTD measurements and for the implementation of BTS-Sat mixed time differencesolutions.In case a full synchronisation between GALILEO time and GSM Network time willbe implemented (each BTS having the same synchronised time reference withGALILEO), the necessity to calculate RTD will decline. This NetworkSynchronisation solution has to be investigated with GSM Mobile Operators atrelevant Standard Forums, being a recommendation more related to Mobile operators,but having high impact on GALILEO Revenues and on LBS servicesexploitation, at least at early stage of GALILEO introduction (when UMTS willbe probably not be fully operative). Therefore, it is recommended to investigate Timesynchronisation with GSM issues within a dedicated ICD.
• Integration with Bluetooth:Bluetooth is commonly considered as the future platform for the interoperation ofnavigation, communication and other external sensors. Specifically, it is consideredone of the most promising platforms for automotive applications (as a standardinterface between different sensors and equipments presents within the vehicle).Bluetooth short range communication capability shall be integrated in the GALILEOterminal in order to allow the exchange of position related between different modulesof an embedded platform.New Requirement: MRD-2232e: GALILEO Bluetooth interfaceGALILEO terminal shall be complaint to Bluetooth standards for positioninformation distribution in an embedded platform
9.2 SRD
Par 5.2.10 Locally Assisted Navigation servicesIn this Paragraph only a �Normal� Locally Assisted navigation service is defined. Assistednavigation has to cover �Non-Nominal� environment, like Urban Canyons, in which the lowSNR (e.g. 10 dB lower than nominal signal power), the multipath and the shadowing do notallow to demodulate navigation data. So in this case a �normal� service has no meaning.Furthermore, in indoor environment, the signal power can decrease by 30 dB.Furthermore, for availability reasons, GPS navigation data should be simultaneouslyprovided.It is recommended to distinguish the two levels of Locally Assisted Navigation Service and tobetter detail Assistance data to be provided:For commercial purposes, GOC shall foresee the interfacing vs. Network operators in order toprovide the navigation data necessary for the Assisted Navigation. It is recommended to addthe following points:GALILEO Service Centre Interface with Mobile NetworksGALILEO Service Centre shall be able to be interfaced to the Wireless Network operatorsCentre (i.e. SMLC) in order to provide the following Services:
• Handset Assisted Navigation Services:GALILEO Service Centre shall provide at least satellite ephemeris and clockcorrections (all the Navigation message in the best case) for the visible satellite to theUser Receiver
• Network Based Navigation Services:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 233
Logica
GALILEO Service Centre shall provide at least the list of visible satellites (the wholeAlmanac in the best case) and the Doppler Corrections to the User Receiver in orderto allow the receiver to calculate only pseudorange and send them back to the ServiceCentre in charge to calculate the related position
Par. 5.2.11 Local Augmented Availability Navigation ServiceIn critical environments the use of Assisted Navigation Services leads to an availabilityimprovement. Following the previous recommendations, it is recommended to add the accessto Assisted navigation to the requirement reported in par. 5.2.11.
Par. 14.1.2.2: Navigation DataFollowing the previous recommendations, it is recommended to provide Navigation datathrough Wireless Communication systems at least at a rate of 1 message (per satellite) every90 s using SMSCB (or equivalent) services
Par. 14.2.6 Protocol for Assisted Navigation interface between Local Component andUserLocal Component shall communicate with the user terminal in an LCS ETSI standard whenoperating through wireless communication systems and protocols (e.g. GSM/RLLP)
Relevant Recommendations for B2 ICDs and impacts on OS and CS development arereported in the relevant sections of the present document.
9.3 ICDS
9.3.1 IMPACTS ON GALILEO TO UMTS ICD ID/GAL/0085/GLI
SIA analysis starts from ETSI recommendations on Augmentation and Network Assistedanalysis. This is due to fact GSM and UMTS will be in the future the drivers for LCS servicesdevelopment. It is foreseeable that UMTS (GSM) terminals with GALILEO embedded willbe the bases for LCS services. At this aim the compliance with ETSI standards should be abasic driver for hybridisation, considering that GALILEO will enter a well-established marketin 2008.
The following recommendations are given from the SIA Analysis:
Data exchange protocols and formats1. It is recommended to use SMSCB channel for UMTS Assisted Navigation and
differential data broadcasting2. It is recommended to study Handset Based Assisted Navigation solution3. It is recommended to detail the data formats for both Network Assisted and Differential
Corrections provisioning. The results of the dd081 are:a. SMSCB service (available both for GSM and UMTS), based on 82 bytes
messages, is recommended to be used as broadcasting mean for Assistednavigation and Differential data
b. It is recommended to transmit both GALILEO + GPS ephemeris and differentialcorrections for availability improvement reasons using ETSI standards describedin par. 8.2.5 of the present document
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 234
Logica
4. It is recommended to transmit ephemeris and clock corrections for both the satellitesevery 90 s, while pseudorange differential corrections (RTCM #1 like) every 30 s(maximum age acceptable after SA switch off and due the absence of SA on GALILEOSIS)
5. It is recommended to implement the RLLP protocol as a standard interface for:a. the exchange of Assistance and Augmentation data between SMLC and User
Terminalb. the exchange of Assistance data and Augmentation data between GALILEO
Ground Segment of Local Elements (e.g. through the GSC) and the GSM SMLC(in order to favourite in this way to the possibility to perform a direct tunnellingbetween GALILEO GSC and the user). See Par. 8.2.5.3 for details.
6. It is recommended to apply UMTS compression algorithm (e.g. the CBS compressionalgorithm reported by ETSI) or develop other studies for data format compression
GALILEO Local Elements -UMTS interfacesThe interfacing elements between UMTS and GALILEO have been identified and should beput within the B2 ICD.
• It is recommended for GALILEO Local Element or Ground Segment (acting as aSAS element) to implement the interface with the UMTS SRNC through the lupcinterface,
See par. 8.2.5.5 for details.
Application levelIt is recommended to include in the UMTS ICD the following considerations:
• It is recommended to implement an IMS interface within the hybridizedUMTS/GALILEO terminal in order to be able to receive multimedia services(including Location Based Services) provided by typical Internet multimedia serviceprovider, Mobile Operator, Service Provider for GALILEO related services.
• At GALILEO system level, GALILEO Local Elements shall be interfaced to the S-CSCF of the IP Multimedia subsystem through the UMTS standard ISC interface andthe defined SIP protocol (Session Initiation Protocol)
Within this framework, IMS could be also used for broadcasting of differential correctiondata in complement to SMSCB service, for instance for more demanding GALILEOapplications (TCAR, VRS, etc.).Regarding the Interoperability at application level, the following recommendations are givenfor UMTS:
• It would be appropriate for any Galileo services or applications to conform to theOSA model. By doing so, the numerous operations relating to authentication,authorisation and privacy are easily addressed following the related standard
• It is recommended to consider the WAP as one option for the applicationsdevelopment. The WAP communications stack provides a method of transportingapplications and data across the link. Application environments such as J2ME andBREW provide the framework in which the applications may run in order to deliverthe relevant Galileo features (see par. 8.2.1 for details)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 235
Logica
9.3.2 RECOMMENDATIONS FOR A GSM ICDThe basic interfaces between GALILEO system and GSM networks for Service Provisioningare not defined in B2 ICDs. A dedicated ICD on GSM interfaces should be produced by B2.The present analysis recommended that:
• An Interface between GALILEO Ground Segment and GSM Network elementsdevoted to LCS services should be designed and implemented for the provision ofephemeris and clock corrections for Assisted Navigation Services
• GALILEO status information (e.g. maintenance bulletins) should be provided byGSC to GSM Network for Broadcasting
• The present study recommends to use the SMLC (Serving Mobile Location Centre)GSM Network Element as interfacing element with GALILEO Ground Segment orLocal Elements (eventually through GSC) and to detail the relevant communicationprotocols.
• It is recommended to use the RLLP protocol for the interfacing between SMLC andGALILEO Ground Segment and Local elements for the provision of Assistance andAugmentation data.
The present Analysis also showed how synchronisation of GSM Network trough a uniquetime reference can reduce the E-OTD infrastructures implementation costs. A fine NetworkSynchronisation can, in fact, avoid the development of LMU for RTD measurementsbroadcasting. It is recommended to give indications during the design phase about thesynchronisation of GSM Network using GALILEO receivers installed in each BTS or higherlevel elements (e.g. BSC).
At the moment an ICD on impacts on GSM has not been developed in B2 phase. Due to thefact that UMTS Operational phase could be delayed by some years and GSM could be alreadythe primary mobile system in 2008, it is recommended to the B2 phase to produce aGALILEO-GSM ICD and to identify the Interfaces to SMLC analysed above.
9.3.3 IMPACTS ON SERVICE CENTRES ICD (EXTICD-PART E)
In the ICD it is not foreseen an interface toward the Mobile Operators for ServiceProvisioning. As stated before, SMLC for GSM and SRNC for UMTS will be the referenceelement of interface between GALILEO and Mobile Operators.Basic Recommendations are the following:1. An External Interface between GSC and SMLC or SRNC for LCS services should be
provided in the ICD, using the same interfaces defined above2. If a Galileo Service Centre has to operate as a service provider, then the relevant interface
is required to connect to OSA framework elements using the OSA API. Applicationsshould be implemented to support the API and thus benefiting from the features thatprovide billing functionality, authentication, and security
3. If the Galileo Service Centre has to operate as a content provider then a similarly openstandard is required. A standard such as XML could be used, given its increased use bygovernment organisations and industry. Application data would be packaged in a relevantXML definition and distributed to third parties for use in providing navigation relatedapplications
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 236
Logica
4. The content provider model implies the need for a billing solution. A flexible billingmodel, integrated with the XML method of distribution would be the most appropriate.Interfaces for off-line and on-line reconciliation should be available, i.e. hard copy billingrecords should be produced as well as CDR�s of an appropriate format
1. The GALILEO Service Centre shall support an interface at application level directly to anSMSC for the provision of a service directly to the individual. The interface should be ofan open nature such as SMPP (Short Message Peer To Peer)
2. A mechanism for recording all information sent to an SMSC is required. This may beused to produce billing records and to reconcile all transactions when providing a service
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 237
Logica
10 SUMMARY OF LEGAL ISSUES
Main legal issues regarding Interoperability between GALILEO and Non Navigation systemscan be summarised in the following point:
IO LEVEL 3
� The Liability chain definition. A clear definition of responsibilities in case ofperformance degradations in the hybridised-receiver needs to be investigated, inparticular if the hybridisation is made at ranging measurements level. In this case infact services inefficiencies are difficult to award to a specific systems operators.In those cases the navigation receiver gets positioning-service by using differentsystems in alternative mode (e.g. A-GALILEO for clear sky and Urban Canyon /Bluetooth for indoor positioning and navigation service) liability-process can beeasier identified due to the complete separation of the different operational modes.
� The cross relations on Intellectual Property Right on the hybridised navigationreceiver have to be clear defined between the different manufacturers (e.g. phonemanufacturers and chip manufacturers). A cross-licensing mechanism is suggested inorder to optimise the royalty flows
IO LEVEL 4/5
Interoperability between GALILEO and Wireless Network (GSM, UMTS), where thewireless networks communication services are exploited to transfer GALILEO Assistance andAugmentation to the GALILEO user terminals.
Relevant Interoperability issue concerning Legal aspects mainly focus on:
� Data security aspects: mainly concern with security aspects in assistance-dataand position information communication between a GALILEO Service Centreand the Network element of the GSM/UMTS LCS architecture which is incharge to collect and distribute them to the UTs (Point-to Point or Broadcastservice). The protocol to be used in the interface between the Wireless Networkand the GALILEO External Entity need to include a security plan in order toguarantee the data transmission in the forward and return communication links.The augmentation information shall be provided to the Emergency ServicesNetwork and Location Based Network in a secure and reliable manner, so thatthe location information is not lost, corrupted, or made available to anyunauthorized third party.In order to be protected by unauthorised access to GALILEO system data thatGALILEO Service Centre has to sell, an authentication process has to be definedbetween Service Providers, Mobile Operators and GALILEO. Only authorisedclients can have access to GALILEO data. Currently, ciphering can be used inorder to encrypt such augmentation data.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 238
Logica
� Privacy aspects: Main legal issues are in this case related to the final serviceProvider that sells and operates position related data and to the Mobile Networkoperator, that provides the communication link on which client position data aretransmitted. In general, a service provider has to guarantee the followingcapability related to privacy:
• Location information must always be available to the network service provider.• Means shall be provided subscriber to control privacy for value added services.• The user shall be able to change the setting of the Privacy exception list at any time.
Unless required by local regulatory requirements, or overridden by the user, the usermay be positioned only if allowed in the UE subscription profile.
� Liability chain: The relevant legal impact mainly concerns therefore with theprecise definition of the responsibilities boundary between the Actor that is incharge to compute and provide the assistance data (GALILEO External Entity)and the Actor that is in charge to use the assistance data in order to implementstandardised LCS (Wireless Operator).
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 239
Logica
11 SUMMARY OF ISSUES FOR OTHER GALILEI TASKSAND OTHER STUDIES
• Pilot Projects and future GALILEO Terminal studies: Analyse improved KalmanFiltering techniques (UKF) for the integration of external automotive sensors(odometers, dead-reckoning) within the navigation solution
• GALILEI Task F: study the interference problem between GALILEO and UWBsystems an define the standardisation process between GNSS and terrestrial mobilefuture systems
• GALIEO EC and ESA studies, Pilot Projects: Participate to NMEA and RTCMconferences and standards in order to insert GALILEO and external ranging sensorswithin those standards and insert new proposed NMEA messages for Quality Reportpurpose (e.g. GST)
• Task G: analyse impacts of hybridisation at measurements and position level withinan integrated terminal for Safety of Life and Emergency applications
• Galileo to Universal Mobile Telecommunications System Interface ControlDocumentAssistance data shall be sent in an ETSI format by UMTS and GSM operators.SMSCB service can be used at the purposes:
o The basic message can contain:� Augmentation data: for 12 satellites the occupation is about 82 bytes� Ephemeris and clock corrections: about 82 bytes for each satellites
o SMSCB service Data capacity occupation varies from 28% to 60% in worstcase (clear sky). It is recommended to use SMS compression in order toreduce such resources occupation
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 240
Logica
12 MIGRATION CONSIDERATION
In the following diagram it is represented a temporal diagram for the introduction of differentsystems for the implementation of interoperability issues.
2004 20082002GALILEO inclusion into ETSI standards
UMTS
Bluetooth
GSM
WLAN, UWB
GALILEO
2005 FCC E-911
mandate
TETRA, DECT(?)
In the future, personal mobility will be the Market driver: PDA, mobile multimedia platform,UMTS, Mobile IP techniques will be the drivers for the Market.GALILEO will have to be inserted in that environment in which a mobile platform will bewell established and probably also mobile operators will have developed their ownpositioning systems based on time differences, integrated with GPS, in order to met E-911mandate by 2005.GSM will probably continue to be maintained also after the UMTSintroduction as a complementary system, while UMTS market entry is foreseen for 2004,(only dense urban areas to be covered at the beginning)Bluetooth will be probably the standard interface mobile phones and external devices and willprovide the possibility to embed a system into another in a wireless way. Car application willbe probably highly impacted by this technology, allowing a hand-free integration of differentsensors within the vehicle. UWB and WLAN will enter the Market and could be used as apositioning means in deep indoor situations.TETRA will be probably relevant for emergency and military applications, while the future ofDECT is very uncertain in some European countries.The risk to GALILEO is to enter a market which is completely saturated by GPS and MobileOperators with consequent loss of interoperability opportunities. It is recommended forGALILEO to immediately establish links with mobile operators and to continue actively toparticipate in the ETSI Forum in order to be included definitively into LCS standards beforethe IOV phase.Following the above considerations, the action plan for the development of Interoperabilitybetween GALILEO and the external systems should be the following:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 241
Logica
Phase 1: 2002-20041. Design of interfaces between GALILEO Local elements and GOC and GSM Network
sub-elements for LCS services (A-GNSS, DGNSS). At the moment standard interfaceswith external elements able to provide Assisted Navigation data (like SAS in UMTS) arenot defined in ETSI, as described in par. 8.2.5.2, so that interfaces toward SMLC shouldbe developed. This is important for two main reasons:• Due to the uncertainties of UMTS starting operations and initial coverage, the
developments of interfaces between GALILEO Local Elements and Ground segments(e.g. GSC and OSS) and existing systems (GSM) is fundamental for MarketStimulation
• The development of dedicated interfaces for GSM could be reused for thedevelopment of interfaces toward UMTS elements
2. Participation and generation of �specific� ETSI-3GPP Work Items in order to providerecommendations for UMTS elements devoted to LCS and Assisted-GNSSimplementation. Design and Specifications of Interfaces between GALILEO LocalElements and UMTS network sub-elements (e.g. Interfaces toward SRNC trough lupc)
3. From 2003 (when presumably SIS specifications will be fixed), specifications and designof User terminal interfaces (during the DD&V phase) between GALILEO and externalsystems (Level 3A and 3B), for hybridisation both at ranging measurements and atposition levels and as communication bearers. In particular, as a priority, GSM/GPS E-OTD integration should be followed and the design of integrated interfaces toward mostpromising systems (Bluetooth, TETRA/DECT, WLAN) should be developed
4. A dedicated specifications and design phase for integrated GALILEO/UMTS terminals(both for TDOA techniques and Communication link) should be developed between 2003and 2004
5. Propose updatings to NMEA 0183 for the inclusions of external ranging and positionsystems within the standard (including quality of serviced indications)
6. Propose the inclusion of GSM and UMTS within NMEA 2000 standard both forcommunication and navigation purposes
All the Phase 1 activities should integrated within the GALILEO Development Phase andusing GSTB facilities and other test beds
Phase 2: 2004-20081. Development and Test of interfaces between GALILEO prototypes of interfaces between
GALILEO Local elements/Ground Segments and GSM using available GALILEOsatellites
2. Development and Test of GALILEO prototypes of interfaces between GALILEO Localelements/Ground Segments and UMTS networks using available GALILEO satellites.The development of the interfaces shall be based on consolidated ETSI standardsdeveloped during the previous phase on GALILEO-UMTS interfacing (to be integratedwithin GALILEO Demonstration and IOV phase)
3. Development and Test of integrated GALILEO/GSM-UMTS terminal prototypes usingavailable GALILEO satellites
4. Launch of first commercial integrated mobile User terminal GSM-GPS enabled forGALILEO for communication and positioning purposes
5. Launch of first commercial integrated UMTS-GPS enabled for GALILEO forcommunications purposes (*)
All the Phase 2 activities should be developed within the GALILEO Demonstration and IOVphase and using GSTB facilities and other test beds
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 242
Logica
Phase 3: 2008-2010 and onward1. Launch of first hybridised commercial terminal (GALILEO (+GPS)-UMTS) for both
communication and Navigation systems integration (*)2. Development of first Commercial Platforms for A-GNSS and LCS based on GALILEO
and relevant links to GALILEO Local Elements and Ground Segment (e.g. through GSC)(*)
All the Phase 3 activities should be developed through agreements between GSC and externalactors and by External Terminal Manufacturers
(*) = Depending on UMTS development status
In the following picture the action plan is summed up.
� Participation to the definition of ETSI-3GPP standards regarding LCS and A-GNSS
� Design of prototypes of GALILEO GSC/LE I/Fs toward GSM for LCS and A-GNSS
� Design of I/Fs of GALILEO GSC/LE I/Fs toward UMTS for LCS and A-GNSS
� Inclusion of GALILEO within NMEA 0183 and NMEA 2000 standards
� Launch of Commercial GALILEO enabled GSMterminals (hybrid NAV and COM)
� Launch of Commercial GALILEO enabled UMTS terminals (hybrid NAV and COM)
� Launch of Commercial LCS and A-GNSS commercial applications based on developed I/Fs
GALILEO FOC
GALILEO
Commercial Applications
2004 2008
DD&V Phase
2002
� Development and Test of interfaces betweenGALILEO prototypes of interfaces betweenGALILEO Local elements/Ground Segments and GSM using availableGALILEO satellites
� Development and Test of GALILEOprototypes of interfaces between GALILEOLocal elements/Ground Segments and UMTS networks using available GALILEOsatellites.
� Use of GSTB and other facilities facilities as a complement for simulation and testing purposes
� Participation to the definition of ETSI-3GPP standards regarding LCS and A-GNSS
� Design of prototypes of GALILEO GSC/LE I/Fs toward GSM for LCS and A-GNSS
� Design of I/Fs of GALILEO GSC/LE I/Fs toward UMTS for LCS and A-GNSS
� Inclusion of GALILEO within NMEA 0183 and NMEA 2000 standards
� Launch of Commercial GALILEO enabled GSMterminals (hybrid NAV and COM)
� Launch of Commercial GALILEO enabled UMTS terminals (hybrid NAV and COM)
� Launch of Commercial LCS and A-GNSS commercial applications based on developed I/Fs
GALILEO FOC
GALILEO
Commercial Applications
2004 2008
DD&V Phase
2002
� Development and Test of interfaces betweenGALILEO prototypes of interfaces betweenGALILEO Local elements/Ground Segments and GSM using availableGALILEO satellites
� Development and Test of GALILEOprototypes of interfaces between GALILEOLocal elements/Ground Segments and UMTS networks using available GALILEOsatellites.
� Use of GSTB and other facilities facilities as a complement for simulation and testing purposes
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 243
Logica
13 SUMMARY OF CONCLUSIONS AND TECHNICALACHIEVEMENT
Introduction
The present Analysis has been performed in order to study the Interoperability and interfacingrequirements between GALILEO and Non Navigation systems (GSM, UMTS, Bluetooth,UWB, etc.), and evaluate the impacts of interoperability on the implementation of GALILEOservices in the future Market environments. Relevant recommendations have been carried outfor the GALILEO MRD/SRD documents.The Analysis has been carried out at the four different levels of Interoperability:
Level 1 RF Processing Level: the RF interference between GALILEO and non-navigationsystems has been here analysed in order to investigate the integration at terminal level
Level 3A Hybridisation at ranging measurements level: hybridisation between GALILEOranging measurements and external systems ranging measurements (e.g. GSM and UMTStime differences) at terminal level has been investigated and indications for improvements oncurrent studies has been provided. This level of integration is important in order to improvesystem GALILEO system availability
Level 3B Hybridisation at position solution level: hybridisation of independent positionsolution obtained by different systems (GNSS, GSM/UMTS ranging, Bluetooth, UWB, etc.)has been analysed. A transition scenario and weighting solutions improvements have beenprovided throughout different service environment (Urban canyons, light indoor, deep indoor,tunnels, etc.) in order to provide possible integrated solutions for GALILEO serviceunavailability problems. Recommendations for position data formats (NMEA) have beenprovided in order to allow the future integration at terminal level of information coming fromdifferent positioning sensors.
Level 4/5: Application and Vehicle level: interoperability between GALILEO terminal andInfrastructures (e.g. GALILEO Service Centre) and external world (Mobile communicationsystems) for the implementation of most promising services (e.g. LBS) have been analysed inorder to identify:
• Protocols and Standards for Application provisioning (Assistance navigationmessages and Augmentation data broadcasting) to be integrated within GALILEOterminal for the implementation of future services (LBS, multimedia applications)
• Identification and proposal for adaptation of standard Systems Interfaces betweenGALILEO Service centres and Local Elements and relevant GSM and UMTSArchitecture Components for the provision of GALILEO Augmentation andAssistance Data and Satellite constellation information and status
• Interoperability at User Control and Administration (e.g. Billing and Charging) leveland protocols analysis, merged in the future mobile IP mobility and LBS Market
In the following main results of the Analysis are reported) for details please refer to the bodyof the document).
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 244
Logica
RF Processing Level
Main results coming from the Interoperability Analysis at RF Processing are reportedhereinafter.The protection distance between navigation and non-navigation equipments (separatedterminals) are synthesised in the following Table.
Dimensioning protection distance between GALILEO receiver and non-navigationsystem to insure interoperability at IOL1
The dimensioning protection distance between navigation and non-navigation equipment onthe same terminal are synthesised in the following
Non-navigation
system
Non-disturbingcriteria
Non-workingcriteria
Dimensioning cases
GSM 81dB 68dB WB interferenceIn-band
UMTS 86dB 73dB WB interferenceIn-band
Bluetooth �WLAN
96dB 83dB WB interferenceIn-band
DECT 86dB 73dB WB interferenceIn-band
TETRA 80dB 67dB NB interferenceIn-band (H3)
Additional out-of-band rejection required
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 245
Logica
As a final conclusion, one should say that the theoretical results trying to assess compatibilitybetween GALILEO and Non-Navigation systems appears to be at the same time critical butvery pessimistic. In particular, for GPS, that should have a similar behaviour than GALILEO,the major outages reports do not show problems with the studied Non-Nav systems but withother devices (TV, Military communications, etc.).Therefore, this �over-dimensioned� approach leads to an important gap between theoreticalresults (derived from the specifications contained within the standards) and operationalmeasures. Nevertheless, the theoretical approach remains the worst case that can beencountered until nothing is done at standardisation level to guaranty a full compatibilitybetween GNSS and Non-Navigation systems.
Terminal Interfaces
At interoperability levels 3A and 3B, the hybridisation at measurement level (rangingmeasurements and time differences from mobile networks, E-OTD and TDOA) and positionlevel has been introduced. Some technical constraints have been examined, in particularrelated to the robustness of the proposed navigation solution in noisy environments and highdynamics situations (typical of road and personal applications), and the inherent errorsintroduced by noise propagation. Partial results coming from external projects have beenreviewed and improvements have been identified.
Hybridisation at ranging levelIn particular, SIA recommend the use of new Kalman Filtering techniques (e.g. UKF) in orderto improve the robustness of the ranging data fusion in high dynamics situation (e.g. car 90°turn). In particular, during the initialisation or reacquisition process, if the number ofmeasurements is not sufficient or characterised by a high level noise, initial position solutioncan be very bad (e.g. estimated using Cell-ID) and could lead the KF rapidly to diverge. Newtechniques are very robust being able to start from a very bad initial position estimation, andare able to mitigate non-linearity problems, avoiding the Jacobian calculation for CovariancesMatrix propagation. The improvements introduced by previous projects (e.g. EMILY) arefocused mainly on the computational effort reduction, and do not take sufficiently intoaccount robustness and accuracy issues. The main advantage of integrating E-OTD (TDOA)and satellite differences ranging measurements is to improve overall navigation servicecoverage (only 1 satellite and 2 BTS are sufficient for a 2-D solution in the tight full couplingsolution). The use of the innovative Kalman filters like UKF allows reaching both theachievement (computational efficiency and robustness). An improvement in terms ofaccuracy and service coverage is foreseen. The numerical evaluation of the impacts implies adetailed filter design, software development and performance assessment through simulation.This is out of the scope of the present analysis. Therefore a detail analysis of the proposedimprovements is recommended for current and future studies on user terminals.
Hybridisation at position levelSIA pointed out that the introduction of external sensors, like heading sensors and odometers(currently developed at low cost starting from ABS system measurements) fused within theloose data fusion process (loose coupling) can improve the overall performance of thepositioning data fusion process. In particular, heading information can improve robustness incase high dynamics situation (e.g. car manoeuvres). Multiple Kalman filters (one local filterfor each sensor and a central Kalman Filter for the data fusion process) solutions arerecommended by SIA in order to improve flexibility and to dominate asynchronous inputs(e.g. different position update rates coming from different sensors). Main improvements aredetailed in the following:
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 246
Logica
• Blunder detection: in the case a blunder in a single sensor processing appears, theerror is detected by the Local Kalman filter and the relevant measurements are notprocessed in the Centralised filter, while drifts and other slowly varying errors can beallowed to accumulate until the error can be detected and eliminated by theCentralised Kalman Filter
• Decrease the computational complexity: the number of ops (operation per second)decrease dramatically by segmenting the number of states. This is fundamental for theperformance of the most demanding computation, like matrix multiplication in statecovariance matrix propagation and matrix inversion in the KF Gain calculation. Forinstance, considering the complexity of a matrix multiplication (O(2n3)), if a 20 statesKF, including all sensors, is segmented in local KF of about 6 states each, thecomputational load can be decreased by 16000 to 6250 bps.
• Sensor intermittences (e.g. GPS providing position information at 1HZ, while E-OTDproviding information at a lower rate) can be taken into account by the central KFthrough dynamic addition and removal of sensors during the processing
Multiple Kalman filtering techniques are recommended to be studied in future Pilot Projectsand during user terminal design and development phase, especially for road applications.
Application and Interfaces between GALILEO and external systems
The present analysis recommend, since the beginning, to develop ETSI interfaces andprotocols for Assisted Navigation and Augmentation Services in the Galileo Service CentreArchitecture and Local Elements. Standardised communication protocols for LBSapplications are recommended to be followed for the future implementation of GALILEOValue Added Services.Furthermore, due to the uncertain date of introduction of UMTS in the future, and to the factthat GSM should continue to complement UMTS in the first period of UMTS development,interfaces for GSM and UMTS have been analysed both at system and at terminal levels.Another important interoperability issue for GALILEO is related to the provision ofGALILEO Assistance and Augmentation Data (e.g. Precise Ephemeris) for Network BasedAssisted solutions and differential solution.The interoperability recommendations have an impact in particular on GALILEO CommercialServices design and development.
GSM interfacesGALILEO Local Elements shall be interfaced to GSM network elements, for the provision ofLocation Based Services and Augmentation services to the GALILEO User Terminal.Currently no standard interfaces are defined for the interfaces between GSM and externalproviders of assistance and Augmentation data. The GSM Network Architectural Elementresponsible for the elaboration of such data and the development of the Service is the SMLC(Service Mobile Location Centre). GALILEO Service Centre shall be interfaced to thatelement (or indirectly through the GMLC) for bulletin distribution, GALILEO ephemeris andaugmentation data provisioning. RRLP ETSI protocol (used for LCS data exchanging on theinterface between GALILEO user terminal and SMLC) is recommended to be analysed andimplemented for the interfacing between GALILEO Local Elements (Service Centre) andGSM SMLC.It is recommended for GALILEO to participate to the ETSI LBS services standards definitionsince the beginning, in order to assure compatibility with mobile Network environment.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 247
Logica
UMTS interfacesUMTS interfaces for Assisted Navigation and Augmentation Services development has beenidentified, following ETSI standards definition for A-GPS case.
Iub
LMU Type A
SRNC CN
Node B (LMU Type B) RNC
UE Node B (LMU Type B)
Iur
IuIub
Uu
SAS
Iupc
GALILEO GS / LE
External Interface
The SNRC, works as SMLC (Serving Mobile Location Centre) and receives authenticatedrequest from LCS applications or LCS Client functions in the CN (Core Network) across theIu interface. RNCs manage the UTRAN resources, the UE and the calculation functions toestimate the position of the UE, and return the result to the CN.The SAS (Stand Alone A-GPS SMLC) provides GPS assistance data to the SRNC to bedelivered through point-to-point or broadcast channels to the UE, and acts as a locationcalculation server if the location estimates are not calculated in the RNC. The SAScommunicates with the SRNC over the Iupc interface.Accordingly, it is recommended to implement the interface between GALILEO LocalElements (through LE Service Centre) and UTRAN SRNC through the Iupc interface throughthe compliance with PCAP (Positioning Calculation Application Part) protocol. GALILEOLE (and relevant Service Centre) could acquire in this way the role of SAS. On the UMTSnetwork side, the SRNC performs the position calculation function and the distribution(Point-to-Point or broadcast) of assistance data to the User Terminal. It is recommended forGALILEO:
• to participate to UMTS ETSI standards development in order to acquire a role as SASdeveloper
• to be compliant with PCAP and lupc interfaces or propose updates to meet GALILEOneeds
At application level, the future Market environment will be dominated by LBS and MobileInternet Multimedia applications. Mobile communication operators will be the point of accessfor such kind of applications. When GALILEO will become operative, mobile operatorsstandards will be well established in the Market. This implies the following needs forGALILEO terminals and systems interoperability:
• If a Galileo Service Centre has to operate as a service provider, then the relevantinterface is required to connect to OSA framework elements using the OSA API
• Use existing and future services dedicated to the mobile Internet environment (e.g.UMTS IMS, recommendation to study interfacing with S-CSF)
• To apply standard session initiating protocols (like SIP) and languages for applicationrelevant data exchange (e.g. XML)
• To interface with Mobile Communication Billing and Charging capabilities, usingstandard Charging and Billing procedures (e.g. through the establishment ofIpAppChargingSession)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 248
Logica
Secondary Systems
The interoperability analysis has highlighted the relevant role of secondary systems both aspositioning systems to be used in alternative way together with GALILEO, and ascommunication systems to provide GALILEO UT with high data-rate communicationfunctionalities. In particular, Bluetooth and UWB are considered as the preferred system forposition integration in deep indoor environment and tunnels. They have to be used inAlternative way, due to the fact that in deep indoor situation neither GALILEO/GPS ormobile networks solutions and measurements are available. Bluetooth is also the preferredway for communication purposes.In the following tables a comparison between different navigation systems in terms ofaccuracy and availability (N/A implies non availability) is reported in order to better representthe alternative or combined use in different environments (in yellow and within the followingranking table).
GALILEO/GPS A-GNSS HybridisedGSM/UMTS
Assisted GNSS
Bluetooth(***)
WLAN(***)
UWB TETRA
DeepIndoor/Tunnel
N/A N/A N/A 10m 10m 10-30cm N/A
LightIndoor
N/A (very badperformances if
available)
20-100 m (*) 20-200 m (**) 10m 10m 10-30cm N/A
UrbanCanyon
N/A (very badperformances if
available)
10-50 m(*)
10-50 m(**)
N/A N/A N/A N/A
Outdoor <10 m <10 m <10 m N/A N/A N/A N/A
(*) = available with sufficient number of satellites (at minimum 3, e.g. urban canyons or near windows within buildings) trackedusing assisted navigation techniques (not usable through nominal receivers)(**) = higher availability compared to A-GNSS solution due to use of external range measurements (e.g. indoor environmentwith number of tracked satellites ≤ 2: needed hybridisation with GSM/UMTS BTSs ranging measurement for positioncomputation)(***)= the reported accuracy levels are depending on the availability of the short range systems infrastructures in the consideredenvironments
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 249
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 250
Logica
Ran
ge
Peak
Dat
a R
ate
Pric
e
GA
LIL
EO
Aug
men
tatio
n/A
ssist
anc
e
Dee
p In
door
Tun
nel
Lig
ht In
door
Urb
an C
anyo
n
Out
door
Bluetooth 10-100m 1 Mbps 5� (future); 9�(current) 200�
(card)
*** (indoor) *** *** * -
WLAN 10-100m 1-11Mbps(IEEE
892.11b)
100�(PCMCIA)
*** (indoor) *** *** * -
UWB 10m <1Gbps - * (indoor) ** ** - -
DECT 300m 1.152 Mbps >50� **(urban, lowmobility)
- ** *** -
GSM/UMTS Km 9.6 Kbps/2Mbps
100�/300� *** (outdoor,Urban, Light
indoor)
- ** *** **
The conclusion is that:• GALILEO provides good position and ranging measurements statistics in outdoor
and light indoor positioning through A-GALILEO and hybridisation with mobileoperators BTSs ranging measurements
• Mobile communications systems positioning services are useful in GALILEO SISshadowed environment (e.g. Urban Canyons), mainly for the increase in availabilityand accuracy service performances (added ranging measurements)
• Due to the high Local precision of short range Secondary Systems, where Secondarysystems are available (e.g. Bluetooth piconets), the GALILEO user terminal shallautomatically switch its operational mode from GALILEO to short range secondarysystems positioning services
• Short range Secondary systems are important for the provision of integrated high datarate multimedia applications for GALILEO User Terminal in local environments
• Conversely, UMTS is the only system able to guarantee high data rate multimediaapplication in Urban and suburban areas
• Mobile communication systems will be the basic bearers for GALILEOAugmentation and Assistance Data (messaging services, broadcasting services,packet/circuit switched data services)
At application level, Bluetooth is foreseen to be in the future the basic platform for theintegration in a multi-system environment. The integration will be particularly suitable in-vehicle applications.
Adaptation Protocols and Data Formats
Position Report and ETSI standardsProtocols adaptation shall be introduced in order to exploit the interoperability. As aconsequence of our terminal interoperability analysis, the essential information to be inserted
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 251
Logica
are the Quality Report (position estimation statistics) and the enhancement of NMEAmessages in order to include GALILEO satellites into standard messages.The following updating are recommended:NMEA 0183:
• Enhancement of GGA or GLL messages for double constellation• New Quality Report messages: GST
Modifications to NMEA 0183 GGA message are proposed in order to include both GALILEOsatellites and BTSs ranging measurements within the message information (e.g. number ofmeasurements instead of satellites only and HDOP information to include BTS rangingdifferences).A new NMEA message has been proposed (GST-Global Statistic), able to include theposition error covariance matrix elements, expressed as an example for a 2-D positioning casein the following$--GST,dev, mode1,mode2,SV,BTS,σx
2 ,σxy, σy2*CHK
$--GST,4,M,2,19,28,14,18,27,22,31,39,,,�.,,46.3,1.2,24.2*35where:dev= device ID (e.g. for multisensors environment, it identifies the source of position solutionand the relevant covariance matrix elements
• mode1=Manual (forced to operate in 2-D or 3-D mode) or Automatic mode(automatic selection of 2D or 3D based on the number of available satellites)
• mode2 = 1=Fix not available, 2=2D, 3=3D• σx
2 ,σxy, σy2= elements of covariance position error matrix
• SV= satellites in view• BTS= BTSs in view
NMEA 2000:• Position statistic• GNSS/GSM DOP
NMEA 2000 (at the early stage of definition and intended to provide standards for theintegration of different sensors for marine operations in a networks environment) updateshave also been proposed in order to add the following information:• GNSS Position statistic, reporting the elements of the error position Covariance Matrix
should be provided for the GALILEO+GPS system. The content of this message shouldbe similar to the above proposed GST message:
o A flag indicating 2-D or 3-D modeo A mask with 1s for the used satelliteso The elements of the Covariance Matrix
• GNSS/GSM DOP: At the moment GSM and future UMTS are not considered as sourcesof ranging in NMEA 2000. This new message has to be introduced in order to includealso GSM E-OTD and UMTS TDOA measurements. The relevant message for thehybridised GNSS/GSM positioning has to be foreseen in the new NMEA standard
For the transmission of Augmentation and Assistance data to the mobile, the ETSI standardapplied to LBS services is recommended.The present SIA recommend to use the RRLP Standard Protocol for the interface betweenUser Terminal and GSM or UMTS Systems. RRLP include all the procedures for Assistednavigation data request/broadcasting and position report to Service Centre.
Data capacity analysis for Augmentation and Assistance data provisioning
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 252
Logica
A data capacity analysis for the broadcasting of Augmentation and Assisted Data has beencarried out. Using the GSM and UMTS SMSCB broadcasting services, based on basicmessages of 82 bytes, the analysis reveals that the utilisation factor of the SMSCB service inthe case of single frequency is less than 20%, while in the worst case of three frequency anddouble constellation in clear sky + Almanac data (worst case), the utilisation factor can reach60% of SMSCB capacity. The use of GSM and UMTS compression algorithms isrecommended, in order to reduce the service load. The basic result is that the feasibility ofdouble constellation Augmentation assistance data is demonstrated and the interoperabilitybetween GALILEO Service Centres and Mobile Operators to this end is recommended.Furthermore, the possibility to use future UMTS services (like IMS, IP MultimediaSubsystem) as differential corrections data broadcasting alternative mode is recommended inorder to support higher data rates (e.g. for RTK/TCAR applications).
Legal IssuesRelevant Interoperability issue concerning Legal aspects mainly focus on: Data securityaspects, Privacy aspects, and Liability chain.Concerning Data security aspects, the overall interoperable system is recommended toguarantee that: Position information is safeguarded against unapproved disclosure or usage;Position information is provided in a secure and reliable manner that ensures the informationis neither lost nor corrupted; Records are maintained of positioning requests and responses tofacilitate resolution of security violations.Management of Data security have to be shared between GALILEO Service Centre, MobileOperators and Service Providers.Concerning Privacy aspects, the following capability related to privacy shall be envisaged:
• Location information must always be available to the network service provider.• Means shall be provided subscriber to control privacy for value added services.• The user shall be able to change the setting of the Privacy exception list at any time.
Furthermore, specific privacy exceptions may exist for compliance with mandated locationbased services (such as for emergency services or lawful intercept), which are required bynational or local regulatory requirements.Privacy requirements have to be respected throughout all the actors of the GALILEO servicesvalue chain.As far as the Liability chain is concerned, legal impacts coming from the interoperabilitybetween GALILEO and Wireless Networks (considered as bearer of assistance data) mainlyfocus on the clear identification of the responsibilities in the Assisted GALILEO andDifferential GALILEO positioning services.The relevant legal impact mainly concerns therefore with the precise definition of theresponsibilities boundary between the Actor that is in charge to compute and provide theassistance data (GALILEO External Entity) and the Actor that is in charge to use theassistance data in order to implement standardised LCS (Wireless Operator).
Conclusions on COSPAS SARSATThe Interoperability between GALILEO and the COSPAS SARSAT system has beeninvestigated within this report.The most critical aspects of the COSPAS SARSAT system are:- the accuracy determination by Doppler-measurements (some nautical miles, if no GPS
receiver is integrated)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 253
Logica
- ambiguities of the position solution- latency of COSPAS SARSAT (up to several hours)- number of processing anomalies, which could cause false alertsSome of the disadvantages of the LEOSAR system (part of the COSPAS SARSAT system)could be overcome by the migration of the COSPAS SARSAT user community from the121.5/243 MHz beacons to the 406 MHz beacons, which is scheduled until 2009. For furtherenhancements of the SAR solution a combined COSPAS SARSAT / Galileo solution isrecommended.Co-existence:The decision in case of co-existence will be driven by user specific requirements and financialbackgrounds. SOLAS convention recommendations shall be followed to allow the user adecision between COSPAS SARSAT and Galileo SAR equipment the certification of Galileoas means of SAR for maritime applications is the first hurdle to be cleared. The next barrierfor a decision for Galileo SAR instead of COSPAS SARSAT is the price of the equipment.Even if Galileo provides a better performance it is expected that ship owners will opt forCOSPAS SARSAT if Galileo SAR equipment is even a little more expensive than COSPASSARSAT devices. The price of an EPIRB is ~ 1000 Euro, the additional cost for theintegrated GPS receiver is 250 Euro (INMARSAT C SAR devices for maritime users cost~3500E plus a communication costs). Such equipment is carried today mostly by ships(obliged by the SOLAS convention to be equipped with SAR facilities). If Galileo SARdevices can be offered at price levels in the order of today�s GPS receivers for leisureshipping, fishing, or small commercial ships a huge market can be exploited. The exploitationof this �unregulated market� could enable to be competitive in the �SOLAS-regulatedmarket�. Interaction with insurance companies is another option to be investigated, followingthe already known automotive market case. Transferring such models into the maritime SARworld would mean that a ship owner who install the �enhanced� Galileo equipment (betteraccuracy, reduced time to alarm between moment of distress and call reception in the rescuecentral (10 minutes instead of >1hour, acknowledgement of call reception to the victim, etc.)will pay reduced insurance premiums, because the financial damage in case of an accidentwill be (statistically) lower due to significant reduction of rescue time. In the area of aviationthe situation is similar to the maritime sector to some extent (also both regulated andunregulated markets for SAR equipment) but less stringent, e.g. in Germany 20-50% of theGeneral Aviation aircrafts (~20 000) are equipped with ELTs. The General Aviationrepresents the biggest market potential for SAR equipment. The price for ELTs is in the orderof some 1000 Euros.Alternative use:Alternative use of either Galileo SAR or COSPAS SARSAT would implicate redundantequipment of ships, additional investments in the COSPAS SARSAT and Galileoinfrastructure, and additional effort on harmonisation with rescue forces without significantimprovements for the users (the only benefit is position determination with Doppler if lessthan 4 Galileo-satellites are in view, but Doppler-positioning also requires a LoS to onesatellite for a certain period of time). For this reason this option was not discussed in moredetail.Combined use:Following approaches for the combined use of Galileo with COSPAS SARSAT wasidentified:• Migration from the use of GPS to Galileo for a certain amount of COSPAS SARSAT
terminals through- replacement of GPS by Galileo
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 254
Logica
- parallel use of Galileo and GPS- use of combined Galileo/GPS receivers
• �Assisted-Galileo� data made available at the LUTs (reduce TTFF, use differentialcorrections, integrity information) either by own reference receivers on-site orcommunication links to Galileo Ground Segment
• Acknowledgement of received distress calls to the usersThe above proposed interoperability interfaces correspond to a large extends to thedescription of the Galileo SAR service as described in the Mission High Level Definition.Within the footprint of a GEO satellite (INMARSAT) the peak figure of simultaneouslyreceived emergency events is approximately 40. This indicates that globally at least 120simultaneously received emergency events have to be handled. Distributing those 120messages equally to the footprints of the 30 Galileo satellites results into 4 events per Galileofootprint. Assuming further that 1 bit is necessary to communicate to the user that his distresscall was received at the MCC and 20 bits are used to address the user via a unique user ID (20bits will be sufficient to encode 1 048 576 users, COSPAS SARSAT has 900 000 users today)an amount of 84 bits has to be handled by each satellite. Offering the system operator thecapability to transmit additional messages to the user will increase the amount of data by 6 bitper digit multiplied by 4 (number of simultaneously expected distress events in peaksituations). The calculation above is globally in line with the information in the HLDassuming 100 bits per message and 6 messages per minute. Geographical distribution andfuture increase in demand should be taken into account for the final system design.Beside the technical aspects mentioned above legal and commercial impacts oninteroperability of Galileo with COSPAS SARSAT must be clarified between the futureGalileo Operating Organisation and a number of countries and organisations participating inthe operation of the COSPAS SARSAT system. The countries participating to the COSPASSARSAT International Programme Agreement are Canada, France, Russia and the USA plus20 ground segment providers, 9 user states and 2 participating organisations involved inCOSPAS SARSAT operations. For future interoperability operations also organisations,which stated their interest in the COSPAS SARSAT Programme e.g. IMO, ICAO, ITU, ICS,the International Radio Maritime Committee (CIRM), and the International Federation of AirLine Pilots Associations (IFALPA), will have to be taken into account.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 255
During the MIA-phase of Galilei Task E the demand for interoperability of Galileo with othersystems (either navigation- or communication systems) was evaluated for different modes oftransport. Based on these results the SIA report provides an in-depth analysis of the mostappropriate systems.
To explain readers, who are not familiar with the MIA-documentations, the basic reasons forinteroperability of Galileo with other systems, as described by the �Galileo AvailabilityAugmentation�-model, which was derived during the Interoperability Workshop held inBrussels on 15-16.3.02, is shown in the following figure.
Figure 14-1; GALILEO Interoperability environment
The figure will be explained using the road sector as an example. The road sector was chosen,because road applications take place in a great diversity of different environments.
The logic behind the figure is to demonstrate the migration from favourable signal receptionconditions (outermost box) to extreme unfavourable signal reception conditions (innermostbox). The consequences for road applications are described hereafter on box-level:
Open Skies: This box represents environments with optimal satellite signal receptionconditions for Galileo, e.g. flat land, no obstacles (vegetation, buildings, hills, etc.) near theroadside, no interference/jamming/spoofing disturbances, etc.. The user requirements can besatisfied by stand-alone use of Galileo
Self Contained
IsolatedDeep Penetration
Shallow Penetration
RedundancyOpen Skies
GalileoGPSGLONASSVORDMETacan
LoranGSMUMTS
CompassMagneto-meter
PseudolitesBluetoothMap-matching
InertialOdometer
Self Contained
IsolatedDeep Penetration
Shallow Penetration
RedundancyOpen Skies
GalileoGPSGLONASSVORDMETacan
LoranGSMUMTS
CompassMagneto-meter
PseudolitesBluetoothMap-matching
InertialOdometer
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 256
Logica
Redundancy: Same environment like described above, but due to safety critical or highlycommercial character of the application (e.g. fleet management for police, fire brigades,ambulances, etc; monitoring of hazardous and valuable goods, just-in-time delivery, etc.) asecond system is required in case one system is not available
Shallow Penetration: Contrary to the above in this scenario the availability of Galileo isreduced to some extent. This can be caused either by obstructions interrupting the LoS to thesatellites (e.g. rural environment), or unintentional/intentional interference. For a reliableposition solution a second (dissimilar) system should be used.
Deep Penetration: The environment is worse than in �shallow penetration� (e.g. urbanenvironment) and affects also the systems, which can be used for �shallow penetration� tosome extend. Therefore the position solution has to be augmented by on-board sensors,preferably using �non-radio navigation techniques�.
Isolated: Due to further deterioration of the conditions systems (e.g. extreme urbanenvironment, urban canyons) that are not affected by external influences (including magneticdisturbances) have to be included
Self Contained: Extreme environment (e.g. tunnel, parking garages), the position solutionmust be augmented with fully autonomous sensors, which do not require e.g. the installationof external infrastructure or the availability of digital maps.
Of course the �Galileo Availability Augmentation�-model described above also applies to theother modes of transport analyzed in the MIA phase.
For example for maritime applications the migration of environments could be:
Open sea � coastal areas � fjords, inland waterways � harbour
For aviation applications the following environments/applications have to be taken intoaccount:
En route � NPA � CAT I � CAT II � CAT III � terminal operations
The environments for rail applications are very similar to the road example, even with higherimportance of tunnels and obstructions at track sides (railway embankments).
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 257
Logica
15 ANNEX B: DESCRIPTION OF NON-NAV SYSTEMSCONSIDERED AT IOL1
All the following systems descriptions have been taken from the GALILEI DD-021 document"Complementary Systems: Functions and Performance" except Satellite CommunicationSystems description taken from Eurocontrol document " Radio characteristics of aviationradio systems".
15.1 GSM/GPRS/UMTS
There are 3 main generations of mobiles:
15.1.1 2G MOBILE RADIO
The most successful is GSM (Global System for Mobile communications) with a total numberof 565 millions subscribers (70% of the total 2G subscribers) in July 2001. It is mainlydedicated to voice communication (13 kbits/s). Data transmission is also possible, with athroughput of 9.6 kbits/s for data transmission and in addition, GSM enables the transmissionof short messages containing less than 160 characters (SMS). Other 2G cellular systems areIS-54 (TDMA), IS-95 (CDMA) and PDC (TDMA).
GSM is based on the TDMA (Time Division Multiple Access) technology.The GSM-system also involves the concept of multiple access defining how users share theradio resources. In fact, GSM is a mix of two multiple access techniques, Frequency DivisionMultiple Access (FDMA) and Time Division Multiple Access (TDMA). This means that eachcarrier is divided by frequency, but within that divided by time.
There are a total of 124 carriers available for the GSM 900-system, and 374 carriers for theGSM 1800-system. Considering the fixed carrier spacing of 200 kHz, the frequency borderspacing adds up to 25 MHz and 75 MHz in the respective GSM-systems. In other words, thisis the total frequency bandwidth available in both the uplink- and the downlink-band.
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 258
Logica
15.1.2 2.5G MOBILE RADIO
Significant enhancement of the GSM has recently been achieved by the so-called GPRS(General Packet Radio service). This end-to-end packet transmission system allows anincrease of the throughput, from 10 kbits/s until 60 kbits/s depending on the radio linkconditions. Finally GPRS has a potential broadcast capability.
15.1.3 3G MOBILE RADIO
UMTS (Universal Mobile Telecommunications Systems) is the third generation cellularsystem standard. Contrary to GSM and GPRS, it is based on CDMA technology. UMTSprovides both voice and bi-directional data communication. Contrary to previous generations,UMTS is an interference-limited system: performances mainly depend on the number of usersin the cell, their useful throughput and the Base Station power. Depending on the providedservice, throughputs range is from 12.2 kbits/s (voice) until around 2 Mbits/s, or even moreunder specific conditions and by combining new high technologies. Finally, UMTS has abroadcast capability.
The 1992 World Radio Conference (WRC) of the International Telecommunication Union(ITU) targeted a 230MHz frequency band for UMTS in the 2GHz band (see following table).However it is still not clear whether this amount of spectrum will be sufficient. It is currentlyestimated that the requirements will be between 300 and 500MHz.
Lower frequency band (includingsatellite uplink)
Higher frequency band (includingsatellite downlink)
Frequencybands
1885-2025 MHz 2110-2200 MHz
Table 15-1: UMTS allocated frequency bands
The nearest GALILEO frequency band is the L1 frequency band centred at 1575,42MHz inthe upper L-band. The separation between UMTS and GALILEO signals will be thereforeabout 300MHz.
15.2 BLUETOOTH
Bluetooth technology is becoming the standard for the connection between different devices(computers, mobile phones, electronic devices, network devices). Potential use for Galileo isan easy connection of Galileo terminals to a wide range of computing, telecommunication andelectronic devices, thus providing navigation aids information.
Bluetooth performance summary
Definition Bluetooth is a technology that enables the merge of mobilecomputing with mobile communications
Transfer Mode Packet switchedFrequency Band 2.4 GHz (unlicensed ISM Band)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 259
Logica
Data: 721 Kbit/s piconet (including a 56 Kbit/s back channel)
Bit RateUp to 3 voice channels / piconetUp to 7 data channels / piconet
Latency Time
Real TimeEach Bluetooth transmitter is able to cover an area with 10m widthBluetooth can operate in a multi-user environment: Up to 8 users /piconet
Coverage
Up to 10 piconets can co-exist in the same coverage rangeSince each link is encoded and protected against botheavesdropping and interference, Bluetooth can be considered asecure short-range wireless network
User Type All
User Terminal
It is a radio module to be integrated in computing andcommunicating devicesLow-power (1mW)Small-sized (0.5 square inches)Low cost (initially between $15 and $20. Driven by volume, thecost should drop to about $5 by 2001)Short range voice communications between communicationsystems and electronic devices
Services
Short range data communications between communication systemsand electronic devicesWireless connectivity of mobile phones to: laptop computers,personal digital assistants, cameras, printers, fax machines andhousehold appliances, other phones (walkie talky)Wireless connectivity of laptop computer to: cellular phones, wire-bound connection (e.g. PSTN, ISDN, LAN, xDSL), other laptopcomputers
Applications
Wireless connectivity of wireless headset to: your mobile phone,mobile computer or any wired connectionAutomatic synchronisation of desktop, mobile computer, notebook(PC- PDA and PC-HPC) and mobile phone (e.g. address list andcalendar in a notebook may automatically be updated to agree withthe one in desktop)In-car handset-vehicular receiver connection
Time Frame
Start up: within 2000Lifetime: beyond 2010Easy connection of GALILEO terminals to a wide range ofcomputing,
Potential Use forGALILEO
Easy connection of GALILEO terminals to a wide range ofcomputing, telecommunications and other electronic devicesConnection of hand-held terminals to vehicular satellite terminalsto allow improved coverage
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 260
Logica
Market
Pioneered by Ericsson, IBM, Intel, Toshiba, and Nokia. TheSpecial interest Group has now over 600 affiliated IT andtelecommunications companies including Motorola, Lucent,Qualcomm, 3Com and VLSIIn June 2000, Ericsson introduced the first Bluetooth-compatiblemobile phone, the T-36.
15.3 WIRELESS LAN (WLAN)
Wireless Local Area Network (WLAN) technology is a mean for providing local areaconnectivity between computers and associated network resources using wireless rather thanwireline links. The most common WLAN standard is defined in IEEE 802.11 with base datarates between 1 and 11 Mbits/s. Another one is Bluetooth which is an industry standard withbase data rate of 1 Mbits/s. Positioning using WLANs could be either network based, i.e. theposition calculation is performed by a server connected to the network, or mobile based, i.e.the position determination is performed by the mobile unit or PC. Such technique applies toin-door environment with a good accuracy: 1m accuracy is claimed for the Bluetoothpositioning.However, unless there are significant commercial drivers for this positioning capability, it isunlikely to be given much consideration by the standard developers who will be more focusedon the communications and networking aspects.
The most common WLAN standard is defined in IEEE 802.11 [20]. The base data rates are 1- 11 Mbps (802.11b) with plans to extend this to 54 Mbps (802.11g). Ranges are typically inthe order of ~100m. WLANs generally operate in the ISM band at 2.4 GHz. Some systems(IEEE 802.11a, ETSI HIPERLAN [21]) operate at 5 GHz. WLAN systems use moderatelywideband signals (spread spectrum) and are intended for operation in indoor and constrainedenvironments. Unfortunately there are a number of variants, particularly concerning themodulation and data rate, none of which are interoperable.
15.4 TETRA (TERRESTRIAL TRUNKED RADIO)
Terrestrial trunked radio (TETRA) is a communication standard for point-to-point, bi-directional links for single cell private nets with cell diameters up to 50 km. TETRA is suitedto organisations that need access to voice and data services also when out of touch with theirinfrastructures.
Definition TETRA is an example of PMR network
Transfer Mode
Circuit switched data (28.8Kbit/s max bit rate).Circuit switched protected data (18.2Kbit/s max bit rate).Circuit switched strongly protected data (9.6Kbit/s).Connection oriented packet switched dataConnectionless packet switched data
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 261
Logica
Multiple Access TDMAModulation π/4 DQPSK
Frequency Band150MHz-900MHz (Europe)Carrier spacing 25KHz4 channels per carrier
Bit Rate
Max data transfer rate 28.8Kbit/sVideo images can be transmitted at 19.2Kbit/sTransmission speeds can vary and can be set according to thespecific needs
Latency TimeReal TimeCall set-up time: 300msec
Coverage
LocalUrban and suburban areas with low to medium user densities andcell sizes oftens of kilometres (large cells)According to estimates, TETRA-based networks will be operative inall thecontinents with 5-10 million users by the year 2010
User Type Land business usersUser Terminal Hand-held
Services
Full duplex person-to-person, group calls (with or without ACK)Broadcast calls within the TETRA networkCalls to any fixed or mobile phone via the PSTN interfaceTerminals can communicate with each other on an one-to-one basisindependentof the TETRA infrastructureIP-based packet dataUser-originated text messagingDirect Mode: allows direct operation between terminals without useof trunking infrastructure
ApplicationsVoice and data communications organisations that need access tovoice and data services also when out of touch with theinfrastructure
Time Frame Lifetime beyond 2010
Potential Use forGALILEO
Personal voice and low speed data communications that this systemreliably provides in urban environments on a local basis, addressinggroup oriented Organisations
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 262
Short range:DECT (Digital Enhanced Cordless Telecommunication) is a radio access technology to alarge number of networks. Cell radii go from 25m-50m (in-door mobile use) to 250m(outdoor mobile use) and up to 15km for fixed wireless use.
DECT performance summary
Definition DECT is a radio access technologyTransfer Mode Circuit switched and Packet-switchedMultiple Access MC-TDMA (24 timeslots/frame on each one of the 10 carriers)Modulation GPSK (BT=0)
Frequency Band
1880MHz, 1900MHz and 3.5GHz10 carriers with 1.728MHz spacingFree of charge frequency bandAll channels are available to all cells (DCA). The handset operatesthe selection of the best available channel to communicate with thebase station (the base station indicates in a broadcast message theavailable carriers).This technology ensures a robust radio link, provides effectivecoexistence of uncoordinated installations of private and publicsystems on the common designated DECT frequency band,avoiding any need for traditional frequency planning and allowseasy installation
Bit Rate
32Kbit/s ADPCM with echo controlUp to V.90 56 Kbit/s in more recent developmentsThis technology guarantees high speech qualityA high-speed mode using alternative modulation schemes wasadded to the DECT base standard, in a fully backward compatibleway, to allow higher bit rates. At this point DECT cordless is ableto offer 512Kbit/s bit rates and with the modifications coming tothe standard, 2Mbit/s will soon be possible.
Latency TimeReal TimeCall set-up time: few seconds
Coverage
The DECT System will be used in three different environments:Business Cordless Telecommunication (BCT): a mobile terminal isconnected to a PABX and consequently any public network. Therequired capacity for this system is 10,000Erl/Km2 /floorStrong limitation on mobile terminal velocity (45km/h).Telepoint: a public structure enabling any subscriber to connecthimself to any network through his mobile terminal. This servicewill only be available in the most crowded areas (airports. Railway
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 263
Logica
stations,-). The required capacity for this system is 1000-6000Erl/Km2 /floor"Local" roaming (within the same building) and global roaming(between different local scenarios)Fast and interruption-less hand-over
Connectivity with othernetworks
PSTN, ISDNPSPDNPLMN standards: GSM
User Type Residential and business usersUser Terminal Hand-held
Services
Two-way circuit data, packet data and multimedia servicesThe A/B profiles specify frame-relay for inter-working withEthernet and Token Ring LANs, and cover IP inter-working inadditionThe C profile specifies data link services, e.g. for inter-workingwith V.24InterfacesThe D profile specifies transparent and isochronously transfer forsynchronous data servicesThe E profile specifies MessagingThe F profile specifies fax, E-mail, WWW access and SMS
Applications
System integrators can make use of DECT modules for measuringor controlling equipment: gas water or electrical meters might bean exampleEasy to operate wireless residential networks (data exchange fromPC to PC orthe control of household appliances via phone)DECT is today the world's dominant technology in WLL with 32%of all WLL lines installed worldwide in 1998.Fixed systems (WLL): voice/data, fixed single or multiple-lineterminals
Time FrameStart-up: 1996Lifetime: Beyond 2005
Potential Use forGALILEO
Data and voice communications that this system can reliablyprovide in indoor environments. (WLL use)
Market
Handsets manufacturers: Siemens, Ericsson, AlcatelSiemens demonstrated the integration of its DECT transmissionmodules into a palmtop computer, allowing the user to exchangedata (e.g. for remote control of alarm and security systems)Alcatel estimates that there will be 1.5 million handsets in thebusiness multi-cell market in Europe by the year 2000.Ericsson's DRA 1900 holds a dominant position in the DECT WLLmarket
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 264
Logica
Philips is in the market too Nordic European countries hold thebiggest part of the market: Sweden is the leading European marketwith around 27% of all office lines being cordless.Norway, Denmark and Finland are close behind with penetrationlevels of 10-15 %. Outside of Europe the cordless office market isless developedIn the public communication field Telpoint-type networks such asTelecomItalia's Fido did not encounter much successBT plans to launch its Onephone service: a DECT/GSM serviceusing the Ericsson's dual mode DECT/GSM phones. Also theGerman Viag Interkom hasunveiled a similar service known as Genion.
15.6 SATELLITE COMMUNICATION SYSTEMS
15.6.1 GLOBALSTAR SATELLITE COMMUNICATION SYSTEM (USER-SATELLITE)
System descriptionSystem type Globalstar satellite communication system (User-
satellite)Frequency band 1559 - 1626.5 MHzsystem overview/applications This system provides a capability for aeronautical
satellite communications requirements external tothe aircraft, including operator flight and cabincrew, as well as passenger, telephone and dataservices depending on aircraft equipage.
Additional overview info [ARINC 761-1 3.4]system category CommunicationsAssociated systems Globalstar satellite communication system
(Satellite-user)Date of last update to data 12/04/2000Relevant standardsICAO NoneRTCA MOPS NoneEUROCAE NoneARINC [ARINC 761]ITU NoneOther information sourcesSources None
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 265
Logica
Coverage/operating volumeHorizontal 360 degreeVertical Hemispheric with 10 degree minimum elevation to
satellite. [ARINC 761 A3.4.4]Transmission characteristicsbase frequency spectrum UnspecifiedITU frequency designator Unspecifiedlower limit 1610upper limit 1626,5Frequency limits additional info [ARINC 761 A3.4.1]central frequencycentral frequency additional info N/Achannel spacing UnspecifiedChannel spacing additional info NonePower spectrum UnspecifiedPower spectrum defined pointsPower spectrum additional info NoneModulation type UnspecifiedModulation type additional info Nonetone frequency N/Apulse width N/AUpper limitLower limitPulse width additional information N/Apulse repetition frequency N/AUpper limitLower limitTransmitter output power UnspecifiedTransmitter output power additional info NoneTransmitter antenna gain 0 dB average of 90% of hemisphereTransmitter antenna gain graphTransmitter antenna gain additional info [ARINC 761 A3.4.2]Effective radiated power 13Effective radiated power additional info [ARINC 761 A3.1.1]Minimum field strength within operating volume UnspecifiedMinimum field strength within operating volumeadditional info
None
power flux density Unspecifiedpower flux density additional info None
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 266
Logica
Polarisation state UnspecifiedPolarisation additional info NoneFrequency tolerance/stability UnspecifiedAdditional transmission information NoneReception characteristicsReception frequency band: Unspecifiedlower limit 1610upper limit 1626,5Frequency limits additional info Nonecentral frequency 1618,25central frequency additional info NoneITU frequency designator UnspecifiedReception spectrum defined points NoneReception spectrum graphReception spectrum additional info Nonereceiver pulse width N/AModulation method UnspecifiedModulation method additional information Nonereceiver minimum detectable signal at centrefrequency
Unspecified
receiver minimum detectable signal additional info Nonereceiver antenna gain Unspecifiedreceiver antenna gain graphreceiver antenna gain additional info Noneeffective received power at antenna Unspecifiedeffective received power additional info NoneImmunity to in-band interference UnspecifiedImmunity to out-of-band interference UnspecifiedFrequency planning protection ratio (co-channel) UnspecifiedFrequency planning protection ratio (adjacentchannel)
Unspecified
Additional reception information NoneOther informationSupporting information: None
15.6.2 GLOBALSTAR SATELLITE COMMUNICATION SYSTEM (SATELLITE-USER)
System descriptionsystem type Globalstar satellite communication system
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 267
Logica
(Satellite-user)Frequency band 2483.5-2500 MHzsystem overview/applications This system provides a capability for aeronautical
satellite communications requirements external tothe aircraft, including operator flight and cabincrew, as well as passenger, telephone and dataservices depending on aircraft equipage.
Additional overview info [ARINC 761-1 3.4]system category CommunicationsAssociated systems Globalstar satellite communication system (User-
satellite)Date of last update to data 12/04/2000Relevant standardsICAO NoneRTCA MOPS NoneEUROCAE NoneARINC [ARINC 761]ITU NoneOther information sourcesSources NoneCoverage/operating volumeHorizontal GlobalVertical GlobalTransmission characteristicsbase frequency spectrum UnspecifiedITU frequency designator Unspecifiedlower limit 2483,5upper limit 2500Frequency limits additional info [ARINC 761 A3.4.1]central frequency 2491,75central frequency additional info Nonechannel spacing UnspecifiedChannel spacing additional info NonePower spectrum UnspecifiedPower spectrum defined pointsPower spectrum additional info NoneModulation type UnspecifiedModulation type additional info Nonetone frequency N/A
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 268
Logica
pulse width N/AUpper limitLower limitPulse width additional information N/Apulse repetition frequency N/AUpper limitLower limitTransmitter output power UnspecifiedTransmitter output power additional info NoneTransmitter antenna gain UnspecifiedTransmitter antenna gain graphTransmitter antenna gain additional info NoneEffective radiated powerEffective radiated power additional info NoneMinimum field strength within operating volume UnspecifiedMinimum field strength within operating volumeadditional info
None
power flux density Unspecifiedpower flux density additional info NonePolarisation state UnspecifiedPolarisation additional info NoneFrequency tolerance/stability UnspecifiedAdditional transmission information NoneReception characteristicsReception frequency band: Unspecifiedlower limit 2483,5upper limit 2500Frequency limits additional info Nonecentral frequency 2491,75central frequency additional info NoneITU frequency designator UnspecifiedReception spectrum defined points NoneReception spectrum graphReception spectrum additional info Nonereceiver pulse width N/AModulation method UnspecifiedModulation method additional information Nonereceiver minimum detectable signal at centrefrequency
G/T ratio is -26 dB/K
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 269
Logica
receiver minimum detectable signal additional info Nonereceiver antenna gain 0 dB average of 90%receiver antenna gain graph Omnidirectionalreceiver antenna gain additional info Noneeffective received power at antenna Unspecifiedeffective received power additional info NoneImmunity to in-band interference UnspecifiedImmunity to out-of-band interference UnspecifiedFrequency planning protection ratio (co-channel) UnspecifiedFrequency planning protection ratio (adjacentchannel)
Unspecified
Additional reception information NoneOther informationSupporting information: None
15.6.3 IRIDIUM SATELLITE COMMUNICATION SYSTEM (SATELLITE-USER)
System descriptionsystem type Iridium satellite communication system (Satellite-
user)Frequency band 1559 - 1626.5 MHzsystem overview/applications Iridium system supports safety and non-safety
packet and telephony services for both air-to-ground and ground-to-air.
Additional overview info [ARINC 761-1 3.2]system category CommunicationsAssociated systems Iridium (User-satellite)Date of last update to data 12/04/2000Relevant standardsICAO NoneRTCA MOPS NoneEUROCAE NoneARINC [ARINC 761 3.2]ITU NoneOther information sourcesSources NoneCoverage/operating volumeHorizontal GlobalVertical N/A
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 270
Logica
Transmission characteristicsbase frequency spectrum UnspecifiedITU frequency designator Unspecifiedlower limit 1616upper limit 1626,5Frequency limits additional info Nonecentral frequency 1621,25central frequency additional info Nonechannel spacing N/AChannel spacing additional info Iridium puts no constraint on number of co-
located channels. [ARINC 761 A2.1.3]Power spectrum UnspecifiedPower spectrum defined pointsPower spectrum additional info [ARINC 761 A2.2.2]Modulation type UnspecifiedModulation type additional info Nonetone frequency N/Apulse width N/AUpper limitLower limitPulse width additional information N/Apulse repetition frequency N/AUpper limitLower limitTransmitter output power UnspecifiedTransmitter output power additional info NoneTransmitter antenna gain UnspecifiedTransmitter antenna gain graphTransmitter antenna gain additional info NoneEffective radiated powerEffective radiated power additional info NoneMinimum field strength within operating volume UnspecifiedMinimum field strength within operating volumeadditional info
None
power flux density Unspecifiedpower flux density additional info NonePolarisation state UnspecifiedPolarisation additional info NoneFrequency tolerance/stability Unspecified
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 271
Logica
Additional transmission information NoneReception characteristicsReception frequency band: Unspecifiedlower limit 1616upper limit 1626,5Frequency limits additional info [ARINC 761 A2.2.2]central frequencycentral frequency additional info N/AITU frequency designator UnspecifiedReception spectrum defined points NoneReception spectrum graphReception spectrum additional info [ARINC 761 A2.2.2]receiver pulse widthModulation method UnspecifiedModulation method additional information Nonereceiver minimum detectable signal at centrefrequency
G/T ratio is -24.8 dB/K
receiver minimum detectable signal additional info Nonereceiver antenna gain 0 dBicreceiver antenna gain graph Omnidirectionalreceiver antenna gain additional info [ARINC 761 A2.4.2]effective received power at antenna Unspecifiedeffective received power additional info NoneImmunity to in-band interference UnspecifiedImmunity to out-of-band interference UnspecifiedFrequency planning protection ratio (co-channel) UnspecifiedFrequency planning protection ratio (adjacentchannel)
Unspecified
Additional reception information NoneOther informationSupporting information: None
15.6.4 IRIDIUM SATELLITE COMMUNICATION SYSTEM (USER-SATELLITE)
System descriptionsystem type Iridium satellite communication system (User-
satellite)Frequency band 1559 - 1626.5 MHzsystem overview/applications Iridium system supports safety and non-safety
packet and telephoney services for both air-to-
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 272
Logica
ground and ground-to-air.Additional overview info [ARINC 761-1 3.2]system category CommunicationsAssociated systems Iridium (Satellite-user)Date of last update to data 12/04/2000Relevant standardsICAO NoneRTCA MOPS NoneEUROCAE NoneARINC [ARINC 761 3.2]ITU NoneOther information sourcesSources NoneCoverage/operating volumeHorizontal 360 degVertical +8 to +90 degTransmission characteristicsbase frequency spectrum UnspecifiedITU frequency designator Unspecifiedlower limit 1616upper limit 1626,5Frequency limits additional info Nonecentral frequency 1621,25central frequency additional info Nonechannel spacing N/AChannel spacing additional info Iridium puts no constraint on number of co-
located channels. [ARINC 761 A2.1.3]Power spectrumPower spectrum defined pointsPower spectrum additional info [ARINC 761 A2.2.2]Modulation type UnspecifiedModulation type additional info Nonetone frequency N/Apulse width N/AUpper limitLower limitPulse width additional information N/Apulse repetition frequency N/AUpper limit
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 273
Logica
Lower limitTransmitter output power UnspecifiedTransmitter output power additional info NoneTransmitter antenna gain 0 dBicTransmitter antenna gain graph OmnidirectionalTransmitter antenna gain additional info [ARINC 761 A2.4.2]Effective radiated power 38.5Effective radiated power additional info EIRP = 38.5 dBm max, 22.5Minimum field strength within operating volume [ARINC 761 A2.1.1]Minimum field strength within operating volume Unspecifiedadditional info Nonepower flux density Unspecifiedpower flux density additional info NonePolarisation state UnspecifiedPolarisation additional infoFrequency tolerance/stability UnspecifiedAdditional transmission information NoneReception characteristicsReception frequency band: Unspecifiedlower limit 1616upper limit 1626,5Frequency limits additional info [ARINC 761 A2.2.2]central frequencycentral frequency additional info N/AITU frequency designator UnspecifiedReception spectrum defined points NoneReception spectrum graphReception spectrum additional info [ARINC 761 A2.2.2]receiver pulse widthModulation method UnspecifiedModulation method additional information Nonereceiver minimum detectable signal at centrefrequency
G/T ratio is -24.8 dB/K
receiver minimum detectable signal additional info Nonereceiver antenna gain Unspecifiedreceiver antenna gain graphreceiver antenna gain additional info Noneeffective received power at antenna Unspecifiedeffective received power additional info None
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 274
Logica
Immunity to in-band interference UnspecifiedImmunity to out-of-band interference UnspecifiedFrequency planning protection ratio (co-channel) UnspecifiedFrequency planning protection ratio (adjacentchannel)
Unspecified
Additional reception information NoneOther informationSupporting information: None
15.6.5 ICO SATELLITE COMMUNICATION SYSTEM (USER-SATELLITE)
System descriptionsystem type ICO satellite communication system (User-
satellite)Frequency band 1985-2015 MHzsystem overview/applications The initial system supports the transmission of
voice, circuit switched data, fax and a shortmessage service (SMS).
Additional overview info [ARINC 761-1 3.3]system category CommunicationsAssociated systems ICO satellite communication system (Satellite-
user)Date of last update to data 12/04/2000Relevant standardsICAO NoneRTCA MOPS NoneEUROCAE NoneARINC [ARINC 761]ITU NoneOther information sourcesSources NoneCoverage/operating volumeHorizontal UnspecifiedVertical UnspecifiedTransmission characteristicsbase frequency spectrum UnspecifiedITU frequency designator Unspecifiedlower limit 1985upper limit 2015Frequency limits additional info None
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 275
Logica
central frequency 2000central frequency additional info Nonechannel spacing UnspecifiedChannel spacing additional info NonePower spectrumPower spectrum defined pointsPower spectrum additional info [ARINC 761 A4.3.3]Modulation type GMSKModulation type additional info GMSK Modulation 36k symbol/s. [ARINC 761
A4.3.2]tone frequency N/Apulse width N/AUpper limitLower limitPulse width additional information N/Apulse repetition frequency N/AUpper limitLower limitTransmitter output power Maximum of 6.8dBWTransmitter output power additional info [ARINC 761 A4.1.1]Transmitter antenna gain 1dBicTransmitter antenna gain graphTransmitter antenna gain additional info [ARINC 761 A4.6.2]Effective radiated power 36.8Effective radiated power additional info Average EIRP 29 dBm. [ARINCMinimum field strength within operating volume UnspecifiedMinimum field strength within operating volumeadditional info
None
power flux density Unspecifiedpower flux density additional info NonePolarisation state UnspecifiedPolarisation additional info NoneFrequency tolerance/stability UnspecifiedAdditional transmission information NoneReception characteristicsReception frequency band: Unspecifiedlower limit 1985upper limit 2015Frequency limits additional info
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 276
Logica
central frequency 2000central frequency additional infoITU frequency designator UnspecifiedReception spectrum defined points NoneReception spectrum graphReception spectrum additional info Nonereceiver pulse width N/AModulation method GMSKModulation method additional information GMSK Modulation 36k symbols/s. [ARINC 761
A4.3.2]receiver minimum detectable signal at centrefrequency
Unspecified
receiver minimum detectable signal additional info Nonereceiver antenna gain 1dBicreceiver antenna gain graphreceiver antenna gain additional info [ARINC 761 A4.6.1]effective received power at antenna Unspecifiedeffective received power additional info NoneImmunity to in-band interference UnspecifiedImmunity to out-of-band interference UnspecifiedFrequency planning protection ratio (co-channel) UnspecifiedFrequency planning protection ratio (adjacentchannel)
Unspecified
Additional reception information NoneOther informationSupporting information: None
15.6.6 ICO SATELLITE COMMUNICATION SYSTEM (SATELLITE-USER)
System descriptionsystem type ICO satellite communication system (Satellite-
user)Frequency band 2170-2200 MHzsystem overview/applications The initial system supports the transmission of
voice, circuit switched data, fax and a shortmessage service (SMS).
Additional overview info [ARINC 761-1 3.3]system category CommunicationsAssociated systems ICO satellite communication system (User-
satellite)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 277
Logica
Date of last update to data 12/04/2000Relevant standardsICAO NoneRTCA MOPS NoneEUROCAE NoneARINC [ARINC 761]ITU NoneOther information sourcesSources NoneCoverage/operating volumeHorizontal GlobalVertical N/ATransmission characteristicsbase frequency spectrum UnspecifiedITU frequency designator Unspecifiedlower limit 2170upper limit 2200Frequency limits additional info Nonecentral frequency 2185central frequency additional info Nonechannel spacing UnspecifiedChannel spacing additional info NonePower spectrumPower spectrum defined pointsPower spectrum additional info [ARINC 761 A4.3.2]Modulation type BPSK and QPSKModulation type additional info QPSK and BPSK Modulation 18k symbols/s/
[ARINC 761 A4.3.2]tone frequency N/Apulse width N/AUpper limitLower limitPulse width additional information N/Apulse repetition frequency N/AUpper limitLower limitTransmitter output power UnspecifiedTransmitter output power additional info NoneTransmitter antenna gain 1dBic
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 278
Logica
Transmitter antenna gain graphTransmitter antenna gain additional info UnspecifiedEffective radiated power UnspecifiedEffective radiated power additional info NoneMinimum field strength within operating volume UnspecifiedMinimum field strength within operating volumeadditional info
None
power flux density Unspecifiedpower flux density additional info NonePolarisation state UnspecifiedPolarisation additional info NoneFrequency tolerance/stability UnspecifiedAdditional transmission information NoneReception characteristicsReception frequency band: Unspecifiedlower limit 2170upper limit 2200Frequency limits additional info Nonecentral frequencycentral frequency additional info N/AITU frequency designator UnspecifiedReception spectrum defined points NoneReception spectrum graphReception spectrum additional info Nonereceiver pulse width N/AModulation method BPSK and QPSKModulation method additional information QPSK and BPSK Modulation 18k symbol/s.
[ARINC 761 A4.3.2]receiver minimum detectable signal at centrefrequency
G/T ratio is -23.8 dB/K
receiver minimum detectable signal additional info [ARINC 761 A4.1.2]receiver antenna gain 1dBicreceiver antenna gain graph Omnidirectionalreceiver antenna gain additional info [ARINC 761 A4.6.1]effective received power at antenna Unspecifiedeffective received power additional info NoneImmunity to in-band interference UnspecifiedImmunity to out-of-band interference UnspecifiedFrequency planning protection ratio (co-channel) Unspecified
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 279
Logica
Frequency planning protection ratio (adjacentchannel)
Unspecified
Additional reception information NoneOther informationSupporting information: None
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 280
Logica
16 ANNEX D: UMTS ARCHITECTURE
In order to understand the UMTS interfaces with the relevant detail we begin with a highlevel view of the logical elements. The following figure shows the functional UMTSarchitecture as defined by release 5 of the 3GPP standards.
BSS
BSC
RNS
RNC
CN
Node B Node B
IuCS IuPS
Iur
Iub
USIM
ME
MS
Cu
Uu
MSC serverSGSN
Gs
GGSN GMSCserver
Gn HSS (HLR,AuC)
Gr
GcC
D
E
EIR
F Gf
GiPSTN
IuCSIuPS
VLR B
Gp
VLR G
BTS BTS
Um
RNC
Abis
SIM
SIM-ME i/f or
MSC serverB
PSTN
cell
CS-MGW CS-MGW
CS-MGW
Nb
Mc Mc
Nb
PSTN PSTN
Nc
Mc
A Gb
Go
Nc
3GPP Release 5
Legend:Bold lines: interfaces supporting user traffic;Dashed lines: interfaces supporting signalling.NOTE 1: The figure shows direct interconnections between the entities. The actual links may be provided by an
underlying network (e.g. SS7 or IP): this needs further studies.NOTE 2: When the MSC and the SGSN are integrated in a single physical entity, this entity is called UMTS
MSC (UMSC).NOTE 3: A (G)MSC server and associated CS-MGW can be implemented as a single node: the (G)MSC.NOTE 4: The Gn interface (between two SGSNs) is also part of the reference architecture, but is not shown for
layout purposes only.
Figure 16-1; The UMTS Network as Defined in Release 5 of the 3GPP Specifications.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 281
Logica
The UMTS network is divided into two parts, shown in the figure, the circuit switcheddomain and the packet switched domain. The interfaces to these are represented in the figureby �PSTN� for the CS domain and �Gi� in the PS domain. A third interface may beconsidered to be the IP Multimedia Subsystem (IMS) although this is not shown in the figure.The IMS uses the PS network as a bearer for multimedia signalling and traffic. The IMS shallbe discussed in more detail later in this section. We do not discuss UMTS signalling trafficfurther, as it is not relevant to the interoperability with Galileo at this level.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 282
Logica
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 283
Logica
17 ANNEX E: SECONDARY SYSTEMS OVERVIEW
17.1 BLUETOOTH
Bluetooth is a Radio Frequency specification for short-range, point-to-point and point-to-multi-point voice and data transfer. Bluetooth will enable users to connect wide range ofcomputing and telecommunications devices without the need for proprietary cables that oftenfall short in terms of ease-of-use.The uses of the 2.4 GHz ISM frequency band ensures Bluetooth devices can be usedworldwide.Bluetooth technology supports simultaneous transmission of both voice and data for multipledevices in a range from 10 to 100 meters depending on the device class. Up to 8 data devicescan be connected in a piconet, and up to 10 piconets can exist within the 10-meter area. Eachpiconet supports up to 3 simultaneous full duplex voice devices (CVSD).The Piconet configuration supports up to eight connected devices where one acts as a masterand all others, slaves; multiple piconets are able to connect to each other via the masterdevices thus increasing the total number of connected devices beyond eight.The gross data rate is 1Mb/s, but the actual data rates are 432Kbps for full duplextransmission, 721/56Kbps for asymmetric transmission, and 384 Kbps for TMS2000transmission. A Time-Division Duplex scheme is used for full-duplex transmission.In the Bluetooth specification there are three classes of radios, which are characterized bytheir output power. Class 1 is specified to have a maximum transmit power of +20 dBm (100milliwatts). Class 2 has a maximum transit power of +4 dBm (2.5 milliwatts). Class 3 has amaximum transmit power of 0 dBm (1 milliwatt). The Bluetooth specification limits the radiooutput power exactly to that actually required. For instance, the receiving radio indicates thatit is only a few meters away; the transmitter immediately modifies its signal strength to suitthe exact range.Bluetooth devices are able to communicate to other devices within a ten meter range; limitingrange to ten meters helps reduce power requirements, making Bluetooth a practicaltechnology for a broad range of battery operated devices like notebook computers and cellularphones. Range of ten meters is adequate for all wireless personal area networkingapplications. Bluetooth has been designed to minimize other burdens on Bluetooth enableddevices such as cost and power consumption.Bluetooth does not require line of sigth between devices to establish a connection, and thisfeature provides greater flexibility and ease-of-use over wireless technologies like IrDA,which require a line of site between devices.The Bluetooth radio uses a fast acknowledgement and frequency hopping transceiver tocombat interference and fading. It uses a frequency hopping spread spectrum technique.Spectrum spreading is accomplished by frequency hopping up to 1600 hops per second on 79channels between 2.402 GHz & 2.480 GHz. Bluetooth radio modules avoid interference fromother signals by hopping to a new frequency after transmitting or receiving a packet.Compared with other systems operating in the same frequency band, the Bluetooth radiotypically hops faster and uses shorter packets. This makes the Bluetooth radio more robustthan other systems.
Bluetooth positioning functionalityAlthough Bluetooth is a communication system, it can also work as positioning system able toprovide the position of Bluetooth devices in typical a WPAN (Wireless Personal AreaNetwork) scenario. A Bluetooth device, moving or fixed, can act as location service client in
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 284
Logica
order to get its position with the support of the other devices present in the same piconet. Theclient device can exploit its communication capability in order to retrieve positioninginformation of the surrounding Bluetooth devices and, on the basis of these multiple positiondata can perform the position calculation. More position data are available from thesurrounding devices (e.g. position of the neighbour device, ranging measurements) better willbe the position accuracy calculated. Position data of the surrounding devices andmeasurements of the received signal strength are the relevant information exploited by theposition service-client, in order to perform its computation. It is worth to underline that, forclass 3 devices, 10 m of range is the worst position accuracy, as the client knows at least theprecise position of one of the surrounding device, that is at least at 10 m of range (maximumcommunication range between two Bluetooth device). Signal strength measurements todetermine the precise distance between the client and an identified device is not a reliablesolution due to the dependence on changeable environment.The problem with getting a really accurate fix is that the slightest alteration of theenvironment (multipath, people, movement, objects) will alter the signal path and thusprovide differing readings even though the client being measured is currently not moving
Bluetooth infrastructure will be deployed and cover large indoor (shopping malls, stations,airports) and urban areas.The Location feature are usable both in devices with no other positioning capability (e. g. for:Laptops, notebooks, PDAs, tags etc) and devices with GPS and/ or cellular positioningcapability, to improve performance indoors and in built up locations.
In General principle, as Bluetooth is a short-range system, even the simple knowledge of the�beacon- ID� position is useful. A Bluetooth device determines its own position from one(cell- id type) or more (interpolation or TDOA) nearby devices whose positions are known.The position of the device will be equal to �source position, +/ - (accuracy + estimatedrange)�. Nearby devices may be pre- programmed 'beacons' and have their own positioningcapability (GPS).Anyway, triangulation solution exploiting the position of multiple location-aware devices canimprove the performance.The normal procedure to look for a positioning service in Bluetooth starts by establishing aradio link between two devices, which also lets the two devices synchronize with the chosenfrequency hopping scheme.The next step is to establish a connection between the link managers in order to get a reliableconnection, and finally a connection to the service discovery protocol can be made. A devicecan now search for the positioning service with use of the unique identifier corresponding toit. A device with the positioning server software installed, will answer the service searchrequest with necessary information to continue with the connection. With the gainedinformation a connection can be made which will allow transfer of a position from the serverto the connected device.Every Bluetooth unit has a unique number that can be used to identify a specific device,which means a device that does not have any software for positioning installed, can stillfunction as a positioning source. The unique number for the Bluetooth unit can be stored in adatabase together with the position of the device. A device with no position server softwareinstalled will answer negatively upon a position service search request. The searching devicewill then try to connect to the database and look for a position using the unique number it gotwhen connecting as search key.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 285
Logica
The ability to create connections to other Bluetooth units opens up the possibility for a deviceto share a position gained from another positioning systems with surrounding devices, whichare not able to support positioning capabilities.
17.2 WLAN
Wireless LAN (WLAN) is a IEEE standard 802.11 based on radio frequencies 2.4 GHz (andothers). Two main radio coding technologies, frequency hopping (FH) and Direct Sequence(DS), are used. Data transmission rates are 1.0, 2.0, 5.5 and 11 Mbps. Cell radius is from fewtens of meters indoors to some hundred meters outdoors (officially 300 m).Wireless LAN networks are designed for very short range communication (max 300 m).When comparing this technology with telecom world (where cell radius can be over 10 km),the mobility of WLAN world is quite different, since the WLAN user does not move with thesame pattern and same movement scenario like GSM users.WLAN architecture is based on a number of Access Points (AP) connected to a core network.The mobile terminal is associated with one AP. Two basic mode of operation are foreseen:Centralised Mode (where AP are connected to a core Network that serves the Mobile user anda Direct Mode, in which the controller does not need to be connected :to the core network, butcan be directly linked to another mobile terminal.WLAN positioning technologies are based on TOA and TDOA techniques and, as in theGSM case, can be network based or handset based. In order to calculate the position of themobile terminal, the time offset from more than three Geolocation Base stations (GBS) thatcan be implemented within the AP or in separated Geolocation Reference Unit (GRP) have tobe calculated. Time measurements are derived from the round-trip delay of MAC frames (2ms each). It has to be pointed out that, in order to measure TOA from different APs, forcedhandover are needed. This imply the need of significant coverage overlap and propergeometric distribution of APs. TDOA measurements can be performed using a reference time(coming from an AP) and the time differences of the MAC burst sent by the mobile to twodifferent GRPs through a Direct Mode connection. Also signal strength from APs can be usedas positioning method.
17.3 UWB
The technology, which has been used by the military for more thantwenty years for highly secure communications, became declassifiedin the last decade. Ultra-wideband (UWB) transmission, could lead tothe development of technology with throughput capacity far superiorto 802.11b wireless LANs. In turn, 802.11b and short-wave Bluetoothradios could be replaced with UWB products that offer lower beaconsand terminal costs and higher bandwidth. The FCC has currentlyapproved the technology for use in three main types of applications, and has stipulated astandard signal power level for each. The three kinds of applications are: (1) ImagingSystems, such as for sensors used in geological surveys; (2) Vehicle Radar Systems, such assensors to help prevent collisions; and (3) Communications and Measurement Systems, forwireless data communications between electrical household appliances and portable devices.UWB transmissions do not involve carrier signals (pulse are transmitted at baseband), andthus eliminate crowding. Furthermore, UWB transmitters and receivers have relatively fewconstructions, operational, and maintenance needs. The power requirements are also quitesmall, in the 50- to 70-milliwatt range. In addition, since pulse signals blend so easily intobackground electronic noise, UWB transmissions are well protected.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 286
Logica
Most important examples of UWB applications are:� high-speed (greater than 20 Mbps) wireless local-area networks (LANs) and wide-areanetworks,� altimeter and obstacle avoidance radios for commercial aviation,� collision avoidance sensors for automobiles,� intelligent transportation systems, electronic signs,� smart appliances, intrusion detection radar and� industrial radio frequency monitoring systems
UWB wireless technology will not have an impact on demand for the long awaited Bluetoothwireless services, according to analysts, because UWB does not even target the same marketdue to the fact that for many applications, especially those that Bluetooth targets, even10Mbps is more than sufficient.UWB devices can beused to measure bothdistance and position.UWB positioningsystems could providereal time indoor andoutdoor precision tracking for many applications. Some potential uses include locator beaconsfor emergency services and mobile inventory, personnel and asset tracking for increasedsafety and security, and precision navigation capabilities for vehicles and industrial andagricultural equipment.
17.4 TETRA
TErrestrial Trunked RAdio (TETRA) is the modern digital Private Mobile Radio (PMR) andPublic Access Mobile Radio (PAMR) technology for police, ambulance and fire services,security services, utilities, military, public access, fleet management, transport services,closed user groups, factory site services, mining, etc.TETRA uses Time Division Multiple Access (TDMA) technology with 4 user channels onone radio carrier and 25 kHz spacing between carriers. This makes it inherently efficient inthe way that it uses the frequency spectrum. For emergency systems in Europe the frequencybands 380-383 MHz and 390-393 MHz have been allocated for use by a single harmonizeddigital land mobile systems by the ERC Decision (96)01. Each of the ten radio carriers isdivided into a continuous cycle of twelve time-slots corresponding to a basic channel of 32kbps user traffic and 6.4 kbps signalling traffic. The average transmitting power is about 10mW, which results to an effective indoor range of 20-100 metres and 300 metres outdoors perbase station.
For civil systems in Europe the frequency bands 410-430 MHz, 870-876 MHz / 915-921MHz, 450-470 MHz, 385-390 MHz / 395-399,9 MHz, have been allocated for TETRA by theERC Decision (96)04.The TETRA standard currently defines a standard codec which employs ArithmeticCodebook Excited Linear Prediction (ACELP) technology. This codec was selected in 1994as a result of a competition between codecs submitted by several manufacturers. This codecprovides robust operation in typical TETRA operational scenarios for public safety andshared system use.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 287
Logica
Inter-working with Other Systems � the rapid take-up of wireless communications equipmentincreases the likelihood of communications between users of different systems; hence a next-generation TETRA codec should provide superior inter-working performance with otherstandards such as GSM and UMTS.TETRA offers the option to interface numerous peripherals and applications such asrecording devices, Private Branch Exchange (PABX) equipment, GPS, cartography,administrative data processing.
17.5 DECT
DECT is the ETSI standard for cordless telephony systems. It was originally used only inEurope, but during the past years it has achieved worldwide acceptance. It works on thededicated radio frequency between 1.880-1900 MHz. DECT uses TDD (Time DivisionDuplex) and TDMA on the air interface multiplexing. On one channel there can be 24TDMA slots which results in a maximum of twelve users, because of the use of TDD. Themaximum range of DECT is 300 m and it offers 1.152 Mbps gross data rate.DECT system consists of base stations called DECT Fixed Parts (FP) and user devices calledDECT Portable Parts (PP). The basic standard covers only the interface between FP and PP,but there are profiles that define access to different types of network, such as GSM or ISDN(Integrated Services Digital Network) network. Handover process has been defined to DECTso that when a PP moves from the radius of one FP, the connection is handed over to the newFP on which radius the PP is.
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 288
Logica
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 289
Logica
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 290
Logica
18 ANNEX F: OVERVIEW OF PRACTICAL RESULTSAVAILABLE FOR GPS USE
For what follows, results taken from GPS studies are presented using examples coming fromaeronautical world. This is due to the fact that the risk analysis has been in priority conductedfor aeronautical applications. Thus, results do exist today and are published.
Nevertheless, the statements and recommendations presented hereafter are most of the timeapplicable to other applications (rail, marine or road applications)
18.1 SIMILARITIES BETWEEN GPS AND GALILEO
GPS and GALILEO are both radio-navigation satellite systems using MEO constellations,transmitting signals on the same (L1, E5) or close frequency bands (L2, E6). The powerreceived by a user is roughly the same. The code frequency width is in a ratio lower than 10.Thus, for all these reasons, an interference due to non- navigation systems operations willhave similar effects on both GPS and GALILEO.
As GALILEO features makes in general more robust than GPS (especially on L1 whereGALILEO received power is planned to be higher than GPS one and where its widerfrequency occupation enhance jamming robustness), we can conclude that if GPS is notaffected by Non-Navigation system�s Emissions, GALILEO should not be either.
In that way, measures campaign already conducted in the frame of GPS studies give us veryinteresting information on what could be a �real� case of GALILEO behaviour, facing thesame environment.
In particular, the following statements have to be kept in mind:
• Impact of WB interference on the 1dB-signal to noise degradation threshold:identical on GPS and GALILEO
• Impact of NB interference on the 1dB-signal to noise degradation threshold:identical between L5gps and E5a/E5bgalileo, 10dB better for E5galileo than forL1gps and 6 dB better for L1galileo than for L1gps
• Performances limits: same order of magnitude for L5/E5, better for L1galileo thanfor L1gps (power)
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 291
Logica
18.2 MAIN RESULTS
The target of this paragraph is to give an overview of the results obtained in the frame ofseveral GPS studies. This is done to give comparison elements and to illustrate what wouldcertainly be the �corresponding� operational results for GALILEO.
GPS Risk Assessment Study Final Report – 1999 – John Hopkins University - § 5.1.1:
“(…) There have been very few reports of GPS outages caused byunintentional interference, so this portion of the study wasbased on evaluating the impact of potential interference sourceslisted in RTCA/D0-235. Of these, only commercial very highfrequency (VHF) radio, over-the-horizon (OTH) military radar, andbroadcast television were considered possible interferencethreats requiring further analysis. Detailed characterizations ofthe military radar signals were not available for analysis, butit was determined that there are only a few widely dispersedsystems and they use relatively narrow antenna beams. For thesereasons, and because there have been no reported problems fromthese emissions, they are not considered a significant risk.However, further review is required to confirm this expectation”
In addition, the outages reports analysed only concern 4 types of potential interferencesources :
• TV broadcasting (Channel 66, USA)• Military spurious communications• FM Transmitter (Netherlands)• VHF communications (VHF onboard, many cases)
But no report has been identified with systems such as GSM, UMTS, Bluetooth, WLAN orDECT.
18.3 MAIN RECOMMENDATIONS ISSUED FROM GPS STUDIES
The recommendations issued from GPS studies can be summarised into the three followingstatements:
• Change the Non-Navigation systems specification for spurious emissions• Achieve operational measures to quantify the �real� spurious emissions in order to
perform a risk analysis using statistics estimations• Put in place a monitoring and alert network in charge of detecting hazardous events
18.3.1 SPECIFICATION CHANGE
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 292
Logica
Preliminary Draft – RTCA special committee 159, Working Group 6 – 24/08/01 – §9.3 :
“(…) FAA and the aviation industry should request that the FCCmodify its current rules pertaining to inadvertent spuriousemissions from all new electronic equipment, to incorporatespecial provisions for the GPS bands. Limits there should be muchstricter, say no more than –75dBm at 3 meters within thepassbands of L1, L2 and L5.”
RTCA DO-194 prepared by special committee 159, Working Group 6 - §9.2 :
“(…) Many of these FCC specifications were adopted some time agoand do not represent current technology. The U.S. is a leader inlimiting unwanted emissions. The ITU-R is now attempting toestablish some world-wide standards for unwanted emissions – butthe current effort is actually at an earlier stage, i.e. tryingto standardize definitions and measurements techniques.”
GPS Risk Assessment Study Final Report – 1999 – John Hopkins University –Appendix K :
“(…) With regard to unintentional interference, current FCCrequirements do not ensure sufficient protection of GPSnavigation signals. It is recommended that the current spectrumcontrol practices be expanded to include protection for the GPSsignals.”
18.3.2 MEASURES AND RISK ANALYSIS
When reading the few outages reports, when seeing the delta between theoretical estimationsand reality and when taking into account already performed measures campaigns, it seemsthat the real spurious emissions levels are far to be as high as indicated in the Non-Navigations system�s specifications.Thus, a statistical approach can be used taking into account both existing measures andpresence probability of incriminated equipment�s, in order to give a more realistic estimationof the risk and the problem.
18.3.3 MONITORING NETWORK
This solution seems to offer the advantage to protect user against hazardous events, even ifthere are statistically of a very low probability.
GPS Risk Assessment Study Final Report – 1999 – John Hopkins University –Appendix J :
“APPENDIX J
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 293
Logica
JAMMER DETECTION
A possible mitigation factor often cited against bothunintentional and intentional interference is to provide a meansfor emitter detection and location. Because detection must beavailable at all times, it is assumed that the detection devicewould be located in the airport area at the highest possiblelocation, most likely the airport tower.
A short study was conducted to determine the sensitivity of lowcost of-the-shelf devices. Assuming a 1-watt emitter, Figure J-1shows that for reasonably sized antennas (<1m), a low-poweremitter can be detected to well over 100 miles. To maintain areasonably sized beamwidth for location purposes, an antennadiameter of 0.5 meter could be selected. A complete system designwas not pursued, but this example illustrates that technology isreadily available to detect low power signals at large distances.“
Other publications also address this topic :
Location of GPS interference using antenna adaptative technology – K. Bond, J.Brading, Raytheon Systems Ltd, UK – ION GPS 2000 Proceedings
Generalized interference detection and location system – K. Gromov, D. Akos, S.Pullen, P. Enge, B. Parkinson, Standford University – ION GPS 2000 Proceedings
On the other hand, it should be noted that this kind of �monitoring� system can only be usedfor a relatively size-limited area, for which the risk has been identified as being high (forexample, an airport for approaching and landing phases).
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 294
Logica
END OF DOCUMENT
GALILEIREF :
DATE :
Gali-TPZ-DD08118/10/2002
System Interoperability Analysis Non-Nav ISSUE : 2.2 PAGE: 295
Logica
DOCUMENT DISTRIBUTION
From : capuaProject Acronym : GALILEIProject Name : Galileo System AnalysisTitle : System Interoperability Analysis Non-NavIssue : 2.2Reference/identification : Gali-TPZ-DD081Date : 18/10/2002Page Number : 295File : Dd081v22.docClassification : REWBS : E.3.BContract : GMA1-42031-2001-SI2.324077Type of Document : DDTemplate Name : galilei_deliverables_v4.dot
