Transcript CSTS-TD_Prototype_Scenarios - The CCSDS Collaborative Work

www.DLR.de/rb • Slide 1
> CSTS-TD Prototype Scenarios > S.Gully
CSTS-TD:
Prototype Scenarios
10.11.2015
www.DLR.de/rb • Slide 2
> CSTS-TD Prototype Scenarios > S.Gully
Overview Slides
I.
II.
III.
IV.
V.
Design
Limitation
Scenarios
Scenario 01 „ Real-Time delivery mode of Doppler data product“
Scenario 05 „ Real-Time delivery mode of Doppler and Range data
product with backpressure“
VI. Open points
www.DLR.de/rb • Slide 3
> CSTS-TD Prototype Scenarios > S.Gully
Design
o NASA/GSFC will implement the service user side (CSTS-TD User).
o DLR/GSOC will implement the service provider side (CSTS-TD Provider).
o The interaction between the CSTS-TD User and the CSTS-TD Provider
will be done using a TCP-IP connection.
o Input and output of the tests are files.
www.DLR.de/rb • Slide 4
> CSTS-TD Prototype Scenarios > S.Gully
Limitation
The TDM files used by the CSTS-TD Provider for service provision are
limited to the following data products:
o Pair of antenna angle Tracking Data Records (Azimuth and Elevation)
o Doppler (integrated)
o Range
Limitation was accepted during the CSTS Working Group teleconference on
30. September 2015.
www.DLR.de/rb • Slide 5
> CSTS-TD Prototype Scenarios > S.Gully
Scenarios
o Network congestion: reducing network bandwidth up to applying back
pressure on CSTS-TD Provider
o Status change: possibility to stop and restart production of data by CSTSTD Provider.
www.DLR.de/rb • Slide 6
> CSTS-TD Prototype Scenarios > S.Gully
Scenario 01 “Real-Time delivery mode of Doppler
data product“
o Managed configuration:
- Association Control:
- service-user-responding-timer = 5
- initiator-identifier = “NASA_CSTSTD_PROT”
- responder-identifier = “DLR_CSTSTD_PROT”
- responder-port-identifier = 1
- service-type = < CSTS-TD service OID>
- version-number = 1
- service-instance-identifer = <spacraftId OID><facilityId OID>< CSTS-TD
service OID>1
- Buffered Tracking Data Message Delivery :
- return-buffer-size = 3
- delivery-latency-limit = 5
- delivery-mode = real-time
- tracking-data-types = doppler integrated
www.DLR.de/rb • Slide 7
> CSTS-TD Prototype Scenarios > S.Gully
o TDM Provider File (extract):
www.DLR.de/rb • Slide 8
> CSTS-TD Prototype Scenarios > S.Gully
o TDM User File (template extract):
www.DLR.de/rb • Slide 9
> CSTS-TD Prototype Scenarios > S.Gully
o Description:
1) Both CSTS-TD User and CSTS-TD Provider should be started before begin of test. They shall
be configured like defined above in “Managed Configuration”. The CSTS-TD provider should
begin with data production by reading the TDM Provider file in a never ending loop.
2) The CSTS-TD User should send a “BIND invocation” and the CSTS-TD Provider should
respond with a “BIND positive return”.
3) The CSTS-TD User should send a “START invocation” and the CSTS-TD Provider should
respond with a “START positive return” containing the TDM header. The CSTS-TD User should
open a new TDM User file and save the TDM Header to it.
4) The CSTS-TD Provider should send TDM data in the form of “TRANSFER-DATA invocation”
containing Doppler. The CSTS-TD User should save these data to the TDM User file.
5) After 30 seconds, the CSTS-TD User should send a “STOP invocation” and the CSTS-TD
Provider should stop sending “TRANSFER-DATA invocation” and send a “STOP positive return”.
6) The CSTS-TD User should send “UNBIND invocation” and the CSTS-TD Provider should
respond with a “UNBIND positive return”.
7) The TDM User file should be compared to the template file described above.
> CSTS-TD Prototype Scenarios > S.Gully
www.DLR.de/rb • Slide 11
> CSTS-TD Prototype Scenarios > S.Gully
Scenario 05 “Real-Time delivery mode of Doppler
and Range data product with backpressure“
o Managed configuration:
- Association Control:
- service-user-responding-timer = 5
- initiator-identifier = “NASA_CSTSTD_PROT”
- responder-identifier = “DLR_CSTSTD_PROT”
- responder-port-identifier = 1
- service-type = < CSTS-TD service OID>
- version-number = 1
- service-instance-identifer = <spacraftId OID><facilityId OID>< CSTS-TD
service OID>1
- Buffered Tracking Data Message Delivery :
- return-buffer-size = 2
- delivery-latency-limit = 5
- delivery-mode = real-time
- tracking-data-types = doppler integrated, range
www.DLR.de/rb • Slide 12
> CSTS-TD Prototype Scenarios > S.Gully
o TDM Provider File (extract):
www.DLR.de/rb • Slide 13
> CSTS-TD Prototype Scenarios > S.Gully
o TDM User File (template extract):
www.DLR.de/rb • Slide 14
> CSTS-TD Prototype Scenarios > S.Gully
o Description:
1) Both CSTS-TD User and CSTS-TD Provider should be started before begin of test. They shall
be configured like defined above in “Managed Configuration”. The CSTS-TD provider should
begin with data production by reading the TDM Provider file in a never ending loop.
2) The CSTS-TD User should send a “BIND invocation” and the CSTS-TD Provider should
respond with a “BIND positive return”.
3) The CSTS-TD User should send a “START invocation” and the CSTS-TD Provider should
respond with a “START positive return” containing the TDM header. The CSTS-TD User should
open a new TDM User file and save the TDM Header to it.
4) The CSTS-TD Provider should send TDM data in the form of “TRANSFER-DATA invocation”
containing Doppler and Range. The CSTS-TD User should save these data to the TDM User file.
5) After 10 seconds, a network congestion should be simulated using the “WANem” tool to reduce
the TCP/IP bandwidth between CSTS-TD Provider and CSTS-TD User to 0, thus provoking a
backpressure on the CSTS-TD Provider.
6) The CSTS-TD Provider should begin to discard the tracking data that are still produced at the
rate of 1/second because it is not able to send them to the CSTS-TD User.
www.DLR.de/rb • Slide 15
> CSTS-TD Prototype Scenarios > S.Gully
7) After another 10 seconds, the network congestion should stop using the “WANem” tool to
reconfigure the TCP/IP bandwidth to the normal value, thus provoking the backpressure on the
CSTS-TD Provider to disappear.
8) The CSTS-TD Provider should generate a “data discarded due to excess backlog” notification
and send it to the CSTS-TD User.
9) The CSTS-TD provider should restart sending (actual) TDM data in the form of “TRANSFERDATA invocation” containing Doppler and Range.
10) After another 10 seconds, the CSTS-TD User should send a “STOP invocation” and the
CSTS-TD Provider should stop sending “TRANSFER-DATA invocation” and send a “STOP
positive return”.
11) The CSTS-TD User should send “UNBIND invocation” and the CSTS-TD Provider should
respond with a “UNBIND positive return”.
12) The TDM User file should be compared to the template file described above.
> CSTS-TD Prototype Scenarios > S.Gully
> CSTS-TD Prototype Scenarios > S.Gully
www.DLR.de/rb • Slide 18
> CSTS-TD Prototype Scenarios > S.Gully
Open points
o Check “WANem” tool for usability
o Check if TD User File needs the full header like the TD Provider File or
only a subset depending which data are saved in.
o Define test environment (2 Laptops and a cross-over cable, cloud, other
idea?)
www.DLR.de/rb • Slide 19
> CSTS-TD Prototype Scenarios > S.Gully
Thank You !!!