[Sls-rfm] SCCS-ARD discussion relating to VCM
Jon Hamkins
Jon.Hamkins at jpl.nasa.gov
Thu Dec 2 04:26:02 UTC 2021
Hi Peter,
I requested the meeting to provide feedback on the SCCS-ARD draft on one
topic that I know best. This feedback is important for you to hear and
discuss prior to a decision on how we ought to proceed. It involves the
VCM "suite" issue but also several other important areas. There are
factual errors, omissions, and artificial complexity. These are not
details. These get at the crux of properly explaining how VCM works and
fits together and what the relevant standards actually are about. These
issues need to be resolved before we will be able to reach closure on an
approach.
With this in mind, I suggest inserting agenda item #4, resulting in the
following:
Agenda
1. SCCS-ARD structure (Peter) - 5 minutes
2. SCCS-ARD viewpoints (Peter) - 5 minutes
3. SCCS-ARD handling of VCM "suite" (Peter) - 5 minutes
4. Feedback on the SCCS-ARD (Jon) - 60 minutes
5. Discussion and path forward (all) - 45 minutes
6. Specific details, if any. - 0 minutes
If more time is needed, we can stretch the meeting length accordingly. I
suggested the first items be brief because we don't need much of a
tutorial on the SCCS-ARD at this point, since those have been covered in
detail in the distributed SCCS-ARD itself and prior meetings.
I intend to come to the meeting with practical suggestions on how to
improve the SCCS-ARD draft, and an open mind.
BTW, I laughed at the cartoon! The irony of it, I mean, which you may
have missed. I am not insulted by VCM being a small piece -- my
recommendation was for VCM to be not included in the SCCS-ARD, but that
was ignored. If you feel VCM is taking outsize importance, we should
keep its removal in the trade-space of options we discuss.
----Jon
*Jon Hamkins*
Chief Technologist, Communications, Tracking, and Radar Division
*JPL* | jpl.nasa.gov
On 12/1/2021 1:50 PM, Shames, Peter M (US 312B) wrote:
>
> Hi Jon,
>
> Actually, what I meant by “deal with the fundamental issues” is that I
> wish to present the point of view that we are working from in this
> document first. This discussion is first and foremost about this
> SCCS-ARD document.
>
> As with so many things, looked at from the bottom up things look one
> way, they look different from the top down. This SCCS-ARD document is
> a top down perspective, as it must be in order to describe how over
> seventy-five (75) standards fit together, like a jig-saw puzzle. This
> is to help the users of this “CCSDS Suite” of standards understand how
> they can be used to create end-to-end information systems for
> missions, create ground stations and their supporting infrastructure,
> design spacecraft on-board systems, and also the mission operations
> systems that deal with all of these communications issues.
>
> This is a big job, and no insult intended, these VCM issues are a very
> small piece of the overall picture. I’ve intentionally exaggerated
> for effect, but we really want to avoid anything like the attached
> picture.
>
> This is my proposed agenda for this discussion of the SCCS-ARD
> “omnibus” architecture document and how this VCM topic fits into it:
>
> 1. Present, briefly, the overall structure of the SCCS-ARD
> 2. Describe the different viewpoints that it covers
> 3. Describe how we have handled the VCM “suite” of standards and why
> we chose to handle them that way
> 4. Try and reach closure on an overall approach
> 5. And then deal with the specific details in that context
>
> Thanks, Peter
>
> PS – we also described all of the Internet protocols, a massive body
> of work, as “the Internet Protocol Suite (IPS)”. See References, pg
> 36. We handle the “DTN suite” in a similar way. No one has complained.
>
> See https://en.wikipedia.org/wiki/Internet_protocol_suite
>
> *From: *Jon Hamkins <Jon.Hamkins at jpl.nasa.gov>
> *Date: *Wednesday, December 1, 2021 at 12:00 PM
> *To: *Peter Shames <peter.m.shames at jpl.nasa.gov>, Space Link Coding &
> Synchronization Working Group <sls-cc at mailman.ccsds.org>,
> "sls-rfm at mailman.ccsds.org" <sls-rfm at mailman.ccsds.org>
> *Cc: *"Ignacio.Aguilar.Sanchez at esa.int" <Ignacio.Aguilar.Sanchez at esa.int>
> *Subject: *Re: [EXTERNAL] Re: [SLS-CC] Fw: WebEx meeting invitation:
> SCCS-ARD update review scheduled for Tuesday, 23 Nov, 2021 at 0700 AM PST
>
> Okay, sounds good. I hope we can find a time that the C&S/RFM chairs
> and champions of the involved standards can be present.
>
> I am requesting the meeting so that I can describe my concerns and
> discuss a way to reach consensus. I suggest a one-hour block at the
> beginning for me to present them, in a two-hour meeting. This
> conversation will quickly get at the issue of the “suite” label, so I
> think that fits in with Peter's plan, and there are a number of
> unrelated fundamental issues relating to factual errors, omissions,
> complexity, etc., as well.
>
> ----Jon
>
> *Jon Hamkins*
> Chief Technologist, Communications, Tracking, and Radar Division
> *O* 818-354-4764 | *M* 626-658-6220
>
> *JPL* | jpl.nasa.gov
>
> On 11/30/2021 10:32 AM, Shames, Peter M (US 312B) wrote:
>
> Thanks Jon. I will fire off a Doodle to pick a time for a Webex.
>
> As far as I am concerned we need to deal with the fundamental
> issues that I raised. The handling of the details in the document
> will be a direct result of that discussion.
>
> Thanks, Peter
>
> *From: *Jon Hamkins <Jon.Hamkins at jpl.nasa.gov>
> <mailto:Jon.Hamkins at jpl.nasa.gov>
> *Date: *Monday, November 29, 2021 at 7:29 PM
> *To: *Peter Shames <peter.m.shames at jpl.nasa.gov>
> <mailto:peter.m.shames at jpl.nasa.gov>, Space Link Coding &
> Synchronization Working Group <sls-cc at mailman.ccsds.org>
> <mailto:sls-cc at mailman.ccsds.org>, "sls-rfm at mailman.ccsds.org"
> <mailto:sls-rfm at mailman.ccsds.org> <sls-rfm at mailman.ccsds.org>
> <mailto:sls-rfm at mailman.ccsds.org>
> *Cc: *"Ignacio.Aguilar.Sanchez at esa.int"
> <mailto:Ignacio.Aguilar.Sanchez at esa.int>
> <Ignacio.Aguilar.Sanchez at esa.int>
> <mailto:Ignacio.Aguilar.Sanchez at esa.int>
> *Subject: *Re: [EXTERNAL] Re: [SLS-CC] Fw: WebEx meeting
> invitation: SCCS-ARD update review scheduled for Tuesday, 23 Nov,
> 2021 at 0700 AM PST
>
> Thanks, Peter. I think we will make faster progress with a webex
> meeting rather than email. I would like to resolve each of the six
> comments.
>
> ----Jon
>
> *Jon Hamkins*
> Chief Technologist, Communications, Tracking, and Radar Division
> *O* 818-354-4764 | *M* 626-658-6220
>
> *JPL* | jpl.nasa.gov
>
> On 11/29/2021 3:29 PM, Shames, Peter M (US 312B) wrote:
>
> Hi Jon and all our other SLS C&S and RFM WG colleagues.
>
> In the context of the Space Communication Cross Support (SCCS)
> Architecture Requirements Document (ARD) we have this on-going
> discussion of the state of the SLS “VCM Suite” of variable
> coding and modulation standards. Jon has pointed out, at
> length, that there is no term “VCM suite” defined within the
> C&S WG or within any of the SLS Area literature. I have to
> agree that this statement, taken by itself, is true.
>
> What Jon has then requested is that this term “VCM Suite”, and
> the diagram we have constructed to explain the complexities of
> this situation, be replaced in the SCCS-ARD by the single term
> “the VCM protocol” and also be shown as three separate boxes
> in figure 6-1, Layering of CCSDS link layer protocols.
>
> Last week we held a 2 hour review of all of the major changes
> we have introduced in the SCCS-ARD. These changes are due to
> the usual 5 year document review and the addition of many new
> standards, several of which had only been forecast in the
> original edition. Among these were the DVB-S2 (CCSDS
> 131.1-B-2), the SCCC (CCSDS 131.2-B-2), and the VCM (CCSDS
> 431.1-B-1). What cannot be in question is that all three of
> these describe themselves as “VCM protocols”. Even the 431.1
> document describes all three of these, separately, as VCM
> protocols.
>
> See the two attachments for screen shots of the 431.1 document
> where these statements are made and where some of the
> differences are described, in text.
>
> The 431.1-B-1 document also makes this statement, in Sec 1.2
> Purpose and Scope
>
> The purpose of this Recommended Standard is to specify various
> combinations of coding and modulations in references [1], [2],
> [4], and [5], that can operate under the VCM protocol defined
> in references [2] and [4]. This enables, for example, some of
> the CCSDS recommended channel codes (reference [1]) and
> modulations (reference [5]) to be used with the CCSDS VCM
> protocol.
>
> In reading through this 431.1-B-1 document, again, I am struck
> fact that the document, in two different sentences, says
> “there are three different VCM protocols”, and then “there is
> one ‘CCSDS VCM protocol’”. Just looking again at these
> documents, all three of them, three things are very clear:
>
> 1. There are three separate documents, each of which is
> defined as a “VCM protocol”.
> 2. The three are similar, but, in detailed fact, are
> different and cannot interoperate.
> 3. The third of these, CCSDS 431.1 cannot stand alone, it is
> meaningless without heavy reliance on major parts of
> DVB-S2 and SCCC, which it terms as Type 1 and Type 2 VCM
> schemes.
>
> I am not going to un-Earth the history of how we got into this
> situation, but I firmly believe that if we asked any
> knowledgeable, independent, reviewer with relevant technical
> background to review these three standards they would ask “Why
> do you have three nearly identical standards when one would do?”.
>
> But the facts are that we do have two nearly identical
> standards and a third one that could not exist at all without
> the other two, which it is (almost) entirely dependent upon.
> This is unique in CCSDS.
>
> As for SCCS-ARD, the attached PPT file will make clear how we
> propose to handle this situation. Instead of showing the
> Telemetry S&C, and the Telecommand S&C, and three separate,
> different, but admittedly nearly identical, VCM protocols, we
> have chosen to call this set of triplets the “VCM suite”, to
> show how these fit with the other related standards, and to
> show their similarities and differences. We think that this
> both provides visibility to this VCM technique, allows us to
> state what value they bring (primarily for high rate downlink
> missions), and also to not overly complicate an already
> complicated diagram with three essentially identical VCM
> protocols.
>
> We called this trio of VCM standards the “VCM suite”. If you
> all have a better name to suggest we are open to hearing it.
> All of the other people we have had review this agree that
> this is a suitably simple, and effective, way to deal with
> this complicated situation.
>
> If we need to have a WebEx to discuss this I am more than
> willing to set one up.
>
> Thanks, Peter
>
> *From: *SLS-CC <sls-cc-bounces at mailman.ccsds.org>
> <mailto:sls-cc-bounces at mailman.ccsds.org> on behalf of Jon
> Hamkins via SLS-CC <sls-cc at mailman.ccsds.org>
> <mailto:sls-cc at mailman.ccsds.org>
> *Reply-To: *Jon Hamkins <jon.hamkins at jpl.nasa.gov>
> <mailto:jon.hamkins at jpl.nasa.gov>
> *Date: *Sunday, November 14, 2021 at 11:05 PM
> *To: *Space Link Coding & Synchronization Working Group
> <sls-cc at mailman.ccsds.org> <mailto:sls-cc at mailman.ccsds.org>,
> "sls-rfm at mailman.ccsds.org" <mailto:sls-rfm at mailman.ccsds.org>
> <sls-rfm at mailman.ccsds.org>
> <mailto:sls-rfm at mailman.ccsds.org>, CCSDS Engineering Steering
> Group - CESG All <cesg-all at mailman.ccsds.org>
> <mailto:cesg-all at mailman.ccsds.org>
> *Subject: *[EXTERNAL] Re: [SLS-CC] Fw: WebEx meeting
> invitation: SCCS-ARD update review scheduled for Tuesday, 23
> Nov, 2021 at 0700 AM PST
>
> Thank you for the invitation to review the SCCS-ARD. I regret
> that I will not be able to discuss the SCCS-ARD in person on
> 23 Nov. I will be on vacation that week. I give my comments
> here, with the hope that this is enough in advance of the
> meeting for each of the individual comments to be read and
> discussed at the meeting.
>
> My primary comment is that updating the SCCS-ARD is clearly a
> large undertaking, and I would like to congratulate John
> Pietras and Peter Shames for on the production of a quality
> document. It is difficult to absorb such a large swath of
> CCSDS standards and integrate them into a helpful summary of
> the interfaces as this SCCS-ARD does.
>
> My other comments primarily relate to the new VCM content.
> There are six main comments, with more detailed description,
> recommendation, and justification for each. These comments are
> written based on the latest SCCS-ARD, but I also repeat
> portions of my June-23 comments if they were not yet
> addressed. I believe the SCCS-ARD will be much improved if we
> adopt these recommendations.
>
> 1. The phrase "VCM suite"
>
> 1. Description: This phrase is introduced in this
> SCCS-ARD. It occurs in Table 6-1, and throughout
> Section 6.1.2, Table 6-8, Table 6-12.
> 2. Recommendation: Remove this phrase in all places and
> replace with "the VCM protocol."
> 3. Justification
>
> 1. CCSDS does not have a "VCM suite" and I think it
> is a mistake to invent this new concept here,
> especially since it would risk confusing the
> reader into thinking that there is more than one
> VCM protocol.
> 2. 131.2 and 131.3 are not members of a supposed "VCM
> suite." They are not even the same kind of thing
> that 431.1 is. 431.1 is a protocol book, while
> 131.2 and 131.3 describes codes, modulation, and VCM.
> 3. One VCM protocol. As we worked out in the C&S and
> RFM WGs at the time we negotiated the VCM protocol
> blue book (431.1-B-1), there is one VCM protocol
> that can be used with multiple sets of codes and
> modulations described in other blue books. There
> are some variations and options in this protocol,
> but it is fundamentally one protocol that operates
> in the same way, namely, with a header signaled
> with pi/2-BPSK and protected with a specific RM
> code, followed by code symbols using a higher
> order modulation. This is why the VCM blue book
> has the title "Variable Coded Modulation Protocol"
> with no plural word or "suite."
> 4. In other words, the protocol is singular. What is
> plural is the set of VCM tables that can be used
> in conjunction with the protocol. Incidentally, in
> other areas CCSDS doesn't refer to a "code suite,"
> or a "ranging suite" or a "frequencies suite"
> where there are clearly multiple options.
>
> 2. Table 6-1 organization.
>
> 1. Description: Table 6-1 lists three references for the
> VCM "Suite": 131.2, 131.3, and 431.1.
> 2. Recommendation: put 131.2, 131.3, and 431.1 each on
> their own row of the table, using their Blue Book
> name, like the other rows of the table do.
> 3. Justification
>
> 1. Books that are the same type of thing are treated
> differently in the table.
>
> 1. As we know, there are 4 CCSDS coding standards
> that ingest TM/AOS/USLP frames (what we might
> previously call space-to-ground links): 131.0
> (turbo/LDPC), 131.2 (SCCC), 131.3 (DVB-S2
> LDPC), and 142.1 (SCPPM). These references
> should appear together in Table 6-1 in the
> same way, not with 131.0 in its own row and
> 131.2 and 131.3 relegated to a secondary
> category within "VCM suite." The SCCS-ARD
> should be about interfaces (in this case,
> ingestion of TM, AOS, or USLP Transfer
> Frames). Treating them differently in the
> table doesn't make sense.
> 2. In particular, Table 6-1 as written calls out
> 142.1 and 131.0 as "coding" books and 131.2
> and 131.3 as members of a supposed "VCM
> suite." But 131.2 and 131.3 are primarily
> about the codes they define -- the SCCC codes
> and DVB-S2 LDPC codes. When C&S negotiated
> their acceptance, the discussion was primarily
> about the coding performance, complexity,
> maturity, etc., and not their associated VCM
> approaches (which are nearly identical).
>
> 2. Books that are different are treated as though
> they are the same in the table
>
> 1. 131.2, 131.3, and 431.1 cannot be listed as
> though they are the same type of thing
> 2. 431.1 is fundamentally different in structure
> from 131.2 and 131.3. 431.1 is the unifying
> description of the (one) CCSDS VCM protocol,
> and refers back to 131.2 and 131.3 in
> describing the differences of the two minor
> variations (types). Whereas 131.2 and 131.3
> describe codes and modulations.
>
> 3. This would be consistent with the rest of the table.
>
> 3. Table 6-1 "space-to-ground links".
>
> 1. Description: The table has a left-column heading
> labeled "Space-to-Ground Links."
> 2. Recommendation:
>
> 1. Remove or reword "Space-to-Ground Links"
>
> 3. Justification:
>
> 1. This may be outdated terminology, given our
> renewed interest in allowing a variety of link
> directions for the standards.
> 2. Or, if we are keeping the concept of direction,
> why is the TC coding book listed in this category?
> Also, why is there no corresponding
> "Ground-to-Space Links" category?
>
> 4. Figure 6-1
>
> 1. Description: Figure 6-1 shows boxes for TM sync and
> channel coding, VCM suite, and RF and modulation, with
> some lines between some of them.
> 2. Recommendation: Revise the figure to include an "SCCC
> coding" box, a "DVB-S2 LDPC coding" (or similar) box,
> and redraw the VCM box to encompass those boxes as
> well as the "TM sync and channel coding" and "RF and
> Modulation" boxes. Also, update the lines to make
> clear which frame types may enter each of the boxes on
> the coding sublayer.
> 3. Justification: As drawn, this figure is not clear and
> bordering on inaccurate.
>
> 1. There is a box labeled VCM suite, presumably meant
> to include 131.2, 131.3, and 431.1 in this box. If
> so, then why is TM Sync And Channel Coding outside
> of this box? Why is RF and Modulation outside of
> this box? Those are specified as part of 431.1.
> 2. It does not make sense for turbo/LDPC codes to get
> their own box in this figure, but not SCCC and
> DVB-S2 codes. These make the same type of
> specification at the same layer. Where SCCS-ARD
> can be of service is in explaining where the
> interfaces are the same in the various books.
> 3. VCM is a standard about both coding and modulation
> and so should be drawn to encompass the coding and
> modulation functions.
>
> 5. Section 6.1.2.2.1
>
> 1. Description. This section:
>
> 1. States that the VCM suite is not a single protocol
> but rather three separate protocols, then says
> they are "very similar," and finally then says
> they are all subsumed into one, using the phrase
> "the VCM protocol."
> 2. Refers to 131.2 and 131.3 as "VCM standards"
> 3. Says that 431.1 subsumes the functionality of
> 131.2 and 131.3
>
> 2. Recommendation: Rewrite the paragraph from scratch to
> include these features
>
> 1. Refer to 131.0, 131.2, and 131.3 on equal footing
> as standards for turbo/LDPC, SCCC, and DVB-S2 LDPC
> codes, and a variety of modulations.
> 2. Refer to 431.1 ("the VCM protocol") as allowing
> the codes specified in these three standards to be
> used with a common protocol with two variations
> called Type 1 and Type 2; and that the VCM
> protocol is easily updated to accommodate other
> codes and/or modulations with the additional of
> new VCM tables.
>
> 3. Justification:
>
> 1. As written, the paragraph is self-contradictory.
> The protocol cannot simultaneously be three
> separate things, two very similar things, and all
> subsumed into one thing.
> 2. The simplicity of the concept of unifying VCM into
> a common protocol that can be used with SCCC,
> DVB-S2 and turbo/LDPC codes is missing from this
> paragraph.
> 3. Saying 431.1 "subsumes" 131.2 and 131.3 makes it
> seem like 131.2 and 131.3 are not needed. They are
> needed, because they are what specifies the codes
> and modulations. 431.1 /refers/ to 131.2 and 131.3.
>
> 6. Figure 6-2
>
> 1. Description. The figure purports to show component
> standards of "the VCM suite."
> 2. Recommendation:
>
> 1. Remove this figure from the SCCS-ARD.
>
> 3. Justification. This figure is unnecessary, redundant,
> artificially complex, misleading, and incomplete.
>
> 1. Unnecessary
>
> 1. There is no "VCM suite."
> 2. The purpose of the SCCS-ARD is to explain how
> things fit together. But this figure
> purportedly shows three standards -- 131.2,
> 431.1, and 131.3 -- /that do not interact with
> each other/ (there are no lines between the
> three main boxes)/. /This makes it unnecessary
> for the SCCS-ARD to address.
>
> 2. Redundant, artificially complex
>
> 1. No information would be lost if the 131.2 and
> 131.3 columns were deleted in their entirety.
> All of the SCCC encoding is shown within the
> middle (431) box, for example. This
> duplication is confusing and artificially adds
> complexity where there is none.
> 2. The things that are common -- functions like
> slicing, ASM, modulation, pilot -- are drawn
> multiple times, giving the impression that
> they are different.
> 3. There is so much stuff on this figure that it
> has been shrunk so that the font is 6 pts.
> This is not legible without zooming.
>
> 3. Misleading
>
> 1. The duplication mentioned above may confuse a
> reader into believing that there is more than
> one VCM protocol that applies to SCCC codes
> (similarly, for DVB-S2 codes). This is the
> opposite of what this figure should be doing.
> 2. The slicer for DVB is shown within the ETSI
> standard, when it is really part of the CCSDS
> standard (131.3).
> 3. The boxes labeled "variable coding and
> modulation" contain no coding and no
> modulation. I think you mean VCM control.
> 4. The circle-plus notation in the figure is
> confusing. In other CCSDS standards, that
> notation means XOR, which is not what is going
> on here.
>
> 4. Incomplete
>
> 1. Few of the salient features of the VCM
> protocol are actually present in the figure.
> The VCM header is transmitted with pi/2-BPSK
> modulation, for example. The pilots are
> optional. The header has two parts, a sync
> marker and a signaling structure (PLS or frame
> descriptor). The frame descriptor is protected
> with a (32,6) code. All of that is missing.
> 2. The input to the "VCM suite" is not labeled.
> The interfaces are the most important part of
> showing how things fit together.
> 3. The output of the "VCM suite" is not labeled.
> Again, that should be the important part.
> 4. No VCM control is shown as an input to the TM
> codes.
> 5. No VCM control is shown for the pilots.
> 6. No VCM control is shown for the slicer.
> 7. Arrows showing direction of flow are missing
> throughout.
>
> ----Jon
>
> *Jon Hamkins*
> Chief Technologist, Communications, Tracking, and Radar Division
> *O* 818-354-4764 | *M* 626-658-6220
>
> *JPL* | jpl.nasa.gov
>
> On 11/10/2021 11:58 PM, Andrea.Modenini at esa.int wrote:
>
> FYI
>
> *ESA - European Space Agency*
> *Ph.D. Andrea Modenini**
> TT&C Communications Systems Engineer***
> TT&C and PDT Systems & Techniques Section (TEC-EST)
> RF Systems Division*
> ESTEC*
> Keplerlaan 1, PO Box 299
> NL-2200 AG Noordwijk, The Netherlands_
> _andrea.modenini at esa.int | www.esa.int
> <https://urldefense.us/v3/__http:/www.esa.int/__;!!PvBDto6Hs4WbVuu7!c_W6kQBKFsU715uHT0ZbEI-Zxyzva6CZAw_475CJiUtC49HEKgcsDEvKn5iiAOkOz9Y62n8$>
> T +31 71 56 53439, M +31 6 484 56 527
> ----- Forwarded by Andrea Modenini/estec/ESA on 11-11-21
> 08:57 -----
>
> From: "Shames, Peter M\(US 312B\) via CESG-All"
> <cesg-all at mailman.ccsds.org>
> <mailto:cesg-all at mailman.ccsds.org>
> To: "CCSDS Engineering Steering Group - CESG All"
> <cesg-all at mailman.ccsds.org>
> <mailto:cesg-all at mailman.ccsds.org>
> Cc: "EXTERNAL-Pietras, John V\(US 332C-Affiliate\)"
> <john.pietras at gst.com> <mailto:john.pietras at gst.com>,
> "SEA-SA" <sea-sa at mailman.ccsds.org>
> <mailto:sea-sa at mailman.ccsds.org>
> Date: 10-11-21 23:55
> Subject: [Cesg-all] FW: [EXTERNAL] WebEx meeting
> invitation: SCCS-ARD update review scheduled for Tuesday,
> 23 Nov, 2021 at 0700 AM PST
> Sent by: "CESG-All" <cesg-all-bounces at mailman.ccsds.org>
> <mailto:cesg-all-bounces at mailman.ccsds.org>
>
> ------------------------------------------------------------------------
>
> Dear CCSDS AD and WG chairs,
>
> The review of the SCCS-ARD has been scheduled for Tuesday,
> 23 Nov, 2021 at 0700 AM PST. The draft of the document,
> which is in rough, “track changes”, form is available
> on-line. The proposed updates to the ABA subsections of
> sections 4, 5, and 6 (except for the security-specific
> subsections) and posted the draft to the CWE at:
>
> https://cwe.ccsds.org/sea/docs/SEA-SA/Draft%20Documents/SCCS-ARD-ADD%20Revisions%202020/SCCS-ARD%20draft%20documents/SCCS-ARD-901x1p1_10-211108.doc?d=wd389d0c8026d47a591fbc35f2e261b58
> <https://urldefense.us/v3/__https:/cwe.ccsds.org/sea/docs/SEA-SA/Draft*20Documents/SCCS-ARD-ADD*20Revisions*202020/SCCS-ARD*20draft*20documents/SCCS-ARD-901x1p1_10-211108.doc?d=wd389d0c8026d47a591fbc35f2e261b58__;JSUlJSU!!PvBDto6Hs4WbVuu7!YAgXpQsrLJbeeQgotEG0WUNrvYYDosRiqy6GyJr5YS38sxD0qn-wbyDWHlnAyZkngUHY_hIq$>
>
> Feel free to download this and review the sections that
> are of interest most interest to you (or all of it if you
> wish). If there are members of your WG who can usefully
> contribute to this review please feel free to invite them
> as well.
>
> The Space Communications Cross Support Architecture
> document (SCCS-ARD) is a cross-cutting Magenta Book that
> largely covers the SLS, SIS, CSS, and SEA areas and their
> working groups. We have being working on an update to
> this document that primarily covers what are called “ABA”
> mission configurations, which are those that involve a
> single mission ops center, a single spacecraft, and a
> ground station. The Solar System Internet (SSI)
> configurations, which involve multiple spacecraft, mission
> centers, and comm assets, and use the DTN (or IP)
> protocols, will be in a future update that builds on this
> foundation.
>
> There have been a number of changes to the CCSDS standards
> landscape since the last edition was published. These
> include:
>
> 1. USLP protocol
> 2. The “VCM suite” of variable coding and modulation
> standards
> 3. New CSTS services
> 4. New Service Management standards
> 5. Updates to the Synch and Channel coding specs, the
> liberal approaches
> 6. New security features in several sections
>
> In addition to these new / updated standards we wish to
> address the following issues as well:
>
> 1. Improved handling of cross references from the
> Services viewpoint to the protocol stack details
> (interface binding signatures)
> 2. Revised section structures and cross referencing
> 3. Inclusion of “recommended” options and clarification
> of optional and mandatory features
> 4. Discussion of incomplete / optional capabilities like
> forward file service, handling of details of
> complexities like MAP service and VC/MC multiplexing,
> COP on the USLP return link, and CADUs in FF-CSTS
> given new Pseudo-randomized “Only Idle Data” (OID) frames
>
> Hope to see you at this review.
>
> Thanks, Peter Shames & John Pietras
>
> *From: *Peter Shames <messenger at webex.com>
> <mailto:messenger at webex.com>*
> Reply-To: *Peter Shames <peter.m.shames at jpl.nasa.gov>
> <mailto:peter.m.shames at jpl.nasa.gov>*
> Date: *Thursday, November 4, 2021 at 3:07 PM*
> To: *Peter Shames <peter.m.shames at jpl.nasa.gov>
> <mailto:peter.m.shames at jpl.nasa.gov>*
> Subject: *[EXTERNAL] (Forward to others) WebEx meeting
> invitation: SCCS-ARD update review
>
> You can forward this invitation to others.
>
> Hello,
>
> Peter Shames invites you to join this WebEx meeting.
>
> *SCCS-ARD update review*
>
> Tuesday, November 23, 2021
>
> 7:00 AM | (UTC-07:00) Pacific Time (US & Canada) | 1
> hr 30 mins
>
> Meeting number (access code): 2761 585 8804
>
> Meeting password: 9JRpYBGHp72
>
> Join meeting
> <https://jpl.webex.com/jpl/j.php?MTID=m19aa1606d8ed2742fa89cd2d8d4b0afa>
>
> *More ways to join:*
>
> *Join from the meeting link*
>
> https://jpl.webex.com/jpl/j.php?MTID=m19aa1606d8ed2742fa89cd2d8d4b0afa
> <https://jpl.webex.com/jpl/j.php?MTID=m19aa1606d8ed2742fa89cd2d8d4b0afa>
>
> *Join from a video system or application*
>
> Dial 27615858804 at jpl.webex.com
> <%20sip:27615858804 at jpl.webex.com>
>
> You can also dial 207.182.190.20 and enter your meeting
> number.
>
> *Join by phone*
>
> +1-510-210-8882 USA Toll
>
> +44-203-457-5798 U.K. Toll
>
> Global call-in numbers
> <https://jpl.webex.com/jpl/globalcallin.php?MTID=m5e38422f279e390de6b43d836a8711d0>
>
> *Local: 818-35(4-4044)*
>
> *Toll Free: 844-JPL-WEBX (844-575-9329)*
>
> Can't join the meeting?
>
> IMPORTANT NOTICE: Please note that this Webex service
> allows audio and other information sent during the session
> to be recorded, which may be discoverable in a legal
> matter. By joining this session, you automatically consent
> to such recordings. If you do not consent to being
> recorded, discuss your concerns with the host or do not
> join the session.
>
> [attachment "Webex_Meeting.ics" deleted by Andrea
> Modenini/estec/ESA]
> _______________________________________________
> CESG-All mailing list
> CESG-All at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg-all
> <https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg-all__;!!PvBDto6Hs4WbVuu7!c_W6kQBKFsU715uHT0ZbEI-Zxyzva6CZAw_475CJiUtC49HEKgcsDEvKn5iiAOkOJm26tok$>
>
> 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 at esa.int).
>
>
>
>
>
> _______________________________________________
>
> SLS-CC mailing list
>
> SLS-CC at mailman.ccsds.org
>
> https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-cc__;!!PvBDto6Hs4WbVuu7!c_W6kQBKFsU715uHT0ZbEI-Zxyzva6CZAw_475CJiUtC49HEKgcsDEvKn5iiAOkOmu4K-Qo$ <https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-cc__;!!PvBDto6Hs4WbVuu7!c_W6kQBKFsU715uHT0ZbEI-Zxyzva6CZAw_475CJiUtC49HEKgcsDEvKn5iiAOkOmu4K-Qo$>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-rfm/attachments/20211201/8065e7c2/attachment.htm>
More information about the SLS-RFM
mailing list