<span style=" font-size:10pt;font-family:sans-serif">Dear All,</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">I have had a detailed
look into LTP Service Data Aggregation and this is my assessment:</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Service Data Aggregation
receives Transmission requests from clients and aggregates the data from
those requests together with the LTP client service IDs into single LTP
transmission requests. This means that the resulting LTP Block has the
following format:</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Client Request
1 Client Service ID, Client Request 1 Client Service data, Client Request
2 Client Service ID, Client Request 2 Client Service data, ..., Client
Request n Client Service ID, Client Request n Client Service data, </span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">The receiving
LTP entity SDA is expected to parse this block and generate n RedPartReception.indications
to the indicated clients containing the respective client service data.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">This is problematic
as the SDA of the receiving LTP entity needs to </span>
<br><span style=" font-size:10pt;font-family:sans-serif">a) know the mapping
from Client Service ID to the protocol used for the Client Service Data
(eg, BP, Space Packets, Encapsulation Packets, ...)</span>
<br><span style=" font-size:10pt;font-family:sans-serif">b) be able to
unambiguously determine the length of each client service data (to find
the start of the next SDA client data capsule). That means that the SDA
implementation needs be able to process all supported protocols at least
partially (unless fixed client data length are agreed for a client service
ID). Eg, for BPv7, the implementation needs to parse the Bundle CBOR array,
for space packets length information needs to be read,  other protocols
may use specific stop sequences, ...</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">While a) could
be worked out by defining client service IDs for specific protocols or
by configuration, b) seems more severe as it requires some implementation
and processing effort (part of the processing will even be repeated in
the upper protocol layers).</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Therefore, we
agreed (I think, TBC) for LTPv2 to remove LTP SDA and standardise how to
put PDU of an upper layer protocol into LTP blocks (aggregated or not)
per supported protocol, eg:</span>
<br><span style=" font-size:10pt;font-family:sans-serif">- BP LTP Convergence
Layer: each LTP block shall contain one or several complete BP bundles
(the BP CL needs to be able to deal with several BP bundles per block)</span>
<br><span style=" font-size:10pt;font-family:sans-serif">- Space / Encapsulation
Packets: each LTP block shall contain one or several complete (space  |
encapsulation) packets </span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">With this approach
we would loose some flexibility as we will not be able to mix PDU of different
protocols in an LTP block. I think that's not a big limitation as we could
have different LTP sessions on-going in parallel if we really want to support
different protocols at the same time.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">The question what
to do for LTPv1 remains. IMHO, we should avoid SDA being implemented /
used as it is more complex in terms of implementation and it will make
a transition towards LTPv2 more difficult.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">So, as part of
the LTPv1 revision, we could remove Section 7 - Client Operation form the
standard or at least add a statement that SDA is considered deprecated
and should not be used.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">(At the same time
we may also want to add a statement regarding mixed red/green sessions
as these should probably be avoided as well.)</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Regards,</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Felix</span>
<br>
<br><span style=" font-size:8pt;color:#808080;font-family:Verdana"><b>_________________________________________</b></span>
<br><span style=" font-size:8pt;color:#808080;font-family:Verdana"><b>ESA
- European Space Agency </b></span>
<br><span style=" font-size:8pt;color:#00a1e0;font-family:Verdana">Dr.
Felix Flentge</span><span style=" font-size:8pt;color:#808080;font-family:Verdana"><br>
Software Engineer, OPS-GSB<br>
Ground Systems Engineering Department<br>
Directorate of Operations</span>
<br><span style=" font-size:8pt;color:#808080;font-family:Verdana"><b>ESA
- ESOC</b><br>
Robert-Bosch-Str.5, D-64293 Darmstadt, Germany</span>
<br><span style=" font-size:8pt;color:#808080;font-family:Verdana">Phone:
+49 6151 90 4075 | Email: Felix.Flentge@esa.int</span><span style=" font-size:10pt;font-family:sans-serif"><br>
<br>
</span>
<br>
<br><span style=" font-size:9pt;color:#808080;font-family:Arial"><b><i>Disclaimer</i></b></span>
<br><span style=" font-size:7pt;color:#808080;font-family:Arial"><i>This
message is intended only for the recipient(s) named above. It may contain
proprietary information and/or protected content. Any unauthorised disclosure,
use, retention or dissemination is prohibited. If you have received this
e-mail in error, please notify the sender immediately. ESA applies appropriate
organisational measures to protect personal data, in case of data privacy
queries, please contact the ESA Data Protection Officer (dpo@esa.int).</i></span>