Tejas Networks: SDH Alarms

Tejas Networks
SDH Alarms
© Tejas Networks India Ltd., 2007, Proprietary Information Rev1.2 Last update 12 Dec 07 Reviewed by:
Organisation of Slides
 SDH section hierarchy
 SDH objects, nomenclature
 Downstream and Upstream
 Alarms understanding rules
 RS alarms
 MS alarms
 HP / LP alarms
 Description of Alarms
 Alarm Masking and Suppressed Secondary Alarms
 Alarm propagation examples

SDH Section Hierarchy
 There are four sections – Regenerator Section (RS), Multiplex Section (MS), Higher
Order Path Section (HP), and Lower Order Path Section (LP)
 RS is a part (section) of the optical fibre network, within which RSOH part of SDH frame
is NOT opened
 MS is a part (section) of the optical fibre network, within which MSOH part of SDH frame
is NOT opened
 HP is a part (section) of the optical fibre network, within which higher order VC part of
SDH frame is NOT opened (it may be opened only for interpreting HOPOH)
 LP is a part (section) of the optical fibre network, within which lower order VC part of
SDH frame is NOT opened (it may be opened only for interpreting LOPOH)
SDH Section Hierarchy (…contd.)
 Points to Remember:
 Without opening RS, one can not do operation with MS and/or open MS
 Without opening MS, one can not do operation with HP and/or open HP
 Without opening HP, one can not do operation with LP and/or open LP
Consequences
• So, for Tejas nodes, even if one is making a VC4 level pass-through (an operation with HP
without opening it), he/she is opening MS & therefore terminating the MS
• One can change any HPOH field (e.g., J1 transmitted trace) only when one is opening HP (e.g., VC12
level cross-connect exists on AU4 mapping), but not when HP is not disturbed (e.g., VC4 level
pass-through on AU4 mapping)
 Points to Remember:
 For Tejas nodes, for AU4 mapping, one can make VC4 and VC12/VC11 level and not VC3 level
pass-through for E1/DS1 traffic
Consequences
• If in a STM-1 node, multiple (say, 18) E1/DS1 traffic have to be passed-through with some other traffic
added/dropped from that node, one has to make multiple (18) VC12 level pass-through
Section Hierarchy (examples)
 Example 1
RS RS
Reg.
ADM 1 ADM 2
MS
 Example 2
RS RS
(VC4)
ADM 1 ADM 2 ADM 3
(STM 1)
MS MS
Section Hierarchy (examples) (… contd.)
 Example 3 (for AU4 mapping only)
RS RS RS
MS MS MS
VC12 VC4 VC12 VC12

A B C D
E1 E1
HP HP
LP
 Example 4a (for STM1 capacity & AU4 mapping only) #1 E1 – between A & E
F #2 E1 – between F & H
E3 E1 E3 – between F & G
12
VC
V
C
3
RS – A-B, B-C, C-D, D-E, F-B, C-G, E-H

MS – A-B, B-C, C-E, F-B, C-G, E-H
C Reg. E
E1
VC12 VC12
A B D
E1
HP – A-B, B-C, C-E
LP – A-E
V
HP – F-B, B-C, C-E, E-H
12
C
E3 E1
3
VC
LP – F-H
G H
HP – F-B, B-C, C-G
LP – F-G
 Example 4b (for STM4 capacity & AU4 mapping only) #1 E1 – between A & E
F #2 E1 – between F & H
E3 E1 E3 – between F & G
12
VC
V
C
RS – A-B, B-C, C-D, D-E, F-B, C-G, E-H

3
----- VC 4
MS – A-B, B-C, C-E, F-B, C-G, E-H
Within STM # 1
STM # 1
C Reg. E
E1
VC12 VC12
A B D STM # 1
E1 STM # 2 STM # 2
HP – A-E
LP – A-E
V
HP – F-C, C-H
12
C
E3 E1
3
VC
LP – F-H
G H
HP – F-C, C-G
LP – F-G
SDH objects, nomenclature
 3 different kinds of objects:

• STM port (STM-1 / STM-4 / STM-16)
• AU (AU-3 / AU-4 / AU-4-4c / AU-4-16c) – Higher-order object
(present even if no HO cross-connect)
• TU (TU-11 / TU-12 / TU-2 / TU-3) – Lower-order object
(present only if LO cross-connect exists)
 Nomenclature
• STM-1 chassis – slot – port (these fields are product specific)
• AU-4 chassis – slot – port – STM # – 1
• AU-3 chassis – slot – port – STM # – K (for AU-3 mapping)
• TU-3 chassis – slot – port – STM # – K (for AU-4 mapping)
• TU-2 chassis – slot – port – STM # –K–L
• TU-12 chassis – slot – port – STM # – K – L – M (M = 1 to 3)
• TU-11 chassis – slot – port – STM # – K – L – M (M = 1 to 4)
Note: STM # = 1 (for STM-1)

= 1 to 4 (for STM-4) like that, K = 1 to 3, L = 1 to 7
Downstream & Upstream
 Downstream direction for a fault condition

Along the direction of fault condition received
OR Towards the Back-plane of the node receiving fault condition
 Upstream direction for a fault condition

Opposite of the direction of fault condition received
OR Away from the Back-plane of the node receiving fault condition
 Downstream & Upstream direction for a node not fixed

Depends on direction of fault condition (abbreviated as FC)
Downstream
Upstream
FC 1
FC 2
ADM 1 Downstream
Upstream ADM 2 ADM 3
Alarm Understanding Rules
Rule 1
Alarms reported are alarms received

Alarm reported
FC 1
ex. a
ADM 1 ADM 2
Alarm reported
FC 1
ex. b
ADM 1 ADM 2
Rule 2
Alarms are reported on SDH Objects

Alarm Understanding Rules (…contd.)
Rule 3
3a. No Object => No Alarms reported

NO TU12
ex. (1-1-1)
FC on TU12 (1-1-1) Note:
ADM 1 ADM 2 These two
NO Alarm reported for examples are
FC on TU12 (1-1-1)
not possible
3b. Object Mismatch => No Alarms reported for AU object
WHY?
TU11
ex. (1-1-1) See slide 9
FC on TU12 (1-1-1)
ADM 1 ADM 2
NO Alarm reported for
FC on TU12 (1-1-1)
Rule 4
4a. No PT XC => No Alarms pass-through
NO VC4
ex. a
PT (1)
FC on AU4 (1)
ADM 1 NO Alarm pass-through ADM 2 ADM 3

Alarm reported for
FC on AU4 (1)
NO VC12
ex. b
PT (1-1-1)
FC on TU12 (1-1-1)
ADM 1 NO Alarm pass-through ADM 2 ADM 3

NO Alarm reported for
FC on TU12 (1-1-1)
4b. Bigger PT XC => No Alarms reported & Alarm pass-through
STM-1
ex. a VC4
links
FC on TU12 (1-1-1)
ADM 1 Alarm pass-through for ADM 2 ADM 3

NO Alarm reported
FC on TU12 (1-1-1)
for FC on TU12 (1-1-1)
4c. Smaller PT XC => No Alarms reported (always ??) &

Alarm pass-through but on smaller object
STM-1
ex. b VC12
links
(1-1-1) FC on TU3 (1)
ADM 1 Alarm pass-through for ADM 2 ADM 3

NO Alarm reported
FC on TU12 (1-1-1)
for FC on TU3 (1)
What if Same size PT XC ?
RS Alarms
RS alarms are those, which can be reported even by a pure Regenerator

(who has privilege of opening (interpreting & rewriting) only RSOH)
LOS (Loss of Signal) RSOH bytes

based on whole RSOH
LOF (Loss of Frame)

A1 A2 J0
based on A1, A2 bytes
B1 E1 F1
TIM (Trace Identifier Mismatch)
based on J0 byte D1 D2 D3
SF (Signal Fail)
based on B1 byte
SD (Signal Degrade) Note: The order in which the alarms are written is important,
based on B1 byte as we will see later while discussing Alarm masking
MS Alarms
MS alarms are those, which can be reported by a Add-Drop Multiplexer, irrespective of

cross-connect configuration
(who has privilege of opening (interpreting & rewriting) RSOH, MSOH, AU pointers plus
opening HOPOH(s) / TU Pointers / LOPOH(s) depending upon cross-connect configuration)
MSOH bytes
AIS (Alarm Indication Signal)
reported based on K2 byte -- bits 6,7,8
B2 K1 K2
SF (Signal Fail)
based on B2 bytes D4 D5 D6
SD (Signal Degrade) D7 D8 D9
based on B2 bytes
D10 D11 D12
RDI (Remote Defect Indication)
based on K2 byte -- bits 6,7,8 S1 M1 E2
Note 1: The order in which the alarms are written is important, we will see later while discussing Alarm masking
Note 2: MS-AIS is also called Line-AIS or AIS on STM port
MS-RDI is also called Line-RDI or RDI on STM port
HP / LP Alarms
HP / LP alarms are those, which can be reported by a Add-Drop Multiplexer, having

HO / HO & LO object (LO object => LO cross-connect)
(who has privilege of “opening (interpreting & rewriting) RSOH, MSOH, AU Pointers plus at
least interpreting HOPOH(s)” / “opening (interpreting & rewriting) RSOH, MSOH, AU
Pointers, HOPOH(s), TU Pointers plus at least interpreting LOPOH(s)”
depending upon cross-connect configuration)
J1
H
HP-AIS reported based on H1, H2 bytes
H1, H2, H3 – AU B3 O
Pointer bytes HP-LOP (Loss of Pointer) based on H1, H2 bytes C2 P
O
Note 1: Same as before HP-UNEQ (unequipped) based on C2 byte G1 H
Note 2: HP-Alarm is also
HP-TIM based on J1 byte F2 b
called AU-Alarm y
or Alarm on AU HP-SF based on B3 byte H4 t
e
LP-Alarm is also HP-SD based on B3 byte F3 s
called TU-Alarm
HP-RDI based on G1 byte -- bit 5
K3
or Alarm on TU N1
HP / LP Alarms (…contd.)
Note 1: Same as before

LP-AIS reported based on V1, V2 bytes
Note 2: Whole of this slide assumes
LP-LOP based on V1, V2 bytes TU2/TU12/TU11 for LP. If there
is TU3 with AU4 mapping, then
LOM (Loss of Multiframe) based on H4 byte – bits 7,8
also it is LP but Pointers & POH
HP-PLM / SLM (Payload / Signal Label Mismatch) bytes will be like HO
based on C2 byte
LP-UNEQ based on V5 byte – bits 5,6,7
LOPOH bytes LP-TIM based on J2 byte
V5 LP-SF based on V5 byte – bits 1,2

V1, V2, V3 – TU
Pointer bytes J2 LP-SD based on V5 byte – bits 1,2
N2 LP-RDI based on V5 byte -- bit 8
K4 LP-PLM / SLM based on V5 byte – bits 5,6,7
Description of Alarms
LOS
Received power is less than Laser receiver sensitivity (All bits interpreted as ‘0’)
Tx off / misconnectivity Rx off / misconnectivity LOS
Fiber Cut
Tx Rx
ex.
Rx Tx
Received power is less than
Laser receiver sensitivity
ADM 1 (Low power transmitted, Span is longer than ADM 2
specified, Fiber gets deformed etc. etc.)
LOS clears when 2 consecutive framing patterns are received & no new LOS condition is detected
LOF
Anything other than “F6 28 (Hex)” in any (?) of the A1 A2 bytes (within a STM frame)
-- for consecutive 5 frames (625 µs)  OOF (Out of Frame)  clearing 2 frames
-- for consecutive 24 frames (3 ms)  LOF  clearing 24 frames
Note: Prolonged LOS => LOF, but not always LOF => LOS
(this fact will be used as one of the Alarm Masking logic later)
Description of Alarms (…contd.)
TIM (J0)
Received J0 trace (1/16 byte(s)) != Expected J0 trace (1/16 byte(s))
Exp trace = A to B
P1 Rx trace = C to B
Tx trace = A to B P2
A Exp trace = C to B B Tx trace = C to B C

Rx trace = A to B
SF (B1/B2/B3/V5)
3 4 5
Equivalent BER exceeds alarm generation threshold ( 1 in 10 / 1 in 10 / 1 in 10 )
SD (B1/B2/B3/V5)
5 9
Equivalent BER exceeds alarm generation threshold ( 1 in 10 to 1 in 10 )
Note: For both SF & SD, alarm clearing threshold is 1 decade lower than generation
threshold, e.g., Gen. Thr. is 1 in 1000 or higher => Clg. Thr. is 1 in 10000 or lower
Generation of AIS & RDI

 Upon Receiving traffic affecting RS alarm, a Reg.
generates AIS towards downstream side

(all ‘1’ in whole STM frame)
 Upon Receiving traffic affecting RS alarm, a ADM
generates MS-AIS towards downstream side

(all ‘1’ in whole STM frame minus RSOH)
& generates MS-RDI towards upstream side
(in K2 byte b6 -- b8 set as ‘110’)
 Upon Receiving traffic affecting HP alarm, a ADM
generates AU-AIS towards downstream side

(all ‘1’ in whole AU)
& generates HP-RDI towards upstream side
(in G1 byte b5 set as ‘1’)
 Upon Receiving traffic affecting LP alarm, a ADM
generates TU-AIS towards downstream side

(all ‘1’ in whole TU)
& generates LP-RDI towards upstream side
(in G1 byte b5 set as ‘1’ for TU3 || in V5 byte b8 set as ‘1’ for TU2/12/11)
Reception of AIS & RDI (condition should persist for consecutive 3 to 5 frames)
 Bytes and bits involved in Reception for RDIs remain unchanged
 Reception for MS-AIS  in K2 byte b6 -- b8 received as ‘111’
for AU-AIS  All ‘1’ in H1, H2 bytes (for TU3 AIS also)
for TU-AIS  All ‘1’ in V1, V2 bytes (TU2/12/11)
Note: 1) For generating MS-AIS / AU-AIS / TU-AIS, the ADM need not be a term. equip. for MS / HP / LP
2) Upon receiving MS-AIS / AU-AIS / TU-AIS also, the ADM generates MS-AIS / AU-AIS / TU-AIS
towards downstream & generates MS-RDI/HP-RDI/LP-RDI towards upstream
3) Some alarms are by default traffic affecting or non traffic affecting, whereas
some alarms can be made traffic affecting by user action
Example of generation of AIS, RDI

MS-AIS (Gen)
AU-AIS
TU-AIS (Gen)
Any traffic affecting LP
RS Alarm
HP Alarm or
or TU-AIS
MS-AIS
AU-AIS (Rx)
(Rx)
ADM
MS-RDI
HP-RDI
LP-RDI
Example of reception of TU-AIS, LP-RDI

TU-AIS (Rx)
Any traffic affecting RS/HP/LP Alarm
VC12 VC12 VC12

E1 E1
ADM 1 ADM 2 ADM 3
LP-RDI (Rx)
AU/TU-LOP (AU-LOP is not reported in Tejas nodes, as always valid AU pointer values are sent)
8/9/10 consecutive invalid AU/TU pointers received or
8/9/10 consecutive NDF (New Data Flag) received (other than in a concatenation indicator)
(cleared when 3 equal valid pointers received) AU-LOP
Ex.
VC4 VC4
E4 E4
ADM 1 ADM 2 ADM 3
AU-LOP
TU-LOP
Ex.
VC12 VC12
E1 E1
ADM 1 ADM 2 ADM 3
TU-LOP
HP/LP-UNEQ
All ‘0’ in C2 byte for at least 5 frames (for AU4/AU3/TU3)
‘000’ in V5 byte, bits 5,6,7 for at least 5 multi-frames (for TU2/12/11)
AU Sig. Label  UNEQuipped HP-UNEQ

ex.
AU has AU has
no XC no XC
UNEQuipped  AU Sig. Label

ADM 1 HP-UNEQ ADM 2
AU Sig. Label  TUG-structured
AU has
ex. VC12
no XC
E1
ADM 1 HP-UNEQ ADM 2
LOM
Multiframe information not recovered from H4 byte (bits 7,8) for 1 to 5 ms
(i.e., 2 to 10 multi-frames)
Note: LOM is an alarm concerning LP, but inferred from HOPOH byte – so,
it will be reported on a HO object
TIM (J1/J2) (Default action is to “Ignore TIM”)

Concept is like TIM (J0), but
a) Remember Section Hierarchy – Tx trace (J1/J2) can not be edited within a HP/LP
VC12 VC4 VC12 VC12

A B C D
E1 E1
Tx trace can be edited Tx trace can be edited Tx trace can be edited

for J0, J1, J2 all for J0 only for J0, J1 only
b) All trace lengths are now 16/64 bytes
HP/LP-PLM (SLM) (Default action is to “Report PLM, but no Downstream AIS”)

Mismatch in ‘own’ and ‘received’ signal label
in C2 byte for at least 5 frames (for AU4/AU3/TU3)
in V5 byte, bits 5,6,7 for at least 5 multi-frames (for TU2/12/11)
HP-PLM (SLM)
AU Sig. Label  TUG-structured
TUG-ST TUG-ST
AU has
ex. VC12
no XC
UNEQ UNEQ
E1
ADM 1 HP-PLM (SLM) ADM 2
TUG TUG Asynch. Asynch.

ST ST C4 C4
ex. VC12 VC4 VC12
Asynch. Asynch. TUG TUG E1
E1
C4 C4 ST ST
ADM 1 ADM 2 ADM 3
HP-PLM (SLM) on all ports
Masking of Alarms
Why?
Do not want to crowd the alarm reporting page ( and thereby confuse the user) with those
alarms, not required for unearthing the root cause
When? (The logics)
Logic 1 (when the alarms are related)
Note: When FC1 clears, FC2 may or may
if ( FC1 ==> FC2 but FC2 =/=> FC1 )
not clear – in the later case FC2 will be
then ( Mask FC2 in presence of FC1 ) reported now
ex. 1a) LOS ==> LOF but LOF =/=> LOS 1b) LOS ==> HP-UNEQ but HP-UNEQ =/=> LOS
2) AU-AIS reported because of MS/AU-AIS generated
==> HP-RDI and
TU-AIS & LP-RDI(s) reported (if TU object(s) are there) but not vice-versa
3) HP-UNEQ because of no XC at other end
==> TU-LOP(s) (if TU object(s) are there) but not vice-versa
4) AU/TU-AIS reported ==> AU/TU-LOP but not vice-versa
Masking of Alarms (…contd.)
Logic 2 (when the alarms are not related)

if ( FC1 has higher priority than FC2 )
Note: When FC1 clears, FC2 will be reported
then ( Mask FC2 in presence of FC1 )
ex. 1) AU/TU-LOP has higher priority than HP/LP-UNEQ
(if one is not getting the starting location of VC, how to look at what is happening within VC)
2) HP/LP-TIM, if action is chosen as “Report TIM, Downstream AIS” (i.e. traffic affecting)
has higher priority than HP/LP-RDI
(first correct received problem, then only look for problem in other direction)
3) HP/LP-TIM has higher priority than HP/LP-PLM
(first correct mis-connection, then see signal label problem within correct correction)
4) HP/LP-UNEQ has higher priority than HP/LP-TIM (even if traffic affecting)

(what to gain by correcting mis-connection, if even after that traffic can not be carried)
Secondary Suppressed Alarms (SSA)
 AIS and RDI are secondary alarms – they are “indications”, not root causes
 These alarms on a pass-through node is normally not reported in the main alarm page,
they are reported in a separate page called “suppressed secondary alarms page”
 These alarms on a path terminating node is reported in the main alarm page as
“terminating” alarms
AU-AIS and HP-RDI are not suppressed, even for pass-through nodes, for Tejas products
Traffic affecting FC TU-AIS (terminating)
ex. VC12 VC12 VC12

E1 E1
ADM 1 ADM 2 ADM 3
LP-RDI (terminating) LP-RDI (SSA)
Alarm Propagation Examples
For every example,

 Assumption(s) is/are stated
 Root Cause(s) is/are stated
 Diagrammatic representation is made (OFCs are shown in cyan)
 Alarm(s) generated / condition(s) generated for reporting alarms is/are
shown in black
 Alarm(s) existing at a port is/are shown in red
 Alarm(s) masked at a port is/are covered with
 Alarm(s) reported at secondary supprressed alarm page is/are shown

in pink, italicised
 Note(s), whenever required is/are mentioned in green
Alarm Propagation Examples (…contd.)
Example 1
Assumption: AU-4 Mapping on both ports Root Cause: NO XConnect on both ports
AU4 Signal Label Unequipped
HP-RDI
HP- UNEQ
HP-RDI
HP- UNEQ
A HP-RDI B
HP-RDI
Note: 1) if AU-3 mapping, then what happens?

2) In newer version of Tejas software, UNEQ is not reported for this root cause
Example 2
Assumption: AU-4 Mapping on both ports, Root Cause: NO XConnect on the port of B
HP-SLM default action is “report
SLM, no downstream AIS”
Signal Label TUG-structure

HP-RDI
LP-RDI
HP-RDI
HP-SLM
VC12
E1 HP- UNEQ
A TU-LOP B
Invalid TU Pointer value
Note: LP-RDI is not reported on B (See Rule 3a)
Example 3
Assumption: AU-4 Mapping on both ports of A & C
Root Cause: Fiber cut in the link from A to B
MS-AIS
AIS
AU-AIS
LOS TU-AIS
VC-12 VC-12
E1 MS-RDI E1
A HP-RDI B C
(Reg.)
LP-RDI MS-RDI
HP-RDI
LP-RDI
Note: The Reg. can not generate any RDI
Actually at C, AU-AIS & TU-AIS conditions are also received
Example 4
Assumption: AU-4 Mapping on all ports Root Cause: Fiber cut in the link from A to B
ADM B  VC-12 PT
MS-AIS
LOS TU AIS
VC-12 VC-12 VC-12

E1 MS-RDI LP RDI E1
A HP-RDI B C
LP RDI MS-RDI LP RDI
HP-RDI
Note: Only TU-AIS is reported on Node C (See Rule 4c)

LP-RDI on B is SSA
Example 5
Assumption: AU-4 Mapping on all ports Root Cause: Fiber cut in the link from A to B
ADM B  VC-4 PT
MS-AIS
AU AIS
LOS TU AIS
VC-12 VC-4 VC-12

E1 MS-RDI E1
A HP-RDI B C
LP RDI MS-RDI LP RDI
HP-RDI
Note: Only AU-AIS is reported on Node C (See Rule 4c)

LP-RDI on B is not reported (See Rule 3b)
Example 6
Assumption: AU-4 Mapping on all ports Root cause: NO XConnect on B, C & D for (1-1-2)
E1 (1) E1 (1)
VC-12 (1-1-1)
LP RDI
(1-1-2)
E1 VC-12 (1-1-2)
(2) TU-LOP
(1-1-2)
A B C D
Invalid TU Pointers
(1-1-2)
Note: Why E1(1) is shown?

LP-RDI is not reported on B (See Rule 3a)
Example 7
Assumption: AU-4 Mapping on all ports Root cause: NO XConnect on C & D for (1-1-2)
E1 (1) E1 (1)
VC-12 (1-1-1)
LP RDI LP RDI
(1-1-2) (1-1-2)
LP-RDI
(1-1-2)
E1 VC-12 (1-1-2) VC-12 (1-1-2)
(2) TU-AIS TU-LOP

(1-1-2) (1-1-2)
A B C D
TU AIS (1-1-2) Invalid TU Pointers
(1-1-2)
Note: LP-RDI at node B is secondary suppressed
TU-AIS at node A is reported as terminating alarm
Example 8
Assumption: AU-4 Mapping on all ports Root cause: NO XConnect on C for (1-1-2)
E1 (1) E1 (1)
VC-12 (1-1-1)
LP RDI LP RDI Invalid TU Pointers

(1-1-2) (1-1-2) (1-1-2)
LP-RDI TU-LOP
(1-1-2) (1-1-2)
E1 VC-12 (1-1-2) VC-12 (1-1-2) VC12(1-1-2) E1

(2) TU-AIS TU-LOP (2)
(1-1-2) (1-1-2)
A B C D
TU AIS (1-1-2) Invalid TU Pointers LP RDI (1-1-2)
(1-1-2)
Note: K-L-M value need not remain same throughout a particular LP, alarms will
be reported accordingly on different objects
Example 9
Assumption: AU-4 Mapping on all ports, Root cause: NO XConnect on C for (1-1-1)
VC4 PT at node B,
For each port, HP-SLM default action is “ignore SLM”
LP-RDI
(1-1-1)
VC-12(1-1-1)
E1 (1) VC-4 VC-12(1-1-2)

VC-12(1-1-2)
E1(2)
TU-LOP
E1 (2)
(1-1-1)
A B C
Invalid TU Pointers
(1-1-1)
Note: LP-RDI from A is not reported on B (See Rule 3b).
Why assumption on SLM?
Example 10 (with SNCP)

Assumption: AU-4 Mapping on all ports Root cause: Fiber-cut in the link from A to B
W  A-B-C, P  A-D-C MS-AIS
LOS TU AIS
E1 VC-12 VC-12 VC-12 E1
MS-RDI LP RDI
HP-RDI LP RDI
A B C
LP RDI MS-RDI
HP-RDI
Note: SNCP is always

uni-directional & for VC-12
Tejas, it is 1+1
D
Thank You…

Tejas Networks: SDH Alarms

Uploaded by

Copyright:

Available Formats

You might also like

Tejas Networks: SDH Alarms

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tejas Networks: SDH Alarms

Uploaded by

Copyright:

Available Formats

Tejas Networks

 SDH section hierarchy

 SDH objects, nomenclature

 Downstream and Upstream

 Alarms understanding rules

 Alarm Masking and Suppressed Secondary Alarms

 Alarm propagation examples

 Example 3 (for AU4 mapping only)

VC12 VC4 VC12 VC12

RS – A-B, B-C, C-D, D-E, F-B, C-G, E-H

HP – F-B, B-C, C-E, E-H

RS – A-B, B-C, C-D, D-E, F-B, C-G, E-H

 3 different kinds of objects:

Note: STM # = 1 (for STM-1)

 Downstream direction for a fault condition

 Upstream direction for a fault condition

 Downstream & Upstream direction for a node not fixed

Alarms reported are alarms received

Alarms are reported on SDH Objects

3a. No Object => No Alarms reported

4a. No PT XC => No Alarms pass-through

ADM 1 NO Alarm pass-through ADM 2 ADM 3

ADM 1 NO Alarm pass-through ADM 2 ADM 3

4b. Bigger PT XC => No Alarms reported & Alarm pass-through

ADM 1 Alarm pass-through for ADM 2 ADM 3

4c. Smaller PT XC => No Alarms reported (always ??) &

ADM 1 Alarm pass-through for ADM 2 ADM 3

RS alarms are those, which can be reported even by a pure Regenerator

LOS (Loss of Signal) RSOH bytes

LOF (Loss of Frame)

MS alarms are those, which can be reported by a Add-Drop Multiplexer, irrespective of

HP / LP alarms are those, which can be reported by a Add-Drop Multiplexer, having

Note 1: Same as before

LOPOH bytes LP-TIM based on J2 byte

V5 LP-SF based on V5 byte – bits 1,2

N2 LP-RDI based on V5 byte -- bit 8

K4 LP-PLM / SLM based on V5 byte – bits 5,6,7

A Exp trace = C to B B Tx trace = C to B C

Generation of AIS & RDI

generates AIS towards downstream side

 Upon Receiving traffic affecting RS alarm, a ADM

generates MS-AIS towards downstream side

 Upon Receiving traffic affecting HP alarm, a ADM

generates AU-AIS towards downstream side

 Upon Receiving traffic affecting LP alarm, a ADM

generates TU-AIS towards downstream side

Example of generation of AIS, RDI

Example of reception of TU-AIS, LP-RDI

VC12 VC12 VC12

AU Sig. Label  UNEQuipped HP-UNEQ

UNEQuipped  AU Sig. Label

AU Sig. Label  TUG-structured

TIM (J1/J2) (Default action is to “Ignore TIM”)

VC12 VC4 VC12 VC12

Tx trace can be edited Tx trace can be edited Tx trace can be edited

HP/LP-PLM (SLM) (Default action is to “Report PLM, but no Downstream AIS”)

TUG TUG Asynch. Asynch.

Logic 2 (when the alarms are not related)