MODELLO

Consiglio Nazionale delle Ricerche	Progetto COORDINATO - AGENZIA2000
codice: CNRC00EC5E

Cognome	FERRO
Nome	ERINA
Sesso	F
Data di nascita	05/11/1951
Luogo di nascita	Pisa
Nazionalità	ITALY
Istituzione di appartenenza	Istituto CNUCE/CNR
Qualifica	Primo Ricercatore CNR
se dipendente CNR inserire la matricola	6441
Codice Fiscale	FRRRNE51S45G702U

I sistemi di comunicazione satellitari sono molto complessi da testare e da mettere a punto senza l'aiuto di strumenti adeguati. Prima di tutto, poiche' l'uso del satellite e' di per se' molto costoso, occorre che il tempo speso nelle fasi pre-operative sia il piu' corto possibile; secondariamente, durante la valutazione delle prestazioni di un sistema satellitare, spesso non e' possibile trovare la gista sequenza di dati o il giusto carico che stressi al massimo il sistema al fine di verificarne i limiti. Quando poi sono coivolte costellazioni di satelliti (MEO o LEO), piuttosto che singoli satelliti (GEO), questi problemi sono esacerbati al punto che e' pressoche' impossibile per i ricercatori fare dei test su reali costellazioni. Spesso, in tal caso, si ripiega su studi analitici che, per loro natura, fanno assunzioni limitanti sulle reali problematiche, oppure si realizzano simulatori ad hoc per studiare uno specifico problema, perdendo inevitabilmente di vista la globalita' del contesto. I simulatori per reti satellitarie attualmente esistenti (OPNET, BONeS, RESQ, AMS, NS, Ptolemy, etc) sono generalmente costosi e pesanti in termini di elaborazione perche'non disegnati per specifiche tematiche satellitarie, ma di tipo "general purpose". Il nostro scopo e' realizzare un simulatore specifico per problematiche satellitarie, disegnato in modo cosi' modulare da permettere la sua crescita a seconda di nuove edigenze di studio. La sua versatilita', pur in un settore ben preciso, lo dovrebbe rendere uno strumento di comune utilizzo per tutti quei ricercatori, italiani e non, che si interessino di problematiche satellitarie, creando cosi' una base per facilitare la cooperazione fra vari ambienti del mondo scientifico. Per raggiungere questo scopo, il simulatore in oggetto deve essere modulare, al fine di poter aggiungere nuove features senza alterane la struttura, scritto in linguaggio portabile, e deve permettere l'esecuzione parallela di attivita' concorrenti.
La realizzazione di GaliLEO viene a colmare un vuoto di mercato, sia nazionale che internazionale, nel campo dei simulatori per trasmissioni satellitarie, vuoto con cui piu' volte i ricercatori del settore si sono in passato dovuti confrontare.

OBIETTIVI
---------

Il progetto GaliLEO punta a progettare, sviluppare e validare un ambiente modulare di simulazione ed emulazione, che sia disponibile in forma sorgente da scaricare liberamente dal sito web di GaliLEO. Il suo scopo è di fornire un ambiente di simulazione alla comunità scientifica e commerciale che opera sui satelliti. A quest'ambiente, in aggiunta alle librerie che saranno sviluppate durante il progetto, l'utente possa aggiungere moduli sviluppati autonomamente, secondo le proprie specifiche necessità. L'ambiente GaliLEO permetterà di valutare le prestazioni di future reti satellitari fornendo una comprensione delle prestazioni raggiungibili in termini di qualità di servizio, specie dal punto di vista della rete.

Il progetto si propone il raggiungimento dei seguenti obiettivi:
o Implementazione di modelli di traffico e di mobilità per voce, dati e servizi multimediali basati sulle prospettive quote di mercato.
o Definizione di un modello parametrico del segmento spaziale della rete (carico utile, accesso, collegamenti intersatellitari, dinamica orbitale, configurazioni di traffico, politiche di routing, ecc.) che possa essere personalizzato dall'utente secondo gli aspetti specifici da simulare. Il modello comprende fra l'altro la possibilità di analizzare l'effetto di guasti nel satellite sulla disponibilità del servizio e sulle prestazioni della rete.
o Scelta di un approccio modulare sia per il progetto che per lo sviluppo del sistema al fine di:
- consentire il riutilizzo del software;
- semplificare lo sviluppo di ulteriori moduli;
- migliorare le possibilità del sistema;
- rendere possibile l'integrazione con altri strumenti commerciali o ad hoc.

PROGRAMMI
---------

Il progetto è organizzato in quattro Gruppi di lavoro: CNUCE-CNR, Università di Siena, Univesità di Firenze e CSELT. Questi gruppi, dopo la prima riunione di avvio, collaboreranno principalmente attraverso il sito web di GaliLEO. Il risultato delle loro attività sarà principalmente costituito da moduli software, che verranno integrati nel sistema man mano che saranno completati. Si potranno organizzare delle riunioni quando sarà necessario ad accelerare l'avanzamento dei lavori. Sarà prodotta documentazione sul software e sul suo utilizzo, fermo restando che la documentazione ufficiale ed aggiornatà risiederà sul sito web.

METODOLOGIA
-----------

GaliLEO sarà scritto in linguaggio Java, con alcune parti in C++. Per sua natura, GaliLEO è un simulatore generico. Come tale, è pensato per essere esteso e personalizzato utilizzando i servizi di base forniti dall'ambiente di simulazione, che quindi devono necessariamente essere documentati con completezza. A tal fine, bisogna definire un metodo per strutturare, documentare e validare il processo di sviluppo di GaliLEO. A causa della sua decisa orientazione agli oggetti, sarà necessario utilizzare strumenti orientati agli oggetti per completarne l'analisi ed il progetto.

Per stabilire le interazioni fra l'utente e GaliLEO si utilizzeranno i case diagram [UML] e i sequence diagram [UML]. Dalla descrizione di tali interazioni sarà possibile ottenere una precisa descrizione dell'interfaccia utente.

Per identificare tutti i moduli che interagiscono fra di loro all'interno del sistema GaliLEO, si useranno i collaboration diagram [UML], i sequence diagram [UML] e gli state chart diagram [UML].

Per descrivere il sistema in termini di classi cooperanti fra loro, si useranno i class diagram [UML], gli attribute diagram, method description, i class hierarchy diagram [UML] e i module diagram.

Sarà disponibile un sito web che conterrà lo stato sempre aggiornato dell'architettura e dello sviluppo del software.

PROJECT OBJECTIVES
------------------

The GaliLEO project aims at designing, developing and validating a modular simulation and emulation environment to be made available to the entire Satellite Community for downloading as an open source software from the GaliLEO Web Server. GaliLEO's objective is to provide the user with a simulation environment where, in addition to the libraries already developed during the project, each user will be allowed to develop his own modules according to his specific needs. The GaliLEO framework will allow to evaluate the performance of future satellite networks by providing a valuable insight into the achievable performance of future satellite systems, in terms of quality of service, mainly from a network perspective standpoint.

The project aims at the achievement of the following objectives:
* Implementation of traffic and mobility models for voice, data and multimedia services based on predicted market shares;
* Definition of a parametric model of the space segment network (payload, access, inter-satellite links, orbital dynamics, traffic patterns, routing policies, etc.) to be customised by the user according to the specific aspects to be simulated. The model will also include the possibility to analyse the impact of satellite failures on service availability and network performance.
* Selection of a modular approach in both the design and development of the framework in order:
- to maximise the possibility of re-use,
- to simplify the development of further adds-on,
- to improve the features of the framework,
- to allow integration with other commercial/custom tools.

PLANS
-----

The project is organised in four Research Units: CNUCE/CNR, University of Siena, University of Florence, and CSELT. These groups, after the initial kick-off meeting, are assumed to collaborate mainly by means of the GaliLEO web server. The results of their activities, mainly software modules, will be integrated as they will be ready. According to the necessity, working meeting will be set-up, in order to speed the activities. Detailed documentation of the GaliLEO software and its usage will be provided, and, once again, the GaliLEO web server will be the offical project descriptor.

METHODOLOGY
-----------

GaliLEO will be mainly developed using the Java language, with some parts in C++. GaliLEO's nature is that of a generic simulator. It is therefore meant to be extended or customised using the core services provided by the simulator. A comprehensive documentation of these core services is therefore a must have. As a result, the need exists to use a methodology in order to structure, document and validate the development process of GaliLEO.
Due to the strong OO nature of GaliLEO, specific OO tools are needed to complete the analysis and design.

In order to establish the interactions existing between the users and GaliLEO, Case diagrams [UML] and Sequence diagrams [UML] will be used. From the description of the interactions between the user and GaliLEO, it will be possible to describe precisely the user interface.

In order to identify all the elements interacting in the GaliLEO system, Collaboration diagrams [UML], Sequence diagrams [UML], and State Chart diagrams [UML] will be used.

In order to describe the system in terms of co-operating classes, Class diagrams [UML], Attribute diagrams, Method descriptions, Class hierarchy diagrams [UML], and Module diagrams will be used.

A web site will be created, containing the updated status of the architecture and of the software development.

L'architettura funzionale che costituisce la base per lo sviluppo del simulatore GaliLEO sarà basata su un approccio modulare, block-oriented, che partiziona la problematica generale relativa all'intero simulatore in blocchi indipendenti, adatti ad ulteriori sviluppi e integrazioni. Si segue l'approccio tipico dell'ingegnerizzazione delle reti, volto ad individuare prima di tutto le Funzioni della rete satellitaria costituita da costellazioni di satelliti, ed le relative esigenze di modellazione e di simulazione. Successivamente, dopo aver identificato i moduli che costituiranno il simulatore nella successiva fase di sviluppo del software, il modello della costellazone satellitaria scelta sarà mappato in diversi moduli, e ne saranno prodotte le relative specifiche. I successivi compiti di ingengeria del software che ne deriveranno saranno dedicati allo sviluppo ed al testing dei singoli moduli, fino alla loro integrazione finale, che costituirà il simulatore GaliLEO.

Il progetto, nella sua globalità, presenta diverse difficoltà. Proprio per questo si dovrà porre particolare attenzione ad identificare quelle soluzioni progettuali che possano dare i risultati migliori in termini di tempo di simulazione, capacità di elaborazione, possibilità di riutilizzo dei moduli, inserimento di nuovi moduli, etc. Per il modeling e la simulazione di segmenti terrestri esistono già numerosi strumenti. Dove invece il mercato è carente è sulla tratta spaziale, su cui invece GaliLEO intende orientarsi. Ciò comunque non impedisce che in futuro GaliLEO possa essere usato insieme ad altri simulatori commerciali o proprietari specifici per le tratte terrestri. Questo obiettivo non è, per ovvi motivi di tempo, fra gli scopi del progetto. Tuttavia GaliLEO ambisce ad essere un simulatore aperto ad interfacciare strumenti esterni.

L'architettura di riferimento di GaliLEO consiste essenzialmente di cinque componenti principali, che hanno corrispondenza con la struttura fisica di una tipica rete a costellazione satellitaria, e che è adeguata alla progettazione e sviluppo modulari e paralleli:

1. Simulatore di Traffico, che comprende:
- simulatore di traffico regionale
- statistiche di traffico e controllo
2. Simulatore di Satellite, che comprende:
- simulatore del router di bordo
- simulatore di accesso terrestre
- simulatore di collegamenti intersatellitari
3. Simulatore delle dinamiche spaziali e terrestri
4. Simulatore delle dinamiche fra piani spaziali
5. Modulo di raccolta ed elaboratore delle statistiche.

Il modulo "Simulatore di Traffico" gestisce la simulazione del traffico aggregato fornito alla sezione spaziale dalle specificate regioni geografiche sul terreno; gestisce inoltre il traffico ricevuto ed effettua le relative statistiche. Qusto componente è una libreria di diversi generatori di traffico definiti dall'utente, che producono traffico real-time e non. Ogni generatore di traffico avrà un insieme di caratteristiche che lo contraddistinguono, come il tipo di traffico generato (chiamata per traffico vocale, Poisson, velocità fissa, frattale, Poisson modulato con catena di Markov, ecc.), l'indirizzo di destinazione dei dati, distribuzione e jitter dei dati prodotti, distribuzione della lunghezza dei pacchetti e loro contenuto, ecc. Grazie alla combinazione di vari tipi di traffico generati simultaneamente dai generatori, è possibile simulare configurazioni di traffico arbitrariamente complesse. Definire un modello globale di traffico è un compito delicato. Una prima difficoltà, ad esempio, consiste nello sviluppo di un modello atto a rappresentare un enorme numero di utenti, come nel caso di traffico web.

Il modulo "Simulatore di Satellite" è composto dei tre seguenti moduli:
1. Simulatore di accesso terrestre
2. Simulatore del router di bordo
3. Simulatore di collegamenti intersatellitari.

Il "simulatore del router di bordo" implementa le seguenti funzioni:
- switching,
- controllo di congestione,
- controllo di ammissione delle chiamate,
- down-beam routing,
- tecniche di accesso sul down-link,
- tecniche di accesso sull'up-link.

La funzione di switching si occupa di inoltrare i dati verso il successivo satellite o verso una stazione di terra, a seconda della destinazione dei dati. La funzione di switching usa le tabelle di routing per decidere dove inoltrare i pacchetti. La funzione di controllo della congestione si occupa invece di controllare continuamente lo stato dei buffer e delle code sul satellite. In caso di congestione, si prendono delle contromisure, come scartare i pacchetti o segnalre ai trasmittenti che la loro velocità di trasmissione è eccessiva. Per ridurre quanto più possibile l'eventualità di congestione, il controllo di ammissione delle chiamate valuta preventivamente se il traffico in ingresso può essere gestito dal satellite.

Il down-beam routing è il processo attraverso il quale il satellite sceglie il fascio (beam) che farà da canale fra il satellite e la stazione di destinazione. Il down-beam routing varia continuamente, a causa del movimento del satellite. In occasione di una riallocazione delle frequenze di cella, è necessario ricalcolare il down-beam routing, in maniera da aggiornare le corrispondenze fra i canali e i fasci.

Le tecniche di accesso sull'up- e sul down-link implementano lo schema di accesso (TDMA, FDMA, ...) usato sul satellite per l'up- e il down-link. La tecnica di accesso di up-link è la parte ricevente della tecnica di accesso di up-link implementata sulla stazione di terra. La tecnica di accesso di down-link è la parte trasmittente che comunica con la parte ricevente situata nella stazione di terra.

Il "Simulatore di accesso terrestre" è il componente dedicato alla modellazione e simulazione dei flussi di traffico ricevuti dal satellite nei fasci di up-link e dei flussi trasmessi dal satellite nei fasci di down-link. Esso svolge le funzioni di:
- up-link routing,
- down-link routing,
- controllo di congestione,
- tecniche di accesso sull'up-link,
- tecniche di accesso sul down-link.

Questo modulo svolge le funzioni di Up-/Down-Link (UDL) routing. Il routing di up-link è il processo per cui la stazione di terra trasmittente seleziona il satellite da usare per l'inoltro dei pacchetti della connessione, mentre il routing di down-link è il processo per cuila stazione di terra ricevente seleziona il satellite dai cui le vengono inoltrati ipacchetti della connessione. Possibili criteri usati per l'UDL routing possono essere: disponibilità di risorse al satellite ed alla stazione di terra, minimizzazione dell'handover sull'UDL, qualità della comunicazione fra stazione di terra e satellite.

Questo modulo include anche un modulo per il controllo di congestione. Il controllo di congestione gestisce la congestione dati al livello della stazione di terra. La congestione può avvenire a causa dello stato delle risorse nella stazione di terra o nel satellite, come risultato di una quantità di traffico troppo grande per poter passare. Grazie a questo modulo si possono sperimentare diverse tecniche di controllo di congestione. All'instaurarsi della congestione, si possono intraprendere azioni quali bloccare i trasmittenti. Per fare un esempio, la probabilità di blocco delle chiamate è un indicatore di congestione delle risorse al satellite che sta illuminando una data area.

Il "Simulatore di collegamenti intersatellitari" è il componente dedicato alla modellazione e simulazione della politica di routing implementata sul satellite, cioè del criterio con cui viene scelta la strada fra due satelliti. Criteri possibili sono: disponibilità di risorse ai satelliti, minimizzazione della frequenza di handover, qualità della comunicazione fra satelliti, lunghezza del persorso. Il risultato della scelta è il persorso che soddisfa maggiormente i criteri scelti, minimizzando nel contempo la quantità di risorse utilizzate.
Fin qui si è data per scontata l'assunzione che, nella maggior parte dei sistemi futuri, il satellite è un vero e proprio nodo della rete spaziale, con la capacità di prendere decisioni autonome circa il routing dei pacchetti ricevuti, secondo lo stato istantaneo della rete.
Il routing è un importante aspetto delle costellazioni satellitari, visto che l'ambiente dinamico delle costellazioni richiede una rivisitazione dell'architettura di routing. Fra l'altro, una questione importante è la gestione dell'handover. Attualmente, nelle reti terrestri coesistono diverse politiche di routing, mentre in quelle spaziali sarà necessario scegliere quella che più si adatta al particolare ambiente.

Il "Simulatore delle dimamiche spaziali e terrestri" simula gli effetti del movimento dell'area illuminata dal satellite, basandosi sulle caratteristiche orbitali della costellazione considerata. Esso assegna i trasmittenti ed i ricevitori di traffico agli appropriati moduli di Simulatore di accesso a terra.
Questo componente può esser sviluppato come componente software, ma successivamente può esser presa in considerazione la possibilità di implementarlo come come misto hardware/software.

Il "Simulatore delle dinamiche fra piani spaziali", basato sui parametri orbitali caratteristici della specifica costellazione considerata, simula le variazioni discrete dello stato dei collegamenti intersatellitari.
Si considerano due tipi di orbite: ellittica e circolare; quest'ultima include orbite equatoriali, polari e inclinate. Un satellite geostazionario è un caso particolare di orbita sincrona, precisamente di orbita circolare sopra l'equatore.

Il "Modulo di raccolta ed elaborazione delle statistiche" non è relativo ad un particolare componente del sistema, ma raccoglie statistiche da qualunque degli altri componenti.
Un esempio delle statistiche che è possibile analizzare è ilseguente elenco:
o ritardo end-to-end, jitter, perdite di pacchetti (QoS);
o traffico generato da una stazione, correispondente a specifici tipi di traffico;
o traffico trasmesso attraverso un dato satellite, o mediato sull'intera costellazione, o mediato su un intervallo di tempo, ecc.;
o traffico perduto a causa di congestione sulle stazioni di terra;
o traffico perduto a causa di congestione sui satelliti;
o disponibilità del sistema in dipendenza di condizioni di attenuazione del segnale, guasti, disponibilità dei collegamenti UDL o intrasatellitari, ecc.;
o statistiche di qualità del servzio;
o probabilità di caduta della connessione;
o probabilità di blocco della connessione.

The functional architecture constituting the current baseline for the modelling, simulation and emulation framework to be developed in the frame of the GaliLEO project will be based on a modular, object-oriented approach which partitions the overall modelling and simulation problem into smaller, independent functional modules suitable for independent and parallel design and development. The definition of the modelling and simulation environment will result from a network engineering approach aimed to first identify the typical Network Functions of a satellite constellation system and the modelling and simulation requirements; then, after identification of the simulation modules to be considered in the following software design and development phase, the model of the network functions selected for implementation will be mapped into the different modules and the related specifications will be produced. The following software engineering tasks are devoted to the design, development and testing of the individual modules and to their final integration into the overall GaliLEO framework.

Because of the envisaged complexity of the overall framework, particular care will be devoted to the identification of design solutions able to improve as much as possible the resulting performance in terms of simulation time, processing capacity, model re-use capability, etc.

Different alternative tools being available for the modelling and simulation of the ground segment, while the focus of the GaliLEO project is mainly on the space segment. This, of course, does not prevent that the resulting framework could be used in conjunction with different commercial or custom simulation environments designed to model ground networks. This objective is, so far, out of the scope of the present project but the simulation modules will be designed to constitute an integrated environment open to interface with external tools.

The reference architecture of the GaliLEO framework consists of the following five main components, having a large correspondence with the physical structure of a typical satellite constellation network, suitable for parallel and modular design and development:

1. Traffic Simulator
- Regional Traffic Simulator
- Traffic Statistics and Control
2. Satellite Simulator
- Satellite On-Board Router Simulator
- Satellite Ground Access Simulator
- Satellite Inter Satellite Link Simulator
3. Ground / Space Dynamics Simulator
4. Inter Plane Dynamics Simulator
5. Statistics Collector & Processor

The Traffic Simulator component deals with the simulation of the aggregated traffic offered, by any specific geographical region on ground, to the space segment; it also manages the received traffic and performs all the relevant statistical evaluations. The traffic simulator component is a sort of modular library of different user-defined traffic generators (TG), created for the generation of both real-time and non-real time data. Each traffic generator has its unique set of characteristics, such as: type of traffic generated (voice call connection, Poisson, fixed rate, fractal, 2-state Markov modulated Poisson, etc.), data destination address, data generation time distribution, data generation time jitter, packet length distribution and contents pattern, etc. Due to the combination of the various types of traffic simultaneously generated by the TGs, it is possible to simulate arbitrary complex traffic patterns. Establishing a global traffic model is a delicate work. The first challenge is to develop a model able to cope with the huge number of consumers, such as the web traffic

The Satellite Simulator component consists of the following three modules: satellite ground access (GA) simulator, satellite on-board router (OBR) simulator, and satellite inter-satellite link (ISL) simulator.

The OBR simulator is the component implementing the following functions:
- switching,
- congestion control,
- call admission control,
- down-beam routing,
- down-link access technique,
- up-link access technique.
The switching function is in charge of forwarding the data either to the next satellite or to a ground station, according to the destination of the data. The switching function relies on the routing tables in order to take the right decision. Monitoring the status of the buffers and queues in the satellite is the role of the congestion control function. If congestion occurs, congestion control techniques must be activated, such as to discard packets and to notify the traffic sources in order to throttle down the packet emission rate. In order to reduce as much as possible the possibility of congestion, the call admission control acts as preventive measure evaluating whether or not incoming traffic can be handled by the satellite.

Down-beam routing is the process by which the satellite selects the beam supporting the channel between the destination satellite and the destination ground station. Down-beam routing is varying over time due to the movement of the satellite. When cell frequency pattern re-allocation occurs down-beam routing may also be invoked in order to re-compute the mapping between the channels and the beams.

The up- and down-link access techniques implement the access scheme (TDMA, FDMA, ...) which is used in the satellite for the up- and down-links. The up-link access technique is the receiving entity of the up-link access technique implemented in the ground station. The down-link access technique is the transmitting entity communicating with the receiving entity located in the ground station.

The Satellite Ground Access Simulator component devoted to the modelling and the simulation of the traffic streams received by any satellite up-link spot and transmitted by any satellite down-link spot.
The functions are the following:
- up-link routing,
- down link routing,
- congestion control,
- up-link access technique,
- down-link access technique.
The Up-/Down-Link (UDL) routing function is performed in this module. The Up-Link (UL) routing is the process by which the source ground station selects the source satellite used to forward the packets of the connection, while the Down-Link (DL) routing is the process by which the destination ground station selects the destination satellite from which the packets of the connection will arrive. Possible criteria used for the UDL routing may be: the resources availability in the satellite and in the ground stations, the minimisation of the hand-over rate on the UDL, and the quality of the communication between the ground station and the satellite.

A congestion control module is also included in this component. The congestion control handles data congestion at the ground station level. Congestion may happen due to the status of the resources in the ground station or in the satellite, as a result of a huge amount of traffic which cannot be let through. This module allows to perform experimentation of different congestion control techniques. If congestion occurs, appropriate actions are taken such as throttling down the sources. For example, the call block probability relevant to a call connection is an indicator of the congestion of the resources in the satellite currently illuminating a certain area.

The Satellite Inter Satellite Link Simulator is the component dedicated to the modelling and simulation of the routing policy implemented in the satellite. Once decided by the satellite OBR simulator that data must be addressed to another satellite, this module computes the (or at least one) optimal path between two satellites. Possible criteria used are: the resource availability in the satellites, the minimisation of the hand-over rate, the quality of the communication among the satellites, and the length of the path. As a result, the optimal path is the one which fulfils most accurately the user requirements while minimising the amount of used resources.

Here the main assumption is that, in most of the future systems the satellite is like an actual node of the space network. Therefore, it must be able to take independent decisions about the routing of the received packet according to the real time status of the network.
Routing is an important aspect of satellite constellations since the dynamic environment of the constellation calls for revisiting the routing architecture. Among others, one of the important issues is the hand-over management. Furthermore, different routing approaches currently exist in terrestrial networks. The most appropriate one must be chosen in order to fit with the environment featured in the constellations.

The Ground/Space Dynamics Simulator component, based on the characteristic orbital parameters of the specific constellation considered, simulates the effect of the motion of the satellite footprint by controlling the assignment of the traffic sources & sinks (associated to the ground regions) to the proper Satellite Ground Access Simulator.
This component could be developed either as a software component or as a mixed hardware/software component. As a first option, the software version will be addressed.

The Inter-Plane Dynamics Simulator component, based on the characteristic orbital parameters of the specific constellation considered, simulates the discrete status variations in the link between satellites.

Two different types of orbits are considered: circular orbit (which includes equatorial orbit, polar orbit, and inclined orbits), and elliptical orbit. A geostationary satellite is a special case of synchronous orbit, namely, a satellite in circular orbit over the equator.
This component could be developed either as a software component or as a mixed hardware/software component. As a first option, the software version will be addressed.

The Statistic Collector and Processor module is not related relevant to a specific component of the system but collects statistics from any of the other components.

As example, a list of some of the possible statistics the user could collect, is as follows:
* end-to-end delay, jitters, losses (QoS);
* amount of data generated by a station, corresponding to specified types of traffic;
* amount of data transmitted over a certain satellite, averaged over the constellation, averaged in a time interval, etc.;
* amount of data lost due to ground congestion;
* amount of data lost due to satellite congestion;
* percentage of availability of the system according to different fading conditions, system faults, link availability, etc?.;
* QoS metrics;
* call connection drop probability;
* call connection block probability.

Area Scientifica	Scienze tecnologiche, ingegneristiche e informatiche
Linea di ricerca	Interdipendenza tra telecomunicazioni e trasporti
Settore	ING-INF/03 - Telecomunicazioni

Parola chiave 1	SIMULATORE
Parola chiave 2	COSTELLAZIONI DI SATELLITI
Parola chiave 3	PROTOCOLLI (ACCESSO, ROUTING)
Parola chiave 4	GENERATORI DI TRAFFICO
Parola chiave 5	VALUTAZIONE DELLE PRESTAZIONI

Parola chiave 1	SIMULATOR
Parola chiave 2	SATELLITE CONSTELLATIONS
Parola chiave 3	PROTOCOLS (ACCESS, ROUTING)
Parola chiave 4	TRAFFIC GENERATORS
Parola chiave 5	PERFORMANCE EVALUATION

nº	Responsabile di unita' di ricerca	Ente	Mesi uomo	Importo (in milioni di lire)
1.	POTORTI' FRANCESCO	CNUCE	30	150
2.	ANDREADIS ALESSANDRO	DIPARTIMENTO DI INGEGNERIA DELL'INFORMAZIONE - UNIVERSITA' DEGLI STUDI DI SIENA	14	50
3.	ANNONI MARCO	CSELT S.p.A.	3	50
4.	DEL RE ENRICO	Dipartimento di Elettronica e Telecomunicazioni - Università degli studi di Firenze	25	50

Mesi uomo previsti progetto	72
Importo (in milioni di lire)	300 (154937 Euro)
Nel caso in cui siano previste altre fonti di finanziamento indicare il COFINANZIAMENTO CNR(%)	83