1. DLR ITCT (Inputs To Current Topics) CCSDS CSSM Technical Meetings London, United Kingdom 9 November – 14 November 2014 Friendly provided to you by: Marcin Gnat™, DLR GSOC

2. Contents Simple Schedule Blue Book (General and RID’s) Generic File Transfer RFI, data volume – planning information Agency metrics/characteristics on accounting

3. Simple Schedule of Services BB

4. Simple Schedule of Services BB – RID’s (1) General: Rather good acceptance (book is short and mostly clear) Standardization of scheduling interface (watch out -> scheduling interface, not only Published Schedule or Simple Schedule) seems to be VERY welcome. However, seems there is some mess-up with understanding (we standardize actually from the end -> published schedule is a result of whole complex process. Many questions related to schedule request (service request)). -> Green Book helps only partially. Columbus / ISS Currently support over TDRS, almost permanent access, contact times pre- scheduled by NASA As of today no specific comments to the Blue Book as such, it seems to be usable for Columbus in the future (however this will be strongly driven by general ISS Program).

5. Simple Schedule of Services BB – RID’s (1) Other specific questions/concerns (less RID’s, more rather things which we may consider to describe better in the document): Where belong things like Antenna Maintenance? Probably this would just limit the antenna free time (different paradigm as now -> typically one “books” explicitly Antenna for the maintenance, now one would have to set the maintenance time as “not free”). For how long period the Antenna Free time shall be provided? Actually good question. Technically (depending on implementation) we can provide even Antenna Free Time for CW34 in Year 2300. Question is, how much does this make sense, operationally? How we obligate (If at all) the users to get the update?

6. Simple Schedule of Services BB – RID’s (1) Other specific questions/concerns (less RID’s, more rather things which we may consider to describe better in the document, ct’): Chapter 1.1.1 (Purpose) Page 1-1 Add another reference: b1) mission planning, e.g., to ensure that the actual planning information is available at the ground station/relay satellite operator, to allow full automatic ground station/relay satellite operation Chapter 1.3.2.2 (Mission Planning) Add another use case: In another mission planning use case the user agency provides the provider agency with a schedule that gives the provider agency the information it requires to plan its uplink/downlink resource operations with respect to the final space craft schedule. This allows the provider agency to use the ground station/relay satellite resources (like power, tape space, personal, mechanical/electrical switch cycles) in a more efficient way. Furthermore it can increase the level of automation to the point of full-automatic operation of the ground station/relay satellite.

7. Simple Schedule of Services BB – RID’s (1) Text change proposal Chapter 1.3.2.2 (Mission Planning) Change “days” into “minutes” The planning process will typically go through a number of cycles, starting months before the actual activities are expected to take place and being finalized a few minutes before execution. RID’s (which did not make it into official form): Time Code Why the time code B used and not time code A? Is there a special reason for that? Why the presence of “Z” for “Zulu Time” is an option? It should be obligatory.

8. Simple Schedule of Services BB – RID’s (2) SUBMITTING ORGANIZATION (Agency, Center): DLR, EOC ------------------------------------------------------------------ REVIEWER'S NAME: Damerow, Heiko CODE: E-MAIL ADDRESS: Heiko.Damerow@dlr.de TELEPHONE: +49 3981 480 209 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 902.1-R-1 Red Book, Issue 1 DOCUMENT NAME: Simple Schedule Format Specification DATE ISSUED: September 2014 PAGE NUMBER: 3.7 PARAGRAPH NUMBER: 3.2.7.3 RID SHORT TITLE: Enumeration style ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) To apply a common style for enumeration please use only capital letters and underscores for semantic separation of terms. C_BAND, KA_BAND, RANGING

9. Simple Schedule of Services BB – RID’s (2) SUBMITTING ORGANIZATION (Agency, Center): DLR, EOC ------------------------------------------------------------------ REVIEWER'S NAME: Damerow, Heiko CODE: E-MAIL ADDRESS: Heiko.Damerow@dlr.de TELEPHONE: +49 3981 480 209 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 902.1-R-1 Red Book, Issue 1 DOCUMENT NAME: Simple Schedule Format Specification DATE ISSUED: September 2014 PAGE NUMBER: 3.7 PARAGRAPH NUMBER: 3.2.7.3 RID SHORT TITLE: Extension of class ServiceInfo ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) The available class ServiceInfo parameters would not unambiguously characterize a service. The recommendation is to have serviceStartTime, serviceStopTime, dataRate and channelIdent to characterize the specific service.

10. Simple Schedule of Services BB – RID’s (2) SUBMITTING ORGANIZATION (Agency, Center): DLR, EOC ------------------------------------------------------------------ REVIEWER'S NAME: Damerow, Heiko CODE: E-MAIL ADDRESS: Heiko.Damerow@dlr.de TELEPHONE: +49 3981 480 209 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 902.1-R-1 Red Book, Issue 1 DOCUMENT NAME: Simple Schedule Format Specification DATE ISSUED: September 2014 PAGE NUMBER: 3.7 PARAGRAPH NUMBER: 3.2.7.3 RID SHORT TITLE: Schedule Confirmation ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) Each schedule should at least responded by a schedule confirmation.

11. Generic File Transfer

12. Generic File Transfer – considerations In general (surprisingly) a welcome approach (esp. standardized protocols, folders, etc..), even not a highest priority for DLR Suggestions to reference (and consider) the Security working group documents: Algorithms Blue Book (encryption and authentication methods) Network Layer Security (Book in work) Missing description / considerations on duration of file storage on server. When should they be removed? Who does that? Do we drop that to be clarified in some ICD’s? What about consideration of very large files (videos)? Experience from Columbus shows it is not so simple, and internet is not a good solution at all. Careful consideration – and explanation of the decision – is needed regarding transport protocol and security layers. Why WebDAV/TLS and not FTP over SSH?

13. Planning Information

14. Planning Information – AI# 2014-0826-03 Mission Analysis for LEOP (prepared by FD) RFI FD can perform some check on conflicts (but rather reactive) registration at ITU, exclusion zones hinder analysis (GEO, broadcasting) LEOP, on orbit servicing (multiple s/c launch with same freq. band, antenna shading of serviced object) Data volume Mainly domain of mission planning – depending on on-board storage use, upcoming data take orders, respective planning and recommendations or requests are generated. Rough estimation is performed in early design phases (analysis from PI / S/C Manufacturer). This is used as input to the design (i.e. storage capacity, bandwidth of links).

15. Planning Information – AI# 2014-0826-03 Costs based on assumed passes the cost is estimated general cost estimates for the mission are combined effort personnel, contractors, investments, maintenance, facilities usage (detailed estimates are internal, customer may get rather general view, at most divided to personnel, investments and facility usage). Resource Conflicts covered by mission planning, scheduling and just human work To consider regarding the BB: Geometrical events are produced by FD, whereas data volumes, costs or resource conflicts are covered by other entities. This will lead to question who is responsible for generating planning information (Because these different things are covered by same file format and defined in one BB, people will tend to think “it’s not my business” and push the interface away).

16. Accountability

17. Accountability – AI #2014-0401-01 No specific / pre defined format are in use In most cases any reporting on accountability / quality is done “on request” Post pass reports as base for reliability statistics Reliability statistics is prepared regularly (monthly or quarterly), but for the internal reference only (not really distributed to customers). Question: is the post pass report part of accounting or rather service monitoring? Metrics / characteristics: Number of requested passes Number of total passes (executed) Number of good passes* Number of bad support G/S Number of bad support (other reasons) Reliability % G/S only Reliability % other only *) good pass does not necessarily means everything was perfect, it is rather a arbitrary decision of the project. I.e. command uplink drops down for one minute during the pass, but at that time the S/C hasn’t been actually commanded, the pass may be declared as “good”.

18. Accountability – AI #2014-0401-01