[Css-csts] Monitored Data CSTS may not be able to directly adopt Framwwork procedures

[John Pietras]

CSTSWG colleagues ---

Yesterday I sent you an email listing some additional review comments on
the CSTS Framework (CSTSFW) R-0.19 version. As I mentioned in that note,
those comments were the result of my re-looking at the CSTSFW in the
context of the monitored data CSTS (MD-CSTS). Those comments were
general to the CSTSFW.

 

In addition to those general comments, I have additional comments that
are specific to its use in the MD-CSTS). In summary, I don't think that
it is possible to build the MD-CSTS through direct adoption of CSTS
procedures as they are currently defined. I've come up with a
refinement-based approach that I plan to use in defining the MD-CSTS,
which I will describe shortly in this note. I've also identified an even
better approach, which would involve a minor modification to the CSTSFW.
I will describe this modification at the end of this note.

 

Before describing the refinements that I plan to use in the MD-CSTS
specification, let me summarize the facts that lead to such a refinement
being necessary: 

 

A. Information Query and Cyclic Report procedures

-        As currently defined, the Information Query and Cyclic Report
procedures both work on the model in which (a) the user subscribes to a
specific list of parameters and (b) the procedure generates a value for
each of the subscribed parameters. The parameter values are of simple
types (e.g., integer, real, character string). For reach parameter named
in the list, the provider returns the value of the named parameter,
reports that the parameter is not currently available, or reports that
the current value is invalid.

 

-        For the Monitored Data service, the user will subscribe to
specific sets of parameters for the Cyclic Report and Information Query
procedures, but those parameter names are really type (or group) names:
each represents a collection of parameter values. For example, the
subscribed parameter name may be "rcvrSignalStrength", but if two
receivers are active at the time (e.g., X- and S-band), _two_ values
will be returned, one for each receiver. This violates the one-to-one
model that is inherent in the Framework.

 

B. Notification procedure

-        In the current CSTSFW Notification procedure, the user
subscribes to a specific list of events and the procedure generates an
event notification whenever one of those subscribed events occurs.

 

-        For the Notification procedure of the MD-CSTS, the user will
also subscribe to a specific list of events and the procedure will still
generate an event notification whenever one of those subscribed events
occurs. However, those names will be different: in the START operation,
the names will be type or group names, whereas the event notifications
will have to use the names of the specific events. For example, the user
may subscribe to the 'carrier modulation unlocked' notification, but
would receive event notifications whose parameter names also identify
the specific carrier, e.g., "S-Band:carrier modulation unlocked"

 

I have considered several schemes for deriving Information Query, Cyclic
Report, and Notification procedures to accommodate these differences.
The one that I have settled on (at least until someone suggests
something better) is a refinement approach. The other approaches that I
considered all required modification of the behaviors of the procedures
which could "break" standard library code written for those CSTSFW
procedures. The refinement approach does not affect the behavior of the
procedures, only how the contents of certain parameters are to be
populated and parsed.

 

The core of the refinement is as follows:

For the monitored parameters accessed via the Information Query and
Cyclic Report procedures, the names of the parameters in the
list-of-parameters parameters are to be interpreted as set names, e.g.,
the name "rcvrSignalStrength" is interpreted to be the name of the set
of receiver strength values for all active functional resources that
have a rcvrSignalStrength monitored parameter. The components of the
qualified-parameters parameter are all to be of type character string,
and the MD-CSTS will refine those character-string-types parameters to
be sets of records of the form

               <functional resource identifier>:<parameter value>

 

Thus for the previous example, if the parameter ""rcvrSignalStrength" is
subscribed to (or requested in the GST invocation) when both the X-band
and S-band receivers are active, the corresponding component of the
qualified-parameters parameter might look like:

        

[parameter name = "rcvrSignalStrength", parameter type = octet string, 

parameter value = "S-Band:<character string representation of dBm
value>; X-Band:<character string representation of dBm value>",
qualifier = 'valid']

 

The specification of the refinement would have to define the syntax of
the character string (e.g., how the records of the set are separated,
how different data types are to be represented I the parameter value
field). We would probably pick an existing standard syntax (e.g., TLV,
XML) instead of creating a new one as I did for the above example. The
production specification section of the MD-CSTS would specify that the
values of the monitored parameters from the various functional resources
would be aggregated in this way and made available to the MD-CSTS
instances.

 

For the Notification procedure, the MD-CSTS specification would refine
the character-string-valued 'event value' component of the extension
value of the notification-type to be of the form:

 

        <functional resource identifier>:<resource event value>, where
the ":<resource event value>" component is 

               optional. 

 

For the example of the user subscribing to the 'carrier modulation
unlocked' notification, when the carrier unlocks on the S-Band link, the
resulting NOTIFY invocation contains the notification-type parameter
value

[event name = "'carrier modulation unlocked', event value = "S-Band"].
(Note that in this example the resource event value doesn't exist.)

 

(You may have noticed that this approach is different from the
distinguished name (or relative distinguished name) approach that I was
promoting earlier. Under that approach, the equivalent information for
the above receiver strength example would have been represented as two
separate components of the qualified-parameters parameter:

 

[parameter name = "S-Band:rcvrSignalStrength", parameter type = Integer,


parameter value = <Integer dBm value>, qualifier = 'valid']

 

and 

 

[parameter name = "X-Band:rcvrSignalStrength", parameter type = Integer,


parameter value = <Integer dBm value>, qualifier = 'valid']

 

Because this distinguished name approach generates two components in the
qualified-parameters parameter for the single name n the
list-of-parameters, it would have required redefinition of the behavior
of the Information Query and Cyclic Report procedures, and has therefore
been discarded.)

 

So this is the approach that I will be taking with the MD-CSTS
specification. However, if one change were to be made to the CSTSFW
specification, the refinement could be made even simpler. That change
would be to add a SetOfRecords type to the supported types, where each
record is has a record name and record value component, and the record
value can be of any of the types currently allowed for the
qualified-parameters type. In the ASN.1; the changes would look like:

 

TypeAndValue                  ::=   CHOICE

{     integer                 [0]   INTEGER

,     intUnsigned             [1]   IntUnsigned

,     duration                [2]   Duration

,     characterString         [3]   VisibleString

,     boolean                 [4]   BOOLEAN

,     octetString             [5]   OCTET STRING

,     float                   [6]   REAL

,     time                    [7]   IntUnsigned

,     setOfRecords            [8]   SetOfRecords   <-- new type

,     valueExtension          [100] Extended

}

 

SetOfRecords                  ::=   SEQUENCE OF

{     record name                   VisibleString

,     record value                  TypeAndValue

}

 

Having this structure available in the Framework would simplify the
refinement of the MD-CSTS. Of course, it may only be useful to the
MD-CSTS, and therefore putting it into the Framework might be
questionable. I will proceed on the assumption that the change will not
be made, but I will be able to incorporate the change if the WG decides
that it is a good thing to do.

 

I would be very happy to receive any comments on this from anyone who is
not already on vacation/holiday. Perhaps we can discuss it in our
telecon on 11 August.

 

Best regards,

John

 

 

John Pietras

GST, Inc. 

7855 Walker Drive, Suite 200

Greenbelt, MD 20770

240-542-1155

 

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