Design of a Simulation Environment for Space-Based Information ...

Proceedings of the 2008 IEEE Systems and Information Engineering Design Symposium, University of Virginia, Charlottesville, VA, USA, April 25, 2008

FPM1Sim,DM.3

Design of a Simulation Environment for Space-Based Information Management and Distribution David W. Cleaves, Tayloe L. Berbert., Brandon Y. Im, Derek W. Yeung, Gerard P.Learmonth, Sr.

Abstract— Many studies have previously been conducted on the subject of service oriented architectures in traditional terrestrial networks. Researchers have only recently begun to apply these studies to space-based networks. This project focuses on the design of a simulation environment for running distributed software services in a space-based network. Specifically, a constellation of linked satellites in a LEO (Low Earth Orbit) configuration is used as the space-based architecture to model. The environment was created by integrating a combination of commercial, open source, and custom written software. The major components of the environment include an orbital propagation and simulation tool, graphical user interfaces for service request initiation and results, a network emulator, a routing module, and service oriented architecture based processing applications. Validation using a simple test scenario showed that the final design of the environment functions in an accurate manner.

R

the concept of a constellation. Researchers have only recently begun to investigate the possibilities of a spacebased approach to satellite communication networking [2]. The implementation of a space-based satellite network would allow a user request to be broken into several discrete service requests. These service requests could then be distributed among the networked satellites. For example, a mobile ground-based user could request the tracking of a certain object in the field. This request could then be divided into services such as imagery collection, object classification, and object tracking. Each service could be handled by a different set of satellites in the network. Upon the completion of each service, the system would coordinate the output from each set of satellites and display the integrated results to the user.

I. INTRODUCTION

ECENT disasters on American soil, such as Hurricane Katrina and the attacks on September 11, 2001, have highlighted America’s need for improved surveillance capabilities. One of the proposed solutions is the use of a space-based satellite communication network consisting of Low Earth Orbit Satellites (LEOs). Satellite communication networking can generally be divided into two categories: ground-based approaches and space-based approaches [1]. In a ground-based approach, satellites simply collect information and transmit it to terrestrial stations where the data are processed. In a spacebased approach, the satellites have processing capabilities. Therefore, the satellites collect and process the data in space and only the results are sent back to Earth. Theoretically, this approach can improve overall performance because terrestrial links are often congested. The space-based approach also gives users greater flexibility in terms of accessibility. If designed correctly, a constellation of satellites would be able to provide constant coverage to any location on Earth. Figure 1 illustrates a simple example of

Manuscript received April 7, 2008. D. W. Cleaves is a fourth year Systems Engineering major at the University of Virginia, Charlottesville, VA 22903 T. L. Berbert is a fourth year Systems Engineering major at the University of Virginia, Charlottesville, VA 22903 B. Y. Im is a fourth year Systems Engineering major at the University of Virginia, Charlottesville, VA 22903 D. W. Yeung is a fourth year Systems Engineering major at the University of Virginia, Charlottesville, VA 22903 G.P. Learmonth is a Research Associate Professor with the Department of Systems Engineering at the University of Virginia, Charlottesville, VA 22903.

1-4244-2366-8/©2008 IEEE

Fig 1., GEO and LEO satellite constellations [3]

Coordinating communications between satellites is complex, and physical modeling is impractical. Therefore, this project focused on the creation of a simulation environment for a satellite communication and processing network consisting of LEO satellites. This system simulates the distributed collection and space-based processing of data as well as the request generation and display of final results. Image classification was chosen arbitrarily as the service to model, although the results of the project could easily be extended to any number of other services. Image classification refers to the automatic identification of potential objects of interest in an image taken by a satellite. Simulation users can create service requests via a simple interface. An emulation system interfaces with an orbital propagation and simulation tool to simulate the flow of data through the network, and a service oriented architecture based suite of applications was created to handle communications between different classes of satellites. Additionally, the code for the project was designed,

141

organized, and documented in a way that should allow researchers to easily utilize or extend upon its functionality. II. REVIEW OF TECHNICAL LITERATURE A. Existing Research While an ideal method for testing applications on a network would be to create a live network test bed, this is not a feasible solution for a satellite network due to the large costs associated with deploying satellites into space. Using a live network may also make it difficult to control certain parameters that a researcher might be interested in changing, such as packet queue length [4]. Because of this, satellite networks are generally modeled using either network simulation or network emulation. Network simulation is a methodology that uses discreteevent simulation to model the state of a network at a given time. Events such as packets being enqueued or dequeued in a router, packets being dropped, or packets being sent between applications are tracked by the simulator [4]. Additionally, simulations use an artificial representation of time, as the current time in the simulation is the time of the event being processed. This allows the simulation software to evaluate an event in a few minutes that might take hours in real life to complete [4]. One of the most prominent network simulators currently in use today is ns-2, which is an open source program [5]. Ns-2 is highly flexible, and contains a number of modules that have been created by researchers. One important module for this project is the Monarch project’s wireless module. This was developed by researchers at Carnegie Mellon University, and allows ns-2 to simulate wireless links, including satellite links [4]. In addition to simulation, another methodology that can be used for performance evaluation is network emulation. Network emulation is essentially a hybrid of simulation and a live network test bed. In emulation, actual networking protocols are used to send packets between computers, but the links that the packets travel over are modeled to correspond to the actual network environment [6]. There have been two main papers that have contributed to the field of network emulation for space based networks. The first paper, titled “Design of a space based Internet emulation system” was written in 2002 by Sujit R. Baliga of the University of Kansas. The approach described by Baliga was to “emulate the space communication environment characteristics in hardware” by “implement[ing] innovative algorithms for emulating the latency and bit error rate characteristics of space communication links” [7]. The end result of Baliga’s work was a program called the Space Based Internet (SBI) emulator. In the SBI system, each computer represents a satellite containing an Ethernet device that is capable of communicating with other satellites. Operations related to the emulation interface are performed by the Virtual Ethernet device layer within the kernel of the Linux operating system. This means that the emulator can 1-4244-2366-8/©2008 IEEE

only run on one operating system, and may possibly only work on one version of the operating system [4]. The kernel modifications made by SBI mean that the program has fairly low portability [7]. This low portability is the reason for the work done by Shaun Endres in 2004 [4]. Endres created a network emulator by integrating a satellite orbit simulator with a proprietary link layer emulator written in C#. The major difference between Endres’s and Baliga’s work lies in the fact that Endres’s emulator is written in the user space, and does not make any kernel modifications. Endres’s emulator captures packets before they are ever sent to the operating system. The packets are then passed through a filter to apply delay and error bit rates that resemble those found in a space environment [4]. This allows different upper layer OSI protocols such as the routing algorithms described in the above section to be tested [4]. Endres’s implementation is more flexible than Baliga’s, as it can be installed on a number of different operating systems. B. Limitations of Existing Research While Endres’s emulator is useful in the sense that it can accurately capture and delay packets being sent between applications running on simulated satellites, it is only one aspect of a robust simulation environment. The applications that actually run on the satellites have to be written, which introduces a number of challenges in the areas of routing, messaging, and processing. III. DESIGN SPECIFICATION AND METHODS A. System Requirements Once the problem had been defined, the project team involved itself in the task of identifying the major requirements of the simulation environment. The major requirements that were generated can be summarized as follows. The system needs to be able to accurately model the orbital properties of a constellation of satellites connected through laser communication links. The system needs to be able to assign applications to run on one or more of the satellites in the constellation. The system needs to accurately model the communication delays associated with the physical properties of the communication links. The system needs to contain service-oriented applications that contain messaging and processing protocols for image classification or other services which actually run on satellites during the simulation. The system needs an intuitive user interface to initiate service requests and receive results. The integrated architecture that resulted from this project was designed to fulfill all of these requirements.

142

B. Construction and Implementation The simulation environment consists of a number of separate pieces that were integrated by the project team. A combination of commercial, open source, and custom designed software was utilized to create the environment. All of the custom written software was coded using the C# programming language and the Microsoft .NET framework. This language was chosen due to its flexible GUI creation capabilities, as well as its ability to easily integrate with the chosen emulator. Additionally, AGI Inc. provides a C# library that can be used to connect custom written software to a running STK scenario and issue commands remotely, which is a key aspect of the system’s functionality. Figure 2 shows a high level view of the architecture of the system. Each two way arrow generally represents a remote network connection using TCP sockets. TCP was chosen, as it has been shown that TCP is a viable communications protocol for satellites in a space network [8].

form that allows entry of longitude and latitude coordinates for the requesting facility and target locations, and a button that begins the emulation. The second main feature of the GUI is the results form, depicted in Figure 4.. This form is displayed after the requested service has been completed, and displays the results of the processing. In the case of image classification, the results form contains information such as the picture taken by the satellite that is being classified, any objects identified within the picture, the time needed to classify the objects, and the confidence level in the result.

Fig. 3, Simulation GUI

Fig. 2, System architecture high level view.

Brief descriptions of each of the system architecture components can be seen below. C. STK Analytical Graphics Inc.’s Satellite Tool Kit (STK) is a commercial software package that can be used to design, simulate, and analyze complex satellite based scenarios. Scenarios can include individual satellites and constellations, sensors, communication transmitters and receivers, ground facilities, targets, and a host of other objects. STK also has extensive analysis capabilities, and can generate a large number of different reports for a scenario. These reports can be accessed by remote programs through the STK/Integration module, which allows programs to query STK for information over a standard TCP/IP Internet connection. The simulation environment uses STK to simulate the constellation network that is being analyzed, and to calculate information about the constellation at different points in time. D. Graphical User Interface The point of entry for researchers using the simulation environment is the graphical user interface (GUI). Depicted below in Figure 3, the initial screen of the GUI is a simple 1-4244-2366-8/©2008 IEEE

Fig. 4, Results GUI

E. Emulator As discussed in the literature review, the distributed space network emulator developed by Shaun Endres of Case Western Reserve University was used as the primary means of modeling the physical properties of the communication links of the satellite constellation network. For the most part, the source code of the emulator was unmodified, as it already contained all of the functionality needed for this project in its most recent version. The emulator consists of two core functional pieces, the coordinator and the traffic

143

shapers. The coordinator is essentially the application that manages the connection between STK and the traffic shapers. It interacts with STK to determine the number of satellites in the scenario, and assigns applications that connect to the emulator to run on the satellites. It also generates tables of statistics from STK for the communication links between each individual satellite and every other satellite in the scenario. The statistics include propagation delay, bandwidth, and bit error rate. The coordinator parses the STK tables into text output and sends them to the traffic shapers at given intervals in time. The traffic shapers are the other main aspect of the emulator. They receive the link statistic text strings from the coordinator in order to apply realistic communications properties to bits being sent between application nodes. When one application attempts to send data to another application, the traffic shapers intercept the data and accurately apply the parameters from the link update table for that node based on the current time in the simulation. F. Routing Module The routing module is used to determine what satellites are used to send a message over the constellation. While the project team initially had planned on implementing a more advanced routing system into the simulation environment, time constraints necessitated that a simpler method be used. Because this project is based on the assumption that satellites will have the capability to execute software programs, it is feasible to assume that each satellite in the constellation being tested could have software similar to the STK package installed on it prior to launch. STK has the capability to construct routing “chains” between two satellites, which consist of lists of all the intermediate satellites that messages need to pass through in order for the two satellites to communicate with each other. STK is also able to calculate the duration in seconds that each chain is open for. The project team decided to utilize these chain reports as the basis for our framework’s routing system. A Router class was written in C# that contains methods to connect to STK, generate chain reports, and parse the raw STK text output into a more usable form. Whenever an application running on a satellite needs to determine the route to any other satellite, the application instantiates and utilizes a Router object, which returns a viable route string based on the current simulation time. An example of the raw STK output can be seen in Figure 4.

1-4244-2366-8/©2008 IEEE

Fig. 4, STK strand access report raw text output

G. SOA Applications While the concept of a service-oriented architecture can be defined in a number of ways, in this project it simply refers to the separation of functionality into different units, which communicate with each other by passing data over a network. The two main functional units developed for this project were the service manager and service processor applications. These are the applications that would be installed on the satellites in an actual implementation of a networked satellite constellation. H. Service Manager The service manager satellite essentially acts as an organizer for incoming service requests. When a new service request is initiated by the user, the satellite that is overhead the requesting ground facility routes the request to the satellite that is running the service manager application. The service manager then determines which satellite is overhead the target, and routes a request to that satellite to take a picture of the specified target location. When the image is eventually routed back to the manager, the manager then sends the image out to one or more service processors, which perform the actual classification. When the all of the classification results are returned to the manager, the manager determines which satellite is overhead the user at the current time, and routes the information back to that satellite, which then sends the information back to the requesting facility. Because it is possible that multiple requests may be received by the service manager at the same time, the manager assigns unique ID numbers to each request so that it can track the progress of each task.

144

I. Service Processor The service processor application runs on all of the satellites in the constellation except for the service manager satellite(s). For the most part, the satellites running the service processor application will only need to serve as simple routers of messages or image collectors. However, some satellites need to perform the task of actually classifying images received from a service manager satellite. Because at least two satellites will always be in constant one hop communication with any given manager satellite, the service manager always attempts to distribute the classification process to these satellites first. However, if these two satellites are busy, the service manager is forced to find an alternative. J. General Application Design Features Both the service manager and service processor applications were designed in a similar way. Each time an application is opened, it is assigned a unique IP address and port combination. This allows the application to link into the emulator and be assigned to one of the satellites in an open STK scenario. One common aspect of both application types is that they both utilize a custom Command data type. This data type contains a list of the possible message types that can be sent and received by the applications. The message types are as follows: • • • • •

Request – Message corresponding to an initial service request from a user. Collect – Message ordering satellite to collect an image at a given location. Image – Image data received from an image collector satellite. Process – Message ordering satellite to perform a service, in this case image classification. Response – Message containing the results of a service, in this case image classification.

IV. TESTING AND EVALUATION In order to validate that the simulation environment functions correctly, a simple test case scenario was designed by the project team. The test case features an STK scenario containing a satellite constellation of 18 satellites in a circular orbit of the Earth at approximately 2000 kilometers. The satellites were identified simply as sat1-sat18. The test case calls for three service requests to be initiated from a facility in Charlottesville, the details of which can be seen in Table 1. London was chosen twice, but at different times, in order to ensure that the system correctly accounts for changes in routes due to the movement of the satellites over time. Target City

Target Coordinates

London Baghdad London

51.32º N 0.5º W 33.2º N 44.3º E 51.32º N 0.5º W

Request Time (from start of simulation) 10 seconds 30 seconds 200 seconds

Table 1. Test case properties

In addition to the Command type, the message strings that are passed between the applications may contain a number of other semi-colon separated pieces of information, such as a route string, target coordinates, or a request ID number. Each application type also contains a simple GUI that logs important events, so that users can visually monitor the simulation as it proceeds. A screenshot of the GUI for a service manager can be seen in Figure 5. While the team had initially planned to further integrate an existing implementation of image classification software into the system, time constraints forced the team to simply simulate this functionality instead. When a processor receives a Process command with a picture object, a random delay is applied to simulate the task of classifying the image, and a random object type and random confidence level are also generated.

1-4244-2366-8/©2008 IEEE

Fig. 5, Manager application GUI and log

After running the simulation, and initiating the service requests at the appropriate times, the system executed successfully without any errors. Table 2 shows the routes logged in the SOA applications for each of the service requests. The output of the SOA applications showed that the requests were moving through the satellite constellation in an accurate manner, and were being processed correctly. These routes were inspected manually in the STK scenario, and were all valid. The routing system was also able to detect the change in the satellite constellation topology, and properly adjusted the route to London on the second request. This is seen in the substitution of sat7 as the image collector, rather than sat3 that had previously been overhead the target. An examination of the logged output of the emulator also showed that the packets being passed between the SOA applications were being captured and delayed appropriately.

145

Request number 1

2

3

Route used UserFacility->sat2->ManagerSat1->sat2>sat3->sat2->ManagerSat1->Processors (sat5, sat6) -> ManagerSat1->sat2>UserFacility UserFacility->sat2->ManagerSat1->sa4-> ManagerSat1->Processors (sat5, sat6) -> ManagerSat1->sat2->UserFacility UserFacility->sat2->ManagerSat1->sat2>sat7->sat2->ManagerSat1->Processors (sat5, sat6) -> ManagerSat1->sat2>UserFacility

[5] [6] [7] [8] [9]

Table 2. Logged application output from test scenario requests.

V. CONCLUSION This project sought to develop a simulation environment capable of modeling distributed services on a constellation of inter-networked satellites. To accomplish this goal, a number of different independent software components were successfully integrated into a larger architecture. There exist a number of opportunities for future work on this particular system and in the area of space-based computing in general. One way in which the simulation environment could be improved on is through a more realistic routing method. Additionally, the topic of multicast groups in a satellite constellation could be explored. This would allow groups of satellites in a constellation to be combined into ad hoc multicast trees to perform different service capabilities, which would allow for a great deal of customizability in terms of the number and type of services that could be performed. Some research has already been performed in this area [9]. Finally, the method used by the current environment to queue incoming service requests could be improved, as the current design does not account for multiple incoming requests in a very elegant manner. ACKNOWLEDGMENT The capstone team would like to thank our technical advisor, Professor Gerard P. Learmonth, for providing feedback and guidance on the project throughout the past year. We would like to thank Roy Hayes for providing technical support with STK and knowledge regarding satellite constellations in general. We would also like to thank Professor Barry Horowitz, Jianping Wang, Rick Jones, Jonathan Bao, and Bob Dorsey for their support. REFERENCES [1] [2] [3] [4]

Wood, Lloyd. “Internetworking with Satellite Constellations.” PhD Diss. University of Surrey, 2001. Floreani, Daniel. “Internet to Orbit: Exploring the Potential of IP Networking Technologies in Space.” Packet Magazine 17.3 (2005): 19-25. Orbits, Where Do You Want it? Retrieved February 14, 2008, from Operation Montserrat Web site: http://www.spacecentre.co.uk/emission/satellites/orbits.aspx# Endres, Shaun and Behnam Malakooti. “Space Based Internet Network Emulation for Deep Space Mission Applications.”

1-4244-2366-8/©2008 IEEE

146

Proceedings of the 22nd AIAA International Communications Satellite Systems Conference and Exhibit 2004 (ICSSC), Monterey, CA, 2-9 May 2004. Breslau, Lee, et. al. “Advances in Network Simulation.” IEEE Computer 33.5 (2000): 59-67 Noble, Brian and Mahadev Satyanarayanan. “Trace-Based Mobile Network Emulation.” Proceedings of ACM SIGCOMM, Cannes, France, September 1997. Baliga, Sujit. “Design of a Space Based Internet Emulation System”. MS Thesis,University of Kansas, 2002. Hogie, Keith, Ed Criscuoluo, and Ron Parise. “Using Internet Protocols and Applications in Space.” Computer Networks 47.5 (2005): 603-650. Ekici, Eylem. “A Multicast Routing Algorithm for LEO Satellite IP Networks”. IEEE Transactions on Networking 10.2 (2002): 183-191.