GaliLEO: a simulation tool for satellite constellations COST 256 - - PowerPoint PPT Presentation

GaliLEO: a simulation tool for satellite constellations

COST 256 Symposium September 2000 - Aachen Laurent Franck 1, Francesco Potort´ ı 2

1ENST/T´

eSA; Toulouse (FR); Laurent.Franck@enst.fr

2CNUCE-CNR; Pisa (IT); F.Potorti@cnuce.cnr.it

http://galileo.supaero.fr

1

• ✁

Overview

History.

Architecture.

Performance aspects.

Project management.

Project status.

Conclusion.

2

• ✁

History

Seminal discussion among some Cost253 participants led to the following conclusion:

There is a need for a generic simulation tool dedicated to satellite constellations.

Current solutions are not satisfactory: – Either from a functional standpoint (focused on a given technology, not extensible), – or from an economical standpoint (expensive fees for maintenance or license renewal, uncertain future).

3

• ✁

History (cont’d)

Some members of Cost253 have had previous experiences about simulation tools:

CNUCE-CNR (IT): Fracas, an emulator for the study of access schemes in GEO environments and Simtoc, its successor for LEO constellations (remained at the design phase).

CSELT (IT): Consim, a simulator for the evaluation of constellation performance in degraded mode.

ENST (FR): Leosim, a network-level simulator for the study of routing in LEO constellations.

reuse experience, design and, if possible, existing code in order to minimise manpower.

4

• ✁

History (cont’d)

A joint effort was set up to develop a federative tool with the following expectations:

To be customisable and extensible (generic),

aimed at the study of channel access, routing and fault management (as a first step),

including the constellation, the stations but NOT the terrestrial network,

available free of charge under the GNU Public License.

The project is partly funded under Cost253 budget,

the deadline corresponds to the end of the Cost253 Action.

5

• ✁

Architecture

GaliLEO relies on a three-layer architecture:

Configuration files Graphical interactive constellation builder Graphical interactive data analysis

scheduler Core modules Custom modules Simulation engine

Source segment Ground segment Space segment Measurement modules configuration validator input user interface initialiser

Results files

CONSIM

• utput user

interface

agenda

6

• ✁

Simulation engine

Lays the foundation for defining components which are the basic building blocks of GaliLEO. Components support genericity (and are eventually mapped to dynamically loaded Java classes).

Schedules the events and dispatches them to the appropriate components.

Events are stored is a structure that can be customised. Currently: – Delta-list: a simple queue (efficient removal of events). – Static calendar queue: an array of queues (efficient insertion and removal of events).

The scheduling of events is also customisable. Currently:

7

– A sequential scheduler for single-CPU computers. – A parallel scheduler for multi-CPU computers.

8

• ✁

Core modules

Define the network model: the scope of GaliLEO possibilities when it comes to modelling a communication network.

ISL satellite UDL cell footprint station beam

• verlap area

traffic generators

Resource management Routing Signaling Handover mgt Resource management Access method Signaling Handover mgt

9

• ✁

Core modules (cont’d)

Define components to perform utility tasks such as gathering statistics, logging of measures, ...

Define templates (consisting in an API) providing guidelines about: – What are the services that a given component (say a routing algorithm) must provide. – How to ensure compatibility with other components. – How the component is initialised (possibly from a configuration file). – How the component is duplicated. Templates are used in the next layer to define new components.

10

• ✁

Custom modules

Provide a library of standard components implementing popular access schemes, routing algorithms, resource management policies etc ....

Define new components that implement a new behaviour or modify the behaviour of an existing component.

11

• ✁

Performance aspects

Modelling related: how to model the packet flow:

Use analytical models (such as ND

D

1 for CBR traffic) to derive the queue behaviour in the switches: – Behaviour for network of queues ? – Behaviour for aggregated or non-trivial traffic patterns ? – Computational tractability ?

Use parallel (multi-CPU) or distributed (multi-computer) simulations: – How to partition the processing load (balance processing load/data traffic) ? – Which communication facility among concurrent processes (shared memory, RMI, MPI, ...) ?

12

• ✁

Performance aspects (cont’d)

Implementation related (GaliLEO uses Java):

Optimise the data structures that are intensively used: – Balance processing time/processing space. – Performance of the Java Core Library: as new versions are released (previously had poor implementation, excessive synchronisation).

Take care of memory management, garbage collection is costly: – Favour object reuse. – Increment heap size. – Keep track of ongoing Java specifications (e.g. Real-Time Java).

13

• ✁

Performance aspects (cont’d)

Development tools/run time related:

Avoid byte-code interpretation (seamless multi-platform support is not mandatory): – Use a Virtual Machine with a Just-in-Time compiler which translates byte-code to native code upon class loading (IBM’s JDK under Linux boosts the execution speed by 90 %). – Use a byte-code to native code translator (e.g. TowerJ) to produce an executable. – Compile the Java source directly to native code (e.g. gcj)

much improvement is expected in this area.

14

• ✁

Project management

Two aspects are important:

The approach used to structure the project life cycle: – Must be incremental. – Must allow the reuse of previous experiences.

The communication among the teams: – The teams are remotely located, – with different working habits, – and different cultures.

15

• ✁

Project management (cont’d)

Project life cycle:

• 1. Describe GaliLEO objectives in plain text.
• 2. Describe the interaction between the program and the user

(interaction diagrams from UML).

• 3. Describe the system in terms of collaborating objects

exchanging messages (collaboration diagrams from UML).

• 4. Group the objects in classes (by writing Java stubs).
• 5. Fill in the gaps (by writing the actual methods).
• 6. Test the classes as the method bodies are written.

16

• ✁

Project management (cont’d)

Project communication:

Diagrams are used as much as possible.

The semantics of the diagrams are part of GaliLEO deliverables.

All deliverables are available in HTML from a web server.

For documents subject to multiple versions (e.g. the sources) a CVS server manages the documents and keep tracks of the changes (who made what).

The main platform is Linux and all tools that are used are available free of charge, however GaliLEO works on any computer with Java support.

17

• ✁

Project status

Start: September 98.

Participants: CNUCE-CNR (IT), CSELT (IT), ENST (FR), Public University of Navarra (ES).

Manpower: 8 Short Term Scientific Missions (1 or 2 weeks each) with 2.5 persons.

Funding: cost253 under the STSM budget, CNUCE-CNR under the 5 % Multimedia Programme.

Achievements: – An early version of GaliLEO is available for downloading. – An experiment was set up to demonstrate GaliLEO principles.

18

– A draft user’s manual is also available.

19

• ✁

Project status (cont’d)

Description of the experiment:

MEO walker constellation of 15 satellites with 4 permanent ISLs, 1 up link and 1 down link per satellite. Each UDL has a single beam using the whole UDL capacity.

4 stations distributed evenly on the earth surface. Each station issues connections to the other 3 stations. Connections have fixed duration, fixed inter-arrival time.

Resources in the satellites, stations, ISLs, UDLs and beams are described as a number of switchable connections.

Resources are managed using firm allocation (i.e. no

• verbooking).

20

Stations select first and last satellites according to highest elevation angle.

21

• ✁

Project status (cont’d)

Description of the experiment (cont’d):

Satellites route connections according to a shortest path algorithm using the number of hops as metric.

Satellites distribute routing information (i.e. the state of their resources) to the other satellites periodically.

When a handover occurs (i.e. in this case when a station leaves a satellite footprint), the connection is completely rerouted.

Example of measures: number of setup requests, setup successes, rerouting requests, rerouting successes, network load distribution.

22

• ✁

Conclusion

There is a need for a simulation tool dedicated to satellite constellations.

GaliLEO is a generic, Java based, simulator for studying channel access methods, routing and fault management in constellation environments.

The experience showed that COST actions can be a useful catalyst to support such initiatives.

23