home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD2.mdf / ccitt / 1992 / g / g783.asc < prev    next >
Text File  |  1993-08-15  |  105KB  |  2,729 lines

  1. C:\WINWORD\CCITTREC.DOT_______________
  2.  
  3.  
  4.  
  5.  
  6.  
  7. INTERNATIONAL  TELECOMMUNICATION  UNION
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15. CCITT    G.783
  16.  
  17. THE  INTERNATIONAL
  18. TELEGRAPH  AND  TELEPHONE
  19. CONSULTATIVE  COMMITTEE
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31. GENERAL  ASPECTS  OF  DIGITAL
  32.  
  33. TRANSMISSION  SYSTEMS;
  34.  
  35. TERMINAL  EQUIPMENTS
  36.  
  37.  
  38.  
  39.  
  40.  
  41. CHARACTERISTICS  OF  SYNCHRONOUS  DIGITAL  
  42. HIERARCHY  (SDH)
  43. MULTIPLEXING  EQUIPMENT  FUNCTIONAL  BLOCKS
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55. Recommendation  G.783
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63. Geneva, 1990
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139. Printed in Switzerland
  140.  
  141.  
  142.  
  143. FOREWORD
  144.  
  145.     The CCITT (the International Telegraph and Telephone Consultative 
  146. Committee) is a permanent organ of the International Telecommuni-
  147. cation Union (ITU). CCITT is responsible for studying technical, 
  148. operating and tariff questions and issuing Recommendations on them 
  149. with a view to standardizing telecommunications on a worldwide 
  150. basis.
  151.  
  152.     The Plenary Assembly of CCITT which meets every four years, 
  153. establishes the topics for study and approves Recommendations pre-
  154. pared by its Study Groups. The approval of Recommendations by the 
  155. members of CCITT between Plenary Assemblies is covered by the 
  156. procedure laid down in CCITT Resolution No. 2 (Melbourne, 1988).
  157.  
  158.     Recommendation G.783 was prepared by Study Group XV and was 
  159. approved under the Resolution No. 2 procedure on the 14 of December 
  160. 1990.
  161.  
  162.  
  163.  
  164.  
  165.  
  166. ___________________
  167.  
  168.  
  169.  
  170.  
  171.  
  172. CCITT  NOTE
  173.  
  174.     In this Recommendation, the expression ôAdministrationö is used for 
  175. conciseness to indicate both a telecommunication Administration and 
  176. a recognized private operating agency.
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196. πITU1990
  197.  
  198. All rights reserved. No part of this publication may be reproduced or uti-
  199. lized in any form or by any means, electronic or mechanical, including pho-
  200. tocopying and microfilm, without permission in writing from the ITU.
  201.  
  202. PAGE BLANCHE
  203.  
  204. Recommendation G.783
  205.  
  206. Recommendation G.783
  207.  
  208. CHARACTERISTICS  OF SYNCHRONOUS DIGITAL HIERARCHY 
  209. (SDH) 
  210. MULTIPLEXING  EQUIPMENT  FUNCTIONAL  BLOCKS
  211.  
  212.     The CCITT,
  213.  
  214. considering
  215.  
  216.     (a)    that Recommendations G.707, G.708 and G.709 form a coherent 
  217. set of specifications for the synchronous digital hierarchy (SDH) and the 
  218. Network Node Interface (NNI);
  219.  
  220.     (b)    that Recommendation G.781 gives the structure of Recommendations 
  221. on multiplexing equipment for the SDH;
  222.  
  223.     (c)    that Recommendation G.782 gives the types and general characteris-
  224. tics of SDH multiplexing equipment;
  225.  
  226.     (d)    that Recommendation G.784 addresses management aspects of the 
  227. SDH;
  228.  
  229.     (e)    that Recommendation G.957 specifies characteristics of optical inter-
  230. faces for use within the SDH;
  231.  
  232.     (f)    that Recommendation G.958 specifies digital line systems based on 
  233. the SDH for use on optical fibre cables;
  234.  
  235.     (g)    that Recommendation G.703 describes electrical interfaces for use 
  236. within the SDH,
  237.  
  238. recommends
  239.  
  240.     that SDH multiplexing equipments having the general characteristics 
  241. described in Recommendation G.782 should support interfaces and func-
  242. tions as described in this Recommendation.
  243.  
  244. 1    General
  245.  
  246.     This Recommendation defines the interfaces and functions to be sup-
  247. ported by the multiplexer types defined in Recommendation G.782. The 
  248. description is generic and no particular physical partitioning of functions is 
  249. implied. The input/output information flows associated with the functional 
  250. blocks serve for defining the functions of the blocks and are considered to 
  251. be conceptual, not physical.
  252.  
  253. 1.1    Abbreviations
  254.  
  255. AIS        Alarm indication signal
  256.  
  257. ALS        Automatic laser shutdown
  258.  
  259. APS        Automatic protection switching
  260.  
  261. AU        Administrative unit
  262.  
  263. AUG        Administrative unit group
  264.  
  265. BER        Bit error ratio
  266.  
  267. BIP        Bit interleaved parity
  268.  
  269. CM        Connection matrix
  270.  
  271. CMISE        Common Management Information Service Element
  272.  
  273. DCC        Data communications channel
  274.  
  275. EOW        Engineering order-wire
  276.  
  277. ES        Errored second
  278.  
  279. FAL        Frame alignment loss
  280.  
  281. FEBE        Far end block error
  282.  
  283. FERF        Far end receive failure
  284.  
  285. HPA        Higher order path adaptation
  286.  
  287. HPC        Higher order path connection
  288.  
  289. HPT        Higher order path termination
  290.  
  291. LOF        Loss of frame
  292.  
  293. LOM        Loss of multiframe
  294.  
  295. LOP        Loss of pointer
  296.  
  297. LOS        Loss of signal
  298.  
  299. LPA        Lower order path adaptation
  300.  
  301. LPC        Lower order path connection
  302.  
  303. LPT        Lower order path termination
  304.  
  305. MCF        Message comunications function
  306.  
  307. MRTIE        Maximum relative time interval error
  308.  
  309. MS        Multiplex section
  310.  
  311. MSOH        Multiplex section overhead
  312.  
  313. MSP        Multiplex section protection
  314.  
  315. MST        Multiplex section termination
  316.  
  317. MTG        Multiplexer timing generator
  318.  
  319. MTIE        Maximum time interval error
  320.  
  321. MTPI        Multiplexer timing physical interface
  322.  
  323. MTS        Multiplexer timing source
  324.  
  325. NDF        New data flag
  326.  
  327. NE        Network element
  328.  
  329. NEF        Network element function
  330.  
  331. NNI        Network node interface
  332.  
  333. NU        National use
  334.  
  335. OFS        Out-of-frame second
  336.  
  337. OHA        Overhead access
  338.  
  339. OOF        Out of frame
  340.  
  341. PDH        Plesiochronous digital hierarchy
  342.  
  343. PI        Physical interface
  344.  
  345. PJE        Pointer justification event
  346.  
  347. POH        Path overhead
  348.  
  349. RS        Regenerator section
  350.  
  351. RSOH        Regenerator section overhead
  352.  
  353. RST        Regenerator section termination
  354.  
  355. SA        Section adaptation
  356.  
  357. SD        Signal degrade
  358.  
  359. SDH        Synchronous digital hierarchy
  360.  
  361. SEMF        Synchronous equipment management function
  362.  
  363. SES        Severely errored second
  364.  
  365. SF        Signal fail
  366.  
  367. SPI        SDH physical interface
  368.  
  369. STM        Synchronous transport module
  370.  
  371. TMN        Telecommunications management network
  372.  
  373. TU        Tributary unit
  374.  
  375. VC        Virtual container
  376.  
  377. 1.2    Definitions
  378.  
  379.     Note û The following definitions are relevant in the context of SDH-
  380. related Recommendations.
  381.  
  382. 1.2.1    Automatic laser shutdown (ALS)
  383.  
  384.     See Recommendation G.958.
  385.  
  386. 1.2.2    automatic protection switching (APS)
  387.  
  388.     Autonomous switching of a signal between and including two MST 
  389. functions, from a failed working channel to a protection channel and subse-
  390. quent restoration using control signals carried by the K-bytes in the MSOH.
  391.  
  392. 1.2.3    Administrative unit (AU)
  393.  
  394.     See Recommendation G.708.
  395.  
  396. 1.2.4    Administrative unit group (AUG)
  397.  
  398.     See Recommendation G.708.
  399.  
  400. 1.2.5    Bit interleaved party (BIP)
  401.  
  402.     See Recommendation G.708.
  403.  
  404. 1.2.6    connection matrix (CM)
  405.  
  406.     A connection matrix is a matrix of appropriate dimensions which 
  407. describes the connection pattern for assigning VC-ns on one side of an LPC 
  408. or HPC function to VC-n capacities on the other side and vice versa.
  409.  
  410. 1.2.7    Common management information service element (CMISE)
  411.  
  412.     See ISO 9595.
  413.  
  414. 1.2.8    Data communications channel (DCC)
  415.  
  416.     See Recommendation G.784.
  417.  
  418. 1.2.9    desynchronizer
  419.  
  420.     The desynchronizer function smooths out the timing gaps resulting 
  421. from decoded pointer adjustments and VC payload de-mapping in the time 
  422. domain.
  423.  
  424. 1.2.10    Frame alignment loss (FAL)
  425.  
  426.     See Recommendation G.706.
  427.  
  428. 1.2.11    Far end block error (FEBE)
  429.  
  430.     See Recommendation G.709.
  431.  
  432. 1.2.12    Far end receive failure (FERF)
  433.  
  434.     See Recommendation G.709.
  435.  
  436. 1.2.13    higher order path adaptation (HPA)
  437.  
  438.     The HPA function adapts a lower order VC (VC-1/2/3) to a higher 
  439. order VC (VC-3/4) by processing the TU pointer which indicates the phase 
  440. of the VC-1/2/3 POH relative to the VC-3/4 POH and assembling/disassem-
  441. bling the complete VC-3/4.
  442.  
  443. 1.2.14    higher order path connection (HPC)
  444.  
  445.     The HPC function provides for flexible assignment of higher order 
  446. VCs (VC-3/4) within an STM-N signal.
  447.  
  448. 1.2.15    higher order path termination (HPT)
  449.  
  450.     The HPT function terminates a higher order path by generating and 
  451. adding the appropriate VC POH to the relevant container at the path source 
  452. and removing the VC POH and reading it at the path sink.
  453.  
  454. 1.2.16    loss of frame (LOF)
  455.  
  456.     An LOF state of an STM-N signal is considered to have occurred 
  457. when an OOF state persists for a defined period of time.
  458.  
  459. 1.2.17    loss of pointer (LOP)
  460.  
  461.     The LOP state is one resulting from a defined number of consecutive 
  462. occurrences of certain conditions which are deemed to have caused the 
  463. value of the pointer to be unknown.
  464.  
  465. 1.2.18    loss of signal (LOS)
  466.  
  467.     The LOS state is considered to have occurred when the amplitude of 
  468. the relevant signal has dropped below prescribed limits for a prescribed 
  469. period.
  470.  
  471. 1.2.19    lower order path adaptation (LPA)
  472.  
  473.     The LPA function adapts a PDH signal to an SDH network by map-
  474. ping/de-mapping the signal into/out of a synchronous container. If the signal 
  475. is asynchronous, the mapping process will include bit level justification.
  476.  
  477. 1.2.20    lower order path connection (LPC)
  478.  
  479.     The LPC function provides for flexible assignment of lower order 
  480. VCs in a higher order VC.
  481.  
  482. 1.2.21    lower order path termination (LPT)
  483.  
  484.     The LPT function terminates a lower order path by generating and 
  485. adding the appropriate VC POH to the relevant container at the path source 
  486. and removing the VC POH and reading it at the path sink.
  487.  
  488. 1.2.22    multiplex section alarm indication signal (MS-AIS)
  489.  
  490.     MS-AIS is an STM-N signal that contains a valid RSOH and an all 
  491. ONEs pattern for the remainder of the signal.
  492.  
  493. 1.2.23    Multiplex section far end receive failure (MS-FERF)
  494.  
  495.     See Recommendation G.709.
  496.  
  497. 1.2.24    multiplex section overhead (MSOH)
  498.  
  499.     The MSOH comprises rows 5 to 9 of the SOH of the STM-N signal.
  500.  
  501. 1.2.25    multiplex section protection (MSP)
  502.  
  503.     The MSP function provides capability for switching a signal between 
  504. and including two MST functions, from a ôworkingö to a ôprotectionö sec-
  505. tion.
  506.  
  507. 1.2.26    multiplex section termination (MST)
  508.  
  509.     The MST function generates the MSOH in the process of forming an 
  510. SDH frame signal and terminates the MSOH in the reverse direction.
  511.  
  512. 1.2.27    multiplexer timing generator (MTG)
  513.  
  514.     The MTG function filters the timing reference signal from those 
  515. selected in the MTS to ensure that the timing requirements at the T0 refer-
  516. ence point are met.
  517.  
  518. 1.2.28    multiplexer timing physical interface (MTPI)
  519.  
  520.     The MTPI function provides the interface between an external syn-
  521. chronization signal and the multiplexer timing source.
  522.  
  523. 1.2.29    multiplexer timing source (MTS)
  524.  
  525.     The MTS function provides timing reference to the relevant compo-
  526. nent parts of a multiplexing equipment and represents the SDH network ele-
  527. ment clock.
  528.  
  529. 1.2.30    Network element function (NEF)
  530.  
  531.     See Recommendation G.784.
  532.  
  533. 1.2.31    Network node interface (NNI)
  534.  
  535.     See Recommendation G.708.
  536.  
  537. 1.2.32    out-of-frame second (OFS)
  538.  
  539.     An OFS is a second in which one or more out of frame events have 
  540. occurred.
  541.  
  542. 1.2.33    overhead access (OHA)
  543.  
  544.     The OHA function provides access to transmission overhead func-
  545. tions.
  546.  
  547. 1.2.34    out of frame (OOF)
  548.  
  549.     The OOF state of an STM-N signal is one in which the position of the 
  550. frame alignment bytes in the incoming bit stream is unknown.
  551.  
  552. 1.2.35    pointer justification event (PJE)
  553.  
  554.     A PJE is an inversion of the I- or D-bits of the pointer, together with 
  555. an increment or decrement of the pointer value to signify a frequency justifi-
  556. cation opportunity.
  557.  
  558. 1.2.36    Path overhead (POH)
  559.  
  560.     See Recommendation G.708.
  561.  
  562. 1.2.37    regenerator section (RS)
  563.  
  564.     A regenerator section is the part of a line system between two regen-
  565. erator section terminations.
  566.  
  567. 1.2.38    regenerator section overhead (RSOH)
  568.  
  569.     The RSOH comprises rows 1 to 3 of the SOH of the STM-N signal.
  570.  
  571. 1.2.39    regenerator section termination (RST)
  572.  
  573.     The RST function generates the RSOH in the process of forming an 
  574. SDH frame signal and terminates the RSOH in the reverse direction.
  575.  
  576. 1.2.40    section adaptation (SA)
  577.  
  578.     The SA function processes the AU-3/4 pointer to indicate the phase of 
  579. the VC-3/4 POH relative to the STM-N SOH and assembles/disassembles 
  580. the complete STM-N frame.
  581.  
  582. 1.2.41    signal degrade (SD)
  583.  
  584.     An SD condition is one in which a signal has been degraded beyond 
  585. prescribed limits.
  586.  
  587. 1.2.42    synchronous equipment management function (SEMF)
  588.  
  589.     The SEMF converts performance data and implementation specific 
  590. hardware alarms into object-oriented messages for transmission over the 
  591. DCC(s) and/or a Q-interface. It also converts object-oriented messages 
  592. related to other management functions for passing across the Sn reference 
  593. points.
  594.  
  595. 1.2.43    SDH physical interface (SPI)
  596.  
  597.     The SPI function converts an internal logic level STM-N signal into 
  598. an STM-N line interface signal.
  599.  
  600. 1.2.44    Synchronous transport module (STM)
  601.  
  602.     See Recommendation G.708.
  603.  
  604. 1.2.45    Telecommunications management network (TMN)
  605.  
  606.     See Recommendation M.30.
  607.  
  608. 1.2.46    Tributary unit (TU)
  609.  
  610.     See Recommendation G.708.
  611.  
  612. 1.2.47    Virtual container (VC)
  613.  
  614.     See Recommendation G.708.
  615.  
  616. 2    Transport terminal functions
  617.  
  618.     The transport terminal functions comprise SDH physical interface 
  619. (SPI), regenerator section termination (RST), multiplex section termination 
  620. (MST), multiplex section protection (MSP) and section adaptation (SA) 
  621. functions as illustrated in Figure2-l/G.783. The functional description of 
  622. each of these functions is based on this figure.
  623.  
  624. FIGURE 2-1/G.783
  625.  
  626.  
  627.  
  628. 2.1    SDH Physical Interface function (SPI)
  629.  
  630.     The SPI function provides the interface between the physical trans-
  631. mission medium at reference point A and the RST function at reference 
  632. pointB. The interface signal at A shall be one of those specified in 
  633. RecommendationG.707. The physical characteristics of the interface sig-
  634. nals are specified in RecommendationG.957 for optical media and 
  635. RecommendationG.703 for electrical media. The information flows associ-
  636. ated with the SPI function are described with reference to Figure2-2/G.783.
  637.  
  638. FIGURE 2-2/G.783
  639.  
  640.  
  641.  
  642. 2.1.1    Signal flow from B to A
  643.  
  644.     DATA at A is fully formatted STM-N data as specified in 
  645. RecommendationsG.707, G.708 and G.709. DATA is presented together 
  646. with associated TIMING at B by the RST function. The SPI function condi-
  647. tions the DATA for transmission over a particular medium and presents it at 
  648. A.
  649.  
  650.     Parameters relating to the physical status of the interface such as 
  651. transmit fail or transmit degraded (e.g. optical output level, laser bias cur-
  652. rent, other media-specific indicators) shall be reported at S1. For optical 
  653. systems, these parameters are specified in RecommendationG.958. For 
  654. other media, these parameters are for further study.
  655.  
  656. 2.1.2    Signal flow from A to B
  657.  
  658.     The STM-N signal at A is a similarly formatted and conditioned sig-
  659. nal which is degraded within specific limits by transmission over the physi-
  660. cal medium. The SPI function regenerates this signal to form data and 
  661. associated timing at B. The recovered timing is also made available at refer-
  662. ence point T1 to the multiplexer timing source for the purpose of synchro-
  663. nizing the multiplexer reference clock if selected.
  664.  
  665.     If the STM-N signal at A fails, then the receive LOS condition is gen-
  666. erated and passed to reference point S1 and to the RST function at B. The 
  667. criteria for LOS are defined in RecommendationG.958.
  668.  
  669. 2.2    Regenerator Section Termination function (RST)
  670.  
  671.     The RST function acts as a source and sink for the regenerator section 
  672. overhead (RSOH). A regenerator section is a maintenance entity between 
  673. and including two RST functions. The information flows associated with the 
  674. RST function are described with reference to Figure2-3/G.783.
  675.  
  676.     Note 1 û In regenerators, the A1, A2 and C1 bytes may be relayed 
  677. (i.e. passed transparently through the regenerator) instead of being termi-
  678. nated and generated as described below. Refer to RecommendationG.958.
  679.  
  680.     Note 2 û This Recommendation is intended for the general case of an 
  681. inter-station interface. A reduced functionality requirement for an intra-sta-
  682. tion interface is for further study.
  683.  
  684. FIGURE 2-3/G.783
  685.  
  686.  
  687.  
  688. 2.2.1    Signal flow from C to B
  689.  
  690.     DATA at C is an STM-N signal as specified in Recommendations 
  691. G.707, G.708 and G.709, timed from the T0 reference point and having a 
  692. valid multiplex section overhead (MSOH). However, the RSOH bytes 
  693. (i.e.bytesA1, A2, B1, C1, E1, F1, D1 to D3 and some bytes reserved for 
  694. national use (NU) or for future international standardization) are indetermi-
  695. nate in this signal. Figure2-4/G.783 shows the assignment of bytes to 
  696. RSOH and MSOH in the SOH of an STM-N frame. RSOH bytes are set in 
  697. accordance with Recommendation G.708 as part of the RST function to give 
  698. a fully formatted STM-N data and associated timing at B. After all RSOH 
  699. bytes have been set, the RST function shall scramble the STM-N signal 
  700. before it is presented to B. Scrambling is performed according to 
  701. RecommendationG.709, which excludes the first row of the STM-N RSOH 
  702. (9┤Nbytes, including the A1, A2, C1 and some bytes reserved for national 
  703. use or future international standardization) from scrambling.
  704.  
  705. FIGURE 2-4/G.783
  706.  
  707.  
  708.  
  709.     Frame alignment bytes A1 and A2 (3N of each) are generated and inserted 
  710. in the first row of the RSOH.
  711.  
  712.     The STM identifier bytes are placed in their respective C1 byte positions in 
  713. the first row of the RSOH. Each is assigned a unique number to identify the 
  714. binary value of the multi-column, interleave depth co-ordinate, 
  715. ôCö(RecommendationG.708 refers). The C1 byte shall be set to a binary 
  716. number corresponding to its order of appearance in the byte-interleaved 
  717. STM-N frame.  The first to appear in the frame shall be designated 
  718. number1 (00000001). The second shall be designated number2 
  719. (00000010), and so on. If the signal at B is an STM-1 (i.e.N=1) then the 
  720. use of the C1 byte is optional.
  721.  
  722.     The error monitoring byte B1 is allocated in the STM-N for a regenerator 
  723. section bit error monitoring function. This function shall be a bit interleaved 
  724. parity8 (BIP-8) code using even parity as defined in 
  725. RecommendationG.708. The BIP-8 is computed over all bits of the previ-
  726. ous STM-N frame at B after scrambling. The result is placed in byte B1 
  727. position of the RSOH before scrambling.
  728.  
  729.     The order-wire byte E1 derived from the OHA function at reference point 
  730. U1 is placed in byte E1 position of the RSOH. This byte shall be terminated 
  731. at each RST function. Optionally, it provides a 64kbit/s unrestricted chan-
  732. nel and is reserved for voice communication between network elements.
  733.  
  734.     The user channel byte F1 derived from the OHA function at reference point 
  735. U1 is placed in byte F1 position of the RSOH. It is reserved for the network 
  736. provider (for example, for network operations). This byte shall be termi-
  737. nated at each RST function; however, access to the F1 byte is optional at 
  738. regenerators. User channel specifications are for further study. Special 
  739. usage, such as the identification of a failed section in a simple backup mode 
  740. while the operations support system is not deployed or not working, is for 
  741. further study. An example of such usage is given in AppendixI.
  742.  
  743.     The three Data communications channel bytes derived from the Message 
  744. Communications function at reference point N are placed in bytes D1-D3 
  745. positions of the RSOH. These bytes are allocated for data communication 
  746. and shall be used as one 192kbit/s message-oriented channel for alarms, 
  747. maintenance, control, monitor, administration, and other communication 
  748. needs between RST functions.  This channel is available for internally gen-
  749. erated, externally generated, and manufacturer specific messages. The pro-
  750. tocol stack used shall be as specified in RecommendationG.784.
  751.  
  752.     Certain RSOH bytes are presently reserved for national use or for future 
  753. international standardization, as defined in RecommendationG.708. One or 
  754. more of these bytes may be derived from the OHA function at reference 
  755. point U1. The unused bytes in the first row of the STM-N signal, which are 
  756. not scrambled for transmission, shall be set to 10101010 when not used for 
  757. a particular purpose. No pattern is specified for the other unused bytes when 
  758. not used for a particular purpose.
  759.  
  760.     If a logical all-ONEs DATA signal is received from an MST function (or an 
  761. RST function in the case of a regenerator) at reference pointC, a multiplex 
  762. section alarm indication signal (MS-AIS) data signal shall be applied at ref-
  763. erence pointB.
  764.  
  765. 2.2.2    Signal flow from B to C
  766.  
  767.     Fully formatted and regenerated STM-N data and associated timing is 
  768. received at B from the SPI function. The RST function recovers frame 
  769. alignment and identifies the frame start positions in the data at C. The STM-
  770. N signal is first descrambled (except for the first row of the RSOH) and then 
  771. the RSOH bytes are recovered before presenting the framed STM-N data 
  772. and timing at C.
  773.  
  774.     Frame alignment is found by searching for the A1 and A2 bytes con-
  775. tained in the STM-N signal. The framing pattern searched for may be a sub-
  776. set of the A1 and A2bytes contained in the STM-N signal. The frame signal 
  777. is continuously checked with the presumed frame start position for align-
  778. ment. If in the in-frame state, the maximum out-of-frame (OOF) detection 
  779. time shall be 625╡s for a random unframed signal. The algorithm used to 
  780. check the alignment shall be such that, under normal operation, a 10-3 
  781. (Poisson type) error ratio will not cause a false OOF more than once per six 
  782. minutes. If in the OOF state, the maximum frame alignment time shall be 
  783. 250╡s for an error-free signal with no emulated framing patterns. The algo-
  784. rithm used to recover from OOF shall be such that the probability for false 
  785. frame recovery with a random unframed signal is no more than 10-5 per 
  786. 250╡s time interval.
  787.  
  788.     If the OOF state persists for [TBD] milliseconds, a loss of frame 
  789. (LOF) state shall be declared. To provide for the case of intermittent OOFs, 
  790. the integrating timer shall not be reset to zero until an in-frame condition 
  791. persists continuously for [TBD] milliseconds. Once in a LOF state, this state 
  792. shall be left when the in-frame state persists continuously for [TBD]  milli-
  793. seconds.
  794.  
  795.     Note û Time intervals [TBD] are for further study. Values in the range 
  796. 0 to 3 ms have been proposed.
  797.  
  798.     OOF events shall be reported at reference point S2 for performance 
  799. monitoring filtering in the SEMF. A LOF condition shall be reported at ref-
  800. erence pointS2 for alarm filtering in the SEMF.
  801.  
  802.     The STM identifier C1 bytes are present in the RSOH within the 
  803. STM-N signal; however, processing of the C1bytes is not required.
  804.  
  805.     The error monitoring byte B1 is recovered from the RSOH after 
  806. descrambling and compared with the computed BIP-8 over all bits of the 
  807. previous STM-N frame at B before descrambling. Any errors are reported at 
  808. reference pointS2 as the number of errors within the B1byte per frame. The 
  809. B1byte shall be monitored and recomputed at every RST function.
  810.  
  811.     The order-wire byte E1 is recovered from the RSOH and passed to the 
  812. OHA function at reference point U1.
  813.  
  814.     The user channel byte F1 is recovered from the RSOH and passed to 
  815. the OHA function at reference pointU1.
  816.  
  817.     The Data communications channel bytes D1-D3 are recovered from 
  818. the RSOH and passed to the message communications function at reference 
  819. pointN.
  820.  
  821.     One or more of the bytes for national use or future international stan-
  822. dardization may be recovered from the STM-N and may be passed to the 
  823. OHA function at reference pointU1. The RST function shall be capable of 
  824. ignoring these bytes.
  825.  
  826.     If loss of signal (LOS) or loss of frame (LOF) is detected, then a logi-
  827. cal all ONEs signal shall be applied at the data signal output at reference 
  828. point C towards the MST function within a certain time interval which is for 
  829. further study. Upon termination of the above failure conditions, the logical 
  830. all ONEs signal shall be removed within a certain time interval which is for 
  831. further study.
  832.  
  833. 2.3    Multiplex section termination function (MST)
  834.  
  835.     The MST function acts as a source and sink for the multiplex section 
  836. overhead (MSOH). A multiplex section is a maintenance entity between and 
  837. including two MST functions. The information flows associated with the 
  838. MST function are described with reference to Figure2-5/G.783.
  839.  
  840.     Note û This Recommendation is intended for the general case of an 
  841. inter-station interface. A reduced functionality requirement for an intra-sta-
  842. tion interface is 
  843.  
  844. FIGURE 2-5/G.783
  845.  
  846.  
  847.  
  848. 2.3.1    Signal flow from D to C
  849.  
  850.     Data at reference point D is an STM-N signal as specified in Recom-
  851. mendations G.707 and G.708, timed from the T0 reference point, having a 
  852. payload constructed as in RecommendationG.709, but with indeterminate 
  853. MSOH bytes (i.e.bytesB2, K1, K2, D4 to D12, Z1, Z2, E2, and bytes 
  854. reserved for national use or future international standardization) and inde-
  855. terminate RSOH bytes. Figure2-4/G.783 shows the assignment of bytes to 
  856. MSOH in the SOH of an STM-N frame. The MSOH bytes are set in accor-
  857. dance with RecommendationG.708 as part of the MST function. The result-
  858. ing STM-N data and associated timing are presented at C.
  859.  
  860.     The error monitoring byte B2 is allocated in the STM-N for a multi-
  861. plex section bit error monitoring function. This function shall be a bit inter-
  862. leaved parity (BIP-24N) code using even parity as defined in 
  863. RecommendationG.708. The BIP-24N is computed over all bits (except 
  864. those in the RSOH bytes) of the previous STM-N frame and placed in the 
  865. 3┤N respective B2 byte positions of the current STM-N frame.
  866.  
  867.     The automatic protection switching bytes derived from the multiplex 
  868. section protection (MSP) function at reference pointD are placed in the K1 
  869. and K2 byte positions. Bits 6 to 8 of the K2 byte are reserved for future use 
  870. for drop and insert and nested protection switching. Note that codes111 and 
  871. 110 will not be assigned to bits6, 7, and 8 of K2 for protection switching 
  872. since they are used for MS-AIS detection and MS-FERF indication.
  873.  
  874.     The nine data communications channel bytes issued by the message 
  875. communications function are placed consecutively in the D4 to D12 byte 
  876. positions. This should be considered as a single message based channel for 
  877. alarms, maintenance, control, monitoring, administration, and other com-
  878. munication needs. It is available for internally generated, externally gener-
  879. ated, and manufacturer specific messages. The protocol stack used shall be 
  880. in accordance with the specifications given in RecommendationG.784. 
  881. Regenerators are not required to access this DCC. The nine DCC bytes may 
  882. alternatively be issued by the overhead access function via the U2 reference 
  883. point to provide a transparent data channel by using an appropriate OHA 
  884. interface.
  885.  
  886.     The N┤6 spare bytes issued by the OHA function at reference point 
  887. U2 are placed in the (3┤N) Z1 and (3┤N) Z2 byte positions. These bytes 
  888. are reserved for future use and currently have no defined value.
  889.  
  890.     The order-wire byte is issued by the OHA function at reference point 
  891. U2 and is placed in the E2 byte position. It provides an optional 64kbit/s 
  892. unrestricted channel and is reserved for voice communications between ter-
  893. minal locations.
  894.  
  895.     Certain MSOH bytes are presently reserved for national use or for 
  896. future international standardization, as defined in RecommendationG.708. 
  897. One or more of these bytes may be derived from the OHA function at refer-
  898. ence pointU2. No patterns are specified for these bytes when they are not 
  899. used.
  900.  
  901.     If a logical all ONEs data signal is received at reference point D, an 
  902. AU path alarm indication signal (AU PATH AIS) shall be applied at the data 
  903. signal output at reference pointC.
  904.  
  905.     If the signal fail (SF) defect at reference point D (see º 2.3.2) is 
  906. detected, then MS-FERF shall be applied within 250╡s at the data signal 
  907. output at reference pointC. MS-FERF is defined as an STM-N signal with 
  908. the code110 in bit positions6, 7 and 8 of byteK2.
  909.  
  910. 2.3.2    Signal Flow from C to D
  911.  
  912.     The framed STM-N data signal whose RSOH bytes have already been 
  913. recovered in the RST function is received at reference pointC from the RST 
  914. function together with the associated timing. The MST function recovers the 
  915. MSOH bytes. Then the STM-N data and associated timing are presented at 
  916. reference pointD.
  917.  
  918.     The 3N error monitoring B2 bytes are recovered from the MSOH. A 
  919. BIP-24N code is computed for the STM-Nframe. The computed BIP-24N 
  920. value for the current frame is compared with the recovered B2bytes from 
  921. the following frame and errors are reported at reference pointS3 as number 
  922. of errors within the B2bytes per frame for performance monitoring filtering 
  923. in the synchronous equipment management function.
  924.  
  925.     The BIP-24N errors are also processed within the MST function to 
  926. detect excessive BER and signal degrade (SD) defects.
  927.  
  928.     An Excessive BER defect should be detected if the equivalent BER 
  929. exceeds a threshold of 10-3. An SD defect should be detected if the equiva-
  930. lent BER exceeds a preset threshold in the range of 10-5 to 10-9. Maximum 
  931. detection time requirements for the BER calculation are listed in Table2-1/
  932. G.783. The SD defect should be applied at reference point D. Excessive 
  933. BER and SD defects should be reported at reference point S3 for alarm fil-
  934. tering in the synchronous equipment management function.
  935.  
  936.     Note û The figures above and in Table 2-1/G.783 are based on a Pois-
  937. son distribution of errors. Studies have shown that error distributions in 
  938. practice tend to be bursty. Derivation of BER values from BIP measure-
  939. ments depends on the error distribution; the relevant studies are in the prov-
  940. ince of Study GroupXVIII.
  941.  
  942.  
  943.  
  944.     Automatic protection switching bytes K1 and K2 are recovered from 
  945. the MSOH at C and are passed to the MSP function at reference pointD.
  946.  
  947.     The multiplex section data communications channel bytes D4 to D12 
  948. are recovered from the MSOH and are passed to the message communica-
  949. tions function at reference pointP. Alternatively, they may be passed to the 
  950. overhead access function via reference pointU2.
  951.  
  952.     The N┤6 Spare bytes Z1 and Z2 may be recovered from the STM-N 
  953. signal and may be passed to the OHA function at reference pointU2. These 
  954. bytes are reserved for future use and currently have no defined value.
  955.  
  956.     The order-wire byte E2 is recovered from the MSOH and is passed to 
  957. the OHA function at reference pointU2.
  958.  
  959.     One or more of the bytes reserved for national use or for future inter-
  960. national standardization may be recovered from the STM-N signal and may 
  961. be passed to the OHA function at reference pointU2. The MST function 
  962. shall be capable of ignoring these bytes.
  963.  
  964.     An MS-AIS defect shall be detected by the MST function when the 
  965. pattern 111 is observed in bits 6, 7 and 8 of byteK2 in at least three consec-
  966. utive frames. Removal of the MS-AIS defect shall take place when any pat-
  967. tern other than the code111 in bits 6, 7 and 8 of byteK2 is received in at 
  968. least three consecutive frames.
  969.  
  970.     An incoming MS-FERF defect shall be detected by the MST function 
  971. when the pattern 110 is observed in bits6, 7 and 8 of byteK2 in at least 
  972. three consecutive frames. Removal of MS-FERF defect shall take place 
  973. when any pattern other than 110 in bits6, 7 and 8 of byteK2 is received in 
  974. at least three consecutive frames.
  975.  
  976.     The MS-AIS and MS-FERF defects shall be reported at reference 
  977. point S3 for alarm filtering in the synchronous equipment management 
  978. function.
  979.  
  980.     If MS-AIS or Excessive BER is detected, then a logical all ONEs 
  981. DATA signal and a signal fail condition shall be applied at reference 
  982. pointD. It should be possible to disable the insertion of FERF at reference 
  983. pointC and AIS at reference pointD on detection of excessive BER defect 
  984. by a configuration command from the SEMF.
  985.  
  986. 2.4    Multiplex section protection function (MSP)
  987.  
  988.     The MSP function provides protection for the STM-N signal against 
  989. channel-associated failures within a multiplex section, i.e.the RST, SPI 
  990. functions and the physical medium from one MST function where section 
  991. overhead is inserted to the other MST function where that overhead is termi-
  992. nated.
  993.  
  994.     The MSP functions at both ends operate the same way, by monitoring 
  995. STM-N signals for failures, evaluating the system status taking into consid-
  996. eration the priorities of failure conditions and of external and remote switch 
  997. requests, and switching the appropriate channel to the protection section. 
  998. The two MSP functions communicate with each other via a bit-oriented pro-
  999. tocol defined for the MSP bytes (K1 and K2 bytes in the MSOH of the pro-
  1000. tection section). This protocol is described in ºA.1 of AnnexA, for the 
  1001. various protection switching architectures and modes defined in 
  1002. RecommendationG.782.
  1003.  
  1004.     The signal flow associated with the MSP function is described with 
  1005. reference to Figure 2-6/G.783. The MSP function receives control parame-
  1006. ters and external switch requests at the S14 reference point from the syn-
  1007. chronous equipment management function and outputs status indicators at 
  1008. S14 to the synchronous equipment management function, as a result of 
  1009. switch commands described in ºA.2 of AnnexA.
  1010.  
  1011. FIGURE 2-6/G.783
  1012.  
  1013.  
  1014.  
  1015. 2.4.1    Signal flow from E to D
  1016.  
  1017.     Data at reference point E is an STM-N signal, timed from the T0 ref-
  1018. erence point, with indeterminate MSOH and RSOH bytes.
  1019.  
  1020.     For 1 + 1 architecture, the signal received at E from the SA function is 
  1021. bridged permanently at D to both working and protection MST functions.
  1022.  
  1023.     For 1 : n architecture, the signal received at E from each working SA 
  1024. is passed at D to its corresponding MST. The signal from an extra traffic SA 
  1025. (if provisioned) is connected to the protection MST. When a bridge is 
  1026. needed to protect a working channel, the signal at E from that working SA is 
  1027. bridged at D to the protection MST and the extra traffic channel is termi-
  1028. nated.
  1029.  
  1030.     The K1 and K2 bytes generated according to the rules in º 1 of Annex 
  1031. A are presented at D to the protection MST.
  1032.  
  1033. 2.4.2    Signal flow from D to E
  1034.  
  1035.     Framed STM-N signals (data) whose RSOH and MSOH bytes have 
  1036. already been recovered are presented at the reference pointD along with 
  1037. incoming timing references. The failure conditions SF and SD are also 
  1038. received at the reference pointD from all MST functions.
  1039.  
  1040.     Also, the recovered K1 and K2 bytes from the protection MST func-
  1041. tion are presented at the reference pointD.
  1042.  
  1043.     Under normal conditions, MSP passes the data and timing from the 
  1044. working MST functions to their corresponding working SA functions at the 
  1045. reference pointE. The data and timing from the protection section is passed 
  1046. to the extra traffic SA, if provisioned in a 1:n MSP architecture, or else it is 
  1047. terminated.
  1048.  
  1049.     If a switch is to be performed, then the data and timing received from 
  1050. the protection MST at reference pointD is switched to the appropriate 
  1051. working channel SA function at E, and the signal received from the working 
  1052. MST at D is terminated.
  1053.  
  1054. 2.4.3    Switch initiation criteria
  1055.  
  1056.     Automatic protection switching is based on the failure conditions of 
  1057. the working and protection sections. These conditions, signal fail (SF) and 
  1058. signal degrade (SD), are provided by the MST functions at reference 
  1059. pointD.  Detection of these conditions is described in º2.3.
  1060.  
  1061.     The protection switch can also be initiated by switch commands 
  1062. received via the synchronous equipment management function.
  1063.  
  1064. 2.4.4    Switching time
  1065.  
  1066.     Protection switching shall be completed within 50 ms of detection of 
  1067. an SF or SD condition that initiates a switch.
  1068.  
  1069. 2.4.5    Switch restoral
  1070.  
  1071.     In the revertive mode of operation, the working channel shall be 
  1072. restored, i.e. the signal on the protection section shall be switched back to 
  1073. the working section, when the working section has recovered from failure. 
  1074. Restoral allows other failed working channels or an extra traffic channel to 
  1075. use the protection section.
  1076.  
  1077.     To prevent frequent operation of the protection switch due to an inter-
  1078. mittent failure (e.g. BER fluctuating around the SD threshold), a failed sec-
  1079. tion must become fault-free (i.e.BER less than a restoral threshold). After 
  1080. the failed section meets this criterion, a fixed period of time shall elapse 
  1081. before it is used again by a working channel. This period, called wait-to-
  1082. restore (WTR) period should be of the order of 5-12minutes and should be 
  1083. capable of being set. An SF or SD condition shall override the WTR.
  1084.  
  1085. 2.5    Section adaptation function (SA)
  1086.  
  1087.     This function provides adaptation of higher order paths into adminis-
  1088. trative units (AUs), assembly and disassembly of AU groups, byte inter-
  1089. leaved multiplexing and demultiplexing, and pointer generation, 
  1090. interpretation and processing. The signal flow associated with the SA func-
  1091. tion is described with reference to Figure2-7/G.783.
  1092.  
  1093. FIGURE 2-7/G.783
  1094.  
  1095.  
  1096.  
  1097. 2.5.1     Signal flow from F to E
  1098.  
  1099.     The higher order paths at reference point F are mapped into AUs 
  1100. which are incorporated into AU groups. N such AUGs are byte interleaved 
  1101. to form an STM-N payload at the reference point E. The byte interleaving 
  1102. process shall be as specified in RecommendationG.709. The frame offset 
  1103. information is used by the PG function to generate pointers according to 
  1104. pointer generation rules in RecommendationG.709. STM-N data at E is 
  1105. synchronized to timing from the T0 reference point. If an all ONEs data sig-
  1106. nal is applied at reference pointF (i.e.invalid frame offset due to loss of AU 
  1107. pointer), an AU path AIS shall be applied at reference pointE.
  1108.  
  1109. 2.5.2    Signal flow from E to F
  1110.  
  1111.     STM-N payloads received at reference point E are disinterleaved and 
  1112. the VC-3/4s recovered using the AU pointers. The latter process must allow 
  1113. for the case of continuously variable frame offset which occurs when the 
  1114. received STM-N signal has been derived from a source which is plesiochro-
  1115. nous with the local clock reference.
  1116.  
  1117.     The PP function provides accommodation for wander and plesiochro-
  1118. nous offset in the received signal with respect to the multiplexer timing ref-
  1119. erence. This function may be null in some applications where the timing 
  1120. reference is derived from the incoming STM-N signal, i.e.loop timing.
  1121.  
  1122.     The PP function can be modelled as a data buffer which is being writ-
  1123. ten with data, timed from the received VC clock, and read by a VC clock 
  1124. derived from reference pointT0. When the write clock rate exceeds the read 
  1125. clock rate the buffer gradually fills and vice-versa. Upper and lower buffer 
  1126. occupancy thresholds determine when pointer adjustment should take place. 
  1127. The buffer is required to reduce the frequency of pointer adjustments in a 
  1128. network. When the data in the buffer rises above the upper threshold for a 
  1129. particular VC, the associated frame offset is decremented by one byte for a 
  1130. VC-3 or three bytes for a VC-4, and the corresponding number of bytes are 
  1131. read from the buffer. When the data in the buffer falls below the lower 
  1132. threshold for a particular VC, the associated frame offset is incremented by 
  1133. one byte for a VC-3 or three bytes for a VC-4 and the corresponding number 
  1134. of read opportunities are cancelled. The pointer hysteresis threshold spacing 
  1135. allocation is specified in º7.1.4.1.
  1136.  
  1137.     The mechanism of pointer processing is illustrated as a flow chart in 
  1138. Figure 2-8/G.783.
  1139.  
  1140.     The algorithm for pointer detection is defined in Annex B/G.783. Two 
  1141. failure conditions can be detected by the pointer interpreter:
  1142.  
  1143. û    loss of pointer (LOP),
  1144.  
  1145. û    AU Path AIS.
  1146.  
  1147.     If either or both of these failure conditions are detected then a logical 
  1148. all ONEs signal shall be applied at reference pointF. These defects shall be 
  1149. reported at reference point S4 for alarm filtering at the synchronous equip-
  1150. ment management function. Pointer justification events (PJE) are also 
  1151. reported at reference pointS4 for performance monitoring filtering. PJEs 
  1152. need only be reported for one selected AU-3/4 out of an STM-N signal.
  1153.  
  1154.     It should be noted that a mismatch between provisioned and received 
  1155. AU type will result in a LOP failure condition.
  1156.  
  1157. 3    Higher order path functions
  1158.  
  1159.     Higher order paths have been defined according to two types of vir-
  1160. tual container (VC-3 and VC-4). These VCs can be created in two ways:
  1161.  
  1162. i)    by direct mappings in AUs (direct mappings are defined for 3rd and 
  1163. 4th level signals and the locked mode level1 mappings are also 
  1164. direct);
  1165.  
  1166. ii)    by mapping of lower level signals into TUs which are then mapped 
  1167. into AUs.
  1168.  
  1169.     These possibilities are illustrated in Figure 2-1/G.783.
  1170.  
  1171. 3.1    Higher order Path Connection function (HPC-n)
  1172.  
  1173.     HPC-n is the function which assigns assembled higher order VCs of 
  1174. level n (n = 3 or 4) to available VC-n capacity on a multiplex section. The 
  1175. inclusion of the HPC-n function constitutes a significant functional differ-
  1176. ence among multiplexer types illustrated in Figures3-1/G.782 to 3-7/G.782.
  1177.  
  1178.     Figure 3-1/G.783 illustrates reference points associated with the 
  1179. HPC-n. VC-ns coming from reference pointG are assigned to available VC-
  1180. n capacity at reference point F. Conversely, the VC-ns coming from refer-
  1181. ence pointF are assigned to available VC-n capacity at reference pointG. 
  1182. The signal format at reference pointsG and F are thus similar, differing only 
  1183. in the logical sequence of VC-ns.
  1184.  
  1185. FIGURE 2-8/G.783
  1186.  
  1187.  
  1188.  
  1189. FIGURE 3-1/G.783
  1190.  
  1191.  
  1192.  
  1193.     The assignment of VC-ns at reference point G to VC-n capacities at refer-
  1194. ence point F and vice versa is defined as the connection pattern which can 
  1195. be described by a two column connection matrix CM (Vi, Vj), where Vi 
  1196. identifies the i-thVC channel at reference point F and Vj identifies the j-
  1197. thVC channel at reference pointG. For some connection patterns Vj is fur-
  1198. ther identified by parameters k and l indicating the k-thport in l tributary 
  1199. ports. The multiplexer types are described below in terms of the CM.
  1200.  
  1201.     At reference point S5 the following primitives are possible:
  1202.  
  1203. û    Set matrix, which causes a particular port assignment to be made 
  1204. according to the connection matrix (CM) (from SEMF to HPC-n).
  1205.  
  1206. û    Request CM report (from SEMF to HPC-n).
  1207.  
  1208. û    Report CM (to SEMF from HPC-n).
  1209.  
  1210.     A clock signal is provided to HPC-n at reference point T0 from 
  1211. theMTS.
  1212.  
  1213.     Depending on the multiplexer type, there may be a degree of flexibil-
  1214. ity in the connection pattern which can be exercised when HPC-n is config-
  1215. ured. Thus, various multiplexers will have various constraints in the 
  1216. parameters i, j, k, l of the connection matrix described above. Multiplexer 
  1217. typesI, II, and IV assume HPC-n is null. Multiplexer typesIIa and III 
  1218. assume a configurable connection pattern. The functions of the HPC-n are 
  1219. described below in terms of signal flow and multiplexer types.
  1220.  
  1221. 3.1.1    Signal flow from G to F
  1222.  
  1223.     HPC-n assigns assembled higher order VC-ns coming from reference 
  1224. pointG to available VC-n capacity at reference pointF. This assignment is 
  1225. based on the connection pattern (fixed or configurable) established.
  1226.  
  1227. 3.1.2    Signal flow from F to G
  1228.  
  1229.     This is similar to the one described in º 3.1.1 above.
  1230.  
  1231. 3.1.3    HPC-n for multiplexer types IIIa and IIIb
  1232.  
  1233.      This multiplexer performs an add and drop function as illustrated in 
  1234. Figures 3-5/G.782, 3-6/G.782 and 3-2/G.783.
  1235.  
  1236. FIGURE 3-2/G.783
  1237.  
  1238.  
  1239.  
  1240.     Signals at FW and FE reference points support a VC-n capacity equivalent 
  1241. to the STM-N aggregate signal of the multiplexer. The add/drop ports GW1-
  1242. GWn and GE1-GEm generally support lower VC-n capacity.
  1243.  
  1244.     In the general case of a type IIIa/b add/drop multiplexer a cross-connect 
  1245. function will be performed where any of the Vi channels at FW and FE can 
  1246. be dropped to any of the Vj channels at GW1-GWn or GE1-GEm.
  1247.  
  1248.     A specific example of a type IIIa/b multiplexer is one where, in the connec-
  1249. tion matrix CM (Vi, Vj), Vi identifies one of the VC-n channels at FW and 
  1250. FE and Vj identifies one of the VC-n channels at GW1-GWn and 
  1251. GE1-GEm. This implies that Vi at FW is dropped to Vj at GW1-GWn and 
  1252. Vi at FE is dropped to Vj at GE1-GEm. All the Vi channels at FW which are 
  1253. not dropped are passed through to the corresponding Vi channels at FE. The 
  1254. number of rows in CM (Vi, Vj) is the same as the number of VC-n channels 
  1255. dropped.
  1256.  
  1257. 3.1.4    HPC-n for multiplexer types Ia and IIa
  1258.  
  1259.     These multiplexers perform a consolidation function as illustrated in 
  1260. Figures 3-2/G.782, 3-4/G.782 and 3-3/G.783.
  1261.  
  1262. FIGURE 3-3/G.783
  1263.  
  1264.  
  1265.  
  1266.     The signal at reference point F supports a VC-n capacity equivalent to the 
  1267. STM-M aggregate signal of the multiplexer. The multiplexer portsG1 to Gl 
  1268. each support a VC-n equivalent to STM-N where M>N. The total capacity 
  1269. at G1 to Gl shall not exceed the capacity at F.
  1270.  
  1271.     In the connection matrix CM (Vi, Vjk) for this multiplexer, Vi identifies one 
  1272. of the VC-n channels at F and Vjk identifies the j-thVC-n channel at Gk 
  1273. (k=1, - - - l). This requires that a particular VC-n channel Vjk at G is con-
  1274. nected to a particular channel Vi at F.
  1275.  
  1276. 3.1.5    HPC-n for multiplexer types I, II, and IV
  1277.  
  1278.     These multiplexers perform a terminal multiplexer function as illus-
  1279. trated in Figures 3-1/G.782, 3-3/G.782, 3-7/G.782 and 3-4/G.783.
  1280.  
  1281.     The signal at reference point F supports a VC-n capacity equivalent to 
  1282. the STM-M or STM-N at the aggregate port of the multiplexer. The total 
  1283. capacity at G is the same as that at F.
  1284.  
  1285.     The HPC-n is a null function where Vi = Vj for all values of i and j; 
  1286. i.e. a fixed connection pattern exists between the assembled VCs at G and F.
  1287.  
  1288. FIGURE 3-4/G/783
  1289.  
  1290.  
  1291.  
  1292. 3.2    Higher order path termination function (HPT-n)
  1293.  
  1294.     This function acts as a source and sink for the higher order path over-
  1295. head (VC-n POH, n = 3,4). A higher order path is a maintenance entity 
  1296. defined between two higher order path terminations. The information flows 
  1297. associated with the HPT-n function are described with reference to 
  1298. Figures2-1/G.783 and3-5/G.783.
  1299.  
  1300. FIGURE 3-5/G/783
  1301.  
  1302.  
  1303.  
  1304.     The timing signal is provided from the MTS at the T0 reference point.
  1305.  
  1306. 3.2.1    Signal flow from G to H
  1307.  
  1308.     Data at G is a VC-n (n = 3,4), having a payload as described in Rec-
  1309. ommendations G.708 and G.709, with complete VC-3/4 POH (bytesJ1, B3, 
  1310. C2, G1, F2, H4, Z3, Z4, Z5). These POH bytes are recovered as part of the 
  1311. HPT-n function and the VC-n is forwarded to reference pointH.
  1312.  
  1313.     Bytes J1, G1 and C2 are recovered from the VC-n POH at G and the 
  1314. corresponding information on path trace, path status and signal label are 
  1315. passed via reference pointS6 to the synchronous equipment management 
  1316. function.
  1317.  
  1318.     The G1 byte is illustrated in Recommendation G.709. FEBE informa-
  1319. tion is decoded from bits 1 to 4 of the G1 byte and reported as path termina-
  1320. tion error report at S6. The path FERF information in bit 5 of the G1byte is 
  1321. recovered and reported as remote alarm indication at S6.
  1322.  
  1323.     In the case of payloads requiring multiframe alignment, a multiframe 
  1324. indicator is derived from the H4 byte. The received H4 value is compared to 
  1325. the next expected value in the multiframe sequence. The H4 value is 
  1326. assumed to be in phase when it is coincident with the expected value. If sev-
  1327. eral H4 values are received consecutively not as expected but correctly in 
  1328. sequence with a different part of the multiframe sequence, then subsequent 
  1329. H4 values shall be expected to follow this new alignment. If several H4 val-
  1330. ues are received consecutively not correctly in sequence with any part of the 
  1331. multiframe sequence then a loss of multiframe (LOM) event shall be 
  1332. reported at S6. When several H4 values have been received consecutively 
  1333. correctly in sequence with part of the multiframe sequence, then the event 
  1334. shall be ceased and subsequent H4 values shall be expected to follow the 
  1335. new alignment.
  1336.  
  1337.     Note û The meaning of ôseveralö is that the number should be low 
  1338. enough to avoid excessive delay in re-framing but high enough to avoid re-
  1339. framing due to errors; a value in the range 2 to 10 is suggested.
  1340.  
  1341.     The error monitoring byte B3 is recovered from the VC-n frame. BIP-
  1342. 8 is computed for the VC-n frame. The computed BIP-8 value for the cur-
  1343. rent frame is compared with the recovered B3byte from the following 
  1344. frame and errors are reported at reference point S6 as number of errors 
  1345. within the B3byte per frame for performance monitoring filtering in the 
  1346. synchronous equipment management function.
  1347.  
  1348.     One byte per frame is allocated for user communication purposes. It is 
  1349. derived from the F2 byte and passed via reference pointU3 to the overhead 
  1350. access function.
  1351.  
  1352.     The three bytes Z3, Z4 and Z5 are reserved for future use. Currently 
  1353. they have no defined value at G.
  1354.  
  1355. 3.2.2    Signal flow from H to G
  1356.  
  1357.     Data at H is a VC-n (n = 3,4), having a payload as described in Rec-
  1358. ommendations G.708 and G.709, but with indeterminate VC-3/4 POH 
  1359. (bytesJ1, B3, C2, G1, F2, H4, Z3, Z4, Z5). These POH bytes are set as part 
  1360. of the HPT-n function and the complete VC-n is forwarded to G.
  1361.  
  1362.     Path trace, path status and signal label information, derived from ref-
  1363. erence point S6 are placed in J1, G1 and C2 byte positions respectively.
  1364.  
  1365.     If the path termination error report indicates an errored block, then the 
  1366. FEBE (bits 1 to 4 of the G1 byte) are encoded according to Figure4-2/
  1367. G.709. If AU path AIS at G is reported, then a path FERF indication should 
  1368. be sent in bit5 of the G1byte.
  1369.  
  1370.     Bit interleaved parity (BIP-8) is computed over all bits of the previous 
  1371. VC-n and placed in B3 byte position.
  1372.  
  1373.     A multiframe indicator is generated as described in Recommendation 
  1374. G.709 and placed in the H4 byte position.
  1375.  
  1376.     One byte per frame is allocated for user communication purposes. It is 
  1377. derived from reference point U3 and placed in the F2byte position.
  1378.  
  1379.     The three bytes Z3, Z4 and Z5 are reserved for future use. Currently 
  1380. they have no defined value at G.
  1381.  
  1382. 3.3    Higher order path adaptation function (HPA-m/n)
  1383.  
  1384.     HPA-m/n (m =1, 2 or 3; n = 3 or 4) defines the TU pointer processing. 
  1385. It may be divided into three functions:
  1386.  
  1387. û    pointer generation;
  1388.  
  1389. û    pointer interpretation;
  1390.  
  1391. û    frequency justification.
  1392.  
  1393.     The format for TU pointers, their roles for processing, and mappings 
  1394. of VCs are described in RecommendationG.709.
  1395.  
  1396.     Figure 3-6/G.783 illustrates the HPA-m/n function.
  1397.  
  1398. FIGURE 3-6/G.783
  1399.  
  1400.  
  1401.  
  1402. 3.3.1    Signal flow from J to H
  1403.  
  1404.     The HPA-m/n function assembles VCs of lower order m (m = 11, 12, 
  1405. 2, 3) as TU-m into VCs of higher order n (n = 3 or 4).
  1406.  
  1407.     The frame offset in bytes between a lower order VC and higher order 
  1408. VC is indicated by a TU pointer which is assigned to that particular lower 
  1409. orderVC. The method of pointer generation is described in 
  1410. RecommendationG.709.
  1411.  
  1412. 3.3.2    Signal flow from H to J
  1413.  
  1414.     The HPA-m/4 function disassembles VC-4 into VCs of lower order m 
  1415. (m=11,12,2, 3). HPA-m/3 disassembles VC-3 into VCs of lower order m 
  1416. (m=11,12, 2). The TU pointer of each lower order VC is decoded to pro-
  1417. vide information about the frame offset in bytes between the higher order 
  1418. VC and the individual lower order VCs. The method of pointer interpreta-
  1419. tion is described in RecommendationG.709. This process must allow for 
  1420. continuous pointer adjustments when the clock frequency of the node where 
  1421. the TU was assembled is different from the local clock reference. The fre-
  1422. quency difference between these clocks affects the required size of the data 
  1423. buffer whose function is described below.
  1424.  
  1425.     The PP function can be modelled as a data buffer which is being writ-
  1426. ten with data, timed from the received VC clock, and read by a VC clock 
  1427. derived from reference point T0. When the write clock rate exceeds the read 
  1428. clock rate the buffer gradually fills and vice versa. Upper and lower buffer 
  1429. occupancy thresholds determine when pointer adjustment should take place. 
  1430. The buffer is required to reduce the frequency of pointer adjustments in a 
  1431. network. When the data in the buffer rises above the upper threshold for a 
  1432. particular VC, the associated frame offset is decremented by one byte and 
  1433. an extra byte is read from the buffer. When the data in the buffer falls below 
  1434. the lower threshold for a particular VC, the associated frame offset is incre-
  1435. mented by one byte and one read opportunity is cancelled. The threshold 
  1436. spacing is for further study.
  1437.  
  1438.     The algorithm for pointer detection is defined in Annex B. Two fail-
  1439. ure conditions can be detected by the pointer interpreter:
  1440.  
  1441. û    loss of pointer (LOP),
  1442.  
  1443. û    TU path AIS.
  1444.  
  1445.     If either or both of these failure conditions are detected then a logical 
  1446. all ONEs signal shall be applied at reference pointJ. These defects shall be 
  1447. reported at reference pointS7 for alarm filtering at the synchronous equip-
  1448. ment management function. Pointer justification events (PJE) shall be 
  1449. reported at reference point S7 for performance monitoring filtering. PJEs 
  1450. need only be reported for one selected TU-1/2/3 out of an STM-N signal 
  1451. and only if PJEs are not reported at the AU level.
  1452.  
  1453.     It should be noted that a mismatch between provisioned and received 
  1454. TU type will result in a Loss of Pointer (LOP) defect. LOP is reported to the 
  1455. Synchronous Equipment Management function through the S7 reference 
  1456. point.  Pointer hysteresis threshold spacing allocation is specified in 
  1457. º7.1.4.2.
  1458.  
  1459. 4    Lower order path functions
  1460.  
  1461.     Recommendations G.708 and G.709 define five basic path capacities 
  1462. corresponding to RecommendationG.702 digital hierarchy levels and 
  1463. denoted by indices11, 12, 2, 3 and 4. In addition, the concatenation function 
  1464. which is defined for level 2 makes possible the creation of 21 new path 
  1465. capacities. User signals are adapted to form containers which are then allo-
  1466. cated to higher order paths. The functions involved in path creation and 
  1467. assignment are described in this section.
  1468.  
  1469.     Note û A VC-3 path can be a lower order or a higher order path, 
  1470. depending on its application. When VC-1s or VC-2s are multiplexed into a 
  1471. VC-3, the VC-3 constitutes a higher order path; when a VC-3 is multiplexed 
  1472. into a VC-4, it constitutes a lower order path.
  1473.  
  1474. 4.1    Lower order path connection function (LPC-m)
  1475.  
  1476.     LPC-m is the function which assigns VCs of level m (m = 1, 2 or 3) to 
  1477. available VC-m capacity in higher order paths. There is no LPC-m function 
  1478. in multiplexer typesII, IIa and IV and the LPC-m function in typeI multi-
  1479. plexer is null. The LPC-m function in multiplexer typeIII is defined to 
  1480. allow add/drop operations between tributaries and one or both aggregate 
  1481. ports in support of bus and ring network topologies.
  1482.  
  1483.     Figure 4-1/G.783 illustrates reference points associated with the LPC-
  1484. m. VC-ms coming from reference pointK are assigned to available VC-m 
  1485. capacity at reference pointJ and vice versa. The signal format at reference 
  1486. pointsK and J are thus similar, differing only in the logical sequence ofVC-
  1487. ms.
  1488.  
  1489. FIGURE 4-1/G.783
  1490.  
  1491.  
  1492.  
  1493.     The assignment of VC-ms at reference point K to VC-m capacities at refer-
  1494. ence point J and vice-versa is defined as the connection pattern which can 
  1495. be described by a two column connection matrix CM (Vi, Vj), where Vi 
  1496. identifies the i-thVC channel at reference pointJ and Vj identifies the j-
  1497. thVC channel at reference pointK. The multiplexer types are described 
  1498. below in terms of the CM.
  1499.  
  1500.     At reference point S8 the following primitives are possible:
  1501.  
  1502. û    Set matrix, which causes a particular port assignment to be made 
  1503. according to the connection matrix (CM) (from SEMF to LPC-m)
  1504.  
  1505. û    Request CM report (from SEMF to LPC-m)
  1506.  
  1507. û    Report CM (to SEMF from LPC-m).
  1508.  
  1509.     A clock signal is provided to LPC-m at reference point T0 from 
  1510. theMTS.
  1511.  
  1512.     Depending on the multiplexer type, there may be a degree of flexibil-
  1513. ity in the connection pattern which can be exercised when LPC-m is config-
  1514. ured. Thus, various multiplexers will have various constraints in the 
  1515. parametersi, j of the connection matrix described above.
  1516.  
  1517. 4.1.1    Signal flow from K to J
  1518.  
  1519.     LPC-m assigns assembled VC-ms coming from reference point K to 
  1520. available VC-m capacity at reference pointJ. This assignment is based on 
  1521. the connection pattern (fixed or configurable) established.
  1522.  
  1523. 4.1.2    Signal flow from J to K
  1524.  
  1525.     This is similar to the one described in º 4.1.1.
  1526.  
  1527. 4.1.3    Connection matrix for multiplexer type III
  1528.  
  1529.     The connection matrix is illustrated in Figure 4-2/G.783. The signals 
  1530. at reference points J West and J East each support a VC-m capacity equiva-
  1531. lent to the higher order paths which have to be accessed. The signal at refer-
  1532. ence pointK supports a similar or lower capacity. The connection function 
  1533. allows VC-ns to be dropped from and inserted into JEast and JWest to and 
  1534. from reference pointK without rearranging the through traffic. The connec-
  1535. tion pattern can be described by the matrix (Vj, Vij) where Vj identifies the 
  1536. j-thVC-n channel at K and the Vij represents the j-thchannel at reference 
  1537. point J West if i =1, the j-th channel at reference point J East if i=2 and the 
  1538. j-th channel at JEast and/or JWest if i=3; i.e. in the direction from K to 
  1539. JEast/JWest, transmission is on both channels while in the direction from J 
  1540. East/JWest to K, the JEast or JWest channel is selected.
  1541.  
  1542.     Note û The mode of operation selected when i = 3 enables type III 
  1543. multiplexers to operate in a ring configuration with path layer protection 
  1544. provided by the alternative route and without intervention from higher layer 
  1545. functions.
  1546.  
  1547. FIGURE 4-2/G.783
  1548.  
  1549.  
  1550.  
  1551. 4.2    Lower order path termination function (LPT-m)
  1552.  
  1553.     The LPT-m function creates a VC-m (m = 1, 2, or 3) by generating and add-
  1554. ing POH to a container C-m. In the other direction of transmission it termi-
  1555. nates and processes the POH to determine the status of the defined path 
  1556. attributes. The POH formats are defined in RecommendationsG.708 
  1557. andG.709. The information flows associated with the LPT function are 
  1558. described in Figure4-3/G.783.
  1559.  
  1560. FIGURE 4-3/G.783
  1561.  
  1562.  
  1563.  
  1564.     Referring to Figure 2-1/G.783, Data at L takes the form of a container C-m 
  1565. (m = 1,2,3) which is synchronized to the timing reference T0.
  1566.  
  1567.     Synchronously adapted information in the form of synchronous containers 
  1568. (data) and the associated container frame offset information (frame offset) 
  1569. are received at reference point L. POH is added to form data which together 
  1570. with the frame offset is passed to reference pointK.
  1571.  
  1572. 4.2.1    Path OH at levels 1 and 2
  1573.  
  1574.     The VC-1/VC-2 POH is carried in the V5 byte as defined in Recom-
  1575. mendation G.709.
  1576.  
  1577. 4.2.1.1    Signal flow from K to L
  1578.  
  1579.     If TU Path AIS is received at K then path AIS condition shall be 
  1580. reported at S9 (TU path AIS detection is described in º3.3) and the all 
  1581. ONEs data signal shall be presented at data (L). Additionally, a path FERF 
  1582. indication shall be sent in bit 8 of V5 in the data in the reverse direction.
  1583.  
  1584.     Bits 5, 6 and 7 of V5 at K shall be detected and reported as signal 
  1585. label at S9.
  1586.  
  1587.     The error monitoring bits 1 and 2 of V5 at K shall be recovered. BIP-
  1588. 2 is computed for the VC-n frame. The computed BIP-2 value for the cur-
  1589. rent frame is compared with the recovered bits1 and2 from the following 
  1590. frame and the number of errors (0, 1 or 2) in the block shall be reported as 
  1591. path termination error report at S9. (Excessive error ratio detection is for 
  1592. further study.)
  1593.  
  1594.     FEBE in bit 3 shall be recovered and reported at S9.
  1595.  
  1596.     The path FERF information in bit 8 shall be recovered and reported as 
  1597. remote alarm indication atS9.
  1598.  
  1599.     Bit 4 is unused. The receiver must be capable of ignoring the value of 
  1600. this bit.
  1601.  
  1602. 4.2.1.2    Signal flow from L to K
  1603.  
  1604.     The signal label presented at S9 shall be inserted in bits 5, 6 and 7 in 
  1605. the V5 byte.
  1606.  
  1607.     BIP-2 shall be calculated on data at L on the previous frame or multi-
  1608. frame and the result transmitted in bits 1 and 2 of the V5byte.
  1609.  
  1610.     If the path termination error report indicates an errored block then 
  1611. FEBE bit (3) shall be set to 1 in the next frame.
  1612.  
  1613. 4.2.2    Path overhead at level 3
  1614.  
  1615.     The VC-m path overhead (for m = 3) is the same as the path overhead 
  1616. for VC-n (n = 3) and is described inº3.2.
  1617.  
  1618. 4.3    Lower order path adaptation functions (LPA-m/n)
  1619.  
  1620.     LPA operates at the access port to a synchronous network or subnet-
  1621. work and adapts user data for transport in the synchronous domain. For 
  1622. asynchronous user data, lower order path adaptation involves bit justifica-
  1623. tion. The LPA-n function directly maps G.703 signals into a higher order 
  1624. container (n=3 or 4). The LPA-m function maps G.703 signals into lower 
  1625. order containers which may subsequently be mapped into higher order con-
  1626. tainers (m=11, 12, 2, 3). The information flows associated with the LPA 
  1627. function are shown in Figure4-4/G.783.
  1628.  
  1629.     (Note û Primary rate signals can be mapped directly into higher order 
  1630. paths using the locked mode mappings:)
  1631.  
  1632. FIGURE 4-4/G.783
  1633.  
  1634.  
  1635.  
  1636.     LPA functions are defined for each of the levels in the existing plesiochro-
  1637. nous hierarchies. Each LPA function defines the manner in which a user sig-
  1638. nal can be mapped into one of a range of synchronous containers C of 
  1639. appropriate size. The container sizes have been chosen for ease of mapping 
  1640. various combinations of sizes into high order containers; see Table4-2/
  1641. G.783. Detailed specifications for mapping user data into containers are 
  1642. given in RecommendationG.709.
  1643.  
  1644.     The LPA type is reported on request to the SEMF through the S10 reference 
  1645. point.
  1646.  
  1647.  
  1648.  
  1649. 4.3.1    Direction M to L or H
  1650.  
  1651.     DATA at M is the user information stream delivered by the PI func-
  1652. tion. Timing of the data is also delivered as timing at M by the PI function. 
  1653. Data is adapted according to one of the LPA functions referred to above. 
  1654. This involves synchronization and mapping of the information stream into a 
  1655. container as described in RecommendationG.709.
  1656.  
  1657.     The container is passed to the reference point L (or H in the case of 
  1658. direct mapping) as data together with frame offset which represents the off-
  1659. set of the container frame with respect to reference pointT0. In byte syn-
  1660. chronous mappings, the frame offset is obtained from the associated framer. 
  1661. In other mappings, a convenient fixed offset can be generated internally.
  1662.  
  1663.     Mapping of overhead and maintenance information from byte syn-
  1664. chronously mapped G.703 signals is for further study.
  1665.  
  1666.     Frame alignment loss (FAL) is reported to the synchronous equipment 
  1667. management function through the S10 reference point (byte sync mapping 
  1668. only). The strategy for FAL detection/indication is described in 
  1669. RecommendationG.706.
  1670.  
  1671. 4.3.2    Direction L or H to M
  1672.  
  1673.     The information stream data at L (or H in the case of direct mapping) 
  1674. is presented as a container together with frame offset. The user information 
  1675. stream is recovered from the container together with the associated clock 
  1676. suitable for tributary line timing and passed to the reference pointM as data 
  1677. (M) and timing (M). This involves de-mapping and desynchronizing as 
  1678. described in RecommendationG.709.
  1679.  
  1680.     Note û Other signals may be required from L to generate overhead 
  1681. and maintenance information for byte-synchronously mapped G.703 sig-
  1682. nals. This is for further study.
  1683.  
  1684.     When path AIS is reported through S10, the LPA function shall gener-
  1685. ate AIS in accordance with the relevant G.700-Series Recommendations.
  1686.  
  1687. 4.4    Physical interface (PI) function
  1688.  
  1689.     This function provides the interface between the multiplexer and the 
  1690. physical medium carrying a tributary signal which may have any of the 
  1691. physical characteristics of those described in RecommendationG.703 and 
  1692. in some cases the signal structure in RecommendationG.704. The informa-
  1693. tion flows for the PI function are described with reference to Figure4-5/
  1694. G.783.
  1695.  
  1696. FIGURE 4-5/G.783
  1697.  
  1698.  
  1699.  
  1700. 4.4.1    Signal flow from M to tributary interface
  1701.  
  1702.     The functions performed by the PI are encoding and adaptation to the 
  1703. physical medium.
  1704.  
  1705.     The PI function takes data and timing at M to form the transmit tribu-
  1706. tary signal. The PI passes the data and timing information to the tributary 
  1707. interface transparently.
  1708.  
  1709. 4.4.2    Signal flow from tributary interface to M
  1710.  
  1711.     The PI function extracts timing from the received tributary signal and 
  1712. regenerates the data. After decoding, it passes the data and timing informa-
  1713. tion to reference pointM. The timing may also be provided at reference 
  1714. point T2 for possible use as a reference in the MTS.
  1715.  
  1716.     In the event of loss of signal (LOS) at the tributary input, AIS in the 
  1717. form of all ONEs is transmitted on data at M accompanied by a suitable ref-
  1718. erence timing signal. LOS is reported at reference pointS11.
  1719.  
  1720. 5    Synchronous equipment management function
  1721.  
  1722.     The synchronous equipment management function (SEMF) provides 
  1723. the means through which the synchronous network element function (NEF) 
  1724. is managed by an internal or external manager. If a network element (NE) 
  1725. contains an internal manager, this manager will be part of the SEMF.
  1726.  
  1727.     The SEMF interacts with the other functional blocks by exchanging 
  1728. information across the Sn reference points. The SEMF contains a number of 
  1729. filters that provide a data reduction mechanism on the information received 
  1730. across the Sn reference points. The filter outputs are available to the agent 
  1731. via managed objects which represent this information. The managed objects 
  1732. also present other management information to and from the agent.
  1733.  
  1734.     Managed objects provide event processing and storage and represent 
  1735. the information in a uniform manner. The agent converts this information to 
  1736. CMISE (Common Management Information Service Element) messages 
  1737. and responds to CMISE messages from the manager performing the appro-
  1738. priate operations on the managed objects.
  1739.  
  1740.     This information to and from the agent is passed across the V refer-
  1741. ence point to the message communications function (MCF).
  1742.  
  1743.     The event processing and storage provided by the managed objects is 
  1744. described in Recommendation G.784 including the filtering and threshold-
  1745. ing of performance and failure information.
  1746.  
  1747.     In the subsequent sections on the SEMF only the information flowing 
  1748. across the Sn reference points and the three filters shown in Figure5-1/
  1749. G.783 is described.
  1750.  
  1751. FIGURE 5-1/G/783
  1752.  
  1753.  
  1754.  
  1755. 5.1    Information flow across the Sn reference points
  1756.  
  1757.     The information flows described in this section are functional. The 
  1758. existence of these information flows in the equipment will depend on the 
  1759. options selected at the external interfaces to the equipment, in particular, the 
  1760. options selected by the TMN.
  1761.  
  1762.     The information that arises from anomalies and defects detected in the 
  1763. functional blocks is summarized in Tables5-1/G.783 to 5-11/G.783. For 
  1764. ease of reference these tables also show the consequent actions that are 
  1765. described in the sections on the individual functional blocks.
  1766.  
  1767.     Table 5-12/G.783 summarizes the configuration and provisioning 
  1768. information that is passed across the S reference points. The information 
  1769. listed under ôSetö in this table refers to configuration and provisioning data 
  1770. that is passed from the SEMF to the other functional blocks. The informa-
  1771. tion listed under ôGetö refers to status reports made in response to a request 
  1772. from the SEMF for such information.
  1773.  
  1774.     As an example we may consider the higher order path trace. The 
  1775. higher order path termination may be provisioned for the HO path trace that 
  1776. it should expect by a Set_Rx_HO_path_trace_ID command received from 
  1777. the manager. If the HO path trace that is received does not match the 
  1778. expected HO path trace this will give rise to a report of a mismatch of the 
  1779. HO path trace across the S6 reference point. Having received this mismatch 
  1780. indication, the relevant managed object may then decide to request a report 
  1781. of the HO path trace ID that has been received by a Get_Rx_HO_ path_tra-
  1782. ce_ID.
  1783.  
  1784. 5.2    Filter functions
  1785.  
  1786.     Note û Fixed one second filter processing of the information is con-
  1787. sidered satisfactory for the purpose of network surveillance and fault identi-
  1788. fication and sectionalization. This does not preclude the additional use of 
  1789. other filter processing techniques for detailed performance or fault charac-
  1790. terization where it is demonstrated that these provide significant additional 
  1791. information on the nature of errored events. If an alternative filter technique 
  1792. is used, it should be in addition to the fixed one second filter.
  1793.  
  1794.     The filtering functions provide a data reduction mechanism on the 
  1795. anomalies and defects presented at the S reference points. Three types of fil-
  1796. ters can be distinguished:
  1797.  
  1798. 5.2.1    One second filters
  1799.  
  1800.     The one second filters perform a simple integration of reported anom-
  1801. alies by counting during a one second interval. At the end of each one sec-
  1802. ond interval the contents of the counters may be obtained by the relevant 
  1803. managed objects. The following counter outputs will be provided:
  1804.  
  1805. û    regenerator section (B1) errors, 
  1806.  
  1807. û    regenerator section out of frame (OOF) events,
  1808.  
  1809. û    multiplex section (B2) errors,
  1810.  
  1811. û    HO path (B3) errors,
  1812.  
  1813. û    path errors (B3/V5),
  1814.  
  1815. û    HO path far end block errors (G1),
  1816.  
  1817. û    path far end block errors (G1/V5),
  1818.  
  1819. û    AU justification events (for further study),
  1820.  
  1821. û    TU justification events (for further study). 
  1822.  
  1823. 5.2.2    Defect filter
  1824.  
  1825.     The defect filter will provide a persistency check on the defects that 
  1826. are reported across the S reference points. Since all of the defects will 
  1827. appear at the input of this filter it may provide correlation to reduce the 
  1828. amount of information offered as failure indications to the agent. The fol-
  1829. lowing failure indications will be provided:
  1830.  
  1831. û    loss of signal,
  1832.  
  1833. û    loss of frame,
  1834.  
  1835. û    loss of AU pointer,
  1836.  
  1837. û    loss of TU pointer,
  1838.  
  1839. û    multiplex section AIS,
  1840.  
  1841. û    HO path AIS,
  1842.  
  1843. û    path AIS,
  1844.  
  1845. û    far-end receive failure,
  1846.  
  1847. û    HO path FERF,
  1848.  
  1849. û    path FERF, etc. (as listed in Tables 5-1/G.783 to 5-11/G.783 in the 
  1850. ôanomalies and defectsö column).
  1851.  
  1852.     In addition to the transmission failures listed above, equipment fail-
  1853. ures are also reported at the output of the defect filter for further processing 
  1854. by the agent.
  1855.  
  1856. 5.2.3    ES, SES filter
  1857.  
  1858.     The ES, SES filter processes the information available from the one 
  1859. second and the defect filter to derive errored seconds and severely errored 
  1860. seconds that are reported to the agent.
  1861.  
  1862.     ES and SES information will be made available for all the parameters 
  1863. listed in º 5.2.1 above, except justification events. In addition, information 
  1864. will be provided on out of frame (OOF) seconds; an OOF second is defined 
  1865. as a second in which one or more out of frame events have occurred.
  1866.  
  1867.  
  1868.  
  1869.  
  1870.  
  1871.  
  1872.  
  1873.  
  1874.  
  1875.  
  1876.  
  1877.  
  1878.  
  1879.  
  1880.  
  1881.  
  1882.  
  1883.  
  1884.  
  1885.  
  1886.  
  1887.  
  1888.  
  1889.  
  1890.  
  1891.  
  1892.  
  1893.  
  1894.  
  1895.  
  1896.  
  1897.  
  1898.  
  1899.  
  1900.  
  1901.  
  1902.  
  1903.  
  1904.  
  1905.  
  1906.  
  1907.  
  1908.  
  1909.  
  1910.  
  1911. 6    Timing functions
  1912.  
  1913. 6.1    Multiplexer timing source function
  1914.  
  1915.     This function provides timing reference to the following functional 
  1916. blocks: LPA, LPT, LPC, HPA, HPT, HPC, SA, MSP, MST, and RST. The 
  1917. multiplexer timing source (MTS) function represents the SDH network ele-
  1918. ment clock. The MTS function includes an internal oscillator function and 
  1919. multiplexer timing generator (MTG) function. The information flows asso-
  1920. ciated with the MTS function are described with reference to Figure6-1/
  1921. G.783.
  1922.  
  1923.     The synchronization source may be selected from any of the reference 
  1924. points T1, T2, T3 or the internal oscillator. When the MTS is synchronized 
  1925. to a signal carrying a network frequency reference standard the short-term 
  1926. stability requirements at the T reference points are specified in Figure6-2/
  1927. G.783.
  1928.  
  1929. FIGURE 6-1/G.783
  1930.  
  1931.  
  1932.  
  1933. FIGURE 6-2/G/783
  1934.  
  1935.  
  1936.  
  1937.     The MTG function filters the selected timing reference to ensure that the 
  1938. timing requirements at the T reference points are met. Additionally the 
  1939. MTG filtering function must filter the step change in frequency caused by a 
  1940. change in reference source so that the rate of change of frequency at the T 
  1941. reference points does not exceed x Hz/s; the value of x is for further study. 
  1942. This applies to the following three cases:
  1943.  
  1944. û    change from one reference source to another;
  1945.  
  1946. û    change from reference source to the internal oscillator;
  1947.  
  1948. û    change from the internal oscillator to a reference source.
  1949.  
  1950.     In practice, the last change will be the worst case.
  1951.  
  1952.     The long- and short-term stability of the internal oscillator function is 
  1953. for further study. 
  1954.  
  1955.     Note 1 û The maximum rate of change of frequency must be tracked 
  1956. by the desynchronizer at the SDH/PDH boundary. This will put an upper 
  1957. bound on the rate for practical desynchronizer designs.
  1958.  
  1959.     Note 2 û Desynchronizers must be designed to allow for maximum 
  1960. frequency offset of the internal oscillator. This may set an upper bound on 
  1961. its stability for some desynchronizer designs.
  1962.  
  1963.     The overall quality requirements of the MTS are in the province 
  1964. ofStudy GroupXVIII.
  1965.  
  1966. 6.2    Multiplexer timing physical interface (MTPI) function
  1967.  
  1968.     This function provides the interface between the external synchroni-
  1969. zation signal and the multiplexer timing source and shall have, at the syn-
  1970. chronization interface port, the physical characteristics of one of the G.703 
  1971. synchronization interfaces. (See Figure6-3/G.783.)
  1972.  
  1973. FIGURE 6-3/G.783
  1974.  
  1975.  
  1976.  
  1977. 6.2.1    Signal flow from MTS to synchronization interface
  1978.  
  1979.     This signal flow only exists if the MTS can provide external synchro-
  1980. nization.
  1981.  
  1982.     The functions performed by the MTPI are encoding and adaptation to 
  1983. the physical medium.
  1984.  
  1985.     The MTPI function takes timing from the MTS to form the transmit 
  1986. synchronization signal. The MTPI passes the timing information to the syn-
  1987. chronization interface transparently.
  1988.  
  1989. 6.2.2    Signal flow from synchronization interface to MTS
  1990.  
  1991.     The MTPI function extracts timing from the received synchronization 
  1992. signal. After decoding, it passes timing information to the MTS.
  1993.  
  1994. 7    Specification of jitter and wander
  1995.  
  1996.     SDH jitter and wander is specified at both STM-N and G.703 inter-
  1997. faces. The SDH multiplex equipment's jitter and wander characteristics at 
  1998. such interfaces may be categorized in terms of whether:
  1999.  
  2000. û    its jitter and wander performance is governed exclusively by the 
  2001. input timing extraction circuitry;
  2002.  
  2003. û    tributary bit justification is performed in addition to input timing 
  2004. extraction;
  2005.  
  2006. û    phase smoothing of pointer justifications is performed as well as 
  2007. tributary bit justification and input timing extraction.
  2008.  
  2009.     In addition, the wander encoded in both the AU and TU pointer 
  2010. adjustments is specified. (This determines the statistics of occurrence of 
  2011. pointer adjustments.)
  2012.  
  2013. 7.1    STM-N interfaces
  2014.  
  2015. 7.1.1    Input jitter and wander accommodation
  2016.  
  2017.     Jitter present on the STM-N signal must be accommodated by the 
  2018. SPI. The detailed parameters and limits are given in 
  2019. RecommendationG.958.
  2020.  
  2021.     The STM-N signal may be used to synchronize the multiplexer timing 
  2022. source (MTS), which must be able to accommodate the maximum absolute 
  2023. jitter and wander present on the STM-N signal. This will be primarily 
  2024. affected by wander, and can be specified in terms of maximum time interval 
  2025. error (MTIE), together with its first and second derivatives with respect to 
  2026. time. The detailed parameters and limits are for further study.
  2027.  
  2028. 7.1.2    Output jitter and wander generation
  2029.  
  2030.     The output jitter and wander must meet the short-term stability 
  2031. requirements given in Figure 6-2/G.783.
  2032.  
  2033.     When the multiplexer timing source is used, the output jitter and wan-
  2034. der depends on the inherent properties of the multiplexer timing generator 
  2035. as well as the properties of the synchronization input.
  2036.  
  2037.     When the equipment is loop-timed, the output jitter and wander 
  2038. depends on the incoming jitter and wander as filtered by the jitter and wan-
  2039. der transfer characteristics described in º7.1.3.
  2040.  
  2041.     Further requirements for wander can be specified in terms of MTIE, 
  2042. together with its first and second derivatives with respect to time. The spec-
  2043. ification of output jitter depends on the demarcation between jitter and wan-
  2044. der. The output jitter should be less than or equal to 0.01UI rms as 
  2045. measured in a 12kHz high pass filter. A second output jitter requirement as 
  2046. measured in a lower frequency high pass filter is for further study. The mea-
  2047. surement technique needs to be specified.
  2048.  
  2049. 7.1.3    Jitter and wander transfer
  2050.  
  2051.     The jitter and wander transfer is dependent on whether the equipment 
  2052. is synchronized and the manner in which it is synchronized.
  2053.  
  2054.     When the equipment is not synchronized, the jitter and wander trans-
  2055. fer characteristics have no meaning as the output jitter and wander is deter-
  2056. mined solely by the internal oscillator.
  2057.  
  2058.     When the equipment is synchronized, the jitter and wander transfer 
  2059. characteristics are determined by the filtering characteristics of the multi-
  2060. plexer timing generator (MTG). These filtering characteristics may vary 
  2061. depending on whether the equipment is loop timed or uses a multiplexer 
  2062. timing source. Figure7-1/G.783 provides a block diagram of timing func-
  2063. tions for multiplex equipment using loop timing.
  2064.  
  2065.     The jitter transfer characteristics (specifically, the ratio of the output 
  2066. jitter to the applied input jitter as a function of frequency) can be tested 
  2067. using sinusoidal input jitter. It should be noted that this may not adequately 
  2068. test some non-linear timing generator implementations. The introduction of 
  2069. some new tests based on broad-band jitter may help to characterize such 
  2070. implementations.
  2071.  
  2072.     Detailed specifications are for further study.
  2073.  
  2074. FIGURE 7-1/G.783
  2075.  
  2076.  
  2077.  
  2078. 7.1.4    Transfer of wander encoded in AU and TU pointer adjustments
  2079.  
  2080.     The transfer of wander encoded in the AU and TU pointer adjust-
  2081. ments is controlled by the AU and TU pointer processors, respectively. 
  2082. Wander is affected by the difference between the incoming phase and the fill 
  2083. within the pointer processor buffer. The larger the buffer spacing, the less 
  2084. likely that incoming pointer adjustments will result in outgoing pointer 
  2085. adjustments.
  2086.  
  2087. 7.1.4.1    AU pointer processor buffer threshold spacing
  2088.  
  2089.     The MTIE of the higher order VC with respect to the clock generating 
  2090. the STM-N frame is quantized and encoded in the AU pointer. When a 
  2091. higher-order VC is transferred from an STM-N to another STM-N derived 
  2092. from a different clock, the AU pointer must be processed. The pointer is 
  2093. first decoded to derive the frame phase and a clock to write to the AU 
  2094. pointer processor buffer. The read clock from the buffer is derived from the 
  2095. multiplexer timing source. The buffer fill is monitored and when upper or 
  2096. lower thresholds are crossed, the frame phase is adjusted. 
  2097.  
  2098.     The allocation in the pointer processor buffer for pointer hysteresis 
  2099. threshold spacing should be at least 12bytes for AU-4 and at least 4bytes 
  2100. for AU-3 (corresponding to maximum relative time interval error (MRTIE) 
  2101. of 640ns between reference point T0 and the incoming STM-N line signal).
  2102.  
  2103. 7.1.4.2    TU pointer processor buffer threshold spacing
  2104.  
  2105.     The MTIE of the lower-order VC with respect to the clock generating 
  2106. the higher-order VC is quantized and encoded in the TU pointer. When a 
  2107. lower-order VC is transferred from one higher-order VC into another 
  2108. higher-order VC derived from a different clock, the TU pointer must be pro-
  2109. cessed. The pointer is first decoded to derive the frame phase and a clock to 
  2110. write to the TU pointer processor buffer. The read clock from the buffer is 
  2111. derived from the multiplexer timing source. The buffer fill is monitored and 
  2112. when upper or lower thresholds are crossed, the frame phase is adjusted.
  2113.  
  2114.     The allocation in the pointer processor buffer for pointer hysteresis 
  2115. threshold spacing should be at least 4bytes for TU-3s and at least 2bytes 
  2116. for TU-1s and TU-2s.
  2117.  
  2118. 7.2    G.703 interfaces
  2119.  
  2120. 7.2.1    Input jitter and wander tolerance
  2121.  
  2122.     Input jitter and wander tolerance for 2048 kbit/s hierarchy based sig-
  2123. nals are specified in RecommendationG.823. Input jitter and wander toler-
  2124. ance of 1544kbit/s hierarchy based signals are specified in 
  2125. RecommendationsG.824, G.743, and G.752.
  2126.  
  2127.     Note û It may be necessary to specify transmit and receive separately 
  2128. for multi-vendor systems.
  2129.  
  2130. 7.2.2    Jitter and wander transfer
  2131.  
  2132.     As a minimum requirement, the jitter transfer specifications in the 
  2133. corresponding plesiochronous multiplex equipment Recommendations must 
  2134. be met.
  2135.  
  2136.     Note 1 û Multiplexer jitter and wander transfer may be difficult to 
  2137. specify for multi-vendor systems. Demultiplexer jitter and wander transfer 
  2138. may be more amenable to specification.
  2139.  
  2140.     Note 2 û The above-mentioned specifications are not sufficient to 
  2141. assure that SDH multiplexers provide adequate overall jitter and wander 
  2142. attenuation. Specifically, attenuation of the jitter and wander arising from 
  2143. decoded pointer adjustments places more stringent requirements on the 
  2144. SDH demultiplexer transfer characteristic.
  2145.  
  2146. 7.2.3    Jitter and wander generation
  2147.  
  2148. 7.2.3.1    Jitter and wander from tributary mapping 
  2149.  
  2150.     Specifications for jitter arising from mapping G.703 tributaries into 
  2151. containers, described in RecommendationG.709, should be specified in 
  2152. terms of peak-to-peak amplitude over a given frequency band over a given 
  2153. measurement interval. Detailed specifications are for further study.
  2154.  
  2155.     Note 1 û Tributary mapping jitter is measured in the absence of 
  2156. pointer adjustments.
  2157.  
  2158.     The output wander should be specified in terms of MTIE together 
  2159. with its first and second derivatives with respect to time. The need for and 
  2160. details of this specification are for further study.
  2161.  
  2162. 7.2.3.2    Jitter and wander from pointer adjustments
  2163.  
  2164.     The jitter and wander arising from decoded pointer adjustments must 
  2165. be sufficiently attenuated to ensure that existing plesiochronous network 
  2166. performance is not degraded. Detailed specifications are for further study.
  2167.  
  2168. 7.2.3.3    Combined jitter and wander from tributary mapping and pointer 
  2169. adjustments
  2170.  
  2171.     The combined jitter arising from tributary mapping and pointer 
  2172. adjustments should be specified in terms of peak-to-peak amplitude over a 
  2173. given frequency band, under application of representative specified pointer 
  2174. adjustment test sequences, for a given measurement interval. This interval is 
  2175. dependent on the test sequence duration and number of repetitions. A key 
  2176. feature that must be considered in the specification of the effects of pointer 
  2177. adjustments on G.703 interfaces is the demarcation between jitter and wan-
  2178. der. Thus a critical feature is the high-pass filter characteristics. The limits 
  2179. for each G.703 tributary interface and the corresponding filter characteris-
  2180. tics are given in Table7-1/G.783. Detailed specifications of the pointer 
  2181. adjustment test sequences are for further study.
  2182.  
  2183.     Two tests for wander may be necessary; one with a single pole HPF 
  2184. and another with a double pole HPF in order to differentiate between the 
  2185. first and second derivatives of MTIE. Detailed specifications are for further 
  2186. study.
  2187.  
  2188. 8    Overhead access function
  2189.  
  2190.     In SDH multiplex equipment, it may be required to provide access in 
  2191. an integrated manner to transmission overhead functions. This subject is for 
  2192. further study in CCITT. The present Recommendation defines the U refer-
  2193. ence points across which information may be exchanged with the other 
  2194. functional blocks.
  2195.  
  2196.     A particular overhead access function which will be required is the 
  2197. engineering order-wire function (EOW) which is used to provide voice con-
  2198. tact between regenerator and line terminal locations for maintenance per-
  2199. sonnel. This subject is for further study.
  2200.  
  2201.  
  2202.  
  2203.  
  2204.  
  2205. ANNEX A
  2206.  
  2207. (to Recommendation G.783)
  2208.  
  2209. Multiplex section protection (MSP) protocol,
  2210. commands and operation
  2211.  
  2212. A.1    MSP Protocol
  2213.  
  2214.     The MSP functions, at the ends of a multiplex section, make requests 
  2215. for and give acknowledgements of switch action by using the MSP bytes 
  2216. (K1 and K2 bytes in the MSOH of the protection section). The bit assign-
  2217. ments for these bytes and the bit-oriented protocol are defined as follows.
  2218.  
  2219. A.1.1    K1 byte
  2220.  
  2221.     The K1 byte indicates a request of a channel for switch action.
  2222.  
  2223.     Bits 1-4 indicate the type of request, as listed in Table A-1/G.783. A 
  2224. request can be:
  2225.  
  2226. 1)    a condition (SF and SD) associated with a section. A condition has 
  2227. high or low priority. The priority is set for each corresponding 
  2228. channel;
  2229.  
  2230. 2)    a state (wait-to-restore, do not revert, no request, reverse request) of 
  2231. the MSP function; or
  2232.  
  2233. 3)    an external request (lockout of protection, forced or manual switch, 
  2234. and exercise).
  2235.  
  2236.     Bits 5-8 indicate the number of the channel for which the request is 
  2237. issued, as shown in Table A-2/G.783.
  2238.  
  2239. A.1.2    K1 byte generation rules
  2240.  
  2241.     Local SF and SD conditions, WTR or do not revert state and the 
  2242. external request are evaluated by a priority logic, based on the descending 
  2243. order of request priorities in TableA-1/G.783. If local conditions (SF or SD) 
  2244. of the same level are detected on different sections at the same time, the 
  2245. condition with the lowest channel number takes priority. Of these evaluated 
  2246. requests, the one of the highest priority replaces the current local request, 
  2247. only if it is of higher priority.
  2248.  
  2249.  A.1.2.1    In bidirectional operation
  2250.  
  2251.     The priorities of the local request and the remote request on the 
  2252. received K1 byte are compared according to the descending order of priori-
  2253. ties in TableA-1/G.783. Note that a received reverse request is not consid-
  2254. ered in the comparison.
  2255.  
  2256.     The sent K1 shall indicate:
  2257.  
  2258. a)    a Reverse Request if
  2259.  
  2260. i)     the remote request is of higher priority, or if
  2261.  
  2262. ii)    the requests are of the same level and the sent K1 byte already 
  2263. indicates Reverse Request, or if
  2264.  
  2265. iii)    the requests are of the same level and the sent K1 byte does not 
  2266. indicate Reverse Request and the remote request indicates a 
  2267. lower channel number;
  2268.  
  2269. b)    the local request in all other cases.
  2270.  
  2271.  
  2272.  
  2273.  
  2274.  
  2275. A.1.2.2    In unidirectional operation
  2276.  
  2277.     The sent K1 byte shall always indicate the local request. Therefore, 
  2278. reverse request is never indicated.
  2279.  
  2280. A.1.3    Revertive/non-revertive modes
  2281.  
  2282.     In revertive mode of operation, when the protection is no longer 
  2283. requested, i.e. the failed section is no longer in SD or SF condition (and 
  2284. assuming no other requesting channels), a local Wait-to-restore state shall 
  2285. be activated. Since this state becomes the highest in priority, it is indicated 
  2286. on the sent K1 byte, and maintains the switch on that channel. This state 
  2287. shall normally time out and become a no requestûnull channel (or no 
  2288. requestûchannel15, if applicable). The wait-to-restore timer deactivates 
  2289. earlier if the sent K1 byte no longer indicates ôwait-to-restoreö, i.e.when 
  2290. any request of higher priority pre-empts this state.
  2291.  
  2292.     In non-revertive mode of operation, applicable only to 1 + 1 architec-
  2293. ture, when the failed working section is no longer in SD or SF condition, the 
  2294. selection of that channel from protection is maintained by activating a do 
  2295. not revert state or a wait-to-restore state rather than a no request state.
  2296.  
  2297.     Both wait-to-restore and do not revert requests in the sent K1 byte are 
  2298. normally acknowledged by a reverse request in the received K1 byte. How-
  2299. ever, no request is acknowledged by another no request received.
  2300.  
  2301. A.1.4    K2 byte
  2302.  
  2303.     Bits 1-5 indicate the status of the bridge in the MSP switch (see Fig-
  2304. ures A-1/G.783 and A-2/G.783). Bits 6 to 8 are reserved for future use to 
  2305. implement drop and insert (nested) switching. Note that codes 111 and 110 
  2306. will not be assigned for such use, since they are used for MS-AIS detection 
  2307. and MS-FERF indication.
  2308.  
  2309. FIGURE A-1/G.783
  2310.  
  2311.  
  2312.  
  2313. FIGURE A-2/G.783
  2314.  
  2315.  
  2316.  
  2317.     Bits 1-4 indicate a channel number, as shown in Table A-3/G.783. Bit 5 
  2318. indicates the type of the MSP architecture: set1 indicates 1:n architecture 
  2319. and set0 indicates 1+1 architecture.
  2320.  
  2321.  
  2322.  
  2323. A.1.5    K2 byte generation rules
  2324.  
  2325.     The sent K2 byte shall indicate in bits 1 to 4, for all architectures and 
  2326. operation modes:
  2327.  
  2328. a)    null channel (0) if the received K1 byte indicates either null channel 
  2329. or the number of a locked-out working channel;
  2330.  
  2331. b)    the number of the channel which is bridged, in all other cases.
  2332.  
  2333.     The sent K2 byte shall indicate in bit 5:
  2334.  
  2335. a)    0 if 1 + 1 architecture;
  2336.  
  2337. b)    1 if 1 : n architecture.
  2338.  
  2339.     Bit 5 of the sent and received K2 bytes may be compared; if a mis-
  2340. match persists for Y ms, a mismatch is indicated at reference point S14. A 
  2341. provisional value for Y is 50ms.
  2342.  
  2343. A.1.6    Control of the bridge
  2344.  
  2345.     In 1 : n architecture, the channel number indicated on the received K1 
  2346. byte controls the bridge. If, at the bridge end, the protection section is in SF 
  2347. condition, the bridge is:
  2348.  
  2349. a)    frozen (current bridge maintained), if the operation is unidirec-
  2350. tional;
  2351.  
  2352. b)    released, if the operation is bidirectional.
  2353.  
  2354.     In 1 + 1 architecture, the working channel 1 is permanently bridged to 
  2355. protection.
  2356.  
  2357. A.1.7    Control of the selector
  2358.  
  2359.     In 1 + 1 architecture in unidirectional operation, the selector is con-
  2360. trolled by the highest priority local request. If the protection section is in SF 
  2361. condition, the selector is released.
  2362.  
  2363.     In 1 + 1 architecture in bidirectional operation, and in 1 : n architec-
  2364. ture, the selector is controlled by comparing the channel numbers indicated 
  2365. on received K2 and sent K1 bytes. If there is a match, then the indicated 
  2366. channel is selected from the protection section. If there is a mismatch, the 
  2367. selector is released. Note that a match on 0000 also releases the selector. If 
  2368. the mismatch persists for Yms, a mismatch is indicated at reference point 
  2369. S14. If the protection section is in SF condition, the selector is released and 
  2370. the mismatch indication is disabled.
  2371.  
  2372. A.1.8    Transmission and acceptance of MSP bytes
  2373.  
  2374.     Byte K1 and bits 1 to 5 of byte K2 shall be transmitted on the protec-
  2375. tion section. Although they may also be transmitted identically on working 
  2376. sections, receivers should not assume so, and should have the capability to 
  2377. ignore this information on the working sections.
  2378.  
  2379.     MSP bytes shall be accepted as valid only when identical bytes are 
  2380. received in three consecutive frames.
  2381.  
  2382.     A detected failure of the received K1 or K2 is considered as equiva-
  2383. lent to an SF condition on the protection section.
  2384.  
  2385. A.2    MSP commands
  2386.  
  2387.     The MSP function receives MSP control parameters and switch 
  2388. requests from the synchronous equipment management function at the S14 
  2389. reference point. A switch command issues an appropriate external request at 
  2390. the MSP function. Only one switch request can be issued at S14. A control 
  2391. command sets or modifies MSP parameters or requests the MSP status.
  2392.  
  2393. A.2.1    Switch commands
  2394.  
  2395.     Switch commands are listed below in the descending order of priority 
  2396. and the functionality of each is described.
  2397.  
  2398. 1)    Clear: Clears all switch commands listed below.
  2399.  
  2400. 2)    Lockout of protection: Denies all working channels (and the extra 
  2401. traffic channel, if applicable) access to the protection section by 
  2402. issuing a lockout of protection request.
  2403.  
  2404. 3)    Forced switch #: Switches working channel # to the protection sec-
  2405. tion, unless an equal or higher priority switch command is in effect 
  2406. or SF condition exists on the protection section, by issuing a forced 
  2407. switch request for that channel.
  2408.  
  2409. Note û For 1 + 1 non-revertive systems, forced switch û no work-
  2410. ing channel transfers the working channel from protection to the 
  2411. working section, unless an equal or higher priority request is in 
  2412. effect. Since forced switch has higher priority than SF or SD on the 
  2413. working section, this command will be carried out regardless of 
  2414. the condition of the working section.
  2415.  
  2416. 4)    Manual switch #: Switches working channel # to the protection sec-
  2417. tion, unless a failure condition exists on other sections (including 
  2418. the protection section) or an equal or higher priority switch com-
  2419. mand is in effect, by issuing a manual switch request for that chan-
  2420. nel.
  2421.  
  2422. Note û For 1 + 1 non-revertive systems, manual switch û no work-
  2423. ing channel transfers the working channel back from protection to 
  2424. the working section, unless an equal or higher priority request is in 
  2425. effect. Since manual switch has lower priority than SF or SD on a 
  2426. working section, this command will be carried out only if the 
  2427. working section is not in SF or SD condition.
  2428.  
  2429. 5)    Exercise #: Issues an exercise request for that channel and checks 
  2430. responses on MSP bytes, unless the protection channel is in use. 
  2431. The switch is not actually completed, i.e.the selector is released by 
  2432. an exercise request on either the sent or the received and acknowl-
  2433. edged K1 byte. The exercise functionality may not exist in all MSP 
  2434. functions.
  2435.  
  2436.     Note that a functionality and a suitable command for freezing the current 
  2437. status of the MSP function is for further study.
  2438.  
  2439. A.3    Switch operation
  2440.  
  2441. A.3.1    1 : n bidirectional switching
  2442.  
  2443.     Table A-4/G.783 illustrates protection switching action between two 
  2444. multiplexer sites, denoted by A and C, of a 1:n bidirectional protection 
  2445. switching system, shown in Figure2-6/G.782.
  2446.  
  2447.     When the protection section is not in use, null channel is indicated on 
  2448. both sent K1 and K2 bytes. Any working channel may be bridged to the pro-
  2449. tection section at the head end. The tail end must not assume or require any 
  2450. specific channel. In the example in TableA-4/G.783, working channel 
  2451. (WCh) 3 is bridged at site C, and WCh 4 is bridged at siteA.
  2452.  
  2453.     When a fail condition is detected or a switch command is received at 
  2454. the tail end of a multiplex section, the protection logic compares the priority 
  2455. of this new condition with the request priority of the channel (if any) on the 
  2456. protection. The comparison includes the priority of any bridge order; i.e. of 
  2457. a request on received K1 byte. If the new request is of higher priority, then 
  2458. the K1 byte is loaded with the request and the number of the channel 
  2459. requesting use of the protection section. In the example, SD is detected at C 
  2460. on working section 2, and this condition is sent on byte K1 as a bridge order 
  2461. at A.
  2462.  
  2463.     At the head end, when this new K1 byte has been verified (after being 
  2464. received identically for three successive frames) and evaluated (by the pri-
  2465. ority logic), byte K1 is set with a reverse request as a confirmation of the 
  2466. channel to use the protection and order a bridge at the tail end for that chan-
  2467. nel. This initiates a bidirectional switch. Note that a reverse request is 
  2468. returned for exerciser and all other requests of higher priority. This clearly 
  2469. identifies which end originated the switch request. If the head end had also 
  2470. originated an identical request (not yet confirmed by a reverse request) for 
  2471. the same channel, then both ends would continue transmitting the identical 
  2472. K1 byte and perform the requested switch action.
  2473.  
  2474.     Also, at the head end, the indicated channel is bridged to protection. 
  2475. When the channel is bridged, byte K2 is set to indicate the number of the 
  2476. channel on protection.
  2477.  
  2478.  
  2479.  
  2480.     At the tail end, when the channel number on received byte K2 
  2481. matches the number of the channel requesting the switch, that channel is 
  2482. selected from protection. This completes the switch to protection for one 
  2483. direction. The tail end also performs the bridge as ordered by byte K1 and 
  2484. indicates the bridged channel on byte K2.
  2485.  
  2486.     The head end completes the bidirectional switch by selecting the 
  2487. channel from protection when it receives a matching K2 byte.
  2488.  
  2489.     If the switch is not completed because the requested/bridged channels 
  2490. did not match within 50 ms, the selectors would remain released and the 
  2491. ôfailure of the protocolö would be indicated. This may occur when one end 
  2492. is provisioned as unidirectional and the other as bidirectional. A mismatch 
  2493. may also occur when a locked-out channel at one end is not locked out at the 
  2494. other. Note that a mismatch may also occur when a 1+1 architecture con-
  2495. nects to a 1:1 architecture (which is not in a provisioned for 1+1 state), due 
  2496. to a mismatch of bit 5 on K2 bytes. This may be used to provision the 1:1 
  2497. architecture to operate as 1+1.
  2498.  
  2499.     The example further illustrates a priority switch, when an SF condi-
  2500. tion on working section 1 pre-empts the WCh 2 switch. Note that selectors 
  2501. are temporarily released before selecting WCh 1, due to temporary channel 
  2502. number mismatch on sent K1 and received K2 bytes. Further in the exam-
  2503. ple, switching back WCh 2 after failed section 1 is repaired is illustrated.
  2504.  
  2505.     When the switch is no longer required, e.g. the failed working section 
  2506. has recovered from failure and Wait-to-restore has expired, the tail end indi-
  2507. cates ôNo Requestö for Null Channel on byte K1 (00000000). This releases 
  2508. the selector due to channel number mismatch.
  2509.  
  2510.     The head end then releases the bridge and replies with the same indi-
  2511. cation on byte K1 and Null channel indication on byte K2. The selector at 
  2512. the head end is also released due to mismatch.
  2513.  
  2514.     Receiving Null channel on K1 byte causes the tail end to release the 
  2515. bridge. Since the K2 bytes now indicate Null Channel which matches the 
  2516. Null Channel on the K1 bytes, the selectors remain released without any 
  2517. mismatch indicated, and restoration is completed.
  2518.  
  2519. A.3.2    1:n unidirectional switching
  2520.  
  2521.     All actions are as described in º A.3.1 except that the unidirectional 
  2522. switch is completed when the tail end selects from protection the channel 
  2523. for which it issued a request. This difference in operation is obtained by not 
  2524. considering remote requests in the priority logic and therefore not issuing 
  2525. reverse requests.
  2526.  
  2527. A.3.3    1 + 1 unidirectional switching
  2528.  
  2529.     For 1 + 1 unidirectional switching, the channel selection is based on 
  2530. the local conditions and requests. Therefore each end operates indepen-
  2531. dently of the other end, and bytes K1 and K2 are not needed to coordinate 
  2532. switch action. However, byte K1 is still used to inform the other end of the 
  2533. local action, and bit 5 of byte K2 is set to zero.
  2534.  
  2535. A.3.4    1 + 1 bidirectional switching
  2536.  
  2537.     The operation of 1 + 1 bidirectional switching can be optimized for a 
  2538. network in which 1 : n protection switching is widely used and which is 
  2539. therefore based on compatibility with a 1:n arrangement; alternatively it 
  2540. can be optimized for a network in which predominantly 1+1 bidirectional 
  2541. switching is used. This leads to two possible switching operations described 
  2542. below.
  2543.  
  2544. A.3.4.1    1 + 1 bidirectional switching compatible with 1 : n bidirectional 
  2545. switching
  2546.  
  2547.     Bytes K1 and K2 are exchanged as described in º A.3.1 to complete a 
  2548. switch. Since the bridge is permanent, i.e.working channel number1 is 
  2549. always bridged, WCh1 is indicated on byteK2, unless received K1 indi-
  2550. cates null channel (0). Switching is completed when both ends select the 
  2551. channel, and may take less time because K2 indication does not depend on a 
  2552. bridging action.
  2553.  
  2554.     For revertive switching, the restoration takes place as described in º 
  2555. A.3.1. For non-revertive switching, TableA-5/G.783 illustrates the opera-
  2556. tion of a 1+1 bidirectional protection switching system, shown in 
  2557. Figure2-5/G.782.
  2558.  
  2559.     For non-revertive operation, assuming the working channel is on pro-
  2560. tection, when the working section is repaired, or a switch command is 
  2561. released, the tail end maintains the selection and indicates do not revert for 
  2562. WCh1. The head end also maintains the selection and continues indicating 
  2563. reverse request. The do not revert is removed when pre-empted by a failure 
  2564. condition or an external request.
  2565.  
  2566. A.3.4.2    1 + 1 bidirectional switching optimized for a network using predom-
  2567. inantly 1 + 1 bidirectional switching
  2568.  
  2569.     Bytes K1 and K2 are exchanged to complete a switch. Since the 
  2570. bridge is permanent, the traffic is always bridged to the working and protec-
  2571. tion channel. Byte K2 indicates the number of the channel which is carrying 
  2572. the traffic, i.e.the working channel. Therefore the channel number on 
  2573. byteK2 will be changed after switching is completed. Note that for this 
  2574. mode of operation, the use of channel numbers may differ from the descrip-
  2575. tion in ºA.1. Switching is completed when both the receive end switches 
  2576. select the channel and receive no request.
  2577.  
  2578.     For non-revertive switching, Table A-6/G.783 illustrates the operation 
  2579. of a 1 + 1 bidirectional protection switching system, using channel 
  2580. numbers1 and2.
  2581.  
  2582.  
  2583.  
  2584.  
  2585.  
  2586.  
  2587.  
  2588. ANNEX B
  2589.  
  2590. (to Recommendation G.783)
  2591.  
  2592. Algorithm for pointer detection
  2593.  
  2594. B.1    Pointer interpretation
  2595.  
  2596.     The pointer processing algorithm can be modelled by a finite state 
  2597. machine. Within the pointer interpretation algorithm three states are defined 
  2598. (as shown in FigureB-1/G.783):
  2599.  
  2600. û    NORM_state
  2601. û    AIS_state
  2602. û    LOP_state
  2603.  
  2604.     The transitions between the states will be consecutive events (indica-
  2605. tions), e.g. three consecutive AIS indications to go from NORM_state to the 
  2606. AIS_state. The kind and number of consecutive indications activating a 
  2607. transition is chosen such that the behaviour is stable and low BER sensitive.
  2608.  
  2609.     The only transition on a single event is the one from the AIS_state to 
  2610. the NORMAL_state after receiving an NDF enabled with a valid pointer 
  2611. value.
  2612.  
  2613.     It should be noted that, since the algorithm only contains transitions 
  2614. based on consecutive indications, this implies that non-consecutively 
  2615. received invalid indications do not activate the transitions to the LOP_state.
  2616.  
  2617.     The following events (indications) are defined:
  2618.  
  2619. û    Norm_point:    normal NDF + ss + offset value in range;
  2620.  
  2621. û    NDF_enable:    NDF enabled + ss + offset value in range;
  2622.  
  2623. û    AIS_ind:            11111111 11111111;
  2624.  
  2625. û    Incr_ind:        Normal NDF + ss + majority of I bits inverted + no major-
  2626. ity of D bits inverted+previous NDF_enable, incr_ind or 
  2627. decr_ind more than 3times ago;
  2628.  
  2629. û    Decr_ind:    Normal NDF + ss + majority of D bits inverted + no 
  2630. majority of I bits inverted+previous NDF_enable, incr_ind 
  2631. or decr_ind more than 3times ago;
  2632.  
  2633. û    Inv_point:        Any other + norm_point with offset value not equal to 
  2634. active offset.
  2635.  
  2636.     Note û Active offset is defined as the accepted current phase of the VC in 
  2637. the NORM_state and is undefined in the other states.
  2638.  
  2639.     The transitions indicated in the state diagram are defined as follows:
  2640.  
  2641. û    Inc_ind/dec_ind:    Offset adjustment (increment or decrement indica-
  2642. tion);
  2643.  
  2644. û    3 ┤ norm_point:    Three consecutive equal norm_point indications;
  2645.  
  2646. û    NDF_enable:    Single NDF_enable indication;
  2647.  
  2648. û    3 ┤ AIS_ind:     Three consecutive AIS indications;
  2649.  
  2650. û    N ┤ inv_point:    N consecutive inv_point (8úNú10);
  2651.  
  2652. û    N ┤ NDF_enable:    N consecutive NDF_enable (8úNú10). 
  2653.  
  2654.     Note û The transitions from NORM to NORM do not represent 
  2655. changes of state but imply offset 
  2656. changes.
  2657.  
  2658. B.2    Concatenated payloads
  2659.  
  2660.     In case a TU-2 is concatenated to a previous TU-2 the algorithm to 
  2661. verify the presence of the Concatenation Indicator can be described conve-
  2662. niently in the same way as for a normal pointer. This is shown by the state 
  2663. diagram of FigureB-2/G.783. Again, three states have been described:
  2664.  
  2665. û    CONC_state; 
  2666. û    LOPC_state; 
  2667. û    AISC_state.
  2668.  
  2669.     The following events (indications) are defined:
  2670.  
  2671. û    Conc_ind:    NDF enabled + ôdd 11111 11111ö;
  2672.  
  2673. û    AIS_ind:        11111111 11111111;
  2674.  
  2675. û    Inv_point:    Any other.
  2676.  
  2677. Note û dd bits are unspecified in G.709 and are therefore don't care 
  2678. for the algorithm.
  2679.  
  2680.     The transitions indicated in the state diagram are defined as follows:
  2681.  
  2682. û    3 ┤ AIS_ind:     Three consecutive AIS indications;
  2683.  
  2684. û    N ┤ inv_point:    N consecutive inv_point (8úNú10);
  2685.  
  2686. û    3 ┤ conc_ind:    Three consecutive conc_ind.
  2687.  
  2688.     A failure in one or more of the TUs of a concatenated payload should 
  2689. be reported across the S reference point as a single failure. Two types of fail-
  2690. ures can be reported:
  2691.  
  2692. û    Loss of pointer,
  2693.  
  2694. û    Path AIS.
  2695.  
  2696.     A Loss of pointer failure is defined as a transition of the pointer inter-
  2697. preter from the NORM_state to the LOP_state or the AIS_state, or a transi-
  2698. tion from the CONC_state to the LOPC_state or AISC_state in any 
  2699. concatenated TU. In case both the pointer interpreter is in the AIS_state and 
  2700. the concatenation indicators of all concatenated TUs are in the AISC_state, 
  2701. a path AIS failure will be reported. These failures will be reported across the 
  2702. Sreference point for alarm filtering at the SEMF.
  2703.  
  2704. FIGURE B-1/G.783
  2705.  
  2706.  
  2707.  
  2708. FIGURE B-2/G.783
  2709.  
  2710.  
  2711.  
  2712. APPENDIX I
  2713.  
  2714. (to Recommendation G.783)
  2715.  
  2716. Example of F1 byte usage
  2717.  
  2718.     Note û The following is not part of the Recommendation and is provided for 
  2719. information only.
  2720.  
  2721.     The F1 byte can be used to identify a failed section in a chain of regenerator 
  2722. sections. When a regenerator detects a failure in its section, it inserts the 
  2723. regenerator number and the status of its failure into the F1 byte.  FigureI-1/
  2724. G.783 illustrates the procedure.
  2725.  
  2726. FIGURE I-1/G.783
  2727.  
  2728.  
  2729.