NEWPTRs, NSEs and PSEs at same rate

Question

Some of our 7200 VXR routers, connected to the same type of SDH-ADMs by OC3 POS-adapters, continously count NEWPTR events at (almost) the same rate as NSEs and PSEs:
sh contr pos4/0
POS4/0
SECTION
LOF = 0 LOS = 0 BIP(B1) = 0
LINE
AIS = 0 RDI = 0 FEBE = 0 BIP(B2) = 0
PATH
AIS = 0 RDI = 0 FEBE = 0 BIP(B3) = 0
PLM = 0 UNEQ = 0
LOP = 0 NEWPTR = 23643175 PSE = 23643174 NSE = 23643175
Does anyone know what could cause this?
My assumption is that these routers see concatenation indicators - although i don't know where they come from.
The only explanation i have is that they are generated in our providers SDH/Sonet ring (by concatenting VCs for diagnosis purposes etc.).
Is there a possibility to get a dump of a SDH frame from the router CLI in order to inspect the overheads?

Answer 1

NSE/PSE (Negative/Positive Stuff Events) indicate that at some point along
the path, the payload on the STS3c was shifted to adjust for a timing
differences on the lower speed (OC-3) tributary and the higher-speed
(OC12-192) path. A NSE occurs when the incoming bitrate on the tributary is
too high for the read clock (the clock that reads data from an inbound
tributary to place the bitstream on the higher speed path) to process the
previous byte before the write clock fills the write buffer with the inbound
stream. Thus, it stuffs last byte received into a reserved position in the
LOH for negative stuffs, and adjusts the pointer values to reflect the the
change in position of the beginning of the SPE. The opposite is true if the
data is coming in to slow. It inserts dummy bits into the higher stream to
account for the "missing" bits because the inbound stream was too slow. To
summarize:
1) The LOH for each STS-3c contains two bytes (H1 & H2) that define the
location of the beginning of the SPE (the payload and the path overhead).
The first 4 bits in H1 are the New Data Flag bits and are used to detect a
malformed pointer value or an invalid pointer operation. Bits 5 and 6 are
reserved and set to 0. Bits 7-15 define the pointer value, which is any
number between 0 and 782. Note that the for concatenated signals, the
pointer vlaue is multiplied by the number of STS-1s concatenated (IE STS-3c,
12c, 48c, 192c, etc). This allows for 10 bit pointer values to be able to
address thousands of byte positions in the SONET frame. Finally, 5 bits of
the 10 are defined as decrement bits, and 5 as increment bits, in an
alternating fashion as such:
IDIDIDIDID
Under nominal operation, the payload (SPE) is somewhere offset from the
end of the LOH. The number of bytes offset from the H3 byte is the pointer
value.
If the incoming rate is too slow, n dummy bytes must be stuffed into the
STS-3n. In your case, it is an STS-3c and thus, three dummy bytes are
stuffed following the last of the three H3 bytes in the LOH. Remember,
STS-3c operates just like STS1 except times everything by three. As such,
the LTE inverts the I bits from their previous value to indicate a positive
stuff shall occur in the next frame. Then, the new pointer value is sent,
incremented by one. No change in this value can occur for the next three
frame. Any such change is regarded as a pointer violation and an LOP
condition is set.
If the rate comes in to the multiplexing equipment too fast, 3 bytes from
the STS-3c must be stuffed into the three H3 bytes in the LOH, and the
pointer value must be decremented by one. But first, the D bits are
inverted to indicate a negative stuff event is occurring. Then, the pointer
is adjusted, the D bits inverted back (inversion meands flip from 0 to 1 and
vice versa), and the pointer vlaue is decremented. Again, no change may
occur for three consecutive frames.
Finally, if there is any reason for the pointer value to change other
than for positive or negative stuff, the new pointer must be sent with the
NDF bits set to 1001. Again, this value cannot change for three consecutive
frames.
What you are seeing is a timing problem. If the routers are back-to-back,
set the clock source to internal on both of them. This sounds odd, but
there is a problem in the POS chipsets on PA-POS-OC3 cards such that this is
the only stable method. If they are through and ADM, check that your
carrier has the circuit optioned properly