[Css-csts] RE: [Smwg] Background materials for discussion on functional resources and OIDs

Tue May 1 16:19:59 EDT 2012

Erik,

You hit on exactly the reason why we decided that while the functional
resource types and parameter types could be defined as OIDs (and the
standard ones could be defined by CCSDS), the functional resource IDs
themselves would best be left to the Agencies, which could create the FR
instance IDs that suited the capabilities of each Agency's network(s).
If multiple concurrent space link carriers in the same frequency band
are possible, then that Agency could create appropriate IDs. For
example, NASA SN has two flavors of S-band service: "single access" (SA)
via a steerable antenna, and "multiple access" (MA) via the shared
phased array antenna. In the SN, each TDRS has two steerable antennas
and one MA antenna. So for the SN, NASA will have to be able to define
identifiers that can be used to differentiate between these two S-Band
possibilities (which indeed the SN does today with the service
designations "SMA" and "SSA"). 

NOTE - This example raises the question as to whether SMA and SSA (in
this example) are two flavors of the same functional resource type, or
functional resource types in their own right. At least for these
examples, I think that they can still be legitimately consider two
flavors of the same FR type. But in the future we might need/want to
entertain the notion of derived functional resource types that inherit
the parameters, events, and directives of their parent types. 

Your follow-on message:

"Having read more carefully into the material provided it appears that
in this case the functional resource would be further identified by the
name of the carrierAgreementId - but that in fact is an agreement of a
range of values for subsequent carriers which in turn are identified by
carrierProfileId  - so it seems to me that that is the carrierProfileId
that is the data value that further identifies the functional resource
instance in this case."

is along the lines of what I have in mind, but it seems to me that using
the Carrier Profile (which specifies a single configuration of the
carrier parameters) to characterize the space link carrier functional
resource is too "narrow" - every mission would essentially create a new
functional resource ID every time it created a new carrier profile
within a space communication service profile. It is more dynamic than
what I believe the CSTSWG has in mind, which is some type of
more-statically defined "publishable" identifiers.

At the Portsmouth meeting I proposed an approach by which each agency
would define essentially what we are now calling functional resource IDs
and to add a parameter to "appropriate" component data sets of the
SpaceLinkCarrierAgreement to carry those FR IDs. Note that the notion
that I proposed in Portsmouth was not exactly the same as today's
more-refined concept of functional resource IDs, but the underlying idea
is the same. The SMWG actually tentatively adopted that approach at
Portsmouth, but by the time we discussed it again in London there were
concerns about adding semantics to the space link carrier agreements
that weren't there before. Toward the end of the London meeting, when we
met with Wolfgang to discuss his reaction to the service agreement
parameters, one of his concerns was a lack of concrete binding of
service agreement parameters to more-tangible entities. I recall noting
during that discussion that Wolfgang's concern was supportive of the
notion of linking functional resources to service agreement-level
entities. 

In any case, I still think that somehow tying functional resource naming
into the service agreement-level entities is probably the better way to
go, although I need to develop some extensive examples and uses cases to
prove that out to myself and to everyone else. I've started to rework
that previous material to reflect the latest functional resource-related
concepts and to develop those examples . Unfortunately, that material
won't be ready for tomorrow's telecon, but I'm aiming for the end of
May. 

Looking forward to discussing this more tomorrow.

John

From: Barkley, Erik J (3170) [mailto:erik.j.barkley at jpl.nasa.gov] 
Sent: Friday, April 27, 2012 8:40 PM
To: John Pietras; smwg at mailman.ccsds.org
Cc: css-csts at mailman.ccsds.org
Subject: RE: [Smwg] Background materials for discussion on functional
resources and OIDs

John,

Thanks for the information.   A quick question re your example.  I
believe it is quite possible to have  multiple carriers in the same band
simultaneously.   It seems then that the X-band vs S-band designation no
longer uniquely identifies the separate instances of carrier lock
parameter.  What do the functional resources look like in this case?  

-Erik

From: smwg-bounces at mailman.ccsds.org
[mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Tuesday, April 24, 2012 11:38 AM
To: smwg at mailman.ccsds.org
Cc: css-csts at mailman.ccsds.org
Subject: [Smwg] Background materials for discussion on functional
resources and OIDs

SMWG colleagues ---

At the meeting in Darmstadt, the SMWG stated that it wanted to review
the concepts for functional resources and their naming using Object
Identifiers (OIDs). The use of these OIDs has become part of the CSTS
Specification Framework (SF), and acceptance of the OIDs as specified in
the current CSTS SF context is one of the last (if not the last) "gates"
that must be passed before the Red-2 version of the CSTS FW is released
to the Secretariat. Given this time constraint, the SMWG agreed to
discuss the topic at the 2 May 2012 SMWG telecon. All interested members
of the SMWG were given the action (SMWG #2012-0419-01) to prepare for
this discussion. 

The driver for these concerns is the need to define unambiguous names
for parameters, events, and directives that might have multiple
instances within the context of a single Service Package. A simple
example is carrier lock, which can have an instance for every return
link carrier executing with the Service Package. The approach that has
been developed is to uniquely name a parameter/event/directive as a pair
of identifiers: (a) the parameter/event/directive type identifier and
(b) the identifier of the instance of the functional resource type with
which that parameter/event/directive type is associated. 

In the above simple example, if return space link carrier is the
functional resource type and if a given network can provide at most one
return link carrier in each frequency band to a mission spacecraft, then
"S-band return space link carrier" and "X-band return space link
carrier" are valid functional resource IDs. If 'carrier lock' is a
monitored parameter of the "return space link carrier" functional
resource type, then ["S-band return space link carrier": 'carrier lock']
and 
["X-band return space link carrier": 'carrier lock'] uniquely identify
the two separate instances of the carrier lock parameter.

During the past year or so, the CSTSWG has focused on the syntax of
these types and identifiers. As currently conceived, the functional
resource type and parameter/event/directive types are defined as ISO
Object Identifiers (OIDs). The functional resource ID (that is, the
"name" of a specific instance of a functional resource type) is
essentially defined as a pair of the functional resource type and an
instance identifier. However, the exact syntax of the instance
identifier has not yet been defined, and that is probably the most
significant outstanding decisions to be made.

Attached to this email is a zipped folder containing four documents that
are arguably the best available materials to review in preparation for
this discussion:

a)      BaselineFunctionalResourcesForMD-CSTS-R2;

b)      CCSDS Candidate Monitored Data; 

c)      201204 Object Identifiers - Framework Annex C; and

d)      20120418 CCSDS Candidate Monitored Data OID Representation.

The first document, BaselineFunctionalResourcesForMD-CSTS-R2, is a
technical note that I last updated in 2010. It originated as a section
of the Monitored Data CSTS Service Specification, and was extracted as a
technical note when the CSTSWG decided to separate the service
specification and the abstract notion(s) of functional resources from
the identification of specific functional resources and their specific
monitored parameters. To my knowledge, this is still the most complete
treatment of the derivation of the functional resource concepts,
although it definitely needs to be updated. I will try to do that in the
coming month or so, but I will not have time to do so before 2 May.
However, something to be aware of while reading this technical note is
that it uses an earlier naming convention that has since been replaced
by the proposed OID approach - please ignore the material on how these
things will be named. 

Wolfgang used the Functional Resources technical note as input to his
spreadsheet CCSDS Candidate Monitored Data. This spreadsheet roughly
follows the functional resources (FRs) identified in (a), identifies the
monitored parameters for each of those FRs, and identifies which
agencies/networks report those parameters (based on the poll that
Wolfgang conducted). There are some differences in the functional
resources called out in (a) and (b). Some of the differences are
terminological: e.g., "uplink/downlink" vs. "forward/return" and "data
interface" vs. "symbol stream". Other differences are more substantive,
and point to the need to derive a definitive set of FRs. However, we do
not need the definitive list of specific functional resource types in
order for the CSTSWG to proceed with the Red-2 CSTS SF. 

The third document, the briefing 201204 Object Identifiers - Framework
Annex C, addresses overall use of OIDs in the CSTS SF. Of particular
interest here are slides 12 - 14, which address the published
identifiers branch of the ISO OID tree {iso   identified organization
(3)   standard producing organization (112)   ccsds (4)   csts (4)
published identifiers (3)}. According to the CSTS FW approach, all
published identifiers are organized first by functional resource type,
then by whether the identifier is a parameter (monitored or control),
event, or directive. The leaves of the various branches are the
parameter/event/directive identifiers themselves.

The fourth document, the spreadsheet 20120418 CCSDS Candidate Monitored
Data OID Representation, was generated by Yves to demonstrate how the
OIDs would be structured for the Antenna FR type and its associated
monitored parameters. In this example, he has assigned the Antenna FR
type the OID {published identifiers (1)}. 

I hope that these documents will be useful to you in preparing for our
discussion on 2 May.

Best regards,

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120501/a98192b2/attachment-0001.htm