Wireless Satellite Network Monitoring using Distributed Multiagent Systems

Transcription

1 Wireless Satellite Network Monitoring using Distributed Multiagent Systems Frank Zimmer Communications Software Engineering Section SES ASTRA Château de Betzdorf, 6815 Betzdorf, Luxembourg Juan C. Burguillo-Rial Department of Telematic Engineering University of Vigo Vigo, Spain Abstract The trend in today s modern communication satellites is driving into the direction of spot beam technologies. This allows the illumination of distinct areas of the earth surface. These areas can be close to each other in which case frequency re-use through Space Division Multiplexing (SDM) paired with orthogonal polarization is applied, to reach beam separation. Areas can also be geographically separated in order to serve different continents. In any case, to ensure the Quality of Service (QoS), monitoring systems should be located in the coverage area of the beams to measure continuously the signal quality. This paper introduces a software architecture for a testbed to be used in a network of interconnected, fixed and mobile wireless monitoring systems using distributed multiagent systems. 1 Introduction 1.1 Satellite Spot Beam Technology Looking at the situation in the satellite telecommunication sector it becomes obvious that nowadays frequencies are a scarce resource. This situation increases the demand for spacecrafts using beam-forming networks or multiple antennas in order to shape distinct illumination areas. Neighboring spot beams use different frequencies to avoid interference. Additionally, orthogonal polarization could be used to increase isolation between the spot beams [7]. The scenario mentioned above refers to an environment where the spot beams are relatively close to each other. One can also imagine that there is another scenario in which a spacecraft comes with spot beams, which serve areas far more apart from each other. One spot beam might serve consumers in the South (e.g. Spain, Portugal) while the other one serves consumers in the East e.g. Russia). Even the illumination of two continents might be possible. Figure 1 shows the service area of a satellite with eight transmit spot beams and one receive spot beam[14]. (a) Downlink Spotbeam (b) Uplink Spotbeams Figure 1. ASTRA 1H Ka-Band Spotbeams 1.2 Quality of Service Challenge In order to ensure a high reliability and an extraordinary Quality of Service (QoS) continuous monitoring of the satellite signal is required. Current portable solutions on the market might be implemented in one of the following ways: Solution 1. After a degradation of the signal was communicated by a customer, a portable system is installed in the area of interest to collect data. Based on the outcome of this test countermeasures have to be taken. An operator is always close to the system during this time limited mission. Solution 2. A portable measurement system is installed in the coverage area and an operator or a piece of software dials-in to the measurement system from the Satellite Control Facility (SCF) and downloads measurement results. This mission might take longer, since not staff is required at the installation site.

2 Solution 3. A portable measurement system is installed in the coverage area and connects automatically to the SCF in order to notify the operator about an incident. This is usually the case for long term tests. Apart from the first solution where an operator is operating the measurement system, the others use in general ISDN or analogue modem lines to communicate with the SCF. Novel measurement system could be media agnostic and work with any kind of communication infrastructure be it satellite link, wireless link or fixed terrestrial lines. 1.3 Measurement System SES ASTRA operates two categories of measurement systems, portable measurement systems mainly used for signal reception and fixed installed measurement systems providing capabilities for signal transmission and reception. Figure 2 shows one type of mobile measurement systems, which are used to monitor the satellite signal in the coverage area. Figure 2. Mobile Measurement Systems Figure 3(a) and 3(b) illustrate a solution for a fixed measurement system. This one belongs to the group of In- Orbit-Test Systems (IOTS). The IOT system is a high flexible measurement system, with interfaces to different ground systems and satellite telemetry. (a) Antenna System (b) Instruments Rack Figure 3. IOTS 2000 All these systems have in common that they perform measurement tasks individually but not in cooperation. Data collected by the portable measurement systems during measurement campaigns are retrieved via modem and then correlated with each other in a subsequent step. 2 Distributed Measurement Systems The idea is to design and set-up a network of monitoring stations, which communicate with each other via wireless communication link. Preferable, the system could make use of a two-way satellite link, in order to make the selection of installation sites independent of existing terrestrial communication infrastructure. Anyhow, wireless terrestrial networks are also interesting as complementary technology. Stations integrated into this network exchange information via a hub, located in Betzdorf. The physical functionality of the hub is similar to the Base Transceivers Stations used in 2G mobile communications. Since satellite capacity is scarce and expensive, each of these measurement stations shall implement algorithms to analyze the received signals, to draw conclusions from the outcome of the analysis and to learn from this situation through communication with the other systems, if needed. Due to the fact that other systems might have another opinion additional service providers could be consulted to retrieve more information. These service providers could provide for instance satellite telemetry data and historical satellite attitude records. After all data has been collected and correlated, the station decides whether it contacts an operator to report an incident or to consider it as normal situation for instance after a maneuver or antenna re-pointing taking into account his internal knowledge base. In the latter case no operator will be contacted. In the beginning, the monitoring system has to go either through a learning process supervised by an operator until the system gained sufficient knowledge, or it might use existing knowledge and build upon this. Such measurement systems have to work as reliable as possible to minimize false alarms and to take correct decisions. This is important since operator notification does not means that a pager call is triggered or an is sent. It s more than that. A notification could be sent to a system in the SCF with an incident report. This system could pop up a message on the operator s console showing the incident report and proposing countermeasures. Figure 4 shows a communication structure that comprises one fixed measurement station (IOTS 2000) and two portable ones.

3 interface to the outside world. The COMSS in its simplest form might allow a connection to one media only such like satellite or 3G network. In its most complex form it might provide an interface to an underlying, media agnostic, architecture. An example for such an architecture is given in figure 6. Figure 4. Communication Infrastructure 3 System Architecture The purpose of the following section is to introduce an architecture for such a measurement system. The focus lies on the portable systems since they are less complex than fixed systems. Anyhow, the design is flexible enough so that it can also be applied and extended to suite the needs of other classes of measurement systems. Figure 5 shows the system architecture for an Advanced Portable Measurement System (APMS). Figure 6. CALM Architecture The Continuous Air interface for Long and Medium distance (CALM) aims at providing a media agnostic solution, for integration into moving vehicles. 1. The last of the three subsystems is the Position Subsystem (POSS). The purpose of POSS is to provide position information needed by the measurement system to point the antenna to the satellite. This subsystem is optional since operators can determine the position during system deployment and update the knowledge base manually. The remaining components of the system will be described in section 5. 4 Agents and Multiagent Sytems Figure 5. Measurement System Architecture The APMS is subdivided into three subsystems orchestrated by the Measurement System Execution Logic (MSEL). The Device Subsystem (DEVSS) comprises the devices needed to perform the measurements such as instruments and programmable logic controller (PLC). The DEVSS is that part which differs most likely between different systems depending on their mission. Mission requirements can range for receive only capabilities in one frequency band up to complex missions where receive and transmit capabilities are needed in more than one frequency band such as Ku and Ka band. The Communication Subsystem (COMSS) provides an The software architecture is based on a multiagent system. An multiagent system is a system composed of multiple interacting intelligent agents [10]. An intelligent agent is a computer systems which can be best described by the characteristics reactivity, proactiveness, and social ability [12]. Distributed MAS as understood in this paper stresses the idea of a regional, European or even global network of interconnected measurement system. Most of the systems, but not necessarily all of them, would be based on multiagent technologies. Where there is no possibility to employ agents directly, bridging or wrapper agents could help to integrate those measurement systems into the network. The systems might belong to one satellite operator but it is also possible that they belong to different operators and participate in the network just to provide their services, most likely not for free. 1 ISO TC204 WG16 is in charge of the standardization process

4 5 Software Architecture The Measurement Execution Logic is implemented by a set of agents communicating with each other using an Agent Communication Language (ACL). Communication with the subsystems is done via the ASCII Signaling Protocol (ASiP). ASiP was developed in SES ASTRA in the frame of other projects and could be reused here. The same holds true for the communication between agents and existing servers implemented using the Common Object Request Broker Architecture (CORBA). The protocol used here is the Internet-Inter-ORB-Protocol (IIOP). It should be clear that the objective of this architecture is to test the suitability of multiagent systems for future measurement systems and not to reinvent the wheel. Whenever possible, existing components will be integrated in the testbed. Figure 7 illustrates the high-level software architecture. Figure 7. Measurement System Execution Logic Five agents are foreseen to be implemented. User Agent. In the testbed implementation, the User Agent will play only a minor role, since it is planned to use a command line interface in the beginning. In future versions, the User Agent might track the activities of the operator in order to analyze in what he is particularly interested in. With this information, it will adapt the user interface to his behavior over time. The User Agent communicates with the Information Agent in order to retrieve measurement data, configuration data and to access the Blackboard. From the Coordination Agent, it receives system status information. Coordination Agent. The task of the Coordination Agent is to coordinate all activities taking place within the measurement system and in which the measurement system plays a supporting role. It is in charge for planning and scheduling the measurement activities either for its own mission or a mission in collaboration with other distributed monitoring systems. Here it triggers the execution of tests, controls their execution and intervenes in order to run a higher prioritized task. It manages all internal resources and decides whether another system has access to them and authorizes it if this is the case. For example, remote agents might be interested in accessing the Blackboard. The Coordination Agent will decide whether the remote agent has read-only, write-only or read-write access. The Coordination Agent is also in charge to work out alternatives in case of problems with the local hardware and informs human operators about critical issues. Finally it decides whether a remote agent is eligible to receive measurement results. The Coordination Agent works closely together with the Information Agent in order to find alternative solutions in case of problems, to retrieve and updated system configuration status, and to forward measurement results to remote agents including human operators. It also provides the User Agent with the current system and measurement status. Close cooperation with the Communication Agent is required for information exchange with remote agents running on other measurements systems. Measurement Agent. The Measurement Agent is primarily responsible for the correct execution of the measurement procedure. For that, it needs to communicate with all devices in the measurement systems. Once a measurement task has been started by the Coordination Agent, it is left alone with the task. Task related configuration parameters are requested from the Information Agent and results are delivered back. During times when no measurement takes place, the agents maintainer task periodically checks the availability of all devices and performs system calibration. There are three solutions for the integration of measurement procedures. The first one foresees that the measurement task is hard coded into the agent. This is the simplest but least flexible one. The second solution implements a scripting engine into the agent. The measurement procedures, defined in a scripting language, would then be executed by the agents scripting engine. The last possibility would support agent mobility. In this case, the Measurement Agent would be replaced by a new Measurement Agent. Anyhow, the proposed architecture is not yet really suited for mobility. The testbed will implement the second solution and use either a scripting engine which is available on the market or a homemade one. The Measurement Agent communicates with the Infor-

5 mation Agent from which it receives measurement configuration data and to which it posts the measurement results. In the future it could also receive the measurement procedure script, which it should execute. The communication with the Coordination Agent is limited to the exchange of measurement status information and execution control requests from the Coordination Agent such like start, stop, pause and resume measurement. In future version the Coordination Agent might also name the test procedure to be execute. Information Agent. The Information Agent s main tasks is management and provision of information [5]. To do so, it makes use of components such as the Blackboard, the Data Repository and Knowledge Base. The Data Repository is used to save the measurement results and holds information about the satellite fleet, communication payload and system calibration parameters. It is largely the same for at least all portable measurement systems and contains a subset of the information which is available in the fixed measurement systems. The Knowledge Base contains information about the system configuration in terms of equipment and constraints such a maximum transmit power, dedicate receive and transmit paths. This information is used to determine whether a system can contribute to a mission in which distributed measurement systems are needed. The Knowledge Base could also be used to propose alternatives in case a system failure has been observed. System failures could happen when there is faulty instrument, the communication link to other stations is down during a collaborative mission or in case software components are no more available e.g. database crash. The testbed implementation will take some representative scenarios into consideration. Case-based reasoning (CBR) [6] seems to be one appropriate candidate for the implementation of an automated reasoning and machine learning techniques. CBR solves new problems by taking into account one or more existing solutions already applied to similar cases. An update of the Knowledge Base takes place each time a problem has been successfully solved. Information Agent and Coordination Agent work close together especially when it comes to situations where redundancy strategies have to be applied, or the reaction on critical events is required. Communication Agent. The Communication Agent s main task is the management of the communication link to other measurement systems and to the headquarter. Since a communication link is only needed when there is a common mission in which collaboration is required or an incident was observed, this agent has to make sure that no bandwidth is wasted and no unnecessary costs are generated. In this case it might also decided which type of link shall be used. The criteria could be the size of information to be exchanged. In the case of small messages a narrow band link would be fully sufficient, whereas in the case of measurement data exchange a broadband link might be mandatory. The Communication Agent also has to react on incoming messages from remote agents and forward them to the Coordination Agent. 6 Implementation Technologies Operating System. APMS could be implemented on a Linux platform. Data Repository. PostgreSQL, a free available Relational Database Management System (RDMS), could be used for the implementation of the Data Repository. Knowledge Base. Jess, a rule engine and scripting environment written completely in Java, could be used to implement reason capacity using rule based knowledge. Another solution could be based on JClips - CLIPS for Java, which is a JNI wrapper around the original C Language Integrated Production System (CLIPS). CORBA ORB. JacORB, is a free Java ORB, proofed to work well with the IOTS 2000 instruments server. It could be used to interface between the Measurement Agent and the already existing device servers. Agent Platform. JADE is a freely available, FIPA [3] compliant agent platform, providing agent development, test and runtime environment. Java. Due to the wide acceptance of this language and the fact that it can be downloaded for free makes it to the No. 1 language for the testbed. Another reason is that some of the previously listed tools require Java. BeanShell. BeanShell is an Open Source Java language interpreter which could be used to specify the measurement procedures to be executed in the agent. 7 Related Work Since years active work is going in the realms of autonomous space systems. A good overview over autonomous intelligent space systems can be found in [8]. The authors address amongst other topics autonomous deep space missions, autonomous mission tools, and the future of space robotics. [4] looks at practical software design requirements for rule-based intelligence in next generation systems. Although a bit outdated, this paper is in so far interesting as it describes RAISE a Reusable Agent Intelligence Software Environment for information access. In [13] the authors describe the Phillips Executive Agentbased Controller Helper (PEACH), which aims at implementing a decision taking tool which takes into account overall spacecraft state, current mission requirements, and future mission objectives.

6 The paper from Weihmayer and Brandau [9] explores close cooperation among heterogeneous agents, and is motivated by the requirements of a specific application in the telecommunications network management: customer net control and joint private/public network management. The paper [1] introduces the concept of mobile agents as an alternative method of structuring software to control distributed systems. [2] reports on the application of NASA s Autonomous Sciencecraft Experiment (ASE) capabilities across a fleet of Earth-observation space platforms, further demonstrating on the value and potential of this emerging autonomy-based science investigation paradigm. The objective of ASE was to demonstrate onboard autonomy for both science and engineering functions. The article by Steven Willmott [11] describes the activities taking place in the frame of the Agentcities and open- Net testbed. There is definitely the trend moving away from covering a single region and instead focusing on a large-scale collaborative effort between research communities around the world. 8 Benefits For Satellite Operators Experiences resulting from the implementation of the testbed could be used to integrate systems of different satellite operators into a virtual distributed measurement system. With the implemented autonomy and learning capabilities, test campaigns could then be effectively and efficiently coordinated between systems belonging to same and different operators. 9 Future Work Since the focus is on a testbed implementation, there are subjects which have not been addressed in this paper. Security aspects such like malicious hosts or agents must be considered and countermeasures implemented, when agent mobility is one of the future objectives. Also the usage of ad-hoc agents seems to be a promising approach for high reliable measurement systems. Ontologies, which are mandatory in order to let the systems understand about what they are talking must be defined and implemented. Otherwise measurement systems from operator A might be able to exchange messages with system from B, but they would not know about what they are talking. When it comes to the situation that measurement systems wish to collaborate, then negotiation becomes an important feature. Questions such as which protocol could be used and how to reach a consensus must be addressed, too. 10 Acknowledgment This paper was written in the frame of the virtual PhD program offered by the Departamento de Teoría de la Señal y Comunicaciones, Universidade de Vigo. The work was mentored by Professor Juan Carlos Burguillo-Rial from the Departamento de Ingeniería Telemática, Universidade de Vigo to whom I own my deepest gratitude for his excellent support during the time I participated in his course Networks and Intelligent Systems. References [1] S. Appleby and S. Steward. Mobile software agents for control in telecommunications networks. In Software Agents for Future Communication Systems. Springer, [2] S. Chien, B. Cichy, A. Davies, D. Tran, G. Rabideau, R. Casta n, D. Mandl, S. Frye, S. Shulman, J. Jones, and S. Grosvenor. An autonomous earth-observing sensorweb. IEEE Intelligent Systems, 20(3), [3] FIPA. FIPA -The Foundation for Intelligent Physical Agents. [4] B. N. Grosof, D. W. Levine, H. Y. Chan, C. J. Parris, and J. S. Auerbach. Reusable architecture for embedding rulebased intelligence in information agents. Technical Report RC (12/05/95), IBM Research Division, T.J. Watson Research Center, [5] M. Klush, S. Bergamaschi, P. Edwards, and P. Petta, editors. Intelligent Information Agents - The AgentLink Perspective. Lecture Notes in Artificial Intelligence LNAI Springer, [6] R. L. d. Mantaras. Case-based reasoning. In G. Paliouras, V. Karkaletsis, and C. D. Spyropoulos, editors, Machine Learning and Its Applications. Springer, [7] G. Maral and M. Bousquet. Satellite Communications Systems; Systems Techniques and Technology. John Wiley & Sons Ltd., 3rd edition, [8] A. W. Stroupe, S. Singh, R. Simmons, T. Smith, P. Tompkins, V. Verma, R. Vitti-Lyons, and M. Wagner. Technology for autonomous space systems. Technical Report CMU-RI- TR-00-02, The Robotics Institute, Canegie Mellon University, [9] R. Weihmayer and R. Brandau. Cooperative distributed problem solving for communication network management. In Software Agents for Future Communication Systems. Springer, [10] G. Weiss, editor. Multiagent Systems; A Modern Approach to Distributed Artificial Intelligence. The MIT Press, [11] S. Willmott. Deploying intelligent systems on a global scale. IEEE Intelligent Systems, 19(5), [12] M. Wooldridge. An Introduction to MultiAgent Systems. Wiley, [13] P. Zetocha and J. Ortiz. An agent for increased space operations automation. [14] F. Zimmer and A. Kurešević. Corba based distributed systems for remote in-orbit satellite test. In IONA World 1999, Dublin, 1999.