<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 15 (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;}
@font-face
{font-family:Georgia;
panose-1:2 4 5 2 5 4 5 2 3 3;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 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:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Georgia",serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
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;}
--></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="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">Colin,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">I think it comes down to whether or not we want to see, relatively clearly, whether or not a general period of visibility is interrupted by an internal provider event
versus potentially confusing shorter periods of visibility as indicating that only short tracking passes are potentially available. I do know that the practice is very well-established for the DSN to indicate the overall length of visibility with small interruptions
rather than the other way around. I think this is ultimately more useful for planning purposes as it tends to fit the reality of scheduling. In other words, even if there is say, a three minute outage during an eight hour tracking pass, it is eight hours of
tracking pass scheduled rather than breaking it up as, for example, five hours and 57 minutes followed by a tracking pass of two hours – it would look odd – why have they scheduled a tracking pass that starts three minutes after the one they just concluded
on the same aperture? -- I think it is cleaner to have the planning information look more like what the ultimate scheduling information looks like.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">So, ultimately I prefer putting in the provider internal limitation event to indicate these short outages. I also think that it is more correct, as technically the
spacecraft is in view for the entire interval of time but, due to provider internal limitations there will be a short outage in service but not with respect to the spacecraft technically being in view.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">-Erik<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b>From:</b> SMWG <smwg-bounces@mailman.ccsds.org> <b>On Behalf Of
</b>Colin.Haddow@esa.int<br>
<b>Sent:</b> Wednesday, July 8, 2020 06:43<br>
<b>To:</b> CCSDS SMWG ML(smwg@mailman.ccsds.org) <smwg@mailman.ccsds.org><br>
<b>Subject:</b> [EXTERNAL] [cssm] CPIF - RIDs 5,6,and 11 (Keyhole and CableWrap)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Dear all,</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> just been trying to do the updates to the schema as discussed yesterday at the Webex and was reading the red book before starting the updates (i.e. replace Keyhole and CableWrap
with ProviderLimitation), only to find that we may already have this covered and all that needs to be done is remove the Keyhole and CableWrap events.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">The reason for saying this is that we have RetComms and FwdComms events already defined and in a note at the bottom of table 3-4 it states;</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">"</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif">NOTE – The Forward and Return Communication Start and End events are used by the provider to specify the possible
start and end of communication service windows to a user platform, relative to any and all limitations and constraints under which that provider can execute user services. The specific limitations and constraints are not implied and are left up to the provider
to consider, so long as the user platform can plan and request any service whose Start and End times are contained (inclusive) within the timeframe bounded by the COMS_START and COMS_END events.</span>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"> Typical limitations and constraints accounted for when defining the COMS_START and COMS_END events are constraints associated with antenna elevation,
<b><i>cable wrap</i></b>, visibility masks, slew rates, etc.</span><span style="font-size:10.0pt;font-family:"Arial",sans-serif">"</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">so the question is to we need the ProviderLimitation events in view of this ?</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">I can see there may be some use in indicating a limitation rather than just providing an available comms window, but would appreciate other vies.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Cheers for now,</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Colin<br>
<br>
---------------------------------------------------------------------------------------------------------<br>
Dr. Colin R. Haddow,<br>
HSO-GI, European Space Agency,<br>
European Space Operations Centre,<br>
Robert-Bosch-Str 5,<br>
64293 Darmstadt,<br>
Germany.<br>
<br>
Phone; +49 6151 90 2896<br>
Fax; +49 6151 90 3010<br>
E-Mail; <a href="mailto:colin.haddow@esa.int">colin.haddow@esa.int</a><br>
---------------------------------------------------------------------------------------------------------</span><o:p></o:p></p>
</div>
<pre>This message is intended only for the recipient(s) named above. It may contain proprietary information and/or<o:p></o:p></pre>
<pre>protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received<o:p></o:p></pre>
<pre>this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect<o:p></o:p></pre>
<pre>personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (<a href="mailto:dpo@esa.int">dpo@esa.int</a>).<o:p></o:p></pre>
</div>
</body>
</html>