1 of 7

ON MANAGING INTELLIGENT SATELLITE NETWORKS – AN EVOLUTIONARY APPROACH IN POLICY BASED DISTRIBUTED MANAGEMENT

Greg Totsline and Rajeev Gopal Hughes Network Systems, LLC

11717 Exploration Lane Germantown, MD 20876

ABSTRACT

Early satellite based communication systems for voice and data consisted of bent pipe communications and could be managed through a traditional TT&C system. Newer systems are emerging where satellite payloads are now doing more than just repeating a signal, they are interpreting the information received and making intelligent decisions on how to process the data. Satellite payloads exist and new ones are being designed to operate like network nodes in the internet. Capacity is also allocated by these latest generation payloads dynamically, in response to changing user needs and environments. Managing these systems with a COTS network management system is not a viable solution. The advent of intelligent payloads requires network management systems that provide more than just hardware status. Instead, higher layer functions such as capacity management, dynamic bandwidth allocation, quality of service in a packet switched environment, and packet routing must be planned and managed. Policy based network management and supporting standards based management protocols serve as the building blocks for distributed, intelligent management. These satellite network management topics are surveyed in this paper.

INTRODUCTION

The primary focus of this paper is on managing communication network services in an evolving satellite technology environment. The outline of this paper is as follows:

• Discuss the functions and issues concerning the management of satellite communication systems

• Review the current state of network management standards and technologies

• Describe the emergence and growing trend towards the deployment of “intelligent” satellite networks

• Discuss the unique capabilities of intelligent satellite networks and propose an evolutionary approach to managing those networks

MANAGING TRADITIONAL SATCOM SYSTEMS The majority of today’s voice and data traffic that is carried via satellites is done so with transparent transponder (or “bent pipe”) based payloads. A typical transparent transponder based system receives a terminal’s signal, performs frequency conversion and filtering of the signal, then separates them into individual transponders finally re-amplifying the signal for transmission to a fixed or pre-configured set of destinations. Many of these systems operate in Ku, C, and L band and are now being launched in higher bands such as Ka. As with any engineered system, there are always trade-offs and compromises. The simple design of a transparent system must be traded with the following consequences of that design. Any noise not filtered by the transponder is amplified and passed on to the destination terminal. This impacts terminal design since it limits minimum antenna size and power requirements. Since the baseband signal is not processed by the payload, any packet based switching or routing must be done via a ground system. This can lead to inefficient use of available spectrum since multiple satellite hops are required which in turn results in longer propagation delay.

Figure 1 Typical System Architecture

Satellite Control Center

Network Control Center

Satellite Gateway

Satellite Gateway

Space

Network Management Segment

Terminal Segment

Public Network

s

TT&C User Data

M&C

User Data

User Data

2 of 7

Figure 1 illustrates the typical communication satellite system architecture; its management is described next.

Space Segment Management

There are two overarching missions of the typical space segment and its operators or stake holders: (1) the mission of the space segment is ultimately to provide [secure] radio links at a specified quality of service to support fixed and mobile terminal communications, (2) the mission of the space segment provider is to optimize utilization and availability of space segment resources to maximize returns (i.e. monetary or mission support) on a substantial initial investment. The primary elements of the typical space segment are: the satellite bus and its payload, the frequency bands and channels used to support radio communications, a satellite control center, and depending on the system architecture, one or more geographically diverse satellite gateways. With respect to network management functions TT&C primarily plays a role in fault and performance management by supplying data, typically in the form of status, events, alarms, and processed measurements that can be used to provide the network manager (with the aid of network management tools) a picture of how the bus is performing. In first generation bent pipe systems, the payload implements the filtering, conversion, amplification, and forwarding of received radio signals for the purposes of supporting terminal and gateway traffic. Second generation systems support multiple spot beams to maximize spectrum efficiency. Another characteristic of second generation systems like ACeS, Inmarsat B, and DIRECWAY is the concept of demand assigned bandwidth and power. These systems employ a ground based network control to manage available pools of bandwidth and allocate power to down link spot beams. In order to support second generation payloads (still considered bent pipe, albeit with enhanced capabilities) space segment network management systems need to support the fault, configuration, accounting, and security (FCAPS) functions associated with managed objects such as spot beams and their associated channels and polarization configuration, frequency sub-band switches, and power allocation tables. Note that with each additional capability of the payload there is an additional responsibility in managing it. Depending on the level of automation within the network management system, this

can in turn lead to additional complexity for the network manager. Support for multiple spot beams exists in many fixed and mobile satellite communication systems. Like terrestrial cellular networks, the objectives of satellite spot beams (i.e., cells) are to provide coverage where markets exist and within defined regulatory boundaries, and to maximize utilization of available spectrum through frequency reuse. Demand assigned capacity is another technique used to maximize its utilization. In second generation satellite systems this typically involves a request from the terminal through the satellite to a network control center that manages bandwidth allocations across the entire system. Finally, variable modulation and coding schemes implemented by the satellite payload and terminal are utilized to support throughputs within prescribed error rates. Network management plays a supporting role in satellite radio channel configuration management. This may include storage, report, and status functions regarding the configuration of spot beam channels, displays of their coverage areas (often with geographic overlays). The network management system can process information from multiple sources to provide the network manager with the operational status of the network. Operational status and alarms received from the satellite bus and payload are reported through telemetry to the network control center to provide the health status of physical assets. Performance statistics regarding bandwidth assignments and capacity utilization are collected by the network management system, correlated to geographic location and provided to a capacity planning system which can analyze traffic trends and help the network planner make decisions regarding distribution of capacity across coverage areas. Performance statistics are also used by the network management system to help the network manager spot trends that might indicate a problem. For example, a sudden drop in traffic over a normally busy coverage area might indicate a problem with the spot beams serving the coverage area.

Managing Satellite Gateways Satellite gateways are a specialized type of satellite terminal that provide high capacity / volume services (relative to individual satellite terminals). Like terminals, gateways convert a customer’s terrestrial or land mobile network interface into a satellite network interface and vice versa. Since gateways are considered high value assets and like satellite operation centers have their own computing and network infrastructures, FCAPS network management functions apply to satellite gateways.

3 of 7

Gateways have the additional complexity of supporting terrestrial PSTN and mobile network interfaces as well as terrestrial data network interfaces.

Managing Satellite Terminals The mission of the terminal segment is to support end user services by providing the bridge between the user’s access network (i.e. it’s physical interface and protocol stacks) and the satellite network. In many ways the terminal operates like a much smaller scale gateway; in the most extreme case a satellite terminal can be for personal use and be the size of a mobile handset. Satellite terminal management can pose unique challenges for satellite network management systems. Satellite networks can contain tens or hundreds of thousands of satellite terminals so a scalable network management solution is required to accommodate a growing population of subscribers. Furthermore, a satellite terminal typically implements a host of protocols (both standard and proprietary) and functions that must be configured and monitored. Satellite terminals also support various authentication, access control, and encryption functions that require the network management system to support key management and distribution functions. Terminal mobility capabilities also put additional requirements on the network management system. Roaming terminals may move from one spot beam to another resulting in configuration changes such as the HLR/VLR for GSM based systems, or IP address and route configuration as a result of changing its local subnetwork. The network management system must be notified by the mobility management function that a location change has taken place which in turn triggers the network management system to perform necessary configuration updates.

Network Management Segment The preceding sections have described the various functions and major components comprising a satellite network that require network management support. The mission of the network management segment is to act as the nexus for the network manager to monitor, optimize, and control the satellite network assets. Examples of satellite network management deployment include: • Centralized – all FCAPS functions are conducted from

a single network control center that perform direct (i.e. element level) management on the space and terminal segment

• Distributed – FCAPS functions are performed within regional network control centers or gateways

• Hierarchical – Selected FCAPS functions are delegated by a centralized network management system in a network control center to one or more distributed management systems in a gateway, satellite operations center, and/or regional management center

There are merits to all architectures. A centralized architecture is the easiest to administer and develop; it helps foster the use of a single set of operational policies since the network management team is typically collocated. A distributed architecture may be the best choice when the satellite network spans multiple national boundaries and the operational staff may have policies and functions unique to their site. A hierarchical system lets each distributed management system perform local management functions while the centralized management system provides an aggregated view of the network’s status, performance, and configuration based on management information provided by each distributed management system. Regardless of the network management system’s architecture and geographic deployment, a common set of functions are required to satisfy the mission of the segment: • Configuration – ability to view and modify satellite

network assets and their configuration (including software). This ranges from a command line interface to an IP router to a high level graphical network topology diagram that’s color coded to indicate asset types and their status.

• Fault – ability to view alarms (either detailed or aggregated) from each of the segments. Fault correlation is also an important function as the network management segment will receive alarms from numerous managed objects (e.g. payload, bus, terminal, local computing and LAN infrastructure) and need to determine the root cause of the alarms.

• Performance and accounting – collection of performance and usage data is a critical function that supports customer billing functions, troubleshooting, and traffic engineering. The network management system typically provides a reporting and graphing capability that enables the network manager and network planners to view traffic loads of various types over time and geographic location.

• Security – security key management and distribution functions required to support payload, terminal, and user authentication and access controls as well as encryption of user and signaling data.

The network control center can also be home to functions such as mobility management, centralized resource (i.e.

4 of 7

satellite bandwidth and power) management, and network admission control functions. It’s evident based upon the information described in the preceding sections that managing a satellite network is a complex task involving numerous technologies (radio link transmission, mobility management, satellite bus management, mobile IP and telephony, network protocols, computing systems and databases, etc.). The next section describes the current state of the art in network management tools and standards.

STATE OF NETWORK MANAGEMENT TOOLS AND STANDARDS

In the past several years the IP protocol has emerged as the de facto standard for networking. Starting with data applications, now voice telephony, multi-media streaming, and video conferencing are also increasingly IP based. The dominance of IP has also had a profound impact on the landscape of network management technologies. Under the auspices of the IETF, the simple network management protocol (SNMPv1) and associated MIB standards emerged during the late 1980s and early 1990s. This was originally intended to be a temporary solution until the ITU OSI based network management solutions completed standardization and adoption. The complexity of the ITU TMN standards, lack of implementation of OSI network protocols, the near universal adoption of IP, and the primitive simplicity of SNMP and its extensible MIBs all contributed towards today’s current state of network management technologies: • Support for SNMP is found in virtually every IP

enabled device from routers, to switches, computers, even UPS power supplies.

• OSI based network management has been relegated to legacy telecommunication networks with limited support for future enhancements

• A bevy of COTS and open source SNMP management tools exist in the market today

Alas, all is not perfect in the network management world. SNMP certainly is the de facto standard and it excels in support of LAN/WAN and network interface monitoring, but has many shortcomings in configuration management and control (no support for transaction control makes the managing system complex and difficult to develop, the simple SNMP set operation is often insufficient for use in configuring systems). In fact most network management solutions in use today are a hybrid of sorts: • SNMP is used for monitoring status and performance

threshold variables

• For enterprises using SNMPv3, SNMP bulk-gets are used for relatively small batch data collection. Large bulk transfers are performed with file transfer protocols which are much more efficient.

• Locally developed scripts and vendor supplied proprietary products are used to perform configuration and commanding. Commercial routers are an example, they support SNMP get operations but are configured through a command line, proprietary GUI tool, web interface, or with XML configuration files.

Problems with a uniform, standard solution for configuration are under study by the IETF. The Network Configuration working group has published the NETCONF Configuration Protocol draft RFC which defines an XML / RPC based approach to supporting configuration [1]. The NETCONF proposal shows much promise as XML is being widely adopted as a standard meta language for defining interfaces in areas such as Web Services and commercial data base access. Additionally, numerous white papers on the application of XML as a network management technology have been written.

Policy Based Network Management Policy based network management (PBNM) is another area of study by the IETF. PBNM is a framework for enabling the network manager to turn operational and network policy into a codified set of rules which can be carried out by PBNM enabled systems to fulfill those policies by automatically executing device specific commands to change configuration. PBNM showed promise early in this decade and a handful of RFCs were produced by the IETF. To date, no enterprise wide standards-based PBNM solutions are known to have been deployed. The standards are lacking in two key areas: no standard policy definition language exists, and no standard transfer syntax has been defined. These are critical issues that must be dealt with, until that time PBNM can serve as a conceptual framework. It should be noted that policy has in fact been enforced by network devices for some time, but not in a standard way. Firewalls are a good example, one can specify “policy” rules regarding the treatment of IP datagrams (block or allow based on source, destination, protocol type, time of day). So even though policy based management is not mature from a standards point of view, its concepts none the less can still be effectively applied to network management. The key to PBNM is that instead of all network management action originating from the management center, the network itself is empowered to make decisions, and the rules behind those decisions can be changed on the fly by the management center.

5 of 7

INTELLIGENT SATELLITE NETWORKS

Communication satellite capabilities have evolved dramatically in the past three decades largely as result of advances in satellite based hardware and software technologies that have enabled enhanced services to be delivered within power, weight, and budget constraints.

Regenerative Transponders With respect to capability improvements in the payload, two key developments have been made that have lead to the development of an “intelligent satellite network” comprising the third generation: (1) regenerative Transponders, (2) Inter Satellite Communication Links. Regenerative transponders demodulate the down converted signal back to baseband. Once this is done, on board processors can perform tasks like packet switching (for example, SPACEWAY [5]), or call setup and mobility functions such as HLR/VLR support. This effectively moves packet switching fabric into orbit. When base band processing is complete, the signal is re-modulated, amplified and transmitted to its next destination. This design inherently removes any noise introduced by the uplink transmission from the downlink transmission, a fundamental issue with bent pipe systems. Another consequence of the architecture is that it now opens the door for greater satellite autonomy. This means the satellite payload can perform more tasks on its own such as local diagnostic actions and take rapid corrective action in the event of failure without requiring ground based intervention. Because of the numerous advantages and advances in flight capable hardware most systems built or planned for development will likely use regenerative transponder architectures especially because of increasing standardization in intelligent satellite networking [4].

Inter Satellite Links Another feature of an ‘intelligent satellite’ is the inter satellite link or ISL (such as those used in the Iridium LEO network). ISLs enable direct payload-to-payload communication via RF or laser channels. ISLs add additional weight and complexity to the payload and satellite operations center (e.g. additional antennas or telescopes are required). If a tracking antenna is used, additional processing is required on the payload. On the other hand, if a stationary antenna scheme is used, the satellite operations center’s orbital maintenance job becomes more challenging. Despite these issues, using ISLs between multiple geo-synchronous or MEO/LEO satellites with baseband processing effectively creates an “intelligent satellite

network”, a network of packet switches creating a microcosm of the Internet in the sky. ISLs go hand-in-hand with on board baseband processing in that they enable the onboard router or switch to choose alternative routes for carrying data, either a gateway on the ground for example, or an adjacent satellite which may be a shorter route. Spare capacity can also be better utilized through the use of terrestrial backhaul gateways AN EVOLUTIONARY APPROACH IN MANAGING

INTELLIGENT SATELLITE NETWORKS

At a high level, the additional complexities and challenges involved in managing an intelligent satellite network include the following:

• Third generation systems such as these typically include a switching and / or routing capability on board each satellite. The management system (and network manager / planner) must now take on the challenges of managing a space network of routers/switches which may include non-standard capabilities and features such as interfaces to an on board demand assigned capacity management function.

• Inter satellite links must be configured and monitored

• Terminal authentication and access control can now be performed on board, thus the network management system must support security key management functions for the constellation.

• Likewise payload based HLR/VLR and other mobility functions can be space based, the management system must support these functions

• Functions such as packet quality of service functions (both in data plane and admission control for guaranteed service) must be managed in such a way as to meet SLA objectives without requiring complex and labor intensive involvement from the operational staff.

The on board baseband computing systems can be utilized to enable the satellite to make intelligent decisions on the function listed above; this is a key concept in the application of distributed policy based management systems for these networks and is the focus of this section. The following sections discuss various capabilities unique to intelligent satellite networks and how policy based and other standards based network management technologies can be applied to help ease the burden and control the complexity of management.

6 of 7

Managing An In-Orbit Network Conceptually an in-orbit network of packet processors looks like a relatively simple network to manage; the number of nodes after all is small compared to typical enterprise terrestrial networks. The challenge in this case comes from the dynamic nature of satellite radio links themselves. Terrestrial networks tend to be static in nature with respect to bandwidth or capacity; the bandwidth of terrestrial links does not change with much if any frequency once in place. Most packet routing protocols are based upon link state or distribution of route tables where routes are added / deleted / weighted as the links connecting routers change state (e.g. they fail or return to service). This behavior is certainly true for space based network nodes as well, they are obligated to adapt to standard routing protocols and make route table updates in response to radio link failures and recoveries. A link’s operational status is not the only variable of influence, particularly with an intelligent satellite network. As we mentioned earlier, the mission of the space segment is “…to optimize utilization and availability of space segment resources to maximize returns …” on investment. In order to achieve this objective, the radio link capacity must be shifted from one coverage area to another, effectively moving bandwidth to where it is needed in response to real time traffic demands. Shifting or modifying radio link capacity changes the links characteristics from a packet routing perspective. At one moment a route might include a coverage area of relatively high capacity and therefore be the best choice to route packets. In response to growing capacity demands (or higher priority of user traffic) in another coverage area, capacity can be shifted away, making what was the best route now non-optimal. The interplay between shifting link capacity and packet routing needs to be responsive, adaptive, and well coordinated. Policy based management can support these needs by providing a framework (i.e. the policy rules and execution environment) for such decision making to be done. By executing policy on board the payload rapid decisions can be made with respect to capacity shifting and the conditions for performing a route change. If such decisions were ground based (for faster computations and scalability), the inherent propagation delay associated with geo-synchronous satellites could prove too lengthy to react fast enough for bandwidth allocation to be truly optimal. Placing decision making on board also lends itself towards a robust solution since the satellite can make these decisions autonomously even during outages of the ground control. Finally, since the policy rules can be changed at run time, the network manager can refine and deploy new rule sets over time as experience is gained by the

operational and networking planning staffs. This is an inherent advantage of policy based management over traditional network management schemes where such changes often require new software to be deployed.

Terminal Access and Mobility Management The on board processing capability can also lend itself well to support information assurance and mobility functions. These functions which have historically been ground based can now be hosted by the satellite. Terminal access refers to the activities involved in authenticating and establishing the presence of a satellite terminal on the network; a system login of sorts. The management system supports this function by providing security key and other material such as digital certificates that are used to authenticate a terminal. Terminal access controls for functions such as mobility, rights to special services such as higher QoS are also configured through the network management system. The rationale for placing these functions on the payload is largely an issue of robustness. Terminals can join the network in a secure fashion and roam by interacting with just the payload; intervention of the network control center during terminal authentication and handover events is not required. So even during a failure event in the control center or its links to the satellite, these critical functions can still be executed therefore delivering service to the end user. Policy based network management supports payload based terminal access and mobility by allowing rules to be defined / changed on exactly what the criteria for terminal access and mobility should be. For example, as a matter of policy it may be desirable to limit network access to only the highest priority terminals when a given coverage area becomes highly congested. Another example is the execution of policy rules to carry out a handover where the handover to a new spot beam might result in preemption of existing traffic to accommodate the new capacity demands introduced by the roaming terminal.

QoS and Dynamically Assigned Capacity

Broadband satellite networks have very unique constraints regarding packet Quality of Service (QoS). Certain applications such as streaming video and audio are very sensitive to variations in latency (also known as jitter) and throughput, and the IP protocol itself is inherently best effort in the sense that one user’s traffic is treated like any other’s in how it is processed. Standards have been published by the IETF in an effort to define mechanisms that can offer guaranteed or at least better than best effort service. They lead to two different approaches,

• Integrated Services - where control plane signaling reserves capacity along each hop a packet will

7 of 7

take, there by ensuring adequate bandwidth exists for the application.

• Differentiated Services - involves marking each IP packet with coded information so it is treated with priority at each hop relative to other packets.

When IP routers are placed on board, these services must also execute on board (typically part of a router’s functionality). Ideally, a network manager would like to specify the policies in a non-implementation specific manner that’s consistent with the service level agreements contracted with customers. For example, an SLA might state that the Acme customer’s terminals should receive “platinum” level service between 10:00 and 4:00 PM local time during the week, and basic service at all other times. Using a policy editor the network manager can create policy rules that specify the conditions of the SLA. The policy can be downloaded to the policy decision point (which can be in the control center or in the payload) that in turn converts the policy into router specific commands and configuration to realize a particular quality of service for the Acme customer’s terminals. This gives the network manager the “language” needed to enforce SLAs without requiring complex and laborious involvement from the operational staff to achieve SLA objectives.

CONCLUSIONS AND RECOMMENDATIONS

This paper has presented the concepts involved in managing satellite networks and the current issues of network management technologies and standards. It has also discussed the key characteristics of third generation intelligent satellite networks and functions unique to those networks. These concepts and issues were tied together and a proposal for the application of policy based management was made as a means of managing intelligent satellite networks. Traditional network management technologies do not have provisions for enabling the network manager to be the one who can define the behavior of the network, most systems change management behavior by changing software (i.e. business logic is locked in the management system’s source code). Emerging network management standards that use web technologies such as XML and web services hold promise and may be the vehicle for specifying a policy language standard. An evolutionary approach to the adoption of PBNM and web services technologies is recommended. Web services are mature and in use in financial and retail industries. Given the wide spread tool support, the benefits of XML, and the implementation independent nature of web services definitions, their application to network

management is a natural choice. Web services can first be implemented between ground based management systems. Once their benefits are demonstrated, their capabilities can also be exploited by the payload as a means of receiving configuration data (e.g. IP routing, capacity and power allocation, channel configuration, mobility and terminal access) in an implementation neutral fashion. The final evolutionary steps involve the adoption of PBNM. Policy translation into payload specific commands and configuration data can at first be performed on the ground in the satellite operations center. The final evolutionary step is the adoption of policy functions on board the payload. This evolutionary process will ultimately give the network manager the flexibility needed by intelligent satellite networks to enforce operational policies and meet SLA objectives by empowering the operational staff (not the network management tools’ software development team) with the ability to codify policy rules and change them as the network changes and experience grows.

REFERENCES [1] draft-ietf-netconf-prot-06, “NETCONF Configuration Protocol”, April 25, 2005, R. Enns, Ed. [2] “Regenerative Payload Downconverter Simulation”, Agilent Technologies, author unknown, http://eesof.tm.agilent.com/pdf/gupta0205.pdf [3] Mobile Satellite Communications Principles and Trends, by M. Richharia, , copyright Pearson Education Limited, 2001. [4] European Telecommunications Standards Institute (ETSI) Technical Specification (TS) 102 188, Satellite Earth Stations and Systems (SES); Regenerative Satellite Mesh – A (RSM-A) air interface, www.etsi.org, 2004. [5] SPACEWAYTM A Vision for the Future, Dr. Arunas Slekys, VSAT 2002, The Global Industry Conference, 10-12 September 2002, London, U.K.

BIOGRAPHIES

Greg Totsline received a B.S. in Computer Science from the Rochester Institute of Technology and an M.S. in Computer Science from the Johns Hopkins University, he also holds an honors GIAC/GSEC security certification. He has been involved in the design, implementation and deployment of software for numerous network control centers including INMARSAT, ACeS, and Spaceway. Dr. Rajeev Gopal received a Ph.D. in Computer Science from Vanderbilt University. Previously he was the chief architect for the SPACEWAY Network Operations Control Center development. Currently he is involved in the Transformational Communications Satellite (TSAT) project.