IV-B.1 Visualization of CORBA Resources

  

Figure 5: A simple relationship model for satellite management

6#6

In order to visualize and monitor managed resources, a simple abstract relationship model of CORBA systems has been defined and integrated in the database of the management platform. The model is based on the layered architecture depicted in figure 5. The LEO/MEO satellite management scenario described in section II poses several requirements for a relationship model which is suitable for monitoring this CORBA-based environment. However, the topological relationships differ to a certain extent from relationships usually encountered in LAN segments. Therefore, we designed a relationship model suitable for satellite management requirements.

2em
• The highest layer (services) consists of distributed objects which may have references to each other and communicate through method invocations. An object offers services to potential clients and may utilize the services of other objects. This is true for telecommunication services implemented as CORBA objects.
• The second layer (call connections) comprises the calls in which one or more service objects may participate. A call may be switched either through one satellite to a ground station or (as it is the case e.g. for the Iridium system) over inter-satellite links where several satellites may be involved.
• The third layer (satellites) contains the systems over which connections are switched. Although more than one ground station may be visible from a satellite, there is only a n:1 communication relationship between satellites and ground stations.
• The lowest layer shows the ground stations which act as the communication backbone for the LEO/MEO satellite constellation.

Although this relationship model is very simple, it is able to handle the dynamic relationships between services, call connections, satellites and ground stations. Please note that the services represent the most fine-grained objects in this model and therefore are placed in the highest part of the hierarchy in our model although one could argue that because call connections depend on services, they should be placed on top of the hierarchy. We believe that the former representation fits better into the topology map navigation mechanism of network management platforms: By selecting a symbol representing a ground station, the platform user reaches a submap that shows all the satellites that maintain actually communication relationships to this one ground station. The subordinate submap shows the call connections that are switched over the satellite in question. If a user clicks on a call connection symbol, he will get the objects that represent the services currently involved in the call.