GALILEO Research and Development Activities Second Call Area 1B Galileo Mass Market Receiver Development Statement of Work Rue du Luxembourg, 3 B 1000 Brussels Tel +32 2 507 80 00 Fax +32 2 507 80 01 www.galileoju.com - 1 -
TABLE OF CONTENT 1 INTRODUCTION...3 1.1 1.2 CONTEXT...3 OBJECTIVES...4 1.3 ACRONYMS...6 2 WORK DESCRIPTION...6 2.1 STUDY LOGIC...7 2.2 MANAGEMENT AND SUPPORT TO EXTERNAL COORDINATION...7 2.2.1 Management...8 2.2.2 Support to external coordination...8 2.2.2.1 Coordination with other GJU project 2 nd call...8 2.2.2.2 Coordination with other activities...9 2.3 TECHNOLOGICAL DEVELOP MENT...10 2.3.1 Core technology investigation... 11 2.3.2 Development of the HW/SW component of receiver... 14 2.3.3 Simulator, test and validation tool... 15 2.4 AWARENESS...15 3 DELIVERABLES... 15 3.1 INPUT...15 3.1.1 From GARDA project... 15 3.1.2 From other studies... 16 3.2 OUTPUT...16 4 APPENDIX A: GRANADA SW RECEIVER... 16 4.1 INTRODUCTION...16 4.2 GRANADA REQUIREMENTS AND FUNCTIONALITY...16 4.3 SUITE DESCRIPTION...17 4.3.1 Bit-True GNSS SW Receiver Simulator I (Matlab/Simulink):... 17 4.3.2 Bit-True GNSS SW Receiver Simulator II (C-code version)... 18 4.3.3 GNSS Environment and Navigation Simulator... 18 4.4 CONCLUSION...18 5 APPENDIX B: GMCS: A MONO-CHANNEL SIGNAL SIMULATOR... 19 5.1 GMCS OVERVIEW...19 5.2 GMCS MAIN FUNCTIONAL CHARACTERISTICS...20 5.3 GMCS MAIN OPERATIONAL CHARACTERISTICS...21-2 -
1 INTRODUCTION The Galileo user receiver represents a key technology and is at the heart of the user segment. It is the main physical interface between the system and the user. It transforms the Galileo Signal-in-Space into services for the citizen. As the majority of Galileo users will be Galileo Open Service users, utilising massmarket type of receiver, a specific emphasis is brought to the development of the specific technologies for the mass-market receiver and its specific constraints. Combining the positioning services with other services (such as communication, map visualisation, guidance or others) and physically integrating the user receiver into a user terminal, the final user will have in hand the user terminal that delivers a full set of services. In the second call, receiver development activities are foreseen in different Statement of work. A first category of activities is foreseen in the different receiver development Statement of Work focusing on the inside -receiver technology. A part of the User Community Statement of Work focuses on the integration of the receiver in the user platform (the user terminal) and the combination of the positioning functionalities offered by the receiver with other functionalities. The link between the Receiver dedicated activities and User Community activities will be further detailed in the work description of this Statement of Work. 1.1 Context The past market studies have clearly identified certain key markets for Galileo in term of number of users. The two main domains are the Location Based Services (LBS) and the Car navigation. Both are identified as potential users of the Galileo Open Service. The receivers used by these two user communities share some common specifications and are generally classified under the term of mass-market receivers. The main characteristics of this type of receivers are their low size, their low cost and their energy consumption. The low-cost aspect is partly a consequence of the expected large quantity production of this type of receivers but represents also an initial constraint, imposed by the user terminal manufacturers or system integrators, that drive the design of this type of receiver. The mass-market type of receivers will probably also be used in other applications domain such as leisure, hand-held receiver, assets management etc. The strong relation between positioning and telecommunication is also a key characteristic of the majority of applications developed in these categories of users communities. Then all the synergies that can be implemented at user level between - 3 -
the GNSS system and other communication system (especially terrestrial) are a key aspect of this type of receiver. 1.2 Objectives Within this second call, the Galileo Joint Undertaking decides to support the development of receiver technologies in order to: - support the Research and Development activities within the industry and research institutes towards the development of Galileo mass-market receiver technologies and to - facilitate the availability of Galileo mass-market receiver prototypes at an early stage The availability of receivers at an early stage is a key element for the market penetration of Galileo and thus for the Galileo program. The broadcasting of the first representative Galileo signal in space (foreseen at the In- Orbit Validation phase of the Galileo Program) will mark the end of the development phase and the start of the deployment of the full Galileo constellation. For the users, this moment is a key milestone. It will allow them using in real environment the receiver and start the introduction of the Galileo services in different applications and services. For receiver manufacturers, it will be then also an important milestone to position them on the market by offering in an early stage Galileo capabilities in their receivers. It is foreseen that a lot of different partners worldwide will express their willingness to have Galileo/GPS receivers when the first signal will be available in order for them to: 1. start testing their applications or services platform including Galileo: this will be a key objective for the different service providers; 2. offer to the final user or to the system integrators the possibility to test directly a receiver including Galileo capabilities (or having the possibility to be easily upgraded to benefit from Galileo) and so avoiding a delay in their investment for GNSS receivers. The availability of a sufficient number and a sufficient choice of Galileo/GPS receivers at an early stage is a key element for the penetration of Galileo services in the market and represents a challenge for GNSS industries worldwide. The objective of this second call is then to support the development of Galileo/GPS prototypes on a wide scale. This will be accomplished through the partial financing, in the second call, of several receiver development initiatives and this for different market targets. - 4 -
The objective of the project is not necessarily to have prototypes available at the end of the project but to allow sufficient investigations and developments in the different receiver technologies to allow industries, research institutes and other partners to proceed with the development of prototype receivers and then to their commercialisation as soon as possible. In this Statement of Work, the objectives of the proposed development activities focus on the support to the development of receiver technologies answering to the specific requirements of the Galileo Open Service users. It represents also the occasion for industries and researchers to initiate prototyping activities and to propose development in related technologies such as indoor GNSS, assisted GNSS, Radio Defined Receiver, miniaturised single antenna, low-cost front end, The technological evolution in the field of mass-market GNSS receivers is fast. The life cycle of a product is relatively short and it follows a similar trend than other massmarket technology such as the mobile phone or information technologies. It is then expected that the work conducted under this SoW will put a major emphasis on innovative solutions and on research that will facilitate the emergence of innovative solution later on. This project gives to the consortium the possibility to perform part of the activities foreseen in its own receiver development plan. The links between the activities performed in the frame of this project and the activities foreseen by each partner in their own development plan are strongly encouraged. The project shall be in-line with the Galileo receiver development plans of the receiver manufacturers, research institutes and other partners of the consortium. The receiver pre-development activities financed under the first call of the Galileo research and development activities (GARDA project) will support the second call activities by offering the possibility to use some tools and technologies produced in the frame of this study. - 5 -
1.3 Acronyms EC EGNOS ESA EU FP FR FOC GJU GNSS GOC GPS GSTB IOV IPR KO KOM MRD MTR PPP SIS SIS ICD SOW European Commission European Geostationary Overlay Service European Space Agency European Union Framework Programme Final Review Full Operational Capability Galileo Joint Undertaking Global Navigation Satellite System Galileo Operating Company (or Concessionaire) Global Position System Galileo System Test Bed In Orbit Validation Intellectual Property Right Kick-Off Kick-Off Meeting Mission Requirements Document Mid Term Review Public-Private Partnership Signal In Space SIS Interface Control Document Statement of Work 2 WORK DESCRIPTION As described in the introduction, the contractor has a certain margin to perform the work following its own views on the most appropriate research and development activities in the field of mass-market receiver. However, in the following paragraph guidelines and requirements for these development activities are given. The work description is organised into three main sections: 1. the study logic which describes the main frame of the project and its link with the other activities 2. the management and coordination section, which describe the expected type of management and reporting process and the way the links shall be implemented 3. the technological section, which includes objectives and requirements of the central work to be accomplished in the frame of the project. - 6 -
This technological section is divided into three tasks a. mass-market receiver core technology investigations which have a clear research nature b. the HW/SW components activities, which tend to the development of prototype receiver. c. the simulator, test and validation tool development, which is optional and depends on the proposed testing and validation plan of the consortium. 2.1 Study logic The activities performed shall be in line with the logic of the overall development plan. Schedule The overall activities shall last 2 years. The management and coordination activities shall last all along the project duration. The core technologies investigation can be made all along the project duration. The prototype development activities shall be performed in different phase (specification, design, development ). The simulator, test and validation tools development, if any, shall start as soon as possible in order to have these tools available for the core technologies investigation and for the test and validation of the developed components. Link with first call The activities performed in the GARDA project are: - consolidation of a development plan - development of a software receiver to test core technologies - development of hardware component, which shall be seen as a way to make development and investigation of core technologies that cannot be fully evaluated through software. The outcome of the GARDA project, initiated at the beginning of 2004 and lasting until Autumn 2005, will support the development made in the frame of the second call. 2.2 Management and support to external coordination The management and coordination activities are described hereunder. The management part focuses on the work to be performed internally to the consortium and the reporting to the GJU. It includes all the basic management activity for R&D activities (internal coordination, reporting, interface ). The support to external coordination focuses on additional activities that will be required by the GJU to implement the necessary coordination between different consortia dealing with common issues. - 7 -
2.2.1 Management This activity consists in providing the overall management for the entire contract. The activities to be performed as a minimum are: Technical project coordination Contractual management Organisation and coordination of internal communication flow Documentation management Tracking project status Establish and maintain travel plan Review and verification of deliverables Organisation of progress meetings (calling notice, agenda, chairing and reporting) Organisation of reviews Identify needs for interfaces with external entities Ensure coordination between the different activities as necessary The contractor shall report on its activity every 3 months. 2.2.2 Support to external coordination In addition to the identification of interfaces with external activities (mentioned in the management part), a specific emphasis is put on the support to external coordination. This project will be performed in parallel with other activities of the Galileo Program. The contractor shall support and facilitate the coordination between the work performed in the frame of this Statement of Work and the work performed in other contracts. These coordination activities, under the steering of the GJU, are mainly on two folds: 1. support to coordination effort required between different projects launched in the frame of the Galileo Research and Development activities (1 st, 2 nd and 3 rd call) 2. support to coordination with other activities performed in the frame of the Galileo program. 2.2.2.1 Coordination with other GJU projects 2 nd call LBS and Road As mentioned before, the mass-market type of receiver is mainly targeting the LBS and the Road sector. Both sectors are the subject of two specific activities in the second call. Strong links exist between the service introduction in these sectors and the development of the mass-market type of receiver. Coordination activities shall then be performed between the current activity and the LBS and Road User Community project. - 8 -
Under the supervision of GJU, the contractor shall interact with the consortia in charge of the LBS User Community and Road User Community in order to - give some input to this project for what concern the receiver investigation. - assess the specifications concerning the user terminal investigated in the User Community projects. Other receiver development activities Synergies can also be found through discussions among the different consortia in charge of the receiver development activities (mass-market, professional and safety of life) planned in the first and in this second call. The contractor shall interact, on the GJU request, with other consortia in charge of receiver development in the frame of the 1 st or 2 nd call of the Galileo Research and Development project. Effort The interaction between the consortia of the different projects will be made under the supervision of GJU and will take the form of common workshops or participation to reviews. The contractor shall, at least: - organise one workshop - participate to workshops organised by the other consortium (at least 4 other workshops) Date and details of the workshop organisation will be decided jointly with the GJU. The objective of each workshop is to provide GJU with consolidated views on some particular topics that will be defined by the GJU (impact on mission evolution on receiver, standardised interface ) The amount of required effort for the coordination between this project and the other GJU 2 nd call projects shall not exceed a total of 4 man-months. 2.2.2.2 Coordination with other activities Context The objective of this project is to support the development of the user receivers in view of having prototype available at the IOV phase (when users and service providers will start using it in real environment). During this phase the Galileo System will be tested and validated using different tools under development in the frame of the ESA GalileoSat project. During this validation phase, some external feedbacks on the system performances and on the first signals transmitted during the IOV could contribute to the validation of the Galileo system and mission. The receiver developers will of course be in an ideal position, while testing their prototypes, to give some useful feedbacks. Activities - 9 -
In the frame of this contract, the contractor shall contribute to the preparation of these external feedbacks to the validation phase of Galileo. This activity shall be based upon its overall receiver development plan (included in the proposal) and more specifically on the activities planned during the IOV phase. The contractor shall - develop in more detail the part of its development plan (presented in the proposal) which will coincide with the IOV phase of the Galileo Program. - indicate what could be its potential contribution to the validation phase of the Galileo System and how he envisaged providing its feedback or the feedbacks of its future consumers to the Galileo Operating Company. Effort The required effort for this activity shall not exceed 2 man months. 2.3 Technological development Context The core of the project aims at developing the different technologies related to the mass-market Galileo/GPS receiver in order to contribute to the overall objective of having high-quality and competitive Galileo/GPS receiver (prototypes and products) for the mass-market type of application of Galileo as soon as possible. The contractor shall orient all its development towards a mass-market interoperable GPS/Galileo receiver. Two types of applications drive the mass-market receiver development: the car navigation (today representing the biggest market for GNSS), the LBS (that will potentially represent tomorrow the biggest market for GNSS). In this type of market, and especially for the LBS, the main drivers for the development of GNSS receiver are the minimisation of the price, the size and the energy consumption. This requires specific design of the receiver component and development of specific techniques and technologies. The general specifications of a mass-market receiver shall at least integrate the following consideration: - this type of receiver will use the Galileo Open Service signals (L1, E5a and E5b). - the majority of receivers will be mono-frequency (L1 only) at least for LBS. However, a bi-frequency receiver can also be considered. - the receiver shall be a Galileo/GPS combined receiver. - size and cost are driving factors for the design of such receiver - 10 -
In the activities presented hereunder, the contractor shall also take into consideration the specifications coming from its targeted market as mentioned in the proposal. The technological activities covered by this Statement of Work are organised in three tasks: 1. The investigation and research activities on the core technologies relevant to the mass-market type of receivers. This task pursues the effort of the first call in the investigation of the core technologies and in the support to advanced research for receiver technologies. It offers the possibility to investigate new techniques, algorithms, design or other relevant features for the mass-market type of receiver, in an innovative way, in order to have the adequate core technologies and knowledge in place to manufacture, in due time, receivers answering in the most appropriate way to the requirements of the mass-market consumer. This part includes also investigation in core technologies that are closely linked due to the environmental conditions in the LBS or Road sector (indoor, urban area) and its combined utilisation with communication system (assisted GNSS, combination with communication network data for positioning, software defined redio receiver). 2. the development of the different SW/HW components of mass market receiver The development of receiver prototype is usually based on tested and improved technologies. This activity is then performed in parallel to the core technologies and shall benefit as much as possible from the different investigations made in the core technology part. Based upon the proposal, the different phases of the development (specification, design, development, testing and validation) can be performed. 3. the development of simulator, test and validation tools As Galileo is not yet transmitting any signals in space, all the developed elements of the receiver have to be tested and validated using different tools. In the frame of this project, for all the aspects concerning the test and validation phase of the developed elements, the consortium has the possibility either to use existing tools, either to develop complementary tools. The activities performed in the frame of the three parts are detailed hereunder. The contractor shall perform activities in the first two tasks and, if necessary, in the third task. The activities described in the three tasks can be combined in another way, which could be more convenient for the contractor and in line with its overall development plan. 2.3.1 Core technology investigation Context The project aims at investigating the necessary core technologies for the professional receiver. These core technologies include the ones related to antennas, front-end, base-band and the receiver architecture and design (simple antennas with reduced size, reduced front-end dimension and power consumption, BOC demodulation, - 11 -
multiple GNSS system in a single receiver, pilot tone signal utilisation, Galileo/GPS chipset design ) Moreover, it includes also core technologies that are related to the condition of use and the typical environment in the LBS and/or Road domain. Based upon the proposal, investigation in core technologies related to the following items can also be considered in the frame of this project. - Assisted GNSS positioning. When mentioning a mass-market receiver, the assisted GNSS techniques come often into consideration. Basically, at receiver level, some GNSS information (ephemerid, Doppler shift ) arrives to the receiver through a terrestrial communication network. It allows the receiver to be functional quasi immediately after its switch-on, by receiving information through terrestrial communication networks instead of through the message modulated on the signal broadcasted by the satellite. The investigation, if any, shall focus on the development of Assisted GNSS capability within the receiver (taking into account the A-GNSS service provider platform, but not further developing it). - GNSS/communication positioning (Nav&Com). The communication networks (GSM, UMTS ) offer also positioning capabilities through different techniques (Cell-ID, E-OTD, TDOA ), which might be particularly interesting in urban areas. The co-existence in a single terminal of GNSS terminals and mobile phones creates a potential for synergies between communication networks and satellite systems for positioning through proper hybridisation. Investigation in this domain can be performed in the frame of this project. This Nav&Com concept impacts of course on the hardware design of the chipset receiver. For example, at antenna level, investigations can be done on the way to combine, in an optimal way, the comm. and nav. signals (unique antenna, clear separation ). Based on the proposal, other investigations or developments linked to the Nav&Com combination can be performed. However, the specific characteristics of Galileo shall be clearly taken into account in these developments. - the Indoor GNSS positioning. Indoor localisation represents a great challenge for user terminal manufacturers, as the service coverage is an important aspect for the mass-market users (and the related service provider). The capacity to determine one s position in an indoor environment in a more seamless way than outdoor is crucial. For indoor localisation, the GNSS technology competes with other technologies and with possible local augmentations of a different nature. This indoor capability is very interesting for the mass-market type of receiver as it allows to increase the LBS service coverage area without new infrastructure (indoor beacons, pseudolite ) and without adding new sensors in the portable unit. This project aims at developing the related technologies to allow receivers to acquire and track attenuated signal. Assisted GNSS is contributing to this - 12 -
indoor capability. However, investigations of specific receiver architecture (multi-correlators ) and signal processing techniques are necessary. The utilisation of the Galileo pilot tone shall be also considered. Based upon the proposal, the contractor can investigate specific designs of receivers and specific technologies enabling the receiver to acquire and track attenuated the GNSS signal in an indoor environment. - The software defined radio (SDR) is used to describe radios that provide software control of a variety of modulation techniques, wide-band or narrowband operation and waveform requirements of current and evolving standards over a broad frequency range. GNSS frequency band can then also be treated by a SDR. It is view as promising implementation for the mid term future. The current status of the technology does not allow it to compete with the Hardware approach, especially for the mass-market. In the future, and depending on the technological evolution, it is an interesting alternative for some receivers. It will allow having flexibility in the receiver, in order to adapt to new signals, new modulation schemes or new code descriptions. It will also allow easily for combining the GNSS functionalities with other functionalities (e.g. mobile communication). The contractor can investigate in more detail some aspects of the Software Radio Defined receiver related to GNSS. Based on its proposal, the contractor can also perform other developments if they have a clear link with the mass-market receiver. Activity Based upon the elements already presented in the proposal (core technologies selection), the contractor shall, at the beginning of the project, deeper describe the emerging technologies that will allow the GNSS receiver to better answer the general requirements (low cost, size, energy consumption) for the mass-market applications. After this first phase (which shall have a duration of maximum 2 months), a set of core technologies will be selected, together with GJU, for further investigation. The contractor shall then perform the necessary investigations to develop, assess and test the selected core technologies. The utilisation of a Software Receiver for this kind of investigation is appropriate for most investigations. The Software Receiver tool developed in the frame of the first call (GARDA project) can be put at the contractor s disposal by the GJU, to be used in the frame of the contract. In which case, the contractor shall finance external engineering support for teaching, installation and support in the utilisation of the Software Receiver. In the frame of this contract, the contractor can also choose another tool or to develop its own tool to investigate these core technologies (see paragraph 2.3.3). At the end of the investigation, the contractor shall provide a synthesis report about the investigated core technologies, including the main results. - 13 -
2.3.2 Development of the HW/SW component of receiver Context The previous activities aim at developing sufficient knowledge and mastery of core technologies to start designing and developing a prototype of a Galileo/GPS massmarket receiver. This part is dedicated to the full or partial development of a prototype. The activities performed in this part shall be in line with the overall development plan presented in the proposal. Phases (specification, design and development) The contractor shall perform activities for all the receiver components (Front End, Base-band, Antenna). The contractor shall perform at minimal the specification and design activities for each component of the mass-market receiver, including the design and architecture of the final mass-market receiver prototype. Based on the proposal, which clearly specifies until which phase the different elements will be developed in the frame of the contract and how the other phases will be handled in the future (this shall already been visible in the overall development plan presented in the proposal), the contractor shall perform the different development activities of the various components. Test and validation of the developed element of the prototype An initial testing plan of the developed component has to be drafted in a precedent phase of the project (in parallel with the specification and design). The contractor shall perform the test and validation activities for the items developed in the frame of the project (antenna, front-end, base-band). Based upon the test and validation approach presented by the consortium in its overall development plan, the "test and validation" can be based on the following tools: 1. the Signal Generator developed in the GARDA project, 2. the GSVF developed by ESA in the frame of the GalileoSat project, 3. some COTS product that the contractor is expecting to be available (a mitigation of the risk of non-availability of COTS product shall then be made), 4. a validation tool developed in another frame than the 6th FP Galileo R&D activities financed by the GJU and than the GalileoSat project, 5. a validation tool which development will be done in the frame of this project (see next section). The utilisation of the Signal-In-Space broadcasted by the GSTB-V2 satellite (expected to be launched by the end of 2005) shall also be considered. In case of utilisation of the GARDA or ESA tool, the contractor shall evaluate the number of hours of utilisation of these tools and shall foresee the appropriate budget - 14 -
to finance the engineering support that will assist him during the utilisation of the tool. 2.3.3 Simulator, test and validation tool Based upon the approach selected by the contractor for the core technology investigations, the project can aim at developing the necessary tools to investigate these technologies. The contractor can also propose to further develop existing tools to adapt them to the required task. Based upon the approach taken by the contractor for the test and validation phase, the project can aim also at developing the necessary test and validation tools. The contractor can also propose to further develop existing tools to adapt them to the required tasks. In both cases the development of these tools shall be performed in different phases (specification, development). 2.4 Awareness The contractor shall participate and present its results at 2 conferences per year. The contractor shall develop and maintain a website to present its activity and disseminate the public documentation. 3 DELIVERABLES 3.1 Input 3.1.1 From the GARDA project The GARDA project is financed by the GJU under the first call of the Galileo Research and Development activities. The outcome of this project can be made available to the contractor. The Software Receiver (GRANADA) tool and the Signal Generator (GMCS) are described below. GRANADA A SW receiver described in Appendix A GMCS A Galileo Mono-Channel Simulator described in Appendix B - 15 -
3.1.2 From other studies Ref Title Delivery Galileo Mission Requirements Document. ITT Launch 077 Final Summary Report of Interoperability ITT Launch 080 Navigation System Interoperability Analysis ITT Launch 081 Non Navigation System Interoperability Analysis. ITT Launch Galileo Signal In Space ICD information KO 3.2 Output In addition to the documentation requested in the management part (progress report ) and in addition to the deliverables identified in the previous paragraphs of this statement of work, the contractor shall deliver a list of documents that reflect the work accomplished within the project and can support the dissemination of the achieved result outside of the consortium. The delivery dates of the documentation shall coincide with main reviews. The proposal shall indicate the list of deliverable of the project, together with the status of the deliverable for dissemination (public or restricted). 4 APPENDIX A: GRANADA SW RECEIVER 4.1 Introduction The GAlileo Receiver Development Activities (GARDA) project is being carried out in the context of first call of the European Commission 6th Framework Programme, under Galileo Joint Undertaking contract. A Software Receiver is a key element in the GARDA project. The Galileo Receiver ANAnalysis and Design Application (GRANADA) will cover a dual role: test-bench for integration and evaluation of technologies on one side, and SW receiver as asset for GNSS application developers on the other side. It will allow detailed simulations in several key receiver aspects, including acquisition performance, Galileo/GPS interoperability, multipath and interference analyses. 4.2 GRANADA Requirements and functionality The GRANADA application is conceived as a modular and configurable tool, in which the user can embed and test his/her own algorithms with a user-friendly interface. The SW receiver runs on a standard PC under Windows, allowing the maximum use form people not involved in the development. The interfaces will be made by means of text files and of the GUI. GRANADA is an open tool that can be used without restrictions (IPR, COTS) by third parties. Its modular design and architecture shall allow the future development and integration of additional functions (such as local elements, inertial sensors or telecommunications interface). The application recreates in detail the signal processing chain of a Galileo receiver. It models the antenna and the R/F, and processes I/F measurements, including the - 16 -
correlation and filtering, signal and data processing and PVT computation, allowing the use of GPS combined with Galileo. The application shall allow performing analysis and trade-off of several receiver key technologies, such as L5 signal, BOC modulation, utilisation of the pilot tone, receiver architecture, SV selection strategies, interference mitigation, cycle slip detecting and correcting or multi-carrier phase ambiguity resolution. SW Receiver Signal Generation Environment Simulation Front-end Modelling Correlation and Filtering Data files Data files Data files Data files Signal and Data Proces. PVT Computation Signal Simulation SW Receiver Figure 1. GRANADA design 4.3 Suite Description GRANADA is a SW suite including three complementary tools. Each tool allows performing different analyses, or to investigate specific functions and algorithms of the receiver. The three approaches have also different characteristics of modularity, CPU and COTS licenses requirements: 4.3.1 Bit-True GNSS SW Receiver Simulator I (Matlab/Simulink): This tool, developed in Matlab/Simulink to provide high modularity, targets receiver experts in the development and analysis of the so-called Receiver core technologies. It implements a single-channel / single-frequency processing, but also allows multiple-channel simulations by a sequential demodulation of the GNSS signals. The GRANADA bit-true simulator will allow performing analyses and simulations of the receiver critical algorithms and architecture design, such as: - Acquisition, in terms of SW, for the different new signals modulations. Several strategies will be implemented, including filters for discriminate the main BOC correlation peak. - E5 signal acquisition. Several possibilities are allowed in the suite for the signal generation: two QPSK signals generated coherently and transmitted - 17 -
through two separate wideband channels on E5a and E5b respectively, or one single wideband signal using an AltBOC(15,10) modulation scheme. For acquisition and tracking, also several possibilities are envisaged, including direct IF sampling in the centre of the E5 band, allowing dualsideband coherent demodulation of E5a+E5b. - Analyses of Galileo / GPS interoperability at receiver component level, including the BOC(1,1) modulation scheme in the L1-Band. - Multipath and interference analyses: due to the modularity of the tool, it is easy to add new scenarios to analyse the behaviour of the GNSS receiver in different environmental conditions. 4.3.2 Bit-True GNSS SW Receiver Simulator II (C-code version) Auto-coding techniques are used to produce a C code version of the Bit-True GNSS SW Receiver, thus providing the users with a version of the SW receiver that is not dependent on any commercial license. 4.3.3 GNSS Environment and Navigation Simulator A lightened version of the SW receiver, implemented in C-code, is oriented to application developers who only need external access to raw data (i.e. pseudorange and carrier phase). It includes realistic characterisation of the effect of the different error components depending on the type of terminal and GNSS receiver configuration. It is possible to configure the GNSS constellation (both Galileo and GPS, allowing the derivation of the optimal algorithms for a combined PVT solution), the environmental conditions, satellites and receiver characteristics, the navigation and integrity algorithms. 4.4 Conclusion GRANADA will be the first open tool, running on a commercial PC under Windows, to precisely (bit-true) replicate GNSS receiver HW and algorithms, integrating both GPS and the new Galileo signals. The Galileo Joint Undertaking will be in position to grant licenses to the user community and application developers, proposing GRANADA as a reference SW suite for GNSS receivers. - 18 -
5 APPENDIX B: GMCS: A MONO-CHANNEL SIGNAL SIMULATOR 5.1 GMCS Overview The Galileo Mono-channel Simulator is conceived as a tool for the validation of the GARDA prototype receiver. It is designed and manufactured by Space Engineering (Rome). Its purpose is the generation of a single Galileo satellite signals covering the three carriers defined in SIS ICD. The simulation capability is limited to the simultaneous generation of two carriers: L1/E5 or L1/E6. In practice, this is not view as a limitation for the receiver performance testing. On each pair of carriers, the modulation techniques are totally in line with requirements of Galileo SIS ICD. The simulator generates time varying signals, taking account of system geometry (relative motion between transmitter and receiver) and the relevant dynamics, propagation, atmospheric effects, transmitter hardware impairment, receiver antenna characteristics. Additional capabilities are available to simulate signal degradations due to noise, in-band interference, multipath. The simulator is provided with a communication link to an external processor (Personal Computer). A graphical user interface gives the user a powerful way of controlling all major signal parameters and condition of simulation. An embedded, sophisticated self-calibration routine periodically checks the signal power level and compensates for unwanted fluctuations. Consequently, the user is not requested to run periodic calibration, avoiding out of service time period. Internal temperature is monitored as well. Self check results and monitors are displayed through the Graphical User Interface. The architecture is based on COTS hardware (for power supply function, clock generation, processors and communication I/F) and custom design for the upconverter (modulator and filtering). The main elements are: AC/DC Power Supply (1 board) 6 21060 DSP (1 board) DSP Builder (2 boards) 1 RF Up-converter (modulator) (1 board), including a reference clock source (10.23 MHz OCXO) VME bus (1 board) 19 inches rack. Personal Computer - 19 -
5.2 GMCS Main Functional Characteristics The GMCS provides Space Segment simulation capability: Signals Overall capability of generating three modulated carriers in the L band [1575.42 MHz (L1), 1278.75 MHz (E6), 1191.795 MHz (E5)], and relevant to one SV, in accordance to Galileo SIS ICD. Two pairs of signals simultaneously generated: L1 and E5 signals L1 and E6 signals RF signals are obtained through DDS complex modulation, using a 14 bit DAC sampled at 125 MHz Messages The data message can be selected among three different message structures, independently on each channel: User defined message Dummy message As described in SIS ICD Viterbi convolutional encoding and interleaving capabilities are included Modulations can be imposed or stripped of via SW command SV and Orbit simulation The following transmitter impairments are simulated: HPA AM-AM and AM-PM TX Antenna Radiation Pattern frequency error offset SV trajectories are SW controllable Ionospheric effects are accounted for No orbital perturbation simulation is included (non spherical earth, moon and sun gravitational influence and solar pressure) The following parameters are accurately accounted for: Pseudorange Pseudorange rate, acceleration, jerk Carriers relative delay Modulation uncertainty The GMCS provides User Segment simulation capability: Receiver Kinematic Two acceleration patterns, i.e. constant acceleration and sinusoidal acceleration Geometry processor generates the single Satellite Doppler information including Doppler shift, Doppler rate and Doppler acceleration Noise and Interference The propagation channel impairments model implemented in the GMCS includes a base band digital noise generator. The noise is generated at base band and up converted to RF through he modulation process. Simulated noise includes: AWGN in-band noise and in-band tone interferer - 20 -
Externally provided interference can be added through a dedicated RF input port Multipath simulation GMCS includes a four rays multi-path model (frequency selective) 5.3 GMCS Main operational characteristics Clock stability Local 10.23 MHz reference oscillator (OCXO) with medium term stability around ±1x10-9 (over 1 day) and long term stability around ±1x10-7 (over 1 year) Phase Noise Phase noise for the 10.23MHz reference oscillator @10 Hz -120 dbc/hz @100 Hz -140 dbc/hz @1 KHz -145 dbc/hz @10 KHz -150 dbc/hz Output signal power level The RF output available signal power is function of the elevation Output power level is adjustable in a offset range [-10; +10] db w.r.t. to the nominal value The output signal power is accurate within ±0.5 db (RSS) RF high power monitor port is available for testing (+120dB w.r.t. the nominal RF signal) Interfaces A 10.23 external clock source can be used instead of the internal one A communication and Control Interface to a Personal Computer is provided, based on RS232 Communication messages input and output are synchronised with time tag pulse. This is useful when running "hardware in the loop" tests All main simulation parameters are controllable through a Graphical User Interface RF output signals are available through SMA connectors, one for each frequency carrier Spreading codes are available at a monitor port A PPS pulse is generated and made available at output - 21 -
Connectors List Port Name IN/OUT Connector Specification Main RF 1 OUT COAXIAL Type SMA Female 50 ohm VSWR <1.2:1 (in band) AC coupled Protection: no damage maximum applied dc level 200V no damage maximum applied RF levels 2W Main RF 2 OUT COAXIAL Type SMA Female Same as Main RF 1 Monitor Port RF 1 OUT COAXIAL Type SMA Female 50 ohm VSWR <1.2:1 (in band) DC coupled Protection: no damage maximum applied dc level 20V no damage maximum applied RF levels 2W Monitor Port RF 2 OUT COAXIAL Type SMA Female Same as Calibration Port RF 1 Interference IN COAXIAL Type SMA Female 50 ohm VSWR <1.4:1 (in the range 1 to 2 GHz) External IN COAXIAL BNC socket 50 ohm -5 to +13 dbm Frequency Standard Internal Standard OUT COAXIAL BNC socket 50 ohm @ 10.23 MHz +10 dbm nominal Spreading Code OUT COAXIAL BNC socket 50 ohm TTL level compatible Synchroniser OUT COAXIAL BNC socket 50 ohm TTL level compatible. Communication IN/OUT Cannon Interface Standard and Control HOST (1PPS) OUT 25-WAY D socket RS232 SYNC (1PPS) IN COAXIAL BNC socket 50 ohm TTL level compatible - 22 -