<div dir="ltr">Great question. I know we talked a bit on Slack already, but here's some answers. <div><br></div><div>For DVB-S2 and DVB-S2X (shortened to DVB-S2/X) we are using the block diagrams in the DVB-S2/X protocol specifications and, probably of more interest, a lot of the ones in the implementation guidelines.<br><br>These can be found here:<br><a href="https://www.dvb.org/standards/dvb-s2">https://www.dvb.org/standards/dvb-s2</a><br><a href="https://www.dvb.org/standards/dvb-s2x">https://www.dvb.org/standards/dvb-s2x</a><br><br>Since we are replacing the transport stream with Generic Stream Encapsulation, to make our design more useful for amateur radio, that standard can be found here:<br><a href="https://www.dvb.org/standards/dvb-gse">https://www.dvb.org/standards/dvb-gse</a><br><br>Wally Ritchie has written about the potential use of Annex M to enable low cost receivers. <br>See <a href="https://www.etsi.org/deliver/etsi_en/302300_302399/302307/01.03.01_20/en_302307v010301a.pdf">https://www.etsi.org/deliver/etsi_en/302300_302399/302307/01.03.01_20/en_302307v010301a.pdf</a> and look for Annex M.</div><div><br></div><div>The correlator draft is here:<br><a href="https://github.com/phase4ground/correlator">https://github.com/phase4ground/correlator</a><br><br>Brennan Ashton was working on the correlator most recently and may have an update. <br><br>The two most active areas of work are a DVB-S2/X correlator and getting the LDPC decode into GNU Radio. Preferably on an FPGA. It's currently written for a GPU. <br><br>In the implementation guidelines, there are several correlator approaches outlined. A simple one, and a more complex and better performing one. Brennan found a paper he liked and was using that as an approach. <br><br>For the uplink, we use 4-ary minimum-shift keying signals. The packet format is assumed to need the following items. A preamble, the modulation, the coding, data rate, and enough data to support authorization and authentication. <br><br>CCSDS recommends a particular 32-bit sequence which we have baselined for use in frame timing. 4-ary MSK is the modulation and I don't think we've picked an uplink code. <br><br><div>Phase 4 Ground has a process of authentication and authorization outlined. </div><div><br></div><div>The state in the satellite requires the following things.</div><div><br></div><div>1. Memory for a database. </div><div>2. The ability to read from this database.</div><div>3. The ability to write to this database.</div><div>4. The ability to demand and process authentication from the Phase 4 Radio.</div><div>5. The ability to do some processing using data received from uplink communication frames and information from the database.</div><div><br></div><div><br></div><div>The state in the Radio requires the following things. </div><div><br></div><div>1. The ability to generate a token.</div><div>2. Memory to store the token.</div><div>3. Memory to store private key.</div><div>4. Memory to store a certificate.</div><div>5. Ability to sign a message containing the generated token with the private key. </div><div>6. Ability to send the signed message plus the certificate to the satellite when it is demanded by the satellite.</div><div><br></div><div>The process is as follows. </div><div><br></div><div>Stations that comply with the air interface can transmit through the satellite. The ground station is configured with an amateur radio callsign, plus a Secondary Station Identifier (SSID) of TBD bits to allow a particular licensee to operate multiple simultaneous stations, and with the ARRL-issued private key and certificate for that callsign (same process as LoTW). In addition, the station must generate a token of TBD bits chosen at random. Every transmitted uplink frame contains in its header the callsign, SSID, and token. </div><div><br></div><div>The callsign and SSID will be retransmitted in the downlink frame header, but the token is never transmitted on the downlink. Since it is fairly difficult to intercept an uplink transmission, this makes it difficult for an impostor to hear another station's authenticated callsign:SSID and start using it.</div><div><br></div><div>The satellite stores the token, the claimed call sign, the claimed SSID associated with the call sign, and a time stamp. This is a tuple that forms the rows of a database. </div><div><br></div><div>(satellite time stamp : callsign : SSID : token)</div><div><br></div><div>When each uplink frame is received by the satellite, it decides whether to accept it for retransmission on the downlink, or discard it. It may also choose to initiate an authentication transaction with the ground station. Alternately, or in addition, a Ground Control Station may initiate an authentication transaction with any or all active station(s). Unless and until an authentication transaction with a given station has been attempted AND FAILED, the satellite must accept its frames for retransmission (unless that station has already been blacklisted for another reason).</div><div><br></div><div>This achieves two important goals. Communication is unimpeded, and the loss of Ground Control Stations can be well-tolerated. When Ground Control Stations are not required for normal communications, system durability and reliability is greatly increased. <br><br>While auth/auth can be turned off, it does then open up the door to kerchunking and DOS. <br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr">-Michelle W5NYV<br><div dir="ltr"><br></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Jul 27, 2018 at 7:58 AM, Ground-Station <span dir="ltr"><<a href="mailto:ground-station@lists.openresearch.institute" target="_blank">ground-station@lists.openresearch.institute</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I've been going through the github account:<div><br></div><div>  <a href="https://github.com/phase4ground" target="_blank">https://github.com/<wbr>phase4ground</a></div><div><br></div><div>But I'm finding it difficult to get a clear understanding of the structure of what is there.  I saw a video/blog post about a correlation issue with the transmitter, but I couldn't necessarily find the place where that code was being stored, or actively debugged.</div><div><br></div><div>I'm interested in helping with the RFNoC blocks, but I'm unclear of the current transmit and receive architecture.</div><div><br></div><div>Any guidance would be appreciated.</div><div><br></div><div>Thanks,<br>Brian</div></div>
<br>______________________________<wbr>_________________<br>
Ground-Station mailing list<br>
Ground-Station@lists.<wbr>openresearch.institute<br>
<a href="http://lists.openresearch.institute/mailman/listinfo/ground-station" rel="noreferrer" target="_blank">http://lists.openresearch.<wbr>institute/mailman/listinfo/<wbr>ground-station</a><br>
<br></blockquote></div><br></div></div>