WPCM 2%B L. W-lvetica--,`H1`D4PkC"S^11>bbu"::Dg1:11bbbbbbbbbb11gggbuuuk1Xubuukuuuk111Rb:bbXbb1bb''X'bbbb:X1bXXXX;.;g:=::m:::mmmmm::::::mm:k1mubububububXubububub11111111bbbbbbbbbuXubbkbuXmmmmumububXXXXbububububbmbbbbbb:k:k::=kmmX:uXb'b:b:b:b'bmbbbb:::uXuXuXuXk:k:k:mbbbmbuXkXkXKQmmmm^b:kbbbbmbA@mmbmmbmmmmmmm:b:mmmbbmmmmmmmmmmmmXXmmmmmmmmmmmmmmmmmmcm`m`mm`m:mmmmmm}}}mjjmmmmmmmmmmmmmmm0mm}mmmmmmmmmmmmmmmmmmmmmmm}Mmmmmmmmmmmmmjmmmtmmmmmmmmm`'mmm`mmjmlWmmmmmmmmmmmmmmmmmmmW`mmmmjmMQMS PS Jet Plus /800 II QPJPII.PRSPl`D4PkCg2W_ qD#|oHelveticaCourier@,`H1`D4PkCmQrrr r  @C2K ` X` hp x (#%'H   x|@  3'3'Standard@8'@8'StandardC6QMS $=R- 6.HRecommendation G.708 <NETWORK NODE INTERFACE FOR THE SYNCHRONOUS DIGITAL HIERARCHY < < HThe CCITT, considering  `  H(a)  that Network Node Interface (NNI) specifications are necessary to enable interconnection of synchronous digital network elements for transport of payloads, including digital signals of the asynchronous hierarchy defined in Recommendation G.702; H(b)  that Recommendation G.707 describes the advantages offered by a synchronous digital hierarchy and multiplexing method and specifies a set of synchronous digital hierarchy bit rates; H(c)  that Recommendation G.709 specifies the multiplexing structures; H(d)  that Recommendations G.707, G.708 and G.709 form a coherent set of specifications for the synchronous digital hierarchy and NNI; H(e)  that Recommendation G.802 specifies the interworking between networks based on different asynchronous digital hierarchies and speech encoding laws, recommends Hthat the frame structure for multiplexed digital signals at the network node interface of a synchronous digital network including ISDN should be as described in this Recommendation. 1.HLocation of NNI HFigure 1.1/G.708 gives a possible network configuration to illustrate the location of network node interface specified in this Recommendation. 2.HBasic multiplexing principle and multiplexing elements 2.1HGeneral HFrame structures and overheads in this document are mainly in the context of circuit mode connection types rather than Asynchronous Transfer Mode (ATM). ATM based multiplexing principles are under study. HFigure 2.1/G.708 shows the relationship between various multiplexing elements that are defined below, and illustrates possible multiplexing structures. HFigures 2.2, 2.3 and 2.4/G.708 are examples of how various signals are multiplexed using these multiplexing elements. HDetails of the multiplexing method and mappings are given in Recommendation G.709. Note When signals at bit rates of the various multiplexing elements of the synchronous digital hierarchy (Recommendations G.707, G.708, G.709) are different from existing hierarchy levels in Recommendation G.702, the signals are not required to be transported via digital networks which are in line with Recommendation G.702. 2.2HDefinitions H1)  Container: Cn (n=14)   HH This element is a defined unit of payload capacity which is sized to carry any of the levels currently defined in Recommendation G.702 and may also provide capacity for carriage of broadband signals which are not yet defined.%H  `  .ԌH2)  Virtual Container: VCn  H Two types of virtual containers have been identified: H Basic Virtual Container: VCn (n=1,2)  `  H  This element comprises a single Cn (n=1,2) plus the basic virtual container path overhead (POH) appropriate to that level.$ H Higher Order Virtual Container: VCn (n=3,4)  H HHX X This element comprises a single Cn (n=3,4), an assembly of tributary unit groups (TUG2s) or an assembly of TU3s, together with virtual container POH appropriate to that level.Ɛ$  H`  H3)  Tributary Unit: TUn (n=13)  `  HH This element consists of a virtual container plus a tributary unit pointer. A tributary unit pointer indicates the phase alignment of the virtual container (VCn) with respect to the POH of the next higher level virtual containers in which it resides. The tributary unit pointer location is fixed with respect to this higher level POH.(#H  `   `  H In certain applications (for example, synchronous mapping HHproviding direct observability of 64 kbit/s channels) the basic virtual container has a fixed phasealignment with respect to the higher level virtual container. In this case, the basic virtual container (VC1) POH and TU1 pointer are null.H!H  `  H4)  Tributary Unit Group: TUG2  `  H This element consists of a homogeneous assembly of identical HTUn (n=1,2). H5)  Administrative Unit: AUn (n=3,4)  8 H This element consists of a VCn (n=3,4) plus an administrative HHunit pointer. An administrative unit pointer indicates the phase alignment of the VCn (n=3,4) with respect to the STM1 frame. The administrative unit pointer location is fixed with respect to the STM1 frame.Ơ#H  8`  H6)  Synchronous Transport Module level 1: STM1  `  H This element is the basic building block of the synchronous HHdigital hierarchy and it comprises either one AU4 or multiple AU3s, together with section overhead (SOH).8"H  `  H7)  Synchronous Transport Module level N: STMN  ` 8 H This element defines the Nth level of the synchronousdigital HHhierarchy and contains N synchronously multiplexed STM1 signals.Ơ#H  8`   `  H The STMNsignal can be obtained via single or multiple stage HHmultiplexing.(#H  `   `  HValues of N correspond to the synchronous digital hierarchy levels given in Recommendation G.707. 3.HFrame structure 3.1HLevel 1 155 520 kbit/s (STM1) 3.1.1HBasic frame structure  .Ԍ H HFrame structure is shown in Figure 3.1/G.708. The three main areas of the STM1 frame are indicated: H section overhead; H AU pointers; H STM1 payload. 3.1.2HSection overhead HRows 13 and 59 of columns 19 of the STM1 in Figure 3.1/G.708 are dedicated to the section overhead. HThe allocation of section overhead capacity and functions is given in Figure 3.4a/G.708. An explanation of the overhead functions is given in section 5. 3.1.3HAdministrative unit (AU) pointers HRow 4 of columns 19 and row 13 of columns 1114 in Figure 3.1/G.708 are available for AU pointers. The positions of the pointers of the AUs for different organizations of the STM1 payload are shown in Table 3.1/G.708. The application of pointers and their detailed specifications are given in Recommendation G.709. 3.1.4HAdministrative units in the STM1 HThe STM1 payload can suppport the following types and numbers of administrative units: H  one AU4; H or three AU32s; H or four AU31s. HThe VCn associated with each AUn does not have a fixed phase with respect to the STM1 frame. The location of the first byte of the VCn is indicated by the AUn pointer. The AUn pointer is in a fixed location in the STM1 frame as illustrated in Figures 2.2, 2.3, 2.4, 3.1, 3.2 and 3.3/G.708. HThe AU4 may be used to carry, via the VC4, three TU32s or four  Hh TU31s. This nested arrangement is illustrated in Figures 2.2 and 3.3/G.708. The VC3 associated with each TU3 does not have a fixed phase relationship with respect to the start of the VC4. The TU3 pointer is in a fixed location in the VC4 and the location of the first byte of the VC3 is indicated by the TU3 pointer (illustrated in Figures 2.2 and 3.3/G.708). 3.1.5HVC4 and VC3 path overheads HThe allocation of the VC4 and VC3 path overhead capacity and functions is given in Figure 3.4b/G.708. An explanation of the overhead functions is given in section 5. HThe position of the VC4 and VC3 path overhead is specified in Recommendation G.709. 3.2HLevel 4 622 080 kbit/s (STM4) HThis level is obtained by one byte interleaving four STM1s as illustrated in Figure 3.5/G.708. HThe SOH of the STM1s shall be 125 s phase aligned prior to multiplexing such that the SOH of the STM4 is contained in the first 36 columns. The AU pointer value(s) of each STM1 is/are adjusted to indicate the start of the VC(s) with respect to this new position of the AU pointer(s) which is fixed relative to the STM4 SOH.  .Ԍ4.HInterconnection of STM1s HThe synchronous digital hierarchy, specified in Recommendations G.707, G.708 and G.709 is designed to be universal allowing transport of a large variety of signals including those specified in Recommendation G.702. HHowever, there are a numebr of options for structuring an STM1. This section provides guidelines for the interconnection of STM1s. Two general cases are considered: HCase 1 STM1s having the same structure (detailed in section 4.1) HCase 2 STM1s having different structures (detailed in section 4.2). 4.1HInterconnection of STM1s having the same structure HThe interconnection unit used between STM1s is the VC associated with the AU. This arrangement is shown in Table 4.1i)/G.708. 4.2HInterconnection of STM1s having different structures HIn the case of STM1s having different structures, the following guidelines should be used to facilitate interconnection by a bilateral agreement or to resolve the contention. HThe method of interconnection between STM1s having different structures depends on whether the type of AU is different or whether the type of TUG is different. The cases are considered in three categories: H different types of AU3 carrying a C3 payload; H different types of AU carrying the same type of TUG2; H different types of TUG2s. 4.2.1HDifferent types of AU3s carrying a C3 payload HFor the interconnection of different types of AU3s carrying a C3 payload, the C3 payload is transferred from the AU3 to a corresponding TU3. This TU3 is then assembled into a VC4 using the nested approach illustrated in Figure 3.3/G.708. This arrangement is shown in Table 4.1ii)/G.708, and is intended to facilitate the transit of C3 in a VC3 across a network which cannot support the associated AU3. 4.2.2HDifferent types of AU carrying the same type of TUG HFor the interconnection of a different type of AU carrying the same type of TUG2, the TUG2s are transferred between the dissimilar AUs. In the absence of bilateral agreement on an AU3 type, the AU4 shall be used. This arrangement is shown in Table 4.1iii)/G.708. 4.2.3HDifferent types of TUG2s HFor the interconnection of different types of TUG2s, the TU1s are transferred from the TUG22 to the TUG21. The TUG21 is used as the interconnection unit. In the absence of bilateral agreement on an AU3 type, the TUG21s are directly assembled into a VC4. This arrangement is shown in Table 4.1iv)/G.708. HThe method of interconnection between an AU31 containing TUG21s and an AU31 containing TUG22s is for further study. 5.HOverhead functions 5.1HTypes of overhead HSeveral types of overhead have been identified for application in the synchronous digital hierarchy. H1)  Section overhead: SOH  .ԌH Section overhead capacity is added to either an AU4 or an assembly of HHAU3s to create an STM1. The content always includes STM1 framing. Content representing section performance monitoring and other maintenance and operational functions can be added or modified without disassembly of the STM1 as appropriate for various configurations of elements (for example, intermediate regenerator monitoring, protection switching control).p&H  h`  H2)  Virtual container path overhead: POH  `  HH Virtual container path overhead provides for communication between the point of assembly of a virtual container and its point of disassembly. Two categories of virtual container path overhead have been identified:!H  `   `  H Basic virtual container path overhead (VC1,2 POH) H Basic virtual container POH is added to the container  H HHX (C1,2) when the VC1,2 is created. Among the functions included in this overhead are virtual container path performance monitoring, signals for maintenance purposes and alarm status indications.Ɛ$  H`   `  H Higher order virtual container path overhead (VC3,4 POH) H VC3 POH is added to either an assembly of TUG2s or a C3 HHX to form a VC3. VC4 POH is added to either an assembly of TU3s or a C4 to form a VC4. Among the functions included within this overhead are virtual container path performance monitoring, alarm status indications, signals for maintenance purposes and multiplex structure indications (VC3,4 composition).$  `   `  HThe types of overhead described above and their applications are shown in Figure 5.1/G.708. 5.2HOverhead descriptions HThe location of the various section and VC3,4 path overhead bytes in the STM1 frame is illustrated in Figure 3.4/G.708. 5.2.1HSOH byte descriptions H1)  Framing: A1, A2 H Six bytes are dedicated to each STM1. The pattern shall be HHA1A1A1A2A2A2 (A1=11110110, A2=00101000). These bytes shall be provided in all STM1 signals within an STMN.%H  `  H2)  Data communication channels: D1 D12  ` H H Twelve bytes are allocated for section data communication. These HHbytes are defined only for STM1 #1 of an STMN signal.Ɛ$H  H`  H3)  STM identifier: C1  ` 8 H This is a unique number assigned to an STM1 prior to it being multiplexed to a higher STMN level. Upon demultiplexing, this byte may be used to identify the position of any particular STM1 within the incoming STMN signal. H4)  Orderwire: E1, E2 H These two bytes provide orderwire channels for voice HHcommunication. These bytes are defined only for STM1 #1 of an STMN signal.Ơ#H  8`  H5)  User channel: F1  `  H This byte is reserved for user purposes (for example, network .ԌHHoperations). This byte is defined only for STM1 #1 of an STMN signal.(#H  `  H6)  BIP8: B1  `  HH One byte is allocated in each STM1 for an elementary regenerator section bit error monitoring function. This function shall be a %H  H HHBit Interleaved Parity 8 (BIP8) code using even parity. The BIP8 is computed over all bits of the previous STMN frame after scrambling and is placed in byte B1 before scrambling. (For details of the scrambling process, see Recommendation G.709.) The B1 byte shall be monitored and recomputed at every regenerator.Ɛ$H  H`   ` X Note Bit Interleaved Parity N (BIPN) code is defined as a method of error monitoring. With even parity, an N bit code is generated by the transmitting equipment over a specified portion of the signal in such a manner that the first bit of the code provides even parity over the first bit of all Nbit sequences in the covered portion of the signal, the second bit provides even parity over the second bits of all Nbit sequences within the specified portion, etc. Even parity is generated by setting the BIPN bits so that there are an even number of 1s in each of all Nbit sequences including the BIPN. H7)  BIP24: B2 x 3 H Three bytes are allocated in each STM1 for a section bit error HHmonitoring function. This function shall be a Bit Interleaved Parity 24 code (BIP24) using even parity. The BIP24 is computed over all bits of the previous STM1 frame except for the first three rows of section overhead (A1 through D3) and is placed in bytes B2 before scrambling. This parity code is not recomputed at regenerators. These bytes shall be provided in all STM1 signals within an STMN signal.ƀ%H  X`  H8)  APS channel: K1, K2  ` H H Two bytes are allocated for Automatic Protection Switching (APS) HHsignalling. These bytes are defined only for STM1 #1 of an STMN signal.Ɛ$H  H`  H9)  Spare: Z1, Z2  ` ( H Six bytes are allocated for functions not yet defined. These HHbytes have no defined value. These bytes are reserved in allư"H HHSTM1s of an STMN.ư"H  (`  5.2.2HAU pointer descriptions H1)  Pointer value  ` H H Two bytes are allocated for a pointer which indicates the offset HHin bytes between the pointer and the first byte of the associated virtual container POH. For a complete specification and location of these bytes, see Recommendation G.709.Ɛ$H  H`  H(2)  Pointer action  `  H Three pointer action bytes are allocated in an AU4 for frequency HHjustification purposes. One pointer action byte is allocated for AU3s and TUns. For complete specification of these bytes, refer to %H  ` HRecommendation G.709.  `  HIn the event of a negative justification, they carry valid information. 5.2.3HVCn (n=3,4) POH byte descriptions H1)  Path BIP8: B3 H One byte is allocated in each virtual container for a path bit error HHmonitoring function. This function shall be a BIP8 code using even parity. The BIP8 is computed over all bits of the previous container and is placed in the B3 byte.%H .Ԍ `  H2)  Path status: G1  `  H One byte is allocated to return the VCn path terminating status  p HHperformance information to the VCn path originating point.hH  p`  H3)  Signal label: C2  `  H One byte is allocated to indicate the composition of the VCn HHpayload.(#H  `  H4)  VCn pathuser channel: F2  ` p H One byte is allocated for user communication purposes. H5)  VCn path trace: J1  p( H This byte is used at the VCn termination point to verify the HHVCn path connection.ư"H  (`  H6)  Spare: Z3 Z5  `  H Three bytes are allocated for as yet undefined purposes. H7)  Multiframe indicator: H4  8 H This byte is allocated to provide a multiframe indication, when Hrequired. H8)  Physical specification of the NNI  8 H Specification for physical, electrical or optical characteristics N#Pof the NNI will be contained in another Recommendation which is under CDstudy.  ` HH   x|@  @8'@8'StandardC6QMS $=R6'6'StandardC6QMS $=R- Ytr  ` `  <  <AP IX142E <#YYt#  ` `  <  <AP IX142E <#Y|d (3291) |R(3291)    <TABLE 3.1/G.708 <# <Position of AU pointersă <# <   <  AU  Position of AU Pointer  <  <  31  Area A and B  <  <  32  Area A  <  <  4  Area A  <    (   8|@:/(3291) CCITT\APIX\DOC\142E4.TXS) 88|@:$(3291) CCITT\APIX\DOC\142E4.TXS) 8