Adding Space Link Extension SLE Service Interfaces to Legacy Provider Systems

1
Adding Space Link Extension (SLE) Service
Interfaces to Legacy Provider Systems

• Martin Götzelmann, Anite
• Catherine Lannes, European Space Agency

2002
2
Presentation Content

• What are Space Link Extension Services?
• Motivation for Provider Side Gateways
• Design Options
• Feasibility Studies
• Mapping Potential and Limitations
• Prototyping Work
• ESA SLE Gateway
• Conclusions

3
Space Link Extension Services
R-AFR-CF R-FSH R-OCF R-SP
Space Element
F-CLTU F-TCF F-TCVCA F-SP
Space Link
CCSDS Packet TC Packet TLM AOS
Space Link Extension (SLE) System
Mission Data Operation System (MDOS)
SPACE LINK EXTENSION SERVICES
GROUND ELEMENT
4
SLE Reference Model
Service Management
SLE System
MDOS
Management
Management
Service Instance
Attributes
Resources are reserved for user X by provider Y
from T1 to T2 such that the user can request
provision of service Z in that period
Use of SLE Services must be agreed and scheduled
in advance
Service Provider
Service User

• Identifier
• WHO (user / provider)
• WHAT (service type)
• WHEN (start / end time)
• WHERE (port identifier)
• HOW (configuration)

5
SLE Reference Model
Service Management
SLE System
MDOS
Management
Management
Service Provider
Service User
SLE TRANSFER SERVICE
Service Instance
Service Instance
6
Initial Implementations
ESA Mission Control System (MCS)
Network Control and Telemetry Routing System
(NCTRS)
SLE Provider
SLE User
DSN Station (Goldstone)
SLE Provider
SLE User
ESA Service
ESA Service
ESA Station (Redu)
ESA Simulator

• Configuration for Cross Support of ESA Missions
  by NASA/JPL (DSN)
• Initially used for INTEGRAL and ROSETTA
• Supported SLE services RAF, RCF, CLTU

ESA Implementation
JPL Implementation
7
Motivation for Provider Side Gateways

• SLE provides the option to offer the services of
  a network via standard interfaces
• Reduction of cost
• Reduction of required lead time for cross-support
• Legacy telemetry and telecommand processing
  equipment generally has proprietary interfaces
• Sometimes such systems are not easy to modify
• New developments are too expensive or cannot be
  completed in the time needed
• Legacy interfaces and SLE interfaces must be
  supported concurrently during a migration period

8
Motivation for Provider Side Gateways

• Before investing into completely new developments
• Operators might want to see whether commercial
  SLE offers become available
• Equipment manufacturers might want to see how
  market demands evolve

• Are SLE Gateways to Legacy Systems feasible?
• What are the limitations?
• Is the approach cost effective?

9
Design Options
Legacy Provider System
SLE User System
SLE
SLE

• Integrated SLE Interfaces
• Modification of the legacy system to support SLE
• Technically best solution
• not always feasible
• sometimes expensive
• Not subject of the presented paper

10
Design Options
Legacy Provider System
SLE User System
WAN
WAN
SLE

• Gateway
• Can be located anywhere
• User and Provider might be connected low
  bandwidth, high latency networks
• Mapping relies completely on the service
  interfaces
• Gateway has no access to provider side management
  ports

11
Design Options
Legacy Provider System
SLE User System
WAN
SLE

• Provider Side Façade
• Co-located with the provider system
• connected via a high speed local area network
• on the same computer
• No data loss and negligible delay on the
  interface to the provider
• Access to management information available

12
Design Options
SLE Provider System
Legacy User System
WAN
SLE

• User Side Adaptor
• Co-located with the user system
• Connected via a high speed local area network
• On the same computer
• Not subject of the presented paper

13
Studies Performed

• Feasibility and Cost of a ESA SLE Gateway
• Two Interface types were investigated
• ESA proprietary interfaces for
• Packet Telemetry (TMP4)
• Packet Telecommand (TCE)
• Interfaces for PCM TM/TC still in use
• Façade and Gateway Approaches were considered
• Study covered
• Detailed mapping specification for RAF, RCF, CLTU
• Operation Concepts
• Architecture, Software Re-use, and Cost Analysis

14
Studies Performed

• SLE I/F to Commercial Equipment (CORTEXNT)
• Objectives
• Demonstration that SLE interfaces can be
  supported at reasonable cost using an SLE API
  implementation
• Promotion of SLE
• Sponsored by ESA and supported by the
  manufacturer
• Only the façade approach considered
• Study covered
• Detailed mapping specification for RAF, RCF, CLTU
• Development of a prototype based on the ESA SLE
  API Package

15
Characteristics of Interfaces

• ESA Interfaces for Packet TLM/TC
• In many aspects similar to SLE
• Access to all frames of a space link, to all
  frames of a master channel or to individual VCs
  are supported
• Return services support delivery modes online
  timely, online complete, offline
• Online timely delivery supports a similar
  buffering mechanism
• Provide access to production parameters
• Monitoring is provided, but no complete
  equivalence to SLE
• Limited configuration and control by the user is
  supported
• Make use of application protocols on top of OSI
  session
• End to end flow control and synchronisation
  available
• SLE QOS requirements met
• Do not support the concept of service instances

16
Characteristics of Interfaces

• ESA Interfaces for PCM TLM/TC
• Very simple protocols on top of X.25 or TCP/IP
• Limited flow control and synchronisation
• No buffering for return services
• Very limited buffering for telecommands
• Limited access to production parameters
• CORTEXNT Interfaces
• Simple message transfer via TCP/IP
• No buffering for return services
• Buffering for telecommands not visible on the
  interface
• Flushing of commands via the control port
• Access to management information via a monitor
  port

17
Summary of Results

• Most SLE features can be supported via a gateway
  or façade
• Amount of functionality that must be implemented
  by the gateway/façade varies.
• The façade approach provides a better mapping for
  the simpler interfaces
• In some cases, a façade is the only option
• For the ESA interfaces to packet TM/TC the
  difference is less significant
• Service management is required on the
  gateway/facade
• Complete mapping of SLE interfaces is not
  possible
• Integrated SLE interfaces are required
• Service production might have to be extended or
  modified

18
Mapping Examples
? direct mapping possible, ? Full support with
work-around, ? Limited support with workaround,
? not possible, only for a façade
19
CORTEX SLE Interface Prototype
Windows NT
CORTEXNT
CORTEX SLE Interface Prototype (CORSIP)

• Implements a subset of RAF, RCF and CLTU features
• Can run on the same machine or on a separate PC
• An improved version is being used operationally
  for support of MSG by ESA

CTRL
ESA SLE API Package
SLE RAF/RCF provider application
TM
TCP ports
SLE CLTU provider application
TC
MON
20
ESA SLE Gateway
SLE Service User
SICF
Service Instance Configuration File
SLE-API
SLE Provider
Scheduler
Scheduled SIs
MMI
Active SIs
ESA GS I/F
SI History
ESA Ground Station
21
ESA SLE Gateway

• Maps the SLE services RAF, RCF, CLTU to ESA
  ground station interfaces for packet TM/TC
• Provisional solution until native SLE
  interfaces are available on ESA ground station
  equipment
• Located at ESOC such that all ground stations
  can be used via SLE services
• Uses existing implementations of ESA interfaces
  and the ESA SLE API Package to reduce development
  cost and time
• Initial version supporting a subset of SLE
  services completed in Q4 2002
• Final version completed Q2 2003

22
Conclusions

• SLE gateways to legacy provider systems
• are technically feasible for most SLE features
• present an acceptable solution for a wide range
  of missions and cross-support scenarios
• can be implemented in a cost effective manner
  using
• an existing SLE API implementation
• existing interfaces to the legacy provider system
• Simpler legacy systems might require co-location
  of the gateway (façade approach)
• Fully compliant provision of SLE transfer
  services requires native SLE interfaces on the
  provider systems