1、 Standard ANSI/AIAA S-124-2007 Adaptations and Conversions of CCSDS Space Link Extension Return All Frames Transfer Service AIAA standards are copyrighted by the American Institute of Aeronautics and Astronautics (AIAA), 1801 Alexander Bell Drive, Reston, VA 20191-4344 USA. All rights reserved. AIAA
2、 grants you a license as follows: The right to download an electronic file of this AIAA standard for storage on one computer for purposes of viewing, and/or printing one copy of the AIAA standard for individual use. Neither the electronic file nor the hard copy print may be reproduced in any way. In
3、 addition, the 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 Sp
4、ace Link Extension 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) stan
5、dard Space Link 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
6、 to allow interoperability 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 tel
7、emetry service 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 requi
8、res verification 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 int
9、erests. Substantial 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 exis
10、tence does not 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 cir
11、cumstances give 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 sec
12、retariat or sponsor 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
13、 later than five 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
14、Link Extension 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 satell
15、ites in telecommunication-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 a
16、nd Astronautics 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 publish
17、er. Printed in 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
18、3 4.4.1 Bit numbering 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
19、 User. 6 5.2.1 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 Sy
20、mbol Substitution 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 RA
21、F-START 13 7.2 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 Servi
22、ce User. 17 9.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 Buf
23、fer Function . 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 F
24、unctions 5 Figure 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 E
25、cho of Streaming 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
26、data transfer 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
27、offline services 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
28、 of the particular 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
29、specific program 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,
30、subsequent amendments 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 e
31、dition of the 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 Ser
32、vice ANSI/AIAA 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
33、NASA National 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 fra
34、ctional part (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 followe
35、d by measured 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 info
36、rmation in the 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 syste
37、ms to unambiguously 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
38、 specified herein 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 infor
39、mation tags in 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 synch
40、ronization value 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-ST
41、ATUS-REPORT The 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 u
42、nknown. NOTE The 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
43、 the octet segments 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 Conv
44、ersion Functions 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 pro
45、vision period 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
46、 ensures that 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 t
47、he service instance 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
48、, the value of 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 Re
49、generation adaptation 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
