<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle18
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:787237561;
mso-list-type:hybrid;
mso-list-template-ids:-262526144 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">CSTSWG colleagues ---<o:p></o:p></p>
<p class="MsoNormal">I’m happy to announce that I’ll be supporting Tim Pham in the development of the Forward Frames (FF) CSTS service specification. Right now I’m just (re)familiarizing myself with the earlier work on the FF service, what Tim has done more
recently, the FINAL versions of the relevant Data Processing procedures in the CSTS SFW BLUE BOOK (Yay!), etc.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">One topic that Tim touched on in his FF-CSTS briefing at the Spring 2017 meeting was that of virtual channel (VC) multiplexing schemes, in which Tim’s initial (and reasonable) approach was to mimic the SLE Forward Space Packet specification
in defining 3 schemes that could be applied to the multiplexing of frames being carried by the FF service instances (FIFO, absolute priority, and polling vector). This triggered some thinking on my part, and in turn that thinking raised some questions and
concerns that may affect not only the production of the FF service but also the Functional Resource Reference Model, and even possibly the FSP service.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I first want to point out that although this set of multiplexing schemes was defined for the purposes of FSP*, in fact the schemes are not implemented in the FSP service instances but in the VC Multiplexing functions that are part of the
Production Processing that supports those FSP service instances. Therefore, we must look at the way the multiplexing functions are defined in the CCSDS Blue Books that define those multiplexing functions – the Telecommand (TC) Space Data Link Protocol (SDLP)
and AOS SDLP Blue Books.<o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none">[*The TC SDLP and AOS SDLP both state “The algorithm used to order the Transfer Frames is not specified by CCSDS, but shall be defined by project organizations considering factors such as priority, release rate,
isochronous timing requirements, etc.”. However, instead of deferring the definition of the allowed multiplexing schemes to the individual spaceflight projects, the FSP specification defined a set that would be commonly supported.]<o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><o:p> </o:p></p>
<p class="MsoNormal" style="text-autospace:none">Both the TC SDLP and AOS SDLP define multiplexing as occurring not only at the VC level (i.e., multiplexing frames from different inputs into a single stream of frames all for the same VC) but also multiplexing
at the Master Channel (MC) level – multiplexing frames from different VCs into a single physical channel symbol stream that is subsequently input to the associated synchronization and channel encoding functions. More important to the point of this email, both
the TC and AOS SLDPs allow multiplexing schemes to be applied at each of the VC and MC levels.<o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><o:p> </o:p></p>
<p class="MsoNormal" style="text-autospace:none">Despite the statement in 1.5.1 (f) of the FSP specification (“annex B provides a specification of the multiplexing between concurrent FSP service instances sharing the same TC Virtual Channel (VC) as well as
the multiplexing between TC VCs sharing the same physical space link data channel”), the FSP specification addresses VC multiplexing but says nothing about MC multiplexing (which is a step in “sharing the same physical space link data channel (the FSP specification
also addresses MAP multiplexing, but that is “above” the VC layer: if any MAP multiplexing is done with respect to frames carried by FF services, it is done “behind” the FF user entity).
<o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><o:p> </o:p></p>
<p class="MsoNormal" style="text-autospace:none">So how should we deal with MC multiplexing?
<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2;text-autospace:none">
<![if !supportLists]><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>One simplifying approach is to assume that there is no multiplexing scheme at the MC level – i.e., when the frames from the different VCs are at the top (bottom?) of their respective VC queues, they are multiplexed into the physical
channel on a FIFO basis. This doesn’t seem to be a very satisfying approach – a frame from a very high-priority VC could still be beaten into the physical channel by a frame from a low-priority VC if the two VCs happen to belong to two different MCs.<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2;text-autospace:none">
<![if !supportLists]><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>A second approach would be to explicitly add multiplexing schemes at the MC level. However, I think that this approach could have unanticipated (and possibly undesirable) results as the two levels of multiplexing schemes interact with
each other in nondeterministic ways. <o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2;text-autospace:none">
<![if !supportLists]><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>A third approach is to collapse the two levels into a single multiplexing level on the basis of the
<i>global VCID</i>. In this approach, every possible global VC (GVC) for the target spacecraft is placed in the polling table or priority list (what the FSP specification calls the
<span style="font-family:"Courier New"">vc-multiplexing-control</span> parameter). I think that this is the most satisfying solution technically, since it allows the polling/priority order to be specified deterministically taking into account both the VC and
MC.<o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><o:p> </o:p></p>
<p class="MsoNormal" style="text-autospace:none">Assume for the moment that we adopt the third approach (GVC multiplexing): what would the impacts on the FF service, the Functional Resource Reference Model, and (possibly) the FSP service?<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level2 lfo2;text-autospace:none">
<![if !supportLists]><span style="mso-list:Ignore">a.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>To the extent that the FF service is “aware” of the underlying multiplexing scheme (e.g., the scheme can be queried using the Information Query procedure), the multiplexing schemes would have to be defined in terms of GVCs instead of
VCs. [Note – the extent to which we want or need the FF service to be aware of the details of the underlying production processes is a matter for separate investigation and discussion.]<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level2 lfo2;text-autospace:none">
<![if !supportLists]><span style="mso-list:Ignore">b.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>The Functional Resource Reference Model currently has separate FR types for VC Multiplexing and MC Multiplexing. If we actually perform multiplexing at only one unified level, then these two FRs (as well as an intermediary FR) would
collapse into a single FR type.<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level2 lfo2;text-autospace:none">
<![if !supportLists]><span style="mso-list:Ignore">c.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>If we wish to extend the same approach to the FSP and eliminate the current ambiguity with respect to MC multiplexing, then the terminology would have to be modified slightly (e.g., VC multiplexing becomes GVC multiplexing) and the revised
concept would have to be unambiguously spelled out in the FSP specification. That could possibly be done with a Technical Corrigendum instead of issuing a completely revised version.<o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><o:p> </o:p></p>
<p class="MsoNormal" style="text-autospace:none">I would very much like to hear your opinions on this matter. Am I misunderstanding something about the FSP approach to multiplexing? Are there other possible approaches to correct the shortcoming?<o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><o:p> </o:p></p>
<p class="MsoNormal" style="text-autospace:none">Best regards,<o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none">John<o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>