[Css-csts] Mapping Functional Resource IDs to SM Service Packages

[John Pietras]

SMWG and CSTSWG colleagues ---

At the SMWG telecon on 2 May 2012, the WG (with participation from
Wolfgang Hell, Yves Doat, and Margherita di Giulio) outlined an approach
for integrating the use of functional resources into Space Communication
Cross Support Service Management (SCCS-SM). This technical note is an
attempt to flesh out that approach and expose questions and issues with
the approach (which are identified at the end of this note). These
issues do not appear to be unsolvable, but their solution does need some
further analysis and consensus.

 

Best regards,

John

 

 

BACKGROUND

The approach centers on the use of functional resources.  The concept of
functional resources was originally developed out of work done in the
CSTSWG to uniquely identify instances of monitored parameters and
notifiable events in the Monitored Data Cross Support Transfer Service
(MD-CSTS). Those same functional resources can also be used to uniquely
identify instances of reconfigurable parameters, such that they could be
used in a real-time Service Control CSTS. 

The name functional resource is derived from the functional group
concept that is defined in the Cross Support Reference Model, Part 1:
SLE Services (commonly known as the SLE Reference Model). Essentially,
the SLE-RM functional groups can now be thought of as comprising one or
more functional resources (this relationship becomes useful in naming
instances of SLE transfer services, which contain the functional group
ID as part of the service instance ID).

 

More recently, the SMWG has selected functional resources as the
conceptual building blocks that are managed via Next Generation Service
Management (NGSM). This approach not only provides a framework for
defining extension points in the NGSM architecture, but also unifies the
approach with that adopted for CSTSes.

 

FUNCTIONAL RESOUCES AND THE NAMING OF MONITORED PARAMETERS, NOTIFIABLE
EVENTS, AND RECONFIGURABLE PARAMETERS

To quickly recap the naming scheme: all monitored parameters, notifiable
events, and reconfigurable parameters are associated with specific
functional resource types, examples of which include space link
carriers, antennas, and RAF transfer services. 

 

NOTE - For the purposes of simplifying the descriptions in this
technical note, the naming scheme is described in terms of its
application to monitored parameters. It is equally applicable to
notifiable events and reconfigurable parameters.

 

Since it is possible to have more than one instance of the same
functional resource type operating concurrently during the execution of
a Service Package, multiple instances of the same monitored parameter
types may be available during the execution of that Service Package.
Supplying just the monitored parameter type (e.g., carrier lock stats)
is insufficient to identify which carrier lock status is being reported
if (for example) both S-band and X-band return links are operating
concurrently. Therefore, each instance of a given monitored parameter
type is uniquely named by qualifying the name of that parameter type
with the individual instance of the functional resource type with which
the monitored parameter is associated. The individual instance of a
functional resource type is formed as the pair of the functional
resource instance type with an instance Number: 

        Functional Resource ID (FR ID)= [Functional Resource Type :
Instance Number]

The functional resource type is an Object Identifier (OID) that is
registered with SANA and the instance identifier is an integer.

 

The fully-qualified monitored parameter name is formed by pairing the FR
ID with the monitored parameter type: 

        Parameter Name = [FR ID : Monitored Parameter Type]

The Functional Resource ID is formed as defined above, and the Monitored
Parameter Type is an OID that is registered with SANA.

 

 

IDENTIFYING FUNCTIONAL RESOURCE INSTANCES IN SERVICE MANAGEMENT

Two fundamental questions are: ( 1) how are the  FR Instance Numbers
assigned and (2) how are they FR IDs known to the user, such that, for
example, the user knows that [FR Type = <space link return carrier OID>
: Instance Number = 5] is the FR ID of the return space link carrier
configured for S-band?

 

The approach that has been selected is to have the Instance Numbers
assigned by Service Management and returned as parameters of the
appropriate component objects (data sets) of the Service Package Result.


 

 

RETURN SPACE LINK CARRIER EXAMPLE

The example that was discussed during the telecon was that of a return
space link carrier. Fleshing out this example,  UM invokes the Create
Service Package operation to create a Service Package with two return
space link carriers, using carrierProfileIds "S-band" and "X-band",
respectively. Since "return space link carrier" is an FR type, UM
assigns an instance number to each return space link carrier that it
schedules. Conveniently, the ServicePackageResult data set contains an
explicit CarrierResult data set for each space link carrier in the
Service Package. Adding an frInstanceNumber parameter to the
ReturnCarrierResult* data set would allow the identification to be
complete. In this example, one ReturnCarrierResult would return
carrierProfileRef = "S-band", fFrInstanceNumber = 1, and the other
ReturnCarrierResult would return with carrierProfileRef = "X-band",
frInstanceNumber = 2.

 

When the Service Package executes and the MD-CSTS service begins to send
monitored parameters, the MD-CSTS user knows that parameter names with
FR ID [FR Type = <return space link carrier OID> : Instance Number = 1]
refers to the S-band link, and parameter names with FR ID [FR Type =
<return space link carrier OID> : Instance Number = 2] refers to the
X-band link.

 

[*NOTE - In SCCS-SM B-1, a CarrierResult object (data set) is returned
and the forward/return nature of the carrier must be inferred from the
carrierProfileRef parameter value. I propose that in NGSM we subtype the
CarrierResult object class based on link direction, so that the
relationship to FR Type is explicit. Having this relationship be
explicit removes the need to also carry the FR Type in the component
objects of the ServicePackageResult.]

 

 

ISSUES WITH THIS APPROACH

This approach works perfectly well for space link carriers because the
F|RCarrierResult carries both a carrierProfileRef that identifies the
exact configuration (e.g., the frequency - and therefore the frequency
band - of the link) as well as frInstanceNumber, allowing (in the above
example) the S-band link to be identified by Instance Number 1 and the
X-band link to be identified by Instance Number 2.

 

There are issues, however, with using this approach with
lower-level/contained FRs that may have multiple instances of the same
type. 

 

Consider the subcarrier. If a carrier can have at most one subcarrier
(as currently specified in CCSDS 401) then there is no problem, because
the instance number of the subcarrier can simply be the same as that of
its carrier. But if we open NGSM to the more-general case of possibly
multiple subcarriers, something will have to be done to allow the
specific subcarriers to be mapped to instance numbers. There are
probably many ways to do this: one that comes to mind is to have the
F|RCarrierResult contain a set of SubcarrierResult objects, each of
which contains a frequency parameter and an frInstanceNumber parameter.

 

Now consider the FR that Wolfgang calls the Data Interface FR and that
maps into the SM call the Symbol Stream. In the case of QPSK modulation,
the possibility of separate data streams on the I & Q channels exists.
In such cases, they will have to have separate instance numbers. Again
there may be multiple ways to handle this, but using the approach
described above for multiple subcarriers, the F|RCarrierResult and
SubcarrierResult objects could contain a SymbolStream (DataInterface)
object for each stream associated with that carrier/subcarrier, each of
which contains a channel parameter ('I', 'Q', or 'single' (for BPSK of
interleaved I & Q)).

 

One might be tempted to think the same multiplicity problems would apply
to SLE transfer service instances, but in fact I believe that we already
have the differentiation built into the instance identifiers that are
already defined for SLE transfer services and accommodated even in SM
Blue-1. I'll have to confirm that it still holds water through the
more-detailed use case analysis that I plan to do this month, but at
this point my assumption is that it will not be a problem.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120504/feb047a9/attachment.html