[Css-csts] RE: What if there is no CLCW VC for F-CLTU? - REVISED

[John Pietras]

Wolfgang,

In my note below, I had proposed that when there is no return virtual
channel carrying CLCWs related to the EF-CLTU service instance, the [0,
0, NULL] GVCID value be used for the clcw-global-VCID parameter value.

 

On further consideration, I have decided to propose instead that the
VCID component of the clcw-global-VCID parameter be set to 63, the Only
Idle Data VC. Since this VC cannot be configured to actually carry data,
it's use in the clcw-global-VCID parameter is unambiguous. 

 

I continue to believe that the best approach would be to allow the
clcw-global-VCID and clcw-physical-channel parameters to assume truly
null values when they in fact do not exist, but because I am trying to
keep the EF-CLTU ASN.1 backward compatible with the F-CLTU ASN.1 I
cannot insert CHOICEs because the resulting tags would eliminate the
compatibility. Rather, I will stick with values that are valid for the
type ("none" and VCID = 63, respectively). 

 

Best regards,

John

 

From: John Pietras 
Sent: Monday, June 04, 2012 4:46 PM
To: Wolfgang.Hell at esa.int
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org)
Subject: What if there is no CLCW VC for F-CLTU?

 

Wolfgang,

I think that I've stumbled onto another minor problem with the F-CLTU
Blue Book. It appears that there is no option to completely avoid having
to specify a physical channel and global VCID for a channel carrying
CLCWs related to the forward link being served by the F-CLTU service
instance. There *is* the option to ignore the No RF Availability and No
Bit Lock CLCW flags when determining production-status,  but Table 3-1
specifies clcw-physical-channel and clcw-global-VCID as Service
Management parameters, and 3.11 (CLTU-GET-PARAMETER) identifies them as
gettable parameters. Their appearance in table 3-1 is not troublesome in
itself, because that does not mandate any required values or syntax.
However, the ASN.1, clcwPhysicalChannel value is specified to be of type
VisibleString (SIZE (1..32)) and clcwGlobalVcid value is defined to be
of type Gvcid. 

 

What values should these parameters take on when there is no return link
VC containing CLCWs for the forward link? In general, it cannot always
be assumed that COP will be operating, because F-CLTU allows arbitrary
block of octets to be transmitted as "CLTUs". In the case of EF-CLTU
operating in AOS frame or AOS CADU mode, it is known that COP will not
be operating and that there will be no CLCWs reported for the forward
link.

 

As a workaround for the EF-CLTU Orange Book, I am planning to put in the
following requirements: 

1.       When there is no CLCW-bearing return VC, clcw-physical-channel
shall equal "none" and clcw-global-VCID shall be set to [0, 0, NULL].

2.       When the service instance is transferring AOS frames or CADUs,
clcw-physical-channel shall equal "none" and clcw-global-VCID shall be
set to [0, 0, NULL].

3.       When CLTU-GET-PARAMETER retrieves a value for clcw-global-VCID
of [0, 0, NULL], the value must be interpreted in the context of the
value of clcw-physical-channel value to determine if it represents a
valid GVCID or the absence of a CLCW-bearing virtual channel.

 

I realize that you are very busy and may not have time to respond to
this, but if you (or anyone else reading this message) do have time to
offer a few quick thoughts I would very much appreciate it. In the
meantime, I will proceed to put those restrictions into the EF-CLTU
Orange Book.

 

Best regards,

John

 

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