[Ground-station] RFNoC Blocks

[Michelle Thompson]

Great question. I know we talked a bit on Slack already, but here's some
answers.

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.

These can be found here:
https://www.dvb.org/standards/dvb-s2
https://www.dvb.org/standards/dvb-s2x

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:
https://www.dvb.org/standards/dvb-gse

Wally Ritchie has written about the potential use of Annex M to enable low
cost receivers.
See
https://www.etsi.org/deliver/etsi_en/302300_302399/302307/01.03.01_20/en_302307v010301a.pdf
and look for Annex M.

The correlator draft is here:
https://github.com/phase4ground/correlator

Brennan Ashton was working on the correlator most recently and may have an
update.

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.

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.

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.

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.

Phase 4 Ground has a process of authentication and authorization outlined.

The state in the satellite requires the following things.

1. Memory for a database.
2. The ability to read from this database.
3. The ability to write to this database.
4. The ability to demand and process authentication from the Phase 4 Radio.
5. The ability to do some processing using data received from uplink
communication frames and information from the database.


The state in the Radio requires the following things.

1. The ability to generate a token.
2. Memory to store the token.
3. Memory to store private key.
4. Memory to store a certificate.
5. Ability to sign a message containing the generated token with the
private key.
6. Ability to send the signed message plus the certificate to the satellite
when it is demanded by the satellite.

The process is as follows.

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.

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.

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.

(satellite time stamp : callsign : SSID : token)

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).

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.

While auth/auth can be turned off, it does then open up the door to
kerchunking and DOS.

-Michelle W5NYV


On Fri, Jul 27, 2018 at 7:58 AM, Ground-Station <
ground-station at lists.openresearch.institute> wrote:

> I've been going through the github account:
>
>   https://github.com/phase4ground
>
> 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.
>
> I'm interested in helping with the RFNoC blocks, but I'm unclear of the
> current transmit and receive architecture.
>
> Any guidance would be appreciated.
>
> Thanks,
> Brian
>
> _______________________________________________
> Ground-Station mailing list
> Ground-Station at lists.openresearch.institute
> http://lists.openresearch.institute/mailman/listinfo/ground-station
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20180731/f680f21c/attachment.html>