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

[Anthony Crowson]

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/619a4d91/attachment-0001.htm