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

Tue May 8 16:14:32 EDT 2012

Anthony,

Off the top of my head, I agree that the handover situation might make
UM assignment of instance numbers problematic. In addition, I can think
of two more potential difficulties with that approach. That's not to say
that these problems are insurmountable if we decide that we like having
UM assign the instance numbers, but we will have to work through them.

The first (additional) difficulty that I see is the added burden to put
on UM to come up with the numbers that don't violate any of the rules
that will probably apply (e.g., uniqueness across all instance of the FR
type within the Service Package). The mirror side of this is that CM
will probably have to validate against these rules, leading to potential
rejections of Service Package Requests that are otherwise valid. 

The second "difficulty" is that more information will have to be exposed
in the Service Package Request in order for the instance numbers to be
properly associated with their instances. In SCCS-SM-B-1, we simply
reference the Space Communication Service Profile (SCSP), and that
inherently defines the structure of its component carriers, subcarriers,
symbol streams, etc. In order to allow UM to insert the appropriate
instance numbers, we would have to somehow expose these components in
the Request itself, which to some extent defeats the purpose of allowing
UM to simply refer to a Profile. 

Note that whether UM or CM assigns the instance numbers, we already face
the need to expose more of the internal structure of the scheduled
Carrier Result objects of the Service Package Result, as described in
the issues section of my previous message (included below). However, in
the case of the Service Package Result, we already have the notion of
(potentially) providing much more detailed configuration information in
response to a Service Package Request with respecifications or returned
by a Query Service Package operation, so the conceptual leap is less. 

Thinking about this again in the light of your proposal, I see the need
to identify the instances of subcomponents as a key challenge to
overcome, and it is something that I have been struggling with for
several years. At this point it might be useful to recap how we got here
- not to argue for returning to the previous approach, but to understand
it and how the current approach compares to/contrasts with it.

ISO approached this problem through the use of relative distinguished
names (RDNs)and distinguished names (DNs). Each "managed object" has
both an RDN and a DN: the RDN is the name of the instance of the object
itself, whereas the DN is the name of the instance of the object in its
containment relationship. The RDNs only have to be unique in the context
of the object within which they are immediately contained, so only the
DNs are globally unique. To use a functional resource (= managed object)
example, for the I-channel  symbol stream of the 5KHz subcarrier of the
S-Band return carrier, RDN  would be equivalent to (SymbolStream =  "I
channel") and the DN would be equivalent (ReturnSpaceLinkCarrier =
"S-Band 1", ReturnSubcarrier = 5000, SymbolStream = "I channel"). Note
that there can be multiple instances of a return I-channel symbol stream
in a service package, but only one I-channel for the 5000Hz of the
return carrier designated as "S-Band 1". 

One thing that appealed to me about this approach is that the values of
the RDNs can be assigned by naming attributes that may already exist in
the CarrierProfile. If that's the case, then CM (or UM) doesn't have to
assign them on a Service Package by Service Package basis. E.g., in the
above example, the RDN of the Subcarrier could be its frequency and the
RDN of the Symbol Stream could be its I, Q, or single/BPSK designation,
both of which are already present in the corresponding subparts of the
Carrier Profiles. A side effect of the ISO naming approach is that it
always explicitly reveals the containment of the FR instance:
(ReturnSpaceLinkCarrier = "S-Band 1", ReturnSubcarrier = 5000,
SymbolStream = "I channel") explicitly names an I-channel symbol stream
carried by a subcarrier, whereas (ReturnSpaceLinkCarrier = "S-Band 1",
SymbolStream = "I channel") explicitly identifies a symbol stream that
is modulated onto the carrier itself. 

My previous attempt at naming functional resources was based on the ISO
approach, although I used text names for the FR types instead of OIDs
(i.e., "ReturnSpaceLinkCarrier" instead of its equivalent OID). Frankly,
I don't think that I explained this approach very well, because I think
everyone except me was confused by it. Regardless of my ability to
explain the approach, the ISO approach admittedly leads to long FR IDs
in many cases.

Now let's compare the ISO approach to the one that are taking now in
CSS. The current approach effectively collapses all of the containment
into a single pair of FR type and instance number. E.g., [<Symbol Stream
type OID>:1] represents (ReturnSpaceLinkCarrier = "S-Band 1",
ReturnSubcarrier = 5000, SymbolStream - "I channel"). Since all of that
containment information is not carried in the instance number
(identifier) itself, it has to be somehow assigned to the instance
number associated with the FR "leaf" (in this case, the Symbol Stream FR
type). The approach that we are taking has the assignment of the
instances numbers for all FRs being made as part of the process of
creating the Service Package, by having either CM or UM making the
assignments. The containment that is inherent in the Service Package
itself is used to identify the containment of the FR that has the
instance number X, and thereafter any reference to the Xth instance of
that FR type (in the context of that Service Package) is known to apply
to the FR instance with that specific containment. 

Since Darmstadt, I have tried to come up with a scheme that would
somehow not require us to explicitly assign instance numbers to every FR
instance, but I don't think that's possible given the nature of the FR
ID as we have currently defined it. Of course, I gladly welcome any
thoughts on how we might accomplish this, or otherwise simplify the FR
instance number assignment task.

Best regards,

John.

From: Anthony Crowson [mailto:anthony.crowson at vega.de] 
Sent: Tuesday, May 08, 2012 3:43 AM
To: John Pietras; smwg at mailman.ccsds.org; css-csts at mailman.ccsds.org
Subject: RE: Mapping Functional Resource IDs to SM Service Packages

John,

It occurs to me that it may turn out to be simpler for UM to assign the
instance numbers in the request, rather than having to match them up
afterwards. The only thing that would obviously scupper that approach
would be if CM can provide more than one instance in response to a
single one requested - this would presumably happen if CM is allowed to
introduce handovers and split a session between two terminals. Any
thoughts?

Anthony

From: smwg-bounces at mailman.ccsds.org
<mailto:smwg-bounces at mailman.ccsds.org>
[mailto:smwg-bounces at mailman.ccsds.org]
<mailto:[mailto:smwg-bounces at mailman.ccsds.org]>  On Behalf Of John
Pietras
Sent: 04 May 2012 17:23
To: smwg at mailman.ccsds.org <mailto:smwg at mailman.ccsds.org> ;
css-csts at mailman.ccsds.org <mailto:css-csts at mailman.ccsds.org> 
Subject: [Smwg] Mapping Functional Resource IDs to SM Service Packages

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/20120508/da8e4d19/attachment-0001.htm