Software-defined radio baseband system for satellite ... https://www.researchgate.net/.../Software-defined-radio-baseband-for-satellite-manage...

Software-defined radio baseband system for satellite management services Moses B. Mwakyanjala∗ Lule˚ a University of Technology, Kiruna, 98128, Sweden

Prof. M. Reza Emami† Lule˚ a University of Technology, Kiruna, 98128, Sweden

Prof. Jaap van de Beek‡ Lule˚ a University of Technology, Lule˚ a, 97187, Sweden This paper presents functional analysis and system specifications of a baseband system based on software-defined radio (SDR) technology. The analysis is primarily based on the latest blue-book standards from Consultative Committee for Space Data Systems (CCSDS). It covers telemetry, telecommand, ranging and Doppler measurements, as well as some specifications of the associated physical layers. The SDR-based baseband system can support satellite management in the form of software-as-a-service (SaaS) private cloud.

Nomenclature K G r M h (x) g (x) f (x) J E I n k q Tαι T−1 αι

Constraint length of a convolutional code Connection vectors of a convolutional code Code rate Puncture matrix Sequence generator polynomial Code generator polynomial Field generator polynomial Number of bits per Reed-Solomon symbol Number of correctable Reed-Solomon symbols Interleave depth of a Reed-Solomon symbols Number of symbols in a Reed-Solomon codeblock Number of information symbols in a Reed-Solomon codeblock Number of zero fill symbols in a Reed-Solomon codeblock Conventional-to-Berlekamp conversion matrix Berlekamp-to-conventional conversion matrix

I.

Introduction

Satellite management is an expensive service due to the high costs of space-standard equipment. Other than the antenna facilities, a major portion of the costs is associated with the type and number of baseband ∗ PhD

Candidate, Onboard Space Systems, Department of Computer Science, Electrical and Space Engineering, Rymdcampus, Email: [email protected] † Chaired Professor, Onboard Space Systems, Department of Computer Science, Electrical and Space Engineering, Rymdcampus, Email: [email protected], ; Institute for Aerospace Studies, University of Toronto, Toronto M3H 5T6, Canada, Email: [email protected]; AIAA member ‡ Chaired Professor, Signals and Systems, Department of Computer Science, Electrical and Space Engineering, Email: [email protected]

1 of 39 American Institute of Aeronautics and Astronautics

systems, consisting of radio receivers and transmitters, which are needed to support different generations of satellite missions. In a typical satellite management setup, customers connect to the baseband systems via a secure server, as shown in Fig. 1. Satellite telecommanding (TC) is achieved by transferring raw transfer frames (TF) from the customer mission control center (MCC) to the TT&C station. With the help of the baseband systems, these raw transfer frames are encoded and processed, according to the standards defined by the Consultative Committee for Space Data Systems (CCSDS) as well as mission specifications, to obtain communication link transmission units (CLTUs) and transmit them to the satellite as modulated radio waveforms. On the telemetry (TM) side, the channel access data units (CADUs) are extracted by the baseband systems after demodulation of radio waveforms received from the satellite. The CADUs are then decoded and processed according to CCSDS standards into telemetry TFs and delivered to the customer MCC. The CCSDS standards follow a layered architecture similar to other networking standards. Fig. 2 shows the CCSDS standard layers used for telemetry and telecommand in relationship to the open system interconnect (OSI) layers. The respective protocols that implement these layers for telemetry and telecommand are depicted on the right. The protocols used for telemetry are TM Synchronization and Channel Coding1 for frame synchronization and error control coding(ECC) and TM Space Data Link Protocol2 for CCSDS virtual channel (VC) extraction. The protocols used for telecommand are TC Space Data Link Protocol3 for CCSDS VC aggregation and TC Synchronization and Channel Coding4 for ECC. The physical layer standard specification is Radio Frequency and Modulation Systems - Part 1 Earth Stations and Spacecraft.5

TT&C Station

Baseband

Internet Baseband

Satellite Operator #2 Mission Control Center(MCC)

Server

Baseband

Satellite operator #1 Mission Control Center(MCC)

Figure 1. Hardware-based satellite management architecture

Software-defined radio (SDR) technology is a collection of hardware and software technologies that enable low-cost and reconfigurable system architectures for wireless networks and user terminals.6 The use of SDRbased baseband systems can address a solution to a number of problems and issues which are inherent in the architecture in Fig. 1, which is currently being used by a number of space agencies across the globe. The SDRs have been deployed extensively in terrestrial communication systems. However, some technological challenges have made the deployment of SDRs in space applications at a slower pace. Due to the recent advancements in microelectronics, SDR platforms have become cheaper and available at high standards capable of supporting satellite ground station operations. Instead of relying on expensive hardware-based baseband systems, SDR-based baseband systems can be easily run on parallel computers or a private cloud that are quite affordable, since they are completely developed in software. In summary, the use of SDR-based baseband systems will address the following issues: 1. Low development and maintenance cost. Current hardware-based baseband systems are expensive with price ranging in tens of thousands of Euros. In addition, there are costs related to licensing for some of the features. 2. Good track of operational code, since software updates are not dependent on the hardware. Software 2 of 39 American Institute of Aeronautics and Astronautics

OSI LAYERS

CCSDS LAYERS

NETWORK AND HIGHER LAYERS

NETWORK AND UPPER LAYERS

CCSDS PROTOCOLS (TELEMETRY)

CCSDS PROTOCOLS (TELECOMMAND)

TM SPACE DATA LINK PROTOCOL & SPACE DATALINK SECURITY PROTOCOL

TC SPACE DATA LINK PROTOCOL

SYNCHRONIZATION AND CHANNEL CODING SUBLAYER

TM SYNCHRONIZATION AND CHANNEL CODING

TC SYNCHRONIZATION AND CHANNEL CODING

PHYSICAL LAYER

RADIO FREQUENCY AND MODULATION SYSTEMS


DATALINK PROTOCOL SUBLAYER DATA LINK SUBLAYER

PHYSICAL LAYER

Figure 2. CCSDS layers and protocols

updates for the current hardware-based baseband systems are expensive. An SDR-based baseband system would incur relatively lower costs in case an update is needed. 3. Homogeneity between different units, since version control is relatively easy to manage in an all-software system. 4. High level of operational redundancy, since the software can be executed on parallel computers in a private cloud, as shown in Fig. 3. 5. Room for technological improvement. The use of SDR-based baseband systems would allow easy integration of new techniques in digital signal processing and digital communications. Of particular interest are cognitive and multipoint capabilities. 6. Easy integration of support for current and future missions that are not compliant with CCSDS standards. The following sections present functional analysis of services that the SDR-based baseband system can provide, including telemetry, telecommand, ranging and Doppler measurements. Functional analysis will be presented by using the functional flow block diagram (FFBD) approach.7 Section II presents functional analysis of telemetry services. The same analysis for telecommand services will be presented in section III. Section IV looks into satellite ranging, including tone ranging, pseudonoise (PN) ranging and hybrid tone-PN ranging techniques. Section V briefly presents hardware and application frameworks that can be used to realize the system. Section VI concludes the paper.


SDR TT&C Station

SDR Private Cloud

Internet

Satellite Operator #2 Mission Control Center(MCC)

Interface Server

Satellite operator #1 Mission Control Center(MCC)

Figure 3. SDR-based satellite management architecture

II.

Functional analysis for telemetry

The CCSDS telemetry12 chain is shown in Fig. 4. At the sending end, virtual channel (VC) service data units (SDU)s are delivered from user applications to the datalink protocol sublayer by virtual channels. These VCs are aggregated into one physical channel which multiplexes the VC SDUs into TM TFs according to the VC service being used. The synchronization and channel coding sublayer instance processes TM TFs from the data link protocol sublayer into fixed-length data units which can be either CADUs or channel symbols (convolutionally encoded CADUs) and transmit them to the receiving end via the physical layer after performing ECC. At the receiving end, another instance of the synchronization and channel coding sublayer extracts and performs error correction decoding (ECD) on the CADU/channel symbols received by a bit synchronizer. The extracted TM TFs from the CADU/channel symbols are delivered to another datalink protocol sublayer instance which demultiplexes VCs and extracts VC SDUs for delivery to the end user applications based on the VC service being used. The top level FFBD of telemetry at the receiving end is shown in Fig. 5. Bits are received by the bit synchronization block (function 1.0). If no other services are required by the customer, these bits can be delivered directly to the customer MCC by the MCC data delivery interface block (function 5.0). For CCSDS missions, the received bits can either be CADU or channel symbols. The CCSDS frame synchronization and ECD block (function 2.0) performs frame synchronization and error control decoding on the received CADU/channel symbols. The output of the CCSDS frame synchronization and ECD block are properly decoded TM TFs, which can either be delivered directly to the customer MCC by the MCC data delivery interface block or delivered to the CCSDS VC channel extraction block (function 3.0). The recovered VC SDUs from the CCSDS VC extraction block are eventually delivered to the customer MCC. For non-CCSDS missions, the received bits from the bit synchronization block are delivered to the Non-CCSDS data processing block (function 4.0). This block performs custom frame synchronization, ECD and VC extraction specific to the mission, and deliver the received TM frames to the customer MCC via the same MCC data delivery interface block. II.A.

Bit synchronization

This block recovers bits from received I/Q signals. The synchronizer supports line codes and modulation schemes commonly found in space communications. The lines codes that the system can support are8 biphase-level (BP-L), biphase-mark (BP-M), biphase-space (BP-S), non-return-to-zero-level (NRZ-L), non-return-to-zero-mark (NRZ-M), non-return-to-zero-space (NRZ-S), differential biphase - space (DBP-S), differential biphase - mark (DBP-M), delay modulation - mark (DM-M),9 delay modulation - space (DMS),9 randomized non-return-to-zero (R-NRZ), NRZ-L + V35 and NRZ-M + V35. The system supports both suppressed and residual carrier systems10 . Suppressed carrier modulation schemes that can be supported


Sending End (Satellite)

App 1

App 2

Receiving End (Ground Station)

App n

App 1

App 2

App n

Service Data Unit (SDU)

Service Data Unit (SDU) TM SPACE DATA LINK PROTOCOL

TM SPACE DATA LINK PROTOCOL

Transfer Frames(TF)

Transfer Frames(TF)

TM SYNCHRONIZATION AND CHANNEL CODING SUBLAYER

TM SYNCHRONIZATION AND CHANNEL CODING SUBLAYER

CADU/Channel Symbols

CADU/Channel Symbols



Figure 4. CCSDS telemetry chain

are binary phase shift keying (BPSK),11 frequency shift keying (FSK),12 Gaussian frequency shift keying (GFSK),12 quadrature phase shift keying (QPSK),11 unbalanced quadrature phase shift keying (UQPSK),13 π 12 four variants of shaped offset QPSK1412 (SOQPSK-A, SOQPSK-B, SOQPSK-MIL, SOQPSK4 -QPSK, TG) and frequency modulation (PCM/FM).13 Residual carrier modulation scheme that can be supported supported is phase modulation (PCM/PM).13 The FFBD for bit synchronization is shown in Fig. 6. 1. I/Q signal acquisition (function 1.1) This is a hardware-independent block that can receive signals from the SDR frontend. A direct digital synthesizer (DDS) of SDR frontend performs zero-IF I/Q passband frequency translation into I/Q baseband. 2. Diversity combining (function 1.2) Diversity combining block aggregates multiple received signals from different SDR frontend RF input sources into one improved signal. 3. Automatic gain controller (function 1.3) Automatic gain controller (AGC) block maintains a constant level of the received signal. This is useful since synchronization of certain tracking loops depends on a constant signal level. 4. Assisted Doppler shift correction (function 1.4) This block performs coarse Doppler shift mitigation in situations where the Doppler shift is relatively higher than the signal bandwidth. Given satellite two-line elements (TLEs) set, the velocity of the satellite relative the ground station, and hence the Doppler shift, can be predicted.15 With the help of a frequency translating filter, this predicted Doppler shift is used for real-time Doppler shift correction. 5. Carrier frequency recovery (function 1.5) Carrier frequency recovery block is used for synchronization of transmitter and receiver carrier oscillators. The frequency-locked loop (FLL)16 is used for this task.


2.0

3.0

CCSDS Frame Synchronization and ECD (CCSDS 131.0-B-2 Blue Book Aug 2011)

CCSDS VC Extraction (CCSDS 232.0-B-2 Blue Book Sept 2015)

1.0

5.0

OR

Bit Synchronization

MCC Data Delivery Interface

4.0

Non-CCSDS Data Processing

Figure 5. Top level FFBD for telemetry receiving end

1.1 I/Q Signal Acquisition

1.6 Baseband Demodulation BPSK FSK GFSK QPSK UQPSK π/4- QPSK SOQPSK-A SOQPSK-B SOQPSK-MIL SOQPSK-TG PCM/PM PCM/FM

1.2

1.3

Diversity Combining

OR

1.4 OR

Automatic Gain Controller (AGC)

1.5

Assisted Doppler Correction

1.7 Symbol Timing Recovery Maximum likelihood TED Early-late TED Zero-crossing TED Gardner TED Mueller and Muller TED

1.8

1.9

Channel Equalization CMA LMS DD

Carrier Phase Recovery Costas Loop ML phase synchronizer

OR

OR

1.10 Line Decoding BP-L BP-M BP-S NRZ-L NRZ-M NRZ-S DBP-M DBP-S DM-M DM-S R-NRZ NRZ-L + V35 NRZ-M + V35

Carrier Frequency Recovery

(3.0)Ref CCSDS ECC and Frame Synchronizatiion

(4.0)Ref Non-CCSDS Data Processing

Figure 6. FFBD for bit synchronization

6. Baseband demodulation (function 1.6) This block extracts unsynchronized symbols from the received I/Q signal. The process is unique for each modulation scheme. 7. Symbol time recovery (function 1.7) This block is used to synchronize transmitter and receiver symbol clocks. It is a loopback system which consists four major components: a time error detector (TED), a loop filter, an interpolation controller and an interpolator.17 An example of algorithms that could be used for error detection are maximum likelihood TED, early-late TED, zero-crossing TED,Gardner TED and Mueller and Muller TED. A second or higher order loop, such as the proportional-plus-integrator loop, can be used as a loop filter. Interpolation control can be performed by a modulo-1 counter or a recursive interpolation control. The piecewise interpolator or polyphase interpolator can be used for interpolation.11 8. Equalization (function 1.8) This block is used to minimize the effect of channel non-linearities. There is a number of equalization algorithms including constant-modulus algorithm (CMA)18 equalizer and the least-mean-square decision directed (LMS-DD).


9. Carrier phase recovery (function 1.9) This block is used for synchronization of transmitter and receiver carrier phase. The maximumlikelihood phase synchronizer or the Costas loop are the most popular structures for this task. 10. Line decoding (function 1.10) This block maps synchronized information symbols into information bits. II.B.

CCSDS Frame Synchronization and Error Control Decoding

To ensure maximum flexibility, CCSDS specifies a number of ECC options.1 The FFBD in Fig. 7 shows eight ECC options: 1. Uncoded In uncoded systems, the received data unit from the bit synchronization block (function 1.0) is CADU. Since no ECC is employed, the CADU payload is a TM TF which can be optionally scrambled. The maximum size of the TF is 2048 octets. The differential decoding block (function 2.3) can be optionally used to perform phase ambiguity resolution. The frame synchronization block (function 2.4) extracts TM TFs from the CADUs by utilizing a predefined synchronization pattern. It can also perform phase ambiguity resolution in case differential encoding is not used. For scrambled TM TFs, the descrambling block (function 2.5) is used to descramble the TM TFs before delivery. Following descrambling, TM TFs can either be delivered to customer MCC by the MCC data delivery interface (function 5.0) or sent to the CCSDS VC extraction block (function 3.0) before delivery. 2. Convolutional coding only When convolutional coding is used at the sending end, the bits received by the bit synchronization block (function 1.0) are channel symbols. By using the Viterbi algorithm, the convolutional decoding block (function 2.1) decodes the channel symbols into CADUs . Since no outer code is used, the payload of the CADU is TM TF with maximum size of 2048 octets. Further processing of the CADU is the same as that of uncoded systems. 3. Punctured convolutional code only Punctured convololutional code is functionally similar to unpunctured counterpart with the exception that the decoding process involves the Viterbi algorithm combined with a depuncturer. Similarly, the data units received from the bit synchronization block are channel symbols and the CADU payload is TM TF with a maximum size of 2048 octets. 4. Reed-Solomon code only When Reed-Solomon is employed as the only ECC method, the bits received from the bit synchronization block (function 1.0) are CADUs which carry Reed-Solomon codeblocks as payload. The maximum size of the TM TFs inside the Reed-Solomon codeblocks is 255I. The frame synchronization block (function 2.4) extracts Reed-Solomon codeblocks from the CADU by utilizing a predefined synchronization pattern. The descrambling block (function 2.5) can be used in case the Reed-Solomon codeblocks were scrambled at the sending end. The descrambled Reed-Solomon codeblocks are decoded by the ReedSolomon decoding block (function 2.6). The data units that result after Reed-Solomon decoding are TM TFs. The TM TFs can either be delivered to customer MCC by the MCC data delivery interface (function 5.0) passed through the CCSDS VC extraction block (function 3.0) before delivery. 5. A concatenation of convolutional and Reed-Solomon codes In this case, Reed-Solomon becomes the outer code while convolutional code becomes the inner code. The maximum size of the TM TFs is the same as that in systems that employ Reed-Solomon code only. The decoding process is functionally similar to that of basic convolutional decoding with the exception that the CADUs payload are Reed-Solomon codeblocks instead of raw TM TFs. Hence, a Reed-Solomon decoding block is invoked before delivery to the customer MCC (function 5.0). 6. A concatenation of punctured convolutional and Reed-Solomon codes This case is functionally similar to a concatenation of a Reed-Solomon and convolutional code. The maximum size of the TM TFs is the same as that in systems that employ Reed-Solomon code only. Similarly, the decoding process is similar to that in systems with punctured convolutional code except


that the CADU payload is Reed-Solomon codeblocks instead of raw TM TFs. A Reed-Solomon decoder is employed to extract raw TM TFs from the codeblocks before delivery to the MCC(function 5.0). 7. Turbo code only Turbo code can only be used without concatenation with an inner code. The received bits from the bit synchronization block (function 1.0) are CADUs. The payload of the CADU are Turbo codewords. The TM TFs inside the Turbo codewords must have the a size in bytes from the following set : 223, 446, 892 or 1115. The frame synchronization block (function 2.4) extracts the Turbo codewords from the CADU by utilizing a predefined synchronization pattern. A descrambling block (function 2.5) can be used in case the Turbo codewords were scrambled at the sending end. The Turbo decoding block (function 2.7) decodes the descrambled Turbo codewords into TM TFs before delivery to the MCC (function 5.0). 8. Low-Density Parity-Check (LDPC) code only Similar to Turbo codes, LDPC code can only be used without concatenation with an inner code. The received bits from the bit synchronization block (function 1.0) are CADUs. The payload of the CADU are LDPC codewords. Allowed size for TM TFs inside LDPC codewords are 892 octets for rate-7/8 code and 128 octets, 512 octets or 2018 octets when rate-1/2, rate-2/3 and rate-4/5 are used. After frame synchronization block (function 2.4) and descrambling blocks (function 2.5), the descrambled LDPC codewords are decoded by the LDPC decoding block (function 2.8) before delivery to the customer MCC (function 5.0).

2.1 Convolutional Decoding 2.3

(1.0)Ref Bit Synchronization

OR

Differential Decoding

2.4

OR

OR

Frame Synchronization

2.5

OR

Descrambling

OR

2.2 Punctured Convolutional Decoding 2.6 Reed-Solomon Decoding

(3.0) Ref. CCSDS VC Extraction

2.7 Turbo Decoding

OR

2.8 LDPC Decoding

(5.0) Ref. MCC Data Delivery Interface

Figure 7. FBBD for CCSDS Error Control Decoding

The following sections present specification and operation of the blocks of the FFBD above. II.B.1.

Convolutional decoding

This block performs convolutional decoding for the basic convolutional code specified in table 1.1 The connection of registers is shown in Fig. 8. The encoder inputs one bit and outputs two bits. Registers values are connected by the two connection vectors G1 and G2 by two exclusive-or operations. The output of the G2 path is inverted to ensure maximum bit transition for modulation schemes with one bit per symbol. For modulation schemes with more than one bit per symbol, the inverter can not guarantee enough bit transition and hence a scrambler has to be employed. Otherwise the output can be split into two paths and inverted separately. The decoder for the basic convolutional code above is shown in the FFBD in Fig. 9. Frame synchronization can be performed before or after decoding(function 2.1.1). Following this is decoding for unsplit and split channels. For unsplit channels, there are two optional blocks for inverting the input of G1 and G2 followed by decoding, which is performed by the Viterbi algorithm19 (function 2.1.4). For split channels, the first task is to split the channel into inphase (I) and quadrature (Q) channels (function 2.1.5). Each channel is


Table 1. Basic convolutional code specifications

Parameter Nomenclature Code rate Constraint length Connection vectors Symbol inversion

Value Convolutional code with maximum-likelihood decoding r = 12 K = 7 bits G1 = 1111001, G2 = 1011011 Output path of G2

G1 XOR

MULTIPLEXER

INPUT

OUTPUT

XOR

G2

Figure 8. Block diagram of a basic convolutional encoder

then decoded separately by means of two Viterbi decoders. After decoding, the I and Q channels are joined by the I/Q join block (function 2.1.14). II.B.2.

Punctured convolutional decoding

Punctured convolutional codes allow high rate coding at the expense of performance. This code is very similar to the basic convolutional code in table 1 with the exception of different code rates and brought by puncturing. The encoder specifications1 are shown in table 2. The connection diagram for the encoder is shown in Fig. 10. Table 2. Basic convolutional code specifications

Parameter Nomenclature Code rate Constraint length Connection vectors Symbol inversion

Value Punctured convolutional code with maximum-likelihood decoding r = 21 , punctured to r = 23 , 43 , 56 , 78 K = 7 bits G1 = 1111001, G2 = 1011011 None

The decoder is shown in Fig. 11. The channel symbols received by the bit synchronization block (function 1.0) are dupunctured (function 2.2.1) before decoding. The depuncturing process involves an insertion of null symbols specified by a puncture matrix. The specifications of puncture matrices are shown in table 3. Following a depuncture is the Viterbi decoding block(function 2.2.2).


(2.3) Ref. Differential Decoding

UNSPLIT CHANNEL DECODING

2.1.2

Invert G2

2.1.3

OR

(2.4) Ref. Frame Synchronization

2.1.4

OR

Invert G1

Viterbi (7,½)

(2.5) Ref. Descrambling (1.0)Ref Bit Synchronization

2.1.1 Frame Synchronization

OR

2.1.6

2.1.7

I-Channel Reception

Invert G2

2.1.8

OR

Invert G1

2.1.9

OR

OR

Viterbi (7,½)

2.1.5

2.1.14

I/Q Split

AND 2.1.10

2.1.11

Q-Channel Reception

Invert G2

2.1.12

OR

Invert G1

I/Q Join


2.1.13

OR

(2.6) Ref. Reed-Solomon Decoding

Viterbi (7,½)


SPLIT CHANNEL DECODING

Figure 9. The FFBD of the basic convolutional decoder

G1 XOR

PUNCTURE

INPUT

OUTPUT

XOR

G2

Figure 10. Block diagram of a punctured convolutional encoder

II.B.3.

Differential decoding

Differential encoding and unique word detection method are among the recommended methods of phase ambiguity resolution5 as shown in Fig. 12. Unique word detection technique is performed by the frame synchronizer which flips the whole data stream until a unique word, known as an attached sync marker (ASM) is detected. Fig. 13 shows two configurations for differential encoding and ECC. In each configuration, there is a modulator and a demodulator. Phase ambiguity arises at the receiver when a phase-locked loop (PLL) or a Costas loop has been used for carrier phase recovery.11 Phase ambiguity manifests itself as a flip of the channel symbols. Differential encoding can be used to eliminate this effect. The choice of a configuration must consider the nature of the ECC in use as well as overall system performance. In the first configuration, differential encoding is performed before ECC. This will only work for ECC codes that are transparent such as convolutional codes. Configuration two will work for all ECC codes. Unfortunately, this configuration is not favored since it involves differential detection which can introduce a considerable loss to the overall system performance. Based on these factors, the eight CCSDS ECC options have been configured to resolve phase ambiguity in the following way: 1. Uncoded


(2.3) Ref. Differential Decoding (1.0)Ref Bit Synchronization

2.2.1

2.2.2

Depuncture

Viterbi (7,½)


Figure 11. The FFBD of the punctured convolution decoder

Table 3. Puncturing matrices

Puncture matrix " # 1 0 M= "1 1 #

Code rate r =

2 3

M=

r =

3 4

r =

5 6

r =

7 8

1 "1

1 M= 1 " 1 M= 1

0 1

1 0

0 1

1 0

0 1

1 0

0 1

0 1

0 1

1 0

#

0 1

1 0

#

In uncoded systems, there is no ECC. Either differential decoding or unique word detection method can be used for phase ambiguity resolution. 2. Convolutional coding only Convolutional codes are transparent and hence configuration one is applicable. Therefore, when convolutional codes are used phase ambiguity resolution can be performed by either differential decoding or unique word detection method. 3. Punctured convolutional code only Punctured convolutional codes are also transparent. Similar to basic convolutional code, differential decoding or unique word detection can be used for phase ambiguity resolution. 4. Reed-Solomon code only Reed-Solomon codes are transparent making them suitable for configuration one. However, ReedSolomon codes lose their transparency when they are shortened. Phase ambiguity need to be resolved before any decoding. Therefore, the unique word detection method is used for phase ambiguity resolution. 5. A concatenation of convolutional and Reed-Solomon codes In systems that use this ECC option, phase ambiguity resolution can be performed by either differential decoding or unique word detection method. 6. A concatenation of punctured convolutional and Reed-Solomon codes Both differential decoding and unique word detection method can be used to perform phase ambiguity 11 of 39 American Institute of Aeronautics and Astronautics

(O)QPSK Systems

Uncoded Systems Differential Data Format

Coded Systems

Unique word detection technique

Differential Data Format

Differential Inside FEC Codec

Differential Outside FEC Codec

Non-Differential Data Format Unique word detection technique

Convolutional Metric Error Technique

Figure 12. Recommended phase ambiguity resolution methods

CONFIGURATION ONE INPUT

Differential Encoder

ECC

Modulator

Demodulator

ECD

Differential Decoder

OUTPUT

INPUT

ECC

Differential Encoder

Modulator

Demodulator

Differential Decoder

ECD

OUTPUT

CONFIGURATION TWO

Figure 13. Configurations of differential encoding and ECC

resolution. 7. Turbo code only The Turbo codes used in CCSDS standard1 are non-transparent and hence configuration one cannot be used. Configuration two is known to cause severe performance degradation. Therefore, phase ambiguity resolution is performed by the unique word detection method. 8. Low-density parity-check (LDPC) code only Like Turbo codes, LDPC codes are also non-transparent and hence configuration one cannot be used. Phase ambiguity resolution is therefore performed by the unique word detection method. The FFBD for the differential decoder is shown Fig. 14. There are two paths for unsplit and split channels. The split channel differential decoding functionality has been included to accommodate systems that uses two differential encoders for the I and Q channels. II.B.4.

Frame synchronization

The main functions of frame synchronization are payload extraction from the CADU and phase ambiguity resolution. Telemetry data consists of a contiguous trail of CADUs as shown in Fig. 15. A CADU consists of a payload and an ASM. The payload can be a TF, codeblock (Reed-Solomon) or codeword (Turbo or LDPC). An ASM is a pattern that enables node synchronization. CCSDS specifies seven ASM patterns to accommodate different coding options specified by the standard as shown in table 4. Frame synchronization is performed by the FFBD in Fig. 16. The first step is ASM searching (function 2.4.1). Ideally, this is achieved by comparing the telemetry data with the ASM pattern bit by bit. However, there is a possibility of bit errors in the ASM pattern. Therefore, the comparison should include a small margin of bit error. The ASM pattern can also be flipped in case phase ambiguity resolution is required.



UNSPLIT CHANNEL DECODING 2.3.1 (1.0)Ref Bit Synchronization

(2.1)Ref Convolutional decoding

Decoding (2.5) Ref. Descrambling

OR

2.3.3

2.3.4

I-Channel Reception

Decoding

OR

OR

2.3.2

2.3.7

I/Q Split

(2.2)Ref Punctured Convolutional decoding


AND 2.3.5

2.3.6

Q-Channel Reception

Decoding


I/Q Join

OR (5.0) Ref. MCC Data Delivery Interface

SPLIT CHANNEL DECODING

Figure 14. The FFBD of the differential decoder

ASM

PAYLOAD

ASM

PAYLOAD

ASM

PAYLOAD

ASM

Figure 15. Channel Access Data Unit (CADU)

Once the ASM search block has located the ASM in the telemetry data at a specified bit error margin, the ASM check block (function 2.4.2) checks for consecutive ASM pattern occurrences. If the number of occurrences is below a specified threshold, the frame synchronizer goes back to the ASM searching block. Otherwise, CADU payload is extracted by the payload extraction block (function 2.4.3). This block extracts payload by checking the occurrence of next ASM pattern to within a specified error margin. If the error margin is exceeded, the frame synchronizer will stop payload extraction and go back to the ASM searching block. II.B.5.

Descrambling

Symbol time recovery is the most important part of any receiver. Traditionally, there is no channel dedicated to symbol clock. Symbol timing recovery is performed by extracting clock frequency from the data signal. TED accuracy relies solely on bit transition. Therefore, the sending end must maintain an adequate bit transition density to enable the receiving end to lock. To ensure adequate bit transition density, CCSDS specifies the following requirements for both category A (below 2 million kilometers) and category B (above 2 million kilometers) missions5 • The maximum strings of either zeros or ones must be limited to 64 bits. • The bit transition density for category A missions must be at least 125 transitions for every 1000 consecutive symbols. • The bit transition density for category B missions must be at least 275 transitions for every 1000 consecutive symbols. A scrambler is used to ensure adequate bit transition density. The scrambler specified by CCSDS has the following polynomial1 h (x) = x8 + x7 + x5 + x3 + 1 (1) 13 of 39 American Institute of Aeronautics and Astronautics

Table 4. Attached Sync Markers (ASM) patterns

Error Correction Code Uncoded data, convolutional, Reed-Solomon, concatenated, and rate- 7/8 LDPC coded data Rate-1/2 Turbo and rates 1/2, 2/3, and 4/5 LDPC coded data Rate-1/3 Turbo coded data Rate-1/4 Turbo coded data Rate-1/6 Turbo coded data

ASM hexadecimal pattern 1ACFFC1D 034776C7272895B0 25D5C0CE8990F6C9461BF79C 034776C7272895B0 FCB88938D8D76A4F 25D5C0CE8990F6C9461BF79C DA2A3F31766F0936B9E40863

(2.5) Ref. Descrambling (1.0)Ref Bit Synchronization


(2.1)Ref Convolutional decoding (2.2)Ref Punctured Convolutional decoding

OR

2.4.1

2.4.2

ASM Search

ASM Check

(2.7) Ref. Turbo Decoding

2.4.3

OR

Payload Extraction

OR

(2.8) Ref. LDPC Decoding (3.0) Ref. CCSDS VC Extraction

(2.3)Ref Differential Decoding


Figure 16. The FBBD of the frame synchronizer

The seed value of this scrambler must all always be all ones. II.B.6.

Reed-Solomon decoding

This block performs Reed-Solomon decoding for the code specified in table 5. It is a systematic code capable of correcting either E = 16 symbols when it is used as a (255,223)-Reed-Solomon code or E = 8 when it is used as a (255,239)-Reed-Solomon code. Code interleaving can be used to improve the performance of this code in channels with impulsive noise. The interleave depths specified for this code are I = 1 , 2, 3, 4, 5 or 8. When an interleaver is used, the Reed-Solomon encoder input is kI and the output is nI symbols. The interleaving process starts by multiplexing the incoming TM TF symbols into I different frames of k symbols. A Reed-Solomon encoder calculates and adds adds parity symbols to these I frames of size k into I frames of size n symbols. Following the encoder is a demultiplexer which combines the I frames and their parity symbols into an nI symbol Reed-Solomon block. The combined effect of a multiplexer and demultiplexer result into a Reed-Solomon codeblock where the original data stream remains unchanged. Reed-Solomon decoding is shown by the FFBD in Fig. 17. The I-channel multiplexer block (function 2.6.1) multiplexes the CADU with Reed-Solomon codeblocks into I frames of size n. A Reed-Solomon decoder decodes these blocks into I frames of size k. Following Reed-Solomon decoding is an I-Channel demultiplexer (function 2.6.6) which demultiplexes the output of the Reed-Solomon decoder into a TM TF of size kI. The decoded TM TF is either delivered to the customer MCC by the MCC data delivery block (function 5.0) or to the CCSDS VC extraction (function 3.0).


Table 5. Reed-Solomon code specifications

Parameter Number of bits per symbol Error correction capability Interleave depth Symbols per codeblock Information symbols per codeblock Field generator polynomial Code generator polynomial Code characteristics

Maximum TM TF length

Value J = 8 E = 8, 16 I = 1 , 2, 3, 4, 5, 8 n = 2J − 1 = 255 k = n − 2E f (x) = x8 + x7 + x2 + x + 1 Q127+E g (x) = j=128−E x − α11j (255,223) Reed-Solomon code when E = 16 (255,239) Reed-Solomon code when E = 8 (n-q,k-q) shortened Reed-Solomon code Lengthmax = (255 − 2E − q) · I for octet compatibility Lengthmax = (255 − q) · I is a multiple of four for 32 bits compatibility

Reed-Solomon symbols can be presented in either conventional or Berlekamp (dual-basis) representation. In conventional representation, a conventional Reed-Solomon decoder (function 2.6.5) is used. Otherwise, if the symbols are in Berlekamp representation, Berlekamp Reed-Solomon decoding is used. Berlekamp ReedSolomon decoding can be performed by a conventional decoder by converting symbols from Berlekamp to conventional representation (function 2.6.2) before conventional decoding and then converting the output to Berlekamp representation after decoding (function 2.6.4). The conversion from Berlekamp to conventional representation is achieved by multiplying the Berlekamp symbols by Berlekamp-to-conventional conversion matrix, T−1 αι , given in equation 2.

−1 Tαι

 1 1   0  0 = 0   1  0 1

0 1 0 0 0 0 1 0

0 0 1 0 1 1 1 0

1 1 1 1 1 1 0 1

1 1 1 1 0 0 0 0

0 1 1 1 1 0 0 1

1 0 1 0 1 1 0 0

 1 1   0  0  1   1  0

(2)

0

On the other end,the conversion from conventional to Berlekamp notation is achieved by multiplying the conventional symbols by the conventional-to-Berlekamp conversion matrix, Tαι , given in equation 3

Tαι

 1 1   1  1 = 1   1  1 0

0 1 1 0 1 0 0 1

0 1 1 0 1 0 1 1

0 0 0 0 1 1 0 1

1 1 1 0 1 1 1 1

1 1 1 1 0 0 1 0

0 1 0 1 1 0 1 1

 1 1   0  0  0   1  1 1


(3)

(2.1) Ref. Convolutional Decoding

Berlekamp Reed-Solomon Decoding 2.6.2 Berlekamp to Conventional Data Conversion

(2.3) Ref. Differential Decoding

2.6.3 Conventional Reed-Solomon Decoding

2.6.4 Conventional to Berlekamp Data Conversion

(3.0) Ref. CCSDS VC Extraction 2.6.6

2.6.1

OR

OR

I-Channel Multiplexer


I-Channel Demultiplexer (5.0) Ref. MCC Data Delivery Interface

2.6.5 Conventional Reed-Solomon Decoding

(2.5) Ref. Descrambler

Figure 17. The FBBD of the Reed-Solomon decoder

II.B.7.

Turbo decoding

CCSDS specifies a systematic parallel concatenated turbo code with two recursive component codes. Each convolutional element has 16 states. Supported rates are 12 , 13 , 14 and 16 . Turbo codes are decoded by an iterative soft-decision process.19 II.B.8.

LDPC decoding

LDPC codes are a class of linear block codes. CCSDS specifies a (8160,7136) LDPC code with coding rate 223 . This code is a modified version of a basic (8176,7156). The standard also specifies punctured of R = 255 versions of this code with rates 12 , 23 and 54 . The FFBD for LDPC decoding is shown in Fig. xxx. Decoding can be performed by the sum-product algorithm19



2.8.1

OR

Depuncturing

OR

(2.5) Ref. Descrambler

2.8.2 Sum-product algorithm decoding


Figure 18. The FBBD of the LDPC decoder

II.C.

CCSDS Virtual Channel Extraction

CCSDS VC extraction is performed according to the TM Space Data Link Protocol.2 The TM Space Data Link Protocol is a logical protocol that channelizes one physical channel into a number of different VCs. A number of VCs can be aggregated into one master channel. A combination of master and VCs result into service access point (SAP) address space. A SAP address is included in the header of each TF. There are three parts of this address: transfer frame version number (TFVN), spacecraft identifier (SCID), and virtual channel identifier (VCID). The concatenation of TFVN and SCID is known as a master channel identifier


(MCID), and the concatenation of an MCID and a VCID is called a global virtual channel identifier (GVCID).

VIRTUAL CHANNEL : IDENTIFIED BY GVCID VC MU X

VC MU X

VC MU X

MASTER CHANNEL : IDENTIFIED BY MCID

MC MUX

PHYSICAL CHANNEL : IDENTIFIED BY CHANN EL NAME

Figure 19. Service Access Point address space for CCSDS TM

This protocol provides eight services operating on the SAP address space in Fig. 19. There are five services provided for the virtual channel. These services are virtual channel packet (VCP), virtual channel access (VCA), virtual channel frame secondary header(VC FSH), virtual channel operational control field(VC OCF), and virtual channel frame(VCF). The SAP address for these services is GVCID. For the master channel, there are three services. These are master channel frame secondary header (MC FSH), master channel operational control field (MC OCF), and master channel frame (MCF) services. The SAP address for these services is MCID.2 These services can be classified into asynchronous, synchronous or periodic categories. Table 6. A summary of TM services

Service name Virtual channel packet Virtual channel access Virtual channel frame secondary header Virtual channel operational control field Virtual channel frame Master channel frame secondary header Master Operational Control Field

Service data unit Packet VCA SDU FSH SDU

Service type Asynchronous Asynchronous or Periodic Synchronous or Periodic

Address GVCID + PVN GVCID GVCID

OCF SDU

Synchronous or Periodic

GVCID

Transfer frame FSH SDU

Asynchronous or Periodic Synchronous or Periodic

GVCID GVCID

OCF SDU

Synchronous or Periodic

GVCID

CCSDS VC extraction involves the process of extracting SDUs from received TFs and deliver them to end user applications. The TM TF format is shown in Fig. 20. The TM TFs consists of four parts


1. Transfer frame primary header This field contains master channel identifier, virtual channel identifier, operational control field, master channel frame count, virtual channel frame count and transfer frame data field status. 2. Transfer frame secondary header This field contains an ID and a datafield. 3. Transfer frame data field This field contains data that is to be delivered to final user applications. It can be a packet, an SDU or and idle frame. 4. Transfer frame trailer This is an optional field which contains an optional operational control field (OCF) and an optional frame error control field. The OCF field allows synchronized transmission of data from either a master channel or a virtual channel. The frame error control field is a 16-bit field used for error control. Its calculation is based on cyclic redundancy check (CRC) techniques.

TM Transfer Frame Transfer frame primary header

Transfer frame secondary header

6 octets

Up to 64 octets

Transfer frame trailer(Optional)

Transfer frame data field

OCF(Optional)

FECF(Optional)

4 octets

2 octets

Varies

Figure 20. Telemetry transfer frame and segment header formats

The FFBD of CCSDS VC extraction is shown in figure 21. Transfer frames are received from CCSDS frame synchronization and ECD block (function 2.0). The all frames reception block (function 3.1) receives all TM TFs and perform cyclic redundancy check (CRC) tests. This block is followed by the master channel demultiplexing block (function 3.2) which splits the the received TM TFs into master channels. If the MCF service is supported for a particular master channel, no other services can exist and theMCF.indication primitive (function 3.4) delivers the TFs to the customer MCC. In case MCF service is not supported by a particular master channel, the master channel frame reception block (function 3.3) receives all master channel frames and adds loss flag if there is a gap in master channel frame count. This block is followed by MC FSH.indication (function 3.6), MC OCF.indication (function 3.7) and virtual channel demultiplexing (function 3.5). MC FSH.indication and MC OCF.indication deliver MC FSH SDU or MC FSH SDU to the MCC respectively. The virtual channel demultiplexing block splits the TFs into virtual channels. If the virtual channel frame service exists, no other services can exist and the VCF.indication (function 3.9) delivers the TF to the customer MCC. Otherwise, the TFs are received by the virtual channel reception block (function 3.8). This block adds loss flag if there is a gap in virtual channel frame count. This block is followed by VCP.indication (function 3.10), VCA.indication (function 3.11), VC FSH.indication (function 3.12) and VC OCF.indication blocks. These deliver packet, VCA SDU, VC FSH SDU and VC OCF SDU to the MCC respectively. However, the VCP and VCA services cannot exist on the same virtual channel. VC FSH and VC OCF services cannot exist if MC FSH and MC OCF services are on the same master channel. II.D.


Non-CCSDS data processing feature caters for missions which are compliant with a subset of common framing and ECC standards. These standards, such as amateur X25 (AX.25), digital video broadcasting satellite (DVB-S), digital video broadcasting - satellite - second generation (DVB-S2) are foreseen to be used in future satellite missions. For non-CCSDS missions that do not fall in this category, telemetry is sent to the data delivery interface block directly. For maximum flexibility, a set of standard non-CCSDS protocols is used in conjunction with generic and customizable framing and ECC functionality as shown in Fig. 22. 18 of 39 American Institute of Aeronautics and Astronautics

3.10 Packet Extraction and forwarding (VCP.indication)

3.11 VCA Service SDU Forwarding (VCA.indication)

3.8 Virtual Channel Reception

3.12 VC_FSH SDU Forwarding (VC_FSH.indication)

3.13 VC_OCF SDU Forwarding (VC_OCF.indication)

3.5

3.3 Master Channel Reception

(2.0)Ref CCSDS Frame Synchronizati on and ECD

Virtual Channel Demultiplexing

3.9

3.6

VC Frame Service SDU forwarding (VCF.indication)

(5.0)Ref OR


MC_FSH Service Packet forwarding (MC_FSH.indication)

3.1

3.2

3.7

All frames reception

Master Channel Demultiplexing

MC_OCF Service Packet forwarding (MC_OCF.indication) 3.4 Master Channel Frame Service SDU forwarding (MCF.indication)

Figure 21. The FFBD of CCSDS virtual channel extraction

4.1 Error Control Decoding

(1.0)Ref Bit Synchronization

DVB-S ECC DVB-S2 ECC Generic differential decoding Generic convolutional decoding Generic descrambling Generic BCH decoding Generic Reed-Solomon decoding Generic Turbo decoding Generic LPDC decoding

4.2 Framing OR

AX.25 Deframing DVB-S Deframing DVB-S2 Deframing

OR

(5.0)Ref MCC Data Delivery Interface

Figure 22. Non-CCSDS data processing

III.

Functional analysis for telecommand

The CCSDS telecommand43 chain is shown in Fig. 23. At the sending end, VC SDUs are delivered from user applications to the datalink protocol sublayer by virtual channels. These VCs are aggregated into one physical channel which multiplexes the VC SDUs into TC TFs according to the VC service being used. The synchronization and channel coding sublayer instance processes TC TFs from the data link protocol sublayer into CLTUs and transmit them to the receiving end. At the receiving end, another instance of the synchronization and channel coding sublayer extracts and performs error correction decoding (ECD) on the CLTUs received by a bit synchronizer. The extracted TC TFs from the CLTUs are delivered to another datalink protocol sublayer instance which demultiplexes VCs and extracts VC SDUs for delivery to the end user applications. The FFBD for the telecommand chain is shown in figure 24. Frames are received by the MCC data transfer interface (function 1.0). In case no framing or ECC is required, the received frames can be directly transferred to the bit modulation block (function 5.0) which modulates and transmits frames to the receiving end. The CCSDS VC aggregation block (function 2.0) aggregates VC SDUs from user applications into TC TFs. This block can be bypassed in case this functionality is not needed by the customer. The TC TFs are transferred to the CCSDS ECC and frame generation block (function 3.0) which performs ECC and generates CLTUs. The CLTUs are transferred to the bit modulation block for modulation and transmission


Sending End (Ground Station)

App 1

App 2

Receiving End (Satellite)

App n

App 1


App 2

App n




Transfer Frames(TF)

Transfer Frames(TF)

TC SYNCHRONIZATION AND CHANNEL CODING SUBLAYER

TC SYNCHRONIZATION AND CHANNEL CODING SUBLAYER

CLTUs

CLTUs



Figure 23. CCSDS telecommand chain

to the receiving end. The non-CCSDS data processing block (function 4.0) processes frames received by the MCC data transfer interface in missions that are not CCSDS-compliant. This block performs custom framing and ECC and transfer the processed frames to the bit modulation block for modulation and transmission.

III.A.

CCSDS Virtual Channel Aggregation

The CCSDS VC aggregation is performed according to the CCSDS TC space datalink protocol.3 The SAP address space of the TC space datalink protocol3 is very similar to the SAP address space of the TM space datalink protocol. The only exception is that the former has an one additional channel called multiplexer access point (MAP) as shown in Fig. 25. This protocol provides seven services operating on the SAP address space in Fig. 25. There are two services for the MAP channel: MAP packet and MAP access. There are also four services provided for the VC: VC packet, VC channel access, VC frame and command operational procedure (COP management) services. There is only one service for the master channel; master channel frame service. Both of these services, with the exception of the VC frame, master channel frame, and COP management services, can be either Type-A or Type-B service. Type-A services use automatic repeat request (ARQ) and a sequence-controlled mechanism that ensures lossless, non-duplicated and in-sequence delivery of transferred user application SDUs. Type-B services are also called expedited services. They are less reliable and are often used in emergency situations or in cases where the retransmission of user application SDUs is handled by higher level protocols. CCSDS VC aggregation is the process of generating TC TFs from user application SDUs. The TC TF format is shown in Fig. 26. The TC TFs consists of three fields


3.0

2.0 CCSDS VC Aggregation (CCSDS 232.0-B-3 Blue Book Sept 2015)

OR

CCSDS ECC and Frame Generation (CCSDS 231.0-B-2 Blue Book Sept 2010)

1.0

5.0

OR

MCC Data Transfer Interface

Bit Modulation

4.0


Figure 24. Top level FFBD for telecommand at the sending end

Table 7. A summary of TC services

Service name MAP packet Virtual channel packet MAP access Virtual channel access Virtual channel frame Master channel frame COP management

Service data unit Packet Packet MAP SDU VCA SDU Transfer frame (TF) Transfer frame (TF) N/A

Service type Type-A and -B Type-A and -B Type-A and -B Type-A and -B N/A N/A N/A

Address GMAP ID + Packet Version Number GVCID + Packet Version Number GMAP ID GVCID GVCID MCID GVCID

1. Transfer frame primary header This field contains eight data fields: TFVN, bypass flag, control command flag, reserved spare, SCID, frame length and frame sequence number. 2. Transfer frame data field This field contains data units to be transmitted. These data units can carry either control information (e.g. Unlock and Set(V(R) commands) (Type-C) or frame data units (FDU) (Type-D) which contains application SDUs. It can be observed that the MAP address is not part of the transfer frame primary header. For services using the MAP channel, MAP address must be specified by means of the segment header in Fig. 26 which is placed at the beginning of the transfer frame data field. 3. Frame error control field This is a 16-bit field used for error control. Its calculation is based on cyclic redundancy check (CRC) techniques.


MAP CHANNEL : IDENTIFIED BY MAPID MAP MUX

VIRTUAL CHANNEL : IDENTIFIED BY GVCID VC MU X

VC MU X

VC MU X

MASTER CHANNEL : IDENTIFIED BY MCID

MC MUX

PHYSICAL CHANNEL : IDENTIFIED BY CHANNEL NAME

Figure 25. Service Access Point address space for CCSDS TC

TC Transfer Frame Transfer frame primary header 6 octets

Segment Header

Transfer frame data field Up to 1019 octets

FECF

Sequence flags

FECF(Optional)

2 bits

6 bits

Figure 26. Telecommand transfer frame and segment header formats

The CCSDS VC aggregation is presented by the FFBD in Fig. 27. SDUs from user applications are received from user applications by the MCC data transfer interface (function 1.0). The blocks involved in aggregating virtual channels into TC TFs are outlined below. 1. MAP packet processing (function 2.1) This block involves processing and transmission of SDUs for the MAP packet (MAPP) service. The SDUs used in this service are packets. The MAPP service is asynchronous, unidirectional and supports multiple user applications. The first task performed by this block is to receive and multiplex packets from user applications for a specified GMAP ID which are differentiated by PVNs. FDUs from this service are generated by blocking and segmentation of packets into compatible lengths. Since this service uses MAP channel, a segment header is generated and attached to each FDU. User applications using this service pass a MAPP.request(Packet,GVCID,MAP ID,Packet Version Number,SDU ID, Service Type) primitive to this block to request the transmission of a packet. This block also notifies user applications with specified PVNs on the status of the transaction by passing back the primitive MAPP Notify.indication(GVCID,MAP ID, Packet Version Number,SDU ID,Service Type,Notification Type) to the service user. 2. MAP generation (function 2.2) 22 of 39 American Institute of Aeronautics and Astronautics

2.1 MAP Processing 2.3

OR

MAP Multiplexing

2.2 MAP Generation

2.4 VC Packet Service Processing

OR

2.7 (1.0)Ref MCC Data Transfer Interface

OR

2.5 VC Access Service Processing

Virtual Channel Generation

2.9

OR

2.6

Virtual Channel Multiplexing

COP Management Service Processing 2.11

2.12

Master Channel Multiplexing

All Frames Generation

2.8

OR

Virtual Channel Frame Service Processing

(3.0)Ref CCSDS ECC and Frame Generation

2.10 Master Channel Frame Service Processing

Figure 27. The FFBD of CCSDS virtual channel aggregation

This block performs processing and transmission of SDUs for the MAP access (MAPA) service. The SDUs used in this service are MAP SDUs. This service is asynchronous, unidirectional and supports only a single user application. This block receives MAP SDUs from a single MAPA user application and processes them into FDUs. This processing involves segmentation of MAP SDUs to fit into predetermined FDU length. Similar to MAPP service, this service operates on the MAP channel and hence a segment header has to be generated and attached to the FDUs. User applications invoke the MAPA.request(MAP SDU,GVCID,MAP ID,SDU ID,Service Type) primitive to request transmission of a packet. User applications are notified about status of the transaction by the MAPA Notify.indication(GVCID,MAP ID,SDU ID,Service Type,Notification Type) transmitted by this block. 3. MAP multiplexing (function 2.3) This block multiplexes and queues FDUs from the MAP packet processing and MAP generation blocks. The policy involved in multiplexing and queuing is specified apriori based on system requirements. 4. Virtual channel packet processing (function 2.4) This block performs processing and transmission of SDUs for the virtual channel packet (VCP) service. The SDUs used in this service are packets. This service is asynchronous, unidirectional and supports multiple users. The block thus receives and multiplexes packets from user applications with specified PVNs and performs blocking into FDUs of specified lengths. VCP service user applications invoke the VCP.request(Packet, GVCID,Packet Version Number,SDU ID,Service Type) primitive to send SDUs. They are notified about the status of all transactions by the primitive VCP Notify.indication(GVCID,Packet Version Number,SDU ID,Service Type,Notification Type) transmitted by this block. 5. Virtual channel access processing (function 2.5) This block performs processing and transmission of SDUs for the virtual channel access (VCA) service. The SDUs used in this service are VCA SDUs. This service is asynchronous, unidirectional and supports only a single user application. This block receives VCA SDUs from a single VCA user application after the application has invoked the VCA.request(VCA SDU,GVCID,SDU ID,Service Type) primitive. The application is notified about the status of all transactions by the primitive VCA Notify.indication(GVCID,SDU ID,Service Type,Notification Type) transmitted by this block. 6. COP management packet processing (function 2.6) This block performs processing and transmission of directives for the communication operation proce23 of 39 American Institute of Aeronautics and Astronautics

dures (COP) service for a particular virtual channel. COP ensures a sequential delivery of transfer frames without duplication or omission. It is a closed-loop procedure involving a frame operations procedure (FOP) at the sending end and a frame acceptance and reporting mechanism (FARM). FARM reports on the acceptance status of transfer frames transmitted by FOP by sending communications link control words (CLCW). User application using this service use the Directive.request(GVCID, Directive ID,Directive Type,Directive Qualifier) to send directives to this block. Applications are notified about the status of all transactions either synchronously by the primitive Directive Notify.indication(GVCID,Directive ID,Notification Type) or asynchronously by the directive Async Notify.indication(GVCID,Notification Type,Notification Qualifier). 7. Virtual channel generation (function 2.7) This block performs frame operations procedure (FOP) and frame generation procedures. FOP controls transmission and retransmission of FDUs from MAP multiplexing block, the VC packet processing block, or a VCA processing block based on the report from the CLCW. It also receives directives from the COP management packet processing. Frame generation procedures generates transfer frames by attaching a transfer frame primary header to each FDU or control command delivered by the FOP. 8. Virtual channel frame service processing (function 2.8) This block performs processing and transmission of transfer frames for the virtual channel frame service. This service does not support sequence control and hence the user must specify how delivery is achieved. User applications use the VCF.request(Frame,GVCID) primitive to send transfer frames to this block. 9. Virtual channel multiplexing (function 2.9) This block multiplexes and queues transfer frames from the virtual channel generation block and the virtual channel frame service processing block. The policy involved in multiplexing and queuing is specified apriori based on system requirements. 10. Master channel service processing (function 2.10) This block involves processing and transmission of transfer frames from the master channel service. This service does not support sequence control and hence the user must specify how delivery is achieved. User application use the MCF.request(Frame, MCID) primitive to send transfer frames to this block. 11. Master channel multiplexing (function 2.11) This block multiplexes and queues transfer frames from the virtual channel multiplexing block and the master channel frame service processing block. The policy involved in multiplexing and queuing is specified apriori based on system requirements. 12. All frames generation (function 2.12) This block involves error control coding and delivery of frames to the CCSDS ECC and frame generation block (function 3.0) at an appropriate rate. III.B.

CCSDS ECC and Frame Generation

The CCSDS ECC and frame generation is performed according the TC Synchronization and Channel Coding4 protocol. Transfer frames are sent to this block by using the ChannelAccess.request(Frame,Repetitions) primitive. The FFBD in Fig. 28 shows that this block has optional scrambling, a modified Bose- ChaudhuriHocquenghem (BCH) encoding and CLTU generation. III.B.1.

Scrambling

Scrambling is used to ensure a adequate bit transition density. The scrambler used the TC Synchronization and Channel Coding4 protocol has the similar properties to the one employed by the TM Synchronization and Channel Coding1 presented in section II.B.5. The generator polynomial is given by the equation h (x) = x8 + x7 + x5 + x3 + 1


(4)

(2.0)Ref CCSDS VC Aggregation

3.1 OR

Scrambler

(1.0)Ref MCC Data Transfer Interface

OR

3.2

3.3

BCH Encoding

CLTU Generation

(5.0)Ref Bit Modulation

Figure 28. The FFBD of CCSDS ECC and Frame Generation

III.B.2.

BCH coding

The only ECC provided is a modified (63,56) BCH code. This is a systematic code with a total length of 64 bits, seven parity bits and one filler bit. The parity bits are complemented to aid synchronization and detection of bit slippage. In order to obtain a codeblock with an integral number of octets, a filler bit is appended to the parity bits. This results in a codeblock of legth 64 bits. This appended filler bit must always be set to zero. If the CLTU do not fit exactly in an integral number of BCH codeblocks, then fill bits are applied to the last BCH codeblock. The fill bits are a sequence of alternating zeros and ones with a first zero bit.

64 bit BCH CodeBlock Information 56 Information bits

Error Control 7 parity check bits (Complemented)

1 appended filer bit (Must be set to 0)

Figure 29. BCH codeblock

Table 8. Modified BCH code specifications

Parameter Code characteristics Number of information bits Number of parity bits Number of filler bits Error correction capability Code generator polynomial

Value (64,56) Modified BCH code 56 7 1 E = 8, 16 g (x) = x7 + x6 + x2 + 1


III.B.3.

CLTU generation

The CLTU is the data unit transmitted by the TC Synchronization and Channel Coding protocol. It controls synchronization and delimiting of the beginning of user data.4 In case there is no phase ambiguity resolution mechanism employed in the physical layer at the receiving end, the start sequence of the CLTU can be used for phase ambiguity resolution as a unique word. The CLTU has three parts as shown in Fig. 30

Communications Link Transmission Unit Start sequence 16 bits

Tail sequence Length of one BCH codeblock

Encoded Data BCH Codeblocks

Figure 30. CLTU structure codeblock

1. Start sequence This is a 16-bit sequence that delimits the start of CLTU data. The sequence has the value 1110101110010000. 2. Encoded data This contain BCH codeblocks to be sent to the receiving end. 3. Tail sequence This is sequence which delimits the end of the codeblock. The sequence has the value 1100010111000101110001011100010111000101110001011100010101111001. III.C.

Non-CCSDS data processing

Telecommand non-CCSDS data processing, just like its telemetry counterpart, caters for missions which are compliant with a subset of framing and ECC standards that are foreseen to be used in future missions.20 These protocols are AX.25,21 DVB-S22 and DVB-S2.23 The FFBD is depicted in Fig. 31.

4.2 Error Control Coding DVB-S ECC DVB-S2 ECC Generic differential encoding Generic convolutional coding Generic scrambling Generic BCH Coding Generic Reed-Solomon coding Generic Turbo coding Generic LPDC coding

4.1 Framing (1.0)Ref MCC Data Transfer Interface

AX.25 Framing DVB-S Framing DVB-S2 Framing

OR

OR

(5.0)Ref Bit Modulation

Figure 31. Non-CCSDS data processing

III.D.

Bit modulation

This block involves a chain of functionality for transmitting information bits from the sending end to the receiving end: line coding, modulation as well as I/Q signal transmission through the SDR frontend. The FFBD for bit modulation is depicted in Fig. 33 1. Line coding (function 5.1) This block transforms information bits into square pulses for transmission.


(3.0)Ref CCSDS ECC and Frame Generation OR (4.0)Ref Non-CCSDS Data Processing

5.1 Line Coding BP-L BP-M BP-S NRZ-L NRZ-M NRZ-S DBP-M DBP-S DM-M DM-S R-NRZ NRZ-L + V35 NRZ-M + V35

5.2 Baseband Modulation BPSK FSK GFSK QPSK UQPSK π/4- QPSK SOQPSK-A SOQPSK-B SOQPSK-MIL SOQPSK-TG PCM/PM PCM/FM

5.3

PLOP 1 Transmission

5.4 PLOP 2 Transmission

5.5 OR

I/Q Signal Transmission

5.5 Non-PLOP Transmission Procedure

Figure 32. FFBD for bit modulation

2. Baseband modulation (function 5.2) This block transforms information from the line coding block into an I/Q symbols. 3. Physical layer operations procedures - 1 transmission(function 5.3) Physical layer operations procedures-1 (PLOP-1) block regulates the flow of I/Q symbols according to PLOP-1 carrier modulation modes (CMMs) specifications. 4. Physical layer operations procedures - 2 transmission (function 5.4) Physical layer operations procedures-2 (PLOP-2) block regulates the flow of I/Q symbols according to PLOP-2 CMMs specifications. 5. Non-PLOP transmission (function 5.5) This block passes all I/Q symbols without following any transmission procedure. 6. I/Q signal transmission (function 5.6) This block passes I/Q symbols to the SDR frontend for upconversion and transmission. This block is also designed to be independent of any hardware. Table 9. Carrier modulation modes

Mode CMM-1 CMM-2

CMM-3 CMM-4

State Unmodulated carrier only Carrier modulated with acquisition sequence Carrier modulated with CLTU Carrier modulated with idle sequence

Comments Only a sinusoidal carrier at a desired frequency is transmitted. Acquisition sequence is a sequence of bytes that aide synchronization. It consists of an alternating sequences of zeros and ones with a minimum of 16 octets. Carrier modulated by telecommands to be transmitted An idle sequence maintains symbol synchronization in the absence of CLTUs. It consists of unconstrained number of alternating ones and zeros


PLOP-1

PLOP-2

Start

Start

CMM-1

CMM-1

CMM-2

CMM-2

CMM-4 (Optional)

CMM-4 (Optional)

CMM-3

CMM-3

CMM-4 (Optional)

CMM-4 (Optional)

CMM-1

Repeat

Non-PLOP Start

CMM-3

Repeat

CMM-1

End

End

End

Figure 33. Transmission procedures

IV.

Functional analysis for ranging

The knowledge of satellite position is essential for payload operation and orbit-correction manoeuvres. Satellite position can be derived from TLEs. TLE orbital parameters change with time and require periodic updates. Due to the lack of full understanding of planetary forces affecting TLE orbital parameters, satellite position calculations based on TLEs are limited to certain accuracy. Therefore, it has to be supplemented by actual satellite data which can be actively determined by the ground station. These data include groundantenna pointing directions, azimuth and elevation, as well as the distance between the satellite and the ground station, also known as satellite range. Ranging is based on measurement of propagation delay from the ground station to the spacecraft. The two-way propagation delay is sometimes referred to as round-trip time (RTT). This delay is a sum of delay due to two-way propagation delay between the ground station and the spacecraft, delay between calibrated reference point (antenna) and the measurement point (baseband), delay in the transponder onboard the satellite as well as delay due to atmospheric diffraction. Atmospheric propagation delay can be calculated from total electronic content (TEC) provided the position of the satellite is known. Baseband and satellite transponder delay can be calibrated before the spacecraft is launched.24 This section presents three ranging methods that are currently used in near-earth and deep-space missions. 1. Pseudonoise (PN) ranging Pseudonoise (PN) ranging utilizes PN codes on spread spectrum signals to determine the RTT. The RTT is obtained by comparing transmitted code phase and the received code phase. PN ranging is commonly used in deep space missions. The paper presents a PN system as defined by the CCSDS Pseudonoise (PN) Systems blue-book standard.25 2. Tone ranging Tone ranging utilizes unmodulated subcarriers,major and minor tones, on PM/FM carrier.26 RTT is derived by measuring the time delay between transmitted tones and received tones. Ranging accuracy is determined by the major tone while ranging ambiguity is resolved by the minor tones. 28 of 39 American Institute of Aeronautics and Astronautics

3. Hybrid PN-tone ranging Hybrid PN-tone ranging uses one major tone and a series of PN codes for ranging. Ranging accuracy is determined by the major tone frequency. Range ambiguity resolution is performed by PN codes instead of minor tones. The hybrid PN-code ranging system presented in this paper is based on the European Space Agency (ESA) code standard as specified by the European Cooperation for Space Standardization ECSS-E-ST-50-02C standard.27 Traditionally, ranging uplink and downlink are performed simultaneously with telecommand uplink and telemetry downlink, respectively. IV.A.

Pseudonoise ranging

The CCSDS Pseudonoise (PN) specifies two types of PN ranging. The first one is regenerative ranging, whereby the spacecraft recovers the PN code and re-remodulates it on the downlink. Regenerative ranging is quite useful in low signal-to-noise (SNR) environment, such as those found in deep space missions. Transparent ranging, on the other hand, re-modulates the full band-pass signal without acquiring the PN code. This results in simple spacecraft transponder design at the expense of ranging accuracy. As far as ground station ranging operations are concerned, there is no difference between regenerative and transparent ranging. In both cases, one-way distance ambiguity is given by the equation Code Length 1 × Speed of Light (5) Damb = × 2 Chip Rate IV.A.1.

PN ranging uplink

PN ranging uplink involves the generation and modulation of a spread spectrum signal. The FFBD for CCSDS PN ranging uplink is shown in Fig. 34.

1.0

2.0

3.0

4.0

5.0


PN Code Generation

Baseband Shaping

PM Modulation


Figure 34. PN ranging uplink

1. MCC Data Transfer Interface (function 1.0) This blocks transfers user data, which contains commands and parameters needed for ranging operations. 2. PN code generation (function 2.0) The PN codes specified by CCSDS PN ranging standard are weighted-voting balanced Tausworthe(v=2) (T2B) and Tausworthe (v=4) (T4B). For transparent ranging, only T2B signal can be used. On the other hand, regenerative ranging can use either code depending on mission specifications. 3. Baseband shaping (function 3.0) Baseband shaping is needed to reduce occupied bandwidth of the PN signal, especially in situations where modulation index and chip rate are high. Baseband shaping is achieved by using a sine pulse shape filter specified by the equation  sin πt t ∈ [0, Tc ] Tc h (t) = hsin (t) = 0 elsewhere where Tc is the chip duration. 4. Linear phase modulation (function 4.0) This block performs standard PM modulation presented in section II.A. 29 of 39 American Institute of Aeronautics and Astronautics

5. I/Q signal transmission (function 5.0) This block sends I/Q signal to the SDR frontend as presented in section III.D. IV.A.2.

PN ranging downlink

PN ranging downlink involves demodulation of the ranging signal, acquisition of the PN code and epoch comparison between transmitted code and received code as shown in the FFBD in Fig. 35


4.0 Code Acquisition and Tracking

2.0 Carrier Tracking and Ranging Signal Demodulation

3.0 Chip Rate Acquisition and Tracking 6.0

5.0 Epochs Comparison


Figure 35. PN ranging downlink

1. I/Q signal acquisition (function 1.0) This block is responsible for receiving I/Q signals from the SDR frontend. 2. Carrier tracking and ranging signal demodulation (function 2.0) This block performs PM demodulation and recovers the ranging bandpass signal. 3. Chip rate acquisition and tracking (function 3.0) This block performs coarse spread spectrum time synchronization. 4. Code acquisition and tracking (function 4.0) This block performs fine spread spectrum and recovers the PN code. 5. Epochs comparison (function 5.0) This block derives the RTT, and hence range, by comparing code phases of received and transmitted PN codes. 6. MCC data delivery interface (function 6.0) This block delivers ranging data including two-way delay (minimum, maximum, mean, standard deviation) and one-way distance. IV.B.

Tone ranging

Tone ranging involves the calculation of RTT by means of phase difference between transmitted tones and received tones. The tones are transmitted sequentially. There is a number of tone ranging standards currently used in near-earth missions. These are 1. ESA 100K tone 2. Inmarsat tone


3. Lockheed Martin Corporation (LMCO) tone 4. ESA-like tone 5. USB tone These standards differ in the frequency and management of major and minor tones. One-way distance ambiguity for both standards is given by the equation Damb =

1 Speed of Light × 2 Frequency of minor tone

(6)

The FFBD for tone ranging uplink is shown in Fig. 36. This FFBD represents building blocks for the five tone ranging standards.

1.0

2.0


Virtual Tone Generation

3.0 OR

Real Tone Generation

4.0 Ranging Signal Modulation PM/FM

5.0 I/Q Signal Transmission

Figure 36. Tone ranging uplink

1. MCC Data Transfer Interface (function 1.0) This block transfers commands and configuration parameters from the MCC to the baseband system. Configuration parameters includes sequence timing and ambiguity resolution, minimum and maximum satellite-to-earth distances, tone frequencies to be used, as well as calibration inputs. 2. Virtual tones generation (function 2.0) This block generates virtual sinusoidal major and minor tones. 3. Real tones generation (function 3.0) This block generates real tones that are to transmitted to the satellite. 4. Ranging signal modulation (function 4.0) This block can perform PM or FM modulations as required by the tone ranging standard. 5. I/Q signal transmission (function 5.0) This block sends I/Q signal to the SDR frontend as presented in section III.D. The tasks involved in the downlink include demodulation of the ranging signal, calculation of phase difference between transmitted and received tones as well as range ambiguity resolution as shown by the FFBD in Fig. 37 1. I/Q signal acquisition (function 1.0) This block is responsible for receiving I/Q signals from the SDR frontend. 2. Ranging signal demodulation (function 2.0) This block performs demodulation of the ranging. The typical modulation scheme used is PM. 3. Signal rotation (function 3.0) This block performs 90◦ , 180◦ or 270◦ . This is useful in case there is a component aboard the satellite that rotates the ranging signal. 4. PLL banks (function 4.0) One PLL is needed to recover a tone. This block therefore contains a bank of PLLs for each minor tone and one for the major tone.


1.0

2.0

3.0

I/Q Signal Acquisition

Ranging Signal Demodulation PM/FM

Signal Rotation 90°,180°,270°

4.0

5.0

6.0

PLL Bank

Phase Comparison

Ambiguity Resolution

OR

7.0


Figure 37. Tone ranging downlink

5. Phase comparison (function 5.0) This block performs phase comparison between the transmitted and received tones. 6. Ambiguity resolution (function 6.0) This block utilizes minor tones to calculate the unambiguous distance between the ground station and the satellite. 7. MCC data transfer interface (function (7.0) This block delivers ranging data to the MCC. This include phase measurements (minimum, maximum, standard deviation), two-way propagation delay as well as one-way distance. IV.C.

Hybrid tone-PN ranging

The ESA code standard is a hybrid tone-PN standard since it uses a major tone and a sequence of PN codes. The hardware-based implementation of the code is part of the ESA’s multipurpose tracking system (MPTS).28 In the ESA code standard, ranging accuracy is determined by the settable major tone frequency. The one-way distance ambiguity is determined by the settable code length 2N as given by the equation Damb =

1 Speed of Light × 2N × 2 Frequency of major tone

(7)

The ESA code standard performs ranging measurements by first transmitting and receiving a pure major tone. The received tone is recovered by the PLL. The phase of the pure major tone is measured by comparing with the transmitted tone after a predefined time interval. Thereafter, the uplink is modulated by the first PN code. After the first tone is recovered on the downlink, its code phase is compared with the phase code of the code replica and enable ambiguity resolution. The process is repeated until all the codes have been transmitted. The FFBD for the ESA code standard uplink is shown in Fig. 38. The tasks involved in the uplink include generation of the major tone and the PN code as well as modulation of the ranging signal. 1. MCC data transfer interface (function 1.0) This block receives and processes commands and configuration parameters including major tone frequency and PN code length. 2. Major tone generation (function 2.0) This block generates a settable major tone frequency according to range accuracy required by the mission. 3. PN code generation (function 3.0) This block generates a settable length-2N code according to one-way range ambiguity required by the mission. 32 of 39 American Institute of Aeronautics and Astronautics

1.0 MCC Data Transfer Interface

2.0

4.0

Major Tone Generation

Major Tone Modulation

AND

OR

5.0

6.0

Ranging Signal Modulation PM


3.0 PN Code Generation

Figure 38. Hybrid tone-PN ranging uplink

4. Major tone modulation (function 4.0) In this block, the PN code generated in function 3.0 is used to phase-modulate the major tone. 5. Ranging signal modulation (function 5.0) In this block, the ranging signal, whether it is the pure major tone or the major tone modulated by the PN code, is phase modulated on the carrier for transmission. 6. I/Q signal transmission (function 6.0) This block sends I/Q signal to the SDR frontend as presented in section III.D. On the downlink, the ESA code standard involve recovery of the major tone and the PN code as well as range ambiguity resolution. There is also a Doppler measurement block for measuring integrated Doppler shift as shown in the FFBD in Fig. 39


3.0 Ranging Signal Demodulation PM

5.0

6.0

Major Tone Recovery

Major Tone Phase Comparison

4.0 Signal Rotation 90°,180°,270°

10.0 AND

OR 7.0

9.0

PN Code Recovery

Code Phase Comparison

2.0

Ambiguity Resolution

7.0

Doppler Measurement

AND


Figure 39. Hybrid tone-PN ranging downlink

1. I/Q signal acquisition (function 1.0) This block is responsible for receiving I/Q signals from the SDR frontend. 2. Doppler measurements (function 2.0) This block performs integrated Doppler measurements, which provides high resolution range-rate over a given integration interval. Correction for ionospheric delay can be achieved by subtracting range-rate variation from the integrated Doppler which result into a quantity known as Differenced Range Versus Integrated Doppler (DRVID).


3. Ranging signal demodulation (function 3.0) This block recovers the major tone/PN-modulate major tone from the received ranging signal. 4. Signal rotation (function 4.0) This block performs 90◦ , 180◦ or 270◦ . This is useful in case there is a component aboard the satellite that rotates the ranging signal. 5. Major tone recovery (function 5.0) This block uses a PLL to recovery the received tone. 6. Major tone phase comparison (function 6.0) This block compares the phase of the transmitted and the received major tone. 7. PN code recovery (function 7.0) This block recovers the received PN code. It involves PM demodulation of the major tone, chip rate tracking and acquisition as well as code tracking and acquisition akin to PN code recovery presented in section IV.A. 8. Code phase comparison (function 8.0) Code phase comparison involves the calculation of the phase difference between the transmitted code phase and the received code phase. 9. Range ambiguity resolution (function 9.0) This block utilizes the PN codes to calculate the unambiguous distance between the ground station and the satellite. 10. MCC data transfer interface (function (10.0) This block sends ranging data to the MCC. The data include phase measurements (minimum, maximum, standard deviation), two-way propagation delay, one-way distance, integrated Doppler as well as DRVID.


V.

System prototyping

The adopted philosophy for prototyping the SDR-based baseband system is based on the use of commercialoff-the-shelf (CoTS) hardware components and open-source libraries, application frameworks and operating systems. CoTS hardware required include SDR frontends and standard cloud server computers. Opensource application frameworks required include SDR application frameworks for radio operations, standard web technologies and QT C++29 for GUI-based system interface. The system is envisioned to work on POSIX-based operating systems such as open-source Linux distributions. V.A.

SDR frontends

SDR frontends are based on different architectures. An SDR architecture depends on the type of processing devices used by the SDR frontend. This can be a general purpose processor (GPP), a field-programmable gate array (FPGA), a digital signal processors (DSP), a specialized processing units (SPU)s or a hybrid solution which can combine the processing hardware mentioned above. Current SDR hardware platforms can be categorized in the following groups6 1. All-software platforms using GPPs. 2. Accelerated GPP based platforms. Device acceleration can be provided by an FPGA or SPU30 .31 3. FPGA-based platforms. Since all-software platforms using GPPs can be programmed in standard high-level programming languages such as C++, they are proposed for system prototyping. There is a number of CoTS GPP-based SDR frontends in the market today. Among the defining features of any SDR frontend are frequency range and instantaneous bandwidth. Most of CoTS SDR frontends at this point in time support a frequency range from a few Mhz to a few Ghz and an instantaneous bandwidth of a few Mhz to a few hundred Mhz. The price ranges from a few hundred to few thousands of Euros.

V.B.

SDR application frameworks

A number of application frameworks for implementing radio functions have been implemented. The most popular open-source SDR application frameworks are GNU Radio and OSSIE. Other known application frameworks are Microsoft SORA, LabView and Matlab/Simulink. Either one of these application frameworks can be used to implement radio functions for the baseband system. V.B.1.

GNU Radio

GNU Radio is an intuitive application framework for SDR development.33 It provides a number of libraries which can be used to implement radio functions such as signal processing, error correction as well as signal acquisition. It is an open-source software which makes it the best candidate for prototyping. GNU Radio comes with a GUI tools which can be used to implement a radio block diagram in a drag-anddrop fashion. Data is passed from block to block by means of circular buffers. The implementation behind these blocks is written in Python though the actual signal processing is implemented in C++ since it is more efficient. Some of the signal processing functions have been customized for high speed real-time operations by taking advantage of single instruction multiple data (SIMD) instructions which comes with specific processor type. GNU radio has a multi-threaded scheduler which enables each block to run separately. V.B.2.

Open-Source SCA Implementation: Embedded (OSSIE)

Open-Source SCA Implementation: Embedded (OSSIE) is an open-source application framework based on the software communication architecture (SCA) standard.6 It also comes with a drag-and-drop GUI tool for easier programming. OSSIE supports secure and robust SDR-based systems since it is based on a sophisticated military standard. Since OSSIE is based on SCA which specifies a specific XML ontology, connections between blocks is specified by XML files. Actual connections are performed by a middleware. The middleware used by OSSIE is common object request broker architecture (COBRA).6


V.B.3.

Microsoft Research Software Radio (SORA)

SORA is an SDR platform that was initiated by Microsoft Research in Asia. Unlike the previously discussed application frameworks , SORA framework contains hardware element. The hardware component is known as radio control board (RCB). Its main task is to interconnect the RF frontend and the GPP.34 SORA is available to institutions and it is not a commercial product.6 V.B.4.

LabVIEW

Laboratory virtual instrument engineering workbench (LabVIEW) is an SDR application framework developed by National Instruments. Like GNU Radio, LabVIEW supports creation of radio functionality through a GUI environment. GUI elements are referred to as virtual instruments (VI). Their operation and appearance is identical to that of their hardware counterparts. LabVIEW has libraries which can be used to realize sophisticated radio circuitry and communication protocols.35

V.B.5.

Mathworks Matlab and Simulink

Matlab/Simulink are high level mathematical computer packages which are capable of interacting directly with hardware. Latest versions have the capability of interacting with a number of SDR platforms including the USRP.36 V.C.

General purpose processors

A general purpose processor is a normal processor that can be found in everyday personal computers or industrial-grade servers. High throughput GPPs, such as those found in industrial-grade servers, are required to support baseband operations. To maximize system throughput, the SDR frontends and the servers can be configured to work as a private cloud shown in Fig. 40. User data and configuration is received through the interface server via TCP/IP sockets. With the help of any cloud computing tools, virtual servers hosted by the physical computers inside the server rack can host a POSIX-based operating system, a software to control the SDR and radio functions, command-line and graphical interfaces as well as other miscellaneous applications. The radio functions have been presented as functional analysis in the previous chapters. I/Q data is exchanged between the SDR frontends and the server through a 1/10 Gb ethernet link. IF/RF signals are exchanged between the SDR frontends and the antennas through standard SubMiniature version A (SMA) links.

Private SDR Cloud

SDR Frontend Rack Server Rack

I/Q Signals

SMA

1/10 Gigabit Ethernet

IF/RF Antenna

Figure 40. SDR private cloud


Interface Server

VI.

Conclusion

Functional analysis of a SDR-based baseband system was detailed in this paper using FFBDs. The analysis covers the design of all aspects of satellite management, including telemetry, telecommand, ranging and Doppler measurements. The analysis for telemetry and telecommand functionality is based on current CCSDS blue-book standards. The analysis of other standards, such as AX.25, DVB-S and DVB-S2, was also presented. For ranging, the functional analysis of three technique was discussed: pseudonoise, tones and hybrid pseudonoise-tone ranging. The PN ranging technique is based on CCSDS standards while the hybrid-tone technique is based on ESA code standard. For the tone ranging technique, a variety of standards, including the Inmarsat, ESA 100K, LMCO, ESA-like and USB tone standards were considered. Some hardware implementations were also discussed, such as SDR frontends and industrial-grade servers, which can be used to prototype the system. The SDR-based system is envisioned to improve traditional satellite management architecture (Fig. 1) into a software-as-as-service (SaaS) cloud (Fig. 3).


References 1 Consulative Committee for Space Data Systems (CCSDS), TM Synchronization and Channel Coding, No. 131.0-B-2 in Blue Book, CCSDS Secretariat, National Aeronautics and Space Administration , Washington DC, 2011. 2 Consulative Committee for Space Data Systems (CCSDS), TM Space Data Link Protocol, No. 132.0-B-2 in Blue Book, CCSDS Secretariat, National Aeronautics and Space Administration , Washington DC, 2015. 3 Consulative Committee for Space Data Systems (CCSDS), TC Space Data Link Protocol, No. 232.0-B-3 in Blue Book, CCSDS Secretariat, National Aeronautics and Space Administration , Washington DC, 2015. 4 Consulative Committee for Space Data Systems (CCSDS), TC Synchronization and Channel Coding, No. 231.0-B-2 in Blue Book, CCSDS Secretariat, National Aeronautics and Space Administration , Washington DC, 2010. 5 Consulative Committee for Space Data Systems (CCSDS), Radio frequency and modulation systems - Part 1 Earth stations and spacecraft, No. 401.0-B-26 in Blue Book, CCSDS Secretariat, National Aeronautics and Space Administration , Washington DC, Oct 2016. 6 Grayver, E., Implementing Software Defined Radio, Springer New York Heidelberg Dordrecht London, 2013. 7 National Aeronautics and Space Administration, Systems Engineering Handbook , No. SP-2007-6105 Rev 1 in Blue Book, National Aeronautics and Space Administration, Washington DC, 2017. 8 Deep Space Network, Telemetry Data Decoding, No. 208 in DSN No. 810-005-208, Rev. B, Jet Propulsion Laboratory California Institute of Technology , California, 2013. 9 Hecht, M. and Guida, A., “Delay modulation,” Proceedings of the IEEE , Vol. 57, No. 7, July 1969, pp. 1314–1316. 10 European Cooperation for Space Standardization, Radio Frequency and Modulation, No. ECSS-E-ST-50-05C Rev. 2 in Space Engneering, ECSS Secretariat ,ESA-ESTEC Requirements and Standards Division , Noordwijk, The Netherlands, 2011. 11 Rice, M., Digital Communications : A discrete-time approach, PEARSON Prentice Hall, 2009. 12 Simon, M. K., Bandwidth-Efficient Digital Modulation with Application to Deep-Space Communications, JPL Deep-Space Communications and Navigation Series, John Wiley, 2003. 13 Joseph H. Yuen (auth.), J. H. Y. e., Deep Space Telecommunications Systems Engineering, Applications of Communications Theory, Springer US, 1st ed., 1983. 14 Tao, F., Xudong, W., and Busheng, Z., “A novel carrier synchronization method for SOQPSK signal in satellite communication,” 2014 International Conference on Information and Communications Technologies (ICT 2014), May 2014, pp. 1–5. 15 Ali, I., Al-Dhahir, N., and Hershey, J. E., “Doppler characterization for LEO satellites,” IEEE Transactions on Communications, Vol. 46, No. 3, Mar 1998, pp. 309–313. 16 Harris, F., Venosa, E., Chen, X., and Dick, C., “Band edge filters perform non data-aided carrier and timing synchronization of software defined radio QAM receivers,” The 15th International Symposium on Wireless Personal Multimedia Communications, Sept 2012, pp. 271–275. 17 Mengali, U., Synchronization Techniques for Digital Receivers (Applications of Communications Theory), Plenum Press, New York, 1st ed., 1997. 18 Godard, D., “Self-Recovering Equalization and Carrier Tracking in Two-Dimensional Data Communication Systems,” IEEE Transactions on Communications, Vol. 28, No. 11, Nov 1980, pp. 1867–1875. 19 Moreira, J. and Farrell, P., Essentials of Error-Control Coding, John Wiley & Sons Ltd,, 2006. 20 Consulative Committee for Space Data Systems (CCSDS), CCSDS PROTOCOLS OVER DVB-S2 - SUMMARY OF DEFINITION,IMPLEMENTATION, AND PERFORMANCE , No. 130.12-G-1 in Green Book, CCSDS Secretariat, National Aeronautics and Space Administration , Washington DC, 2016. 21 Beech, W. A., Nielsen, D. E., and Taylor, J., AX.25 Link Access Protocol for Amateur Packet Radio, No. Version 2.2, American Radio Relay League (ARRL) and the Tucson Amateur Packet Radio Corporation (TAPR), Newington, Connecticut, United States, 1984. 22 European Telecommunications Standards Institute, Digital Video Broadcasting (DVB);Framing structure, channel coding and modulation for 11/12 GHz satellite services, No. ETSI EN 300 421 V1.1.2 (1997-08) in European Standard (Telecommunications series), European Telecommunications Standards Institute , Valbonne France, 1997. 23 European Telecommunications Standards Institute, Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications (DVB-S2), No. ETSI EN 302 307 V1.2.1 (2009-08) in European Standard (Telecommunications series), European Telecommunications Standards Institute , Valbonne France, 2009. 24 Maldari, P., “ESA’s new high-performance tone-ranging system,” ESA Bulletin, Vol. 34, May 1983, pp. 54–59. 25 Consulative Committee for Space Data Systems (CCSDS), Pseudo-noise (PN) ranging systems, No. CCSDS 414.1-B-2 in Blue Book, CCSDS Secretariat, National Aeronautics and Space Administration , Washington DC, 2014. 26 European Telecommunications Standards Institute, Satellite Earth Stations and Systems (SES); Technical analysis of Spread Spectrum Solutions for Telemetry Command and Ranging (TCR) of Geostationary Communications Satellites, No. ETSI TR 101 956 V1.1.1 (2001-09) in European Standard (Telecommunications series), European Telecommunications Standards Institute , France, 2001. 27 European Cooperation for Space Standardization, Ranging and Doppler tracking, No. ECSSEST5002C in Space Engneering, ECSS Secretariat ,ESA-ESTEC Requirements and Standards Division , Noordwijk, The Netherlands, 2008. 28 Gaudenzi, R. D., Lijphart, E. E., and Vassallo, E., “A new high performance multipurpose satellite tracking system,” IEEE Transactions on Aerospace and Electronic Systems, Vol. 29, No. 1, Jan 1993, pp. 27–43. 29 “Qt,” Accessed : July 29, 2017. 30 Palkovic, M., Raghavan, P., Li, M., Dejonghe, A., der Perre, L. V., and Cattho, F., “Signal Processing on Multicore Platforms,” IEEE Signal Processing Magazine, 2010, pp. 22 – 33.


31 Johnson, S. K., Reinhart, R. C., and Kacpura, T. J., “CoNNeCT’s Approach for the Development of Three Software Defined Radios for Space Application,” . 32 Ettus Research, “usrp,” https://www.ettus.com/content/files/X300 X310 Spec Sheet.pdf. 33 GNURadio, “GNURadio,” https://www.gnuradio.org/. 34 The Sora Core Team, The Sora Manual, Microsoft Research, 1st ed., aug 2012. 35 Fairweather, I., Brumfield, A., and Press, C., LabVIEW : a developer’s guide to real world integration, Chapman and Hall/CRC, 2011. 36 “Mathworks - Software-Defined Radio (SDR),” Accessed : July 29, 2017.
