[Css-csts] uplink status effects on PLOPs

[John Pietras]

Wolfgang,

Some questions have arisen regarding the interactions and cross-effects
among uplink status, production status, and PLOP modes when the service
instance is configured to require confirmation of bit-lock and RF
availability. In looking at the Blue Book again, I think that there are
some ambiguities and even a few cases of incorrect statements. In any
case, the documentation of the interactions and cross-dependencies are
spread out across the book, making it difficult for readers to grasp the
whole story.

 

Let me try to walk through the processes and expose the questions that
come to my mind, first for PLOP-1 and then for PLOP-2.

 

PLOP-1:

1.       At the start of production, production-status is 'configured'
and the PLOP is in CMM-1.

2.       The uplink sweep is performed.

3.       If the service instance requires that RF availability be
confirmed, then the production process remains 'configured' until the
confirmation is received via the CLCW in the designated return VC, at
which point production-status transition to 'operational'. If the
service instance does not require RF availability to be confirmed, then
the production process transitions to 'operational' immediately after
completion of the uplink sweep. In either case, the PLOP remains in
CMM-1

NOTE 1 - The transition from 'configured' to 'operational' is
independent of the bit-lock status.

NOTE 2-   The description of PLOP-1 processing in 3.6.2.8.2 (a) (under
delay-time) omits mention of dependency on production-status, which in
turn might depend on RF availability.  

4.       Upon receipt of a CLTU-TRANSFER-DATA invocation, the PLOP
transitions to CMM-2 and the acquisition sequence begins to be
transmitted at the time determined by the combination of the
earliest-radiation-time for the CLTU and the times needed to transmit
the acquisition sequence and (if present) the leading idle sequence.

5.       If RF availability (as reported in the CLCW) is required and
the RF link becomes unavailable before the acquisition sequence begins
transmission: production-status transitions to 'interrupted',  a NOTIFY
is sent, the service instance is blocked (all subsequent
CLTU-TRANSFER-DATA invocations are rejected), and the CLTU buffer is
cleared (including the CLTU that triggered the beginning of the
acquisition sequence transmission).

NOTE  - When the service is blocked, STOP and subsequent START are
required before CLTU-TRANSFER-DATA invocations can be subsequently
accepted.

a.       Presumably the PLOP stays in CMM-1. 

b.      Does the notification-mode have any effect, or does it only
control when the notification is sent? I've always been confused about
the notification-mode. According to its definition in table 3-11, if the
value is 'deferred' the user is notified about the production-status
change "only if and when the radiation of a CLTU is affected." But if
the CLTU is cleared from the buffer as soon as the status transitions to
"interrupted" or "halted", there is no possibility to transmit that CLTU
even if the production-status changes, so why wait to notify the user?
>From various sections, I get the feeling that the real intent is not to
delay *notification* of transition to 'interrupted', but to actually
delay the transition itself  to 'interrupted' such that a CLTU might
still be radiated if production-status returns to 'operational' in time.
However, that interpretation is not supported by the state table.

c.       Is a new forward sweep (and confirmation of RF) required before
production-status transitions back to 'operational"?

d.      If the service instance is configured to require bit-lock
confirmation, is bit-lock confirmation required to transition from
'interrupted' to 'operational'? If so, how can that be achieved if the
PLOP is in CMM-1?

6.       If the link fails to satisfy the RF availability and bit lock
confirmation requirements before the acquisition sequence has completed
transmission: production-status transitions to 'interrupted', a NOTIFY
is sent, the service instance is blocked (all subsequent
CLTU-TRANSFER-DATA invocations are rejected), and the CLTU buffer is
cleared (including the CLTU that triggered the transition out of CMM-1).

a.       The uplink-status parameter (3.7.2.11 and 3.9.2.9.2 ) cannot
report that both the RF is unavailable and there is no bit lock in the
same report/notification. Is it to be inferred that if there is no RF
there will be no bit lock, so no RF is what is reported in tis case?
Should this be explicitly stated in a note?

b.      What happens to the PLOP? Does it fall back into CMM-1 or
complete CMM-4? Does it proceed to the optional idle sequence (CMM-4)?
What happens then (without a CLTU to transmit)? Does it go back to
CMM-1? 

c.       If the reason that the production-status transitioned to
'interrupted' was because of loss of RF, is a new forward sweep (and
confirmation of RF) required before production-status transitions back
to 'operational"?

d.      If the reason that the production-status transitioned to
'interrupted' was because of loss of bit-lock, how does
production-status transitions back to 'operational"? At the start, only
RF availability (at most) is required to transition from 'configured' to
'operational'. If only RF availability (at most) is required to
transition from 'interrupted' to 'operational' and that condition is
satisfied even though the bit-sync is lost, what's to keep it from
toggling immediately to 'operational' (and back to 'interrupted' if
bit-lock is still false, etc.)? Alternatively, if bit-lock confirmation
is required to transition from 'interrupted' to 'operational', how can
that be achieved if the PLOP is in CMM-1?

7.       Upon successful completion of CMM-2 (transmission of the
acquisition sequence), if an idle sequence is specified, it is then
transmitted (PLOP transitions to CMM-4).

8.       If the link fails to satisfy the RF availability and bit lock
confirmation requirements before the idle sequence has completed
transmission: production-status transitions to 'interrupted', a NOTIFY
is sent, the service instance is blocked (all subsequent
CLTU-TRANSFER-DATA invocations are rejected), and the CLTU buffer is
cleared (including the CLTU that triggered the transition out of CMM-1).

a.       Similar questions as for item 6.

9.       Upon successful completion of the idle sequence, the PLOP
begins to transmit the CLTU (CMM-3).

10.   If the link fails to satisfy the RF availability and bit lock
confirmation requirements before the CLTU has completed transmission:
production-status transitions to 'interrupted', a NOTIFY is sent, the
service instance is blocked (all subsequent CLTU-TRANSFER-DATA
invocations are rejected), and the CLTU buffer is cleared.

a.       Does transmission of the CLTU-in-progress cease? (Maybe it
doesn't matter).

b.      Similar questions as for item 6.

11.   Upon successful completion of transmission of the CLTU, if there
is an idle sequence, the PLOP begins transmission of that trailing idle
sequence (CMM-4). Otherrwise, the PLOP transitions to CMM-1.

12.   If the link fails to satisfy the RF availability and bit lock
confirmation requirements before the trailing idle sequence has
completed transmission: production-status transitions to 'interrupted',
a NOTIFY is sent, the service instance is blocked (all subsequent
CLTU-TRANSFER-DATA invocations are rejected), and the CLTU buffer is
cleared.

a.       Does the trailing idle sequence continue to be transmitted, or
does the PLOP go immediately to CMM-1? (Does it matter?)

b.      Similar questions as for 6 b & c.

13.   Upon transition to CMM-1, if bit lock availability is required,
what's to keep production-status from going to 'interrupted'?

 

My summary conclusion is that it seems to me to be a bad idea to allow
bit lock availability confirmation to be required to keep
production-status to 'operational' or return production-status to
'operational' when executing PLOP-1. Since the link becomes unmodulated
routinely in PLOP-1, that seems to guarantee that the production will
transition to 'interrupted' (and block, etc.), following every CLTU
transmission). 

 

PLOP-2:

1.       At the start of production, production-status is 'configured'
and the PLOP is in CMM-1.

2.       The uplink sweep is performed, followed immediately by the
transmission of the acquisition sequence ( CMM-2), followed immediately
by the transmission of the idle sequence (CMM-4).

3.       If the service instance requires that RF availability and/or
bit-lock to be confirmed, then the production process remains
'configured' until the confirmation of the required availability/lock is
received via the CLCW in the designated return VC, at which point
production-status transition to 'operational'. Otherwise, the
production-status transitions to 'operational' immediately following the
transmission of the acquisition sequence. Once the production-status
becomes 'operational', the service instance will accept
CLTU-TRANSFER-DATA invocations.

4.       If the link status (RF availability and bit-lock) fails to meet
the confirmation requirements for the service instance while the PLOP is
in either CMM-2 or CMM-4: production-status transitions to
'interrupted',  a NOTIFY is sent, the service instance is blocked (all
subsequent CLTU-TRANSFER-DATA invocations are rejected), and the CLTU
buffer is cleared (if there happen to be any CLTUs in the buffer
awaiting release).

NOTE  - When the service is blocked, STOP and subsequent START are
required before CLTU-TRANSFER-DATA invocations can be subsequently
accepted.

a.       Does the PLOP return to the beginning of CMM-2 upon transition
to the 'interrupted' production-status, or does it remain in CMM-4? (The
difference being that CMM-2 puts a defined number of bit transitions on
the link as a prerequisite to being declared operational. )  

b.       If the reason that the production-status transitioned to
'interrupted' was because of loss of RF, is a new forward sweep,
followed by an acquisition sequence, required before the
production-status can return to 'operational'?

5.       While the production-status is 'operational', when next CLTU in
the buffer becomes available for radiation or at the end of the
acquisition sequence transmission (whichever is later), the PLOP
transitions to CMM-3 and the CLTU begins to be transmitted.

NOTE -  The description of PLOP-2 processing in 3.6.2.8.2 (b) (under
delay-time) omits mention of dependency on production-status, which in
turn might depend on RF availability and/or bit-lock.

6.       If the link status to meet the confirmation requirements for
the service instance before the CLTU has completed transmission:
production-status transitions to 'interrupted',  a NOTIFY is sent, the
service instance is blocked (all subsequent CLTU-TRANSFER-DATA
invocations are rejected), and the CLTU buffer is cleared.

a.       Does transmission of the CLTU-in-progress cease? (Maybe it
doesn't matter).

b.      Does the PLOP return to the beginning of CMM-2 upon transition
to the 'interrupted' production-status, or does it go to CMM-4? (The
difference being that CMM-2 puts a defined number of bit transitions on
the link as a prerequisite to being declared operational. )

c.       Same as question 4 b. 

7.       Upon successful completion of transmission of the CLTU, the
PLOP transmits the idle sequence (CMM-4).

8.       If the link fails to satisfy the RF availability and bit lock
confirmation requirements before the next CLTU begins transmission (i.e.
while the PLOP is in CMM-2): production-status transitions to
'interrupted', a NOTIFY is sent, the service instance is blocked (all
subsequent CLTU-TRANSFER-DATA invocations are rejected), and the CLTU
buffer is cleared.

a.       Similar questions as for 4 a & b.

9.       While the production-status is 'operational', when the (1) the
expiration of the delay-time (if any) of the previous CLTU occurs or (2)
the next CLTU in the buffer becomes available for transmission
(whichever is later), the PLOP transitions to CMM-3 and the next CLTU in
the buffer begins to be transmitted.

10.   Steps 6 through 9 are repeated until the end of the communications
session, at which time the PLOP transitions back to CMM-1.

a.       There doesn't appear to be any constraint that forces the end
of the communications session to occur at or after the end of the
service instance provision period. What should the value of the
production-status be after the end if the communications session
(halted?)

 

 

Some related bits and pieces:

1.       The 'operational' value for production-status is defined in
3.7.2.10 and `3.9.2.8 as "the production process has been configured for
support, has completed the acquisition sequence, and is capable of
radiating CLTUs." This definition applies to PLOP-2, but not to PLOP-1
(where the prerequisite is completion of uplink sweep but not acq
sequence). Note too that there is no qualification related to RF
availability confirmation.

2.       3.6.2.7.4 states "If latest-radiation-time is specified, i.e.,
it is not 'null', the provider shall defer processing of a CLTU if the
current production-status value is 'interrupted'.  Processing shall be
deferred until either recovery from a temporary problem is accomplished,
i.e., the production-status value changes to 'operational' before
latest-radiation-time expires, or latest-radiation-time expires, in
which case the provider shall discard the CLTU". This is not supported
by the state table, which states that when the 'production interrupted'
event occurs, the CLTU buffer is to be cleared. 

 

Best regards,

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120523/54d10e58/attachment-0001.html