1、 Standard ANSI/AIA S-124-207 Adaptations and Conversions of CSDS Space Link Extension Return Al Frames Transfer Service AIA standards are copyrighted by the American Institute of Aeronautics and Astronautics (AIA), 1801 Alexander Bel Drive, Reston, VA 20191-434 USA. Al rights reserved. AIA grants yo
2、u a license as folows: The right to download an electronic file of this AIA standard for storage on one computer for purposes of viewing, and/or printing one copy of the AIA standard for individual use. Neither the electronic file nor the hard copy print may be reproduced in any way. In adition, the
3、 electronic file may not be distributed elsewhere over computer networks or otherwise. The hard copy print may only be distributed to other employees for their internal use within your organization. ANSI/AIAA S-124-2007 American National Standard Adaptations and Conversions of CCSDS Space Link Exten
4、sion Return All Frames Transfer Service Sponsored by American Institute of Aeronautics and Astronautics Approved 3 May 2007 American National Standards Institute Abstract This document defines adaptations and conversions of the Consultative Committee for Space Data Systems (CCSDS) standard Space Lin
5、k Extension (SLE) Return All Frames (RAF) telemetry data transfer service. The CCSDS SLE transfer services do not support some legacy command and telemetry data flows that must be accommodated by US civil, military, and commercial space element tracking, telemetry, and control networks to allow inte
6、roperability in support of US Government space operations. Adaptations of RAF by the user and conversions of RAF by the provider provide standardized time-correlated telemetry and command echo services which are not otherwise provided by CCSDS SLE transfer services. Time-correlated telemetry service
7、 supports space elements which use unframed bit streams or bit streams without provider-side frame synchronization. Command echo service supports systems which require an independent check of provider RF equipment. ANSI/AIAA S-124-2007 ii Approval of an American National Standard requires verificati
8、on by ANSI that the requirements for due process, consensus, and other criteria have been met by the standards developer. Consensus is established when, in the judgment of the ANSI Board of Standards Review, substantial agreement has been reached by directly and materially affected interests. Substa
9、ntial agreement means much more than a simple majority, but not necessarily unanimity. Consensus requires that all views and objections be considered, and that a concerted effort be made toward their resolution. The use of American National Standards is completely voluntary; their existence does not
10、 in any respect preclude anyone, whether he has approved the standards or not, from manufacturing, marketing, purchasing, or using products, processes, or procedures not conforming to the standards. The American National Standards Institute does not develop standards and will in no circumstances giv
11、e an interpretation of any American National Standard. Moreover, no person shall have the right or authority to issue an interpretation of an American National Standard in the name of the American National Standards Institute. Requests for interpretations should be addressed to the secretariat or sp
12、onsor whose name appears on the title page of this standard. CAUTION NOTICE: This American National Standard may be revised or withdrawn at any time. The procedures of the American National Standards Institute require that action be taken to affirm, revise, or withdraw this standard no later than fi
13、ve years from the date of approval. Purchasers of American National Standards may receive current information on all standards by calling or writing the American National Standards Institute. Library of Congress Cataloging-in-Publication Data Adaptations and conversions of CCSDS Space Link Extension
14、 Return all Frames transfer service / sponsored by American Institute of Aeronautics and Astronautics. p. cm. Includes bibliographical references. “Approved 3 May 2007.“ “ANSI/AIAA, S-124-2007“ ISBN 978-1-56347-924-3 (hardcopy) - ISBN 978-1-56347-925-0 (electronic) 1. Artificial satellites in teleco
15、mmunication-Standards-United States. 2. Data transmission systems-Standards-United States. 3. Consultative Committee for Space Data Systems. I. American Institute of Aeronautics and Astronautics. TK5104.A165 2007 621.3825-dc22 2007013285 Published by American Institute of Aeronautics and Astronautic
16、s 1801 Alexander Bell Drive, Reston, VA 20191 Copyright 2007 American Institute of Aeronautics and Astronautics All rights reserved No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without prior written permission of the publisher. Printed in
17、 the United States of America American National Standard ANSI/AIAA S-124-2007 iii Contents Foreword.v Introduction vi 1 Scope 1 2 Tailoring 1 3 Applicable Documents . 1 4 Vocabulary 2 4.1 Acronyms and Abbreviated Terms 2 4.2 Terms and Definitions 2 4.3 Nomenclature . 3 4.4 Conventions 3 4.4.1 Bit nu
18、mbering convention 3 4.4.2 Typographic conventions. 4 5 Summary of Functions . 4 5.1 RAF Conversion Functions Performed by the Service Provider 6 5.1.1 Bitstream Blocking Function 6 5.1.2 Ternary Symbol Stream Translation Function 6 5.2 RAF Adaptation Functions Performed by the Service User. 6 5.2.1
19、 Time Source-Synchronized Bitstream Regeneration Function 6 5.2.2 Delayed Time Source Generation Function 6 5.2.3 Dibit to Ternary Symbol Translation Function. 6 5.2.4 Streaming Ternary Command Echo Buffer Function . 7 5.2.5 Preamble and Postamble Substitution Function. 7 5.2.6 Null Symbol Substitut
20、ion Function. 7 5.2.7 Streaming Binary Command Echo Buffer Function 8 6 Supported Data Flows 8 6.1 Time-correlated Binary Telemetry . 8 6.2 Echo of Streaming Ternary Command Data. 10 6.3 Echo of Streaming Binary Command Data. 10 7 Deviation from Normal CCSDS SLE RAF Service . 13 7.1 RAF-START 13 7.2
21、 RAF-TRANSFER-DATA. 13 7.3 RAF-SYNC-NOTIFY. 14 7.4 RAF-STATUS-REPORT 15 8 RAF Conversion Functions Performed by Service Provider 15 8.1 Bitstream Blocking Function 15 ANSI/AIAA S-124-2007 iv 8.2 Ternary Symbol Stream Translation Function 16 9 RAF Adaptation Functions Performed by Service User. 17 9.
22、1 Time Source-Synchronized Bitstream Regeneration Function 17 9.1.1 Estimated Receipt Time of User Bits 17 9.1.2 Generation of Output Bitstream. 18 9.2 Delayed Time Source Generation Function 19 9.3 Dibit to Ternary Symbol Translation Function. 19 9.4 Streaming Ternary Command Echo Buffer Function .
23、 19 9.5 Preamble and Postamble Substitution Function. 20 9.6 Null Symbol Substitution Function. 20 9.7 Streaming Binary Command Echo Buffer Function 20 Annex A Informative References 22 Figures Figure 1 Bit Numbering Convention. 4 Figure 2 Context of the RAF Conversion and Adaptation Functions 5 Fig
24、ure 3 RAF Conversion and Adaptation Functions Supporting the Time-Correlated Delivery of Binary Telemetry Data . 9 Figure 4 RAF Conversion and Adaptation Functions Supporting the Echo of Streaming Ternary Command Data 11 Figure 5 RAF Conversion and Adaptation Functions Supporting the Echo of Streami
25、ng Binary Command Data. 12 Tables Table 1 Ternary Symbol to Ternary Dibit Encoding. 16 ANSI/AIAA S-124-2007 v Foreword This standard was prepared by the AIAA Satellite Control Network Data Transfer Committee on Standards (CoS). The CoS was formed in 2005 to consider standardization of data transfer
26、services relevant to the interoperation of US civil, military, and commercial telemetry, tracking, and control (TT that is, data that is transferred without storage and subsequent forwarding (e.g., recording and playback of telemetry). Support for stored-and-forwarded services (termed offline servic
27、es in the CCSDS SLE specifications) is outside the scope of this standard and are subject for further study. 2 Tailoring When viewed from the perspective of a specific program or project context, the requirements defined in this Standard may be tailored to match the actual requirements of the partic
28、ular program or project. Tailoring of requirements shall be undertaken in consultation with the procuring authority where applicable. NOTE Tailoring is a process by which individual requirements or specifications, standards, and related documents are evaluated and made applicable to a specific progr
29、am or project by selection, and in some exceptional cases, modification and addition of requirements in the standards. 3 Applicable Documents The following documents contain provisions which, through reference in this text, constitute provisions of this standard. For dated references, subsequent ame
30、ndments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the
31、normative document referred to applies. CCSDS 911.1-B-2 Space Link ExtensionReturn All Frames Service Specification CCSDS 301.0-B-3 Time Code Formats ANSI/AIAA S-123-2007 Adaptations and Conversions of CCSDS Space Link Extension Forward Communication Link Transmission Unit Transfer Service ANSI/AIAA
32、 S-124-2007 2 4 Vocabulary 4.1 Acronyms and Abbreviated Terms AFSCN Air Force Satellite Control Network AIAA American Institute of Aeronautics and Astronautics ANSI American National Standards Institute CCSDS Consultative Committee for Space Data Systems EXU SGLS ternary external user NASA National
33、Aeronautics and Space Administration NOAA National Oceanic and Atmospheric Administration RAF Return All Frames RF Radio Frequency SDU Service Data Unit SGLS Space Ground Link Subsystem SLE Space Link Extension TT where XXX is the integer part of the bit rate and YY is the optional fractional part (
34、in bits per second). Either bit rate can appear individually in a private-annotation parameter, or they can both appear in the same private-annotation parameter. In the latter case, both tagged values shall be simply concatenated (e.g., “XXX.YYXXX.YY”), in either order (nominal followed by measured
35、or measured followed by nominal). Use of the private-annotation parameter to carry bit rate information is optional, and depends on the ability of the implementation of the service provider to acquire the rate information. Service provider-specific implementations may convey other information in the
36、 private-annotation parameter in addition to or instead of the nominal and measured bit rate information specified herein. Service provider implementations should represent any other such annotation values as value Unicode strings in Network Byte Order, to allow peer service user systems to unambigu
37、ously extract the standard bit rate information even if the other annotation values are unknown to and/or unsupported by those service user systems. Service user implementations should be capable of handling tagged Unicode strings in the private-annotation parameter other than the ones specified her
38、ein without disruption of the normal performance of their functions. That is, an implementation should either process the tagged items if they are known to the implementation, or discard any unknown tagged items without being forced into a non-operative state. NOTE 2 The bit rate information tags in
39、 the private-annotation parameter are intended for reporting telemetry bit rates. Although not prohibited for use in other purposes (e.g., command echo data), such uses are outside the scope of this standard. 7.3 RAF-SYNC-NOTIFY The notification-type parameter has a loss of frame synchronization val
40、ue that is not applicable to the functions specified in this standard, and thus this value, and the corresponding information in the notification-value parameter, should not be sent in any RAF service instances used in conjunction with these function. ANSI/AIAA S-124-2007 15 7.4 RAF-STATUS-REPORT Th
41、e frame-sync-lock-status parameter normally reports whether the frame synchronization process is in-lock, out-of-lock, or unknown. Since the functions specified in this standard do not implement or use the results of frame synchronization, the value of this parameter should always be unknown. NOTE T
42、he number-of-error-free-frames-delivered parameter reports the number of frames delivered with a frame quality of good. When the version of RAF as specified in CCSDS 911.1-B-2 is used, this will result in the number-of-error-free-frames-delivered parameter having a value of zero, since the octet seg
43、ments will all be tagged as undetermined. However, if an earlier version of the RAF spec is implemented and all octet segments are tagged as good, the number-of-error-free-frames-delivered parameter will have a value equal to that of the number-of-frames-delivered parameter. 8 RAF Conversion Functio
44、ns Performed by Service Provider 8.1 Bitstream Blocking Function a) Received bits shall be accumulated into segments of octets in the order that they are received. b) The size of the segments shall be such that the time required to accumulate any segment during the service instance provision period
45、is guaranteed to be no greater than a maximum time value, as controlled via managed parameter(s). NOTE The requirement to accumulate a segment within a maximum time period is driven by overall data delivery latency requirements. Controlling the time during which the segments are formed ensures that
46、the segment-accumulation process is kept within its allocation of the data delivery latency budget. The requirement for a controllable segment accumulation time can be met with by the specification of a maximum segment length parameter that is applied to all segments generated during the service ins
47、tance provision period, subject to the following considerations. 1) The lower the data rate of the stream being carried, the shorter the segments need to be to stay within a given latency. If source data rates are expected to vary over the duration of the data transfer service instance, the value of
48、 the maximum segment length parameter should be set to the size that satisfies the latency requirement at the lowest data rate that will be encountered for the duration of the service instance. 2) If the bitstream is intended to be processed by the Time Source-Synchronized Bitstream Regeneration ada
49、ptation function (see Section 9.1), the segments must be short enough to ensure that the difference in bit rates at which the first and last bits in each segment are received by the Bitstream Blocking function does not exceed the percentage difference required to ensure accurate time-data correlation. The more rapidly the data rate changes, the shorter the segments need to be to ensure that time-data correlation can be maintained. 3) While the segments must be short enough to satisfy the latency and rate-variation requirements cited in (1) and (2) abov
