Gmux-2000

INSTALLATION AND OPERATION MANUAL
Gmux-2000
Hub-Site Pseudowire and Voice Trunking Gateway (SONET Version)
Version 4.0
The Access Company
Gmux-2000
Hub-Site Pseudowire and Voice Trunking Gateway (SONET Version)
Version 4.0
Installation and Operation Manual Notice

This manual contains information that is proprietary to RAD Data Communications Ltd. ("RAD"). No part of this publication may be reproduced in any form whatsoever without prior written approval by RAD Data Communications. Right, title and interest, all information, copyrights, patents, know-how, trade secrets and other intellectual property or other proprietary rights relating to this manual and to the Gmux-2000 and any software components contained therein are proprietary products of RAD protected under international copyright law and shall be and remain solely with RAD. No right, license, or interest to such trademark is granted hereunder, and you agree that no such right, license, or interest shall be asserted by you with respect to such trademark. The RAD name, logo, logotype, and the terms EtherAccess, TDMoIP and TDMoIP Driven, and the product names Optimux and IPmux, are registered trademarks of RAD Data Communications Ltd. All other trademarks are the property of their respective holders. You shall not copy, reverse compile or reverse assemble all or any portion of the Manual or the Gmux-2000. You are prohibited from, and shall not, directly or indirectly, develop, market, distribute, license, or sell any product that supports substantially similar functionality as the Gmux-2000, based on or derived in any way from the Gmux-2000. Your undertaking in this paragraph shall survive the termination of this Agreement. This Agreement is effective upon your opening of the Gmux-2000 package and shall continue until terminated. RAD may terminate this Agreement upon the breach by you of any term hereof. Upon such termination by RAD, you agree to return to RAD the Gmux-2000 and all copies and portions thereof. For further information contact RAD at the address below or contact your local distributor.
International Headquarters RAD Data Communications Ltd. 24 Raoul Wallenberg Street Tel Aviv 69719, Israel Tel: 972-3-6458181 Fax: 972-3-6498250, 6474436 E-mail: market@rad.com
North America Headquarters RAD Data Communications Inc. 900 Corporate Drive Mahwah, NJ 07430, USA Tel: (201) 5291100, Toll free: 1-800-4447234 Fax: (201) 5295777 E-mail: market@rad.com
19952010 RAD Data Communications Ltd.
Publication No. 358-201-08/10
Limited Warranty
RAD warrants to DISTRIBUTOR that the hardware in the Gmux-2000 to be delivered hereunder shall be free of defects in material and workmanship under normal use and service for a period of twelve (12) months following the date of shipment to DISTRIBUTOR. If, during the warranty period, any component part of the equipment becomes defective by reason of material or workmanship, and DISTRIBUTOR immediately notifies RAD of such defect, RAD shall have the option to choose the appropriate corrective action: a) supply a replacement part, or b) request return of equipment to its plant for repair, or c) perform necessary repair at the equipment's location. In the event that RAD requests the return of equipment, each party shall pay one-way shipping costs. RAD shall be released from all obligations under its warranty in the event that the equipment has been subjected to misuse, neglect, accident or improper installation, or if repairs or modifications were made by persons other than RAD's own authorized service personnel, unless such repairs by others were made with the written consent of RAD. The above warranty is in lieu of all other warranties, expressed or implied. There are no warranties which extend beyond the face hereof, including, but not limited to, warranties of merchantability and fitness for a particular purpose, and in no event shall RAD be liable for consequential damages. RAD shall not be liable to any person for any special or indirect damages, including, but not limited to, lost profits from any cause whatsoever arising from or in any way connected with the manufacture, sale, handling, repair, maintenance or use of the Gmux-2000, and in no event shall RAD's liability exceed the purchase price of the Gmux-2000. DISTRIBUTOR shall be responsible to its customers for any and all warranties which it makes relating to Gmux-2000 and for ensuring that replacements and other adjustments required in connection with the said warranties are satisfactory. Software components in the Gmux-2000 are provided "as is" and without warranty of any kind. RAD disclaims all warranties including the implied warranties of merchantability and fitness for a particular purpose. RAD shall not be liable for any loss of use, interruption of business or indirect, special, incidental or consequential damages of any kind. In spite of the above RAD shall do its best to provide error-free software products and shall offer free Software updates during the warranty period under this Agreement. RAD's cumulative liability to you or any other party for any loss or damages resulting from any claims, demands, or actions arising out of or relating to this Agreement and the Gmux-2000 shall not exceed the sum paid to RAD for the purchase of the Gmux-2000. In no event shall RAD be liable for any indirect, incidental, consequential, special, or exemplary damages or lost profits, even if RAD has been advised of the possibility of such damages. This Agreement shall be construed and governed in accordance with the laws of the State of Israel.
Product Disposal
To facilitate the reuse, recycling and other forms of recovery of waste equipment in protecting the environment, the owner of this RAD product is required to refrain from disposing of this product as unsorted municipal waste at the end of its life cycle. Upon termination of the units use, customers should provide for its collection for reuse, recycling or other form of environmentally conscientious disposal.
General Safety Instructions

The following instructions serve as a general guide for the safe installation and operation of telecommunications products. Additional instructions, if applicable, are included inside the manual.
Safety Symbols
This symbol may appear on the equipment or in the text. It indicates potential safety hazards regarding product operation or maintenance to operator or service personnel.
Warning
Danger of electric shock! Avoid any contact with the marked surface while the product is energized or connected to outdoor telecommunication lines.
Protective ground: the marked lug or terminal should be connected to the building protective ground bus.
Warning
Some products may be equipped with a laser diode. In such cases, a label with the laser class and other warnings as applicable will be attached near the optical transmitter. The laser warning symbol may be also attached. Please observe the following precautions: Before turning on the equipment, make sure that the fiber optic cable is intact and is connected to the transmitter. Do not attempt to adjust the laser drive current. Do not use broken or unterminated fiber-optic cables/connectors or look straight at the laser beam. The use of optical devices with the equipment will increase eye hazard.
Use of controls, adjustments or performing procedures other than those specified herein, may result in hazardous radiation exposure. ATTENTION: The laser beam may be invisible! In some cases, the users may insert their own SFP laser transceivers into the product. Users are alerted that RAD cannot be held responsible for any damage that may result if non-compliant transceivers are used. In particular, users are warned to use only agency approved products that comply with the local laser safety regulations for Class 1 laser products. Always observe standard safety precautions during installation, operation and maintenance of this product. Only qualified and authorized service personnel should carry out adjustment, maintenance or repairs to this product. No installation, adjustment, maintenance or repairs should be performed by either the operator or the user.
Handling Energized Products

General Safety Practices
Do not touch or tamper with the power supply when the power cord is connected. Line voltages may be present inside certain products even when the power switch (if installed) is in the OFF position or a fuse is blown. For DC-powered products, although the voltages levels are usually not hazardous, energy hazards may still exist. Before working on equipment connected to power lines or telecommunication lines, remove jewelry or any other metallic object that may come into contact with energized parts. Unless otherwise specified, all products are intended to be grounded during normal use. Grounding is provided by connecting the mains plug to a wall socket with a protective ground terminal. If a ground lug is provided on the product, it should be connected to the protective ground at all times, by a wire with a diameter of 18 AWG or wider. Rack-mounted equipment should be mounted only in grounded racks and cabinets. Always make the ground connection first and disconnect it last. Do not connect telecommunication cables to ungrounded equipment. Make sure that all other cables are disconnected before disconnecting the ground. Some products may have panels secured by thumbscrews with a slotted head. These panels may cover hazardous circuits or parts, such as power supplies. These thumbscrews should therefore always be tightened securely with a screwdriver after both initial installation and subsequent access to the panels.
Connecting AC Mains
Make sure that the electrical installation complies with local codes. Always connect the AC plug to a wall socket with a protective ground. The maximum permissible current capability of the branch distribution circuit that supplies power to the product is 16A (20A for USA and Canada). The circuit breaker in the building installation should have high breaking capacity and must operate at short-circuit current exceeding 35A (40A for USA and Canada). Always connect the power cord first to the equipment and then to the wall socket. If a power switch is provided in the equipment, set it to the OFF position. If the power cord cannot be readily disconnected in case of emergency, make sure that a readily accessible circuit breaker or emergency switch is installed in the building installation. In cases when the power distribution system is IT type, the switch must disconnect both poles simultaneously.
Connecting DC Power
Unless otherwise specified in the manual, the DC input to the equipment is floating in reference to the ground. Any single pole can be externally grounded. Due to the high current capability of DC power systems, care should be taken when connecting the DC supply to avoid short-circuits and fire hazards. Make sure that the DC power supply is electrically isolated from any AC source and that the installation complies with the local codes.
The maximum permissible current capability of the branch distribution circuit that supplies power to the product is 16A (20A for USA and Canada). The circuit breaker in the building installation should have high breaking capacity and must operate at short-circuit current exceeding 35A (40A for USA and Canada). Before connecting the DC supply wires, ensure that power is removed from the DC circuit. Locate the circuit breaker of the panel board that services the equipment and switch it to the OFF position. When connecting the DC supply wires, first connect the ground wire to the corresponding terminal, then the positive pole and last the negative pole. Switch the circuit breaker back to the ON position. A readily accessible disconnect device that is suitably rated and approved should be incorporated in the building installation. If the DC power supply is floating, the switch must disconnect both poles simultaneously.
Connecting Data and Telecommunications Cables

Data and telecommunication interfaces are classified according to their safety status. The following table lists the status of several standard interfaces. If the status of a given port differs from the standard one, a notice will be given in the manual.
Ports V.11, V.28, V.35, V.36, RS-530, X.21, 10 BaseT, 100 BaseT, Unbalanced E1, E2, E3, STM, DS-2, DS-3, S-Interface ISDN, Analog voice E&M xDSL (without feeding voltage), Balanced E1, T1, Sub E1/T1
Safety Status SELV Safety Extra Low Voltage: Ports which do not present a safety hazard. Usually up to 30 VAC or 60 VDC.
TNV-1 Telecommunication Network Voltage-1: Ports whose normal operating voltage is within the limits of SELV, on which overvoltages from telecommunications networks are possible. TNV-2 Telecommunication Network Voltage-2: Ports whose normal operating voltage exceeds the limits of SELV (usually up to 120 VDC or telephone ringing voltages), on which overvoltages from telecommunication networks are not possible. These ports are not permitted to be directly connected to external telephone and data lines. TNV-3 Telecommunication Network Voltage-3: Ports whose normal operating voltage exceeds the limits of SELV (usually up to 120 VDC or telephone ringing voltages), on which overvoltages from telecommunication networks are possible.
FXS (Foreign Exchange Subscriber)
FXO (Foreign Exchange Office), xDSL (with feeding voltage), U-Interface ISDN
Always connect a given port to a port of the same safety status. If in doubt, seek the assistance of a qualified safety engineer. Always make sure that the equipment is grounded before connecting telecommunication cables. Do not disconnect the ground connection before disconnecting all telecommunications cables. Some SELV and non-SELV circuits use the same connectors. Use caution when connecting cables. Extra caution should be exercised during thunderstorms.
When using shielded or coaxial cables, verify that there is a good ground connection at both ends. The grounding and bonding of the ground connections should comply with the local codes. The telecommunication wiring in the building may be damaged or present a fire hazard in case of contact between exposed external wires and the AC power lines. In order to reduce the risk, there are restrictions on the diameter of wires in the telecom cables, between the equipment and the mating connectors.
Caution
To reduce the risk of fire, use only No. 26 AWG or larger telecommunication line cords.
Attention
Pour rduire les risques sincendie, utiliser seulement des conducteurs de tlcommunications 26 AWG ou de section suprieure.
Some ports are suitable for connection to intra-building or non-exposed wiring or cabling only. In such cases, a notice will be given in the installation instructions. Do not attempt to tamper with any carrier-provided equipment or connection hardware.
Electromagnetic Compatibility (EMC)

The equipment is designed and approved to comply with the electromagnetic regulations of major regulatory bodies. The following instructions may enhance the performance of the equipment and will provide better protection against excessive emission and better immunity against disturbances. A good ground connection is essential. When installing the equipment in a rack, make sure to remove all traces of paint from the mounting points. Use suitable lock-washers and torque. If an external grounding lug is provided, connect it to the ground bus using braided wire as short as possible. The equipment is designed to comply with EMC requirements when connecting it with unshielded twisted pair (UTP) cables. However, the use of shielded wires is always recommended, especially for high-rate data. In some cases, when unshielded wires are used, ferrite cores should be installed on certain cables. In such cases, special instructions are provided in the manual. Disconnect all wires which are not in permanent use, such as cables used for one-time configuration. The compliance of the equipment with the regulations for conducted emission on the data lines is dependent on the cable quality. The emission is tested for UTP with 80 dB longitudinal conversion loss (LCL). Unless otherwise specified or described in the manual, TNV-1 and TNV-3 ports provide secondary protection against surges on the data lines. Primary protectors should be provided in the building installation. The equipment is designed to provide adequate protection against electro-static discharge (ESD). However, it is good working practice to use caution when connecting cables terminated with plastic connectors (without a grounded metal hood, such as flat cables) to sensitive data lines. Before connecting such cables, discharge yourself by touching ground or wear an ESD preventive wrist strap.
FCC-15 User Information

This equipment has been tested and found to comply with the limits of the Class A digital device, pursuant to Part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accordance with the Installation and Operation manual, may cause harmful interference to the radio communications. Operation of this equipment in a residential area is likely to cause harmful interference in which case the user will be required to correct the interference at his own expense.
Canadian Emission Requirements

This Class A digital apparatus meets all the requirements of the Canadian Interference-Causing Equipment Regulation. Cet appareil numrique de la classe A respecte toutes les exigences du Rglement sur le matriel brouilleur du Canada.
Warning per EN 55022 (CISPR-22)

Warning
This is a class A product. In a domestic environment, this product may cause radio interference, in which case the user will be required to take adequate measures. Cet appareil est un appareil de Classe A. Dans un environnement rsidentiel, cet appareil peut provoquer des brouillages radiolectriques. Dans ces cas, il peut tre demand lutilisateur de prendre les mesures appropries. Das vorliegende Gert fllt unter die Funkstrgrenzwertklasse A. In Wohngebieten knnen beim Betrieb dieses Gertes Rundfunkstrrungen auftreten, fr deren Behebung der Benutzer verantwortlich ist.
Avertissement
Achtung
Mise au rebut du produit

Afin de faciliter la rutilisation, le recyclage ainsi que d'autres formes de rcupration d'quipement mis au rebut dans le cadre de la protection de l'environnement, il est demand au propritaire de ce produit RAD de ne pas mettre ce dernier au rebut en tant que dchet municipal non tri, une fois que le produit est arriv en fin de cycle de vie. Le client devrait proposer des solutions de rutilisation, de recyclage ou toute autre forme de mise au rebut de cette unit dans un esprit de protection de l'environnement, lorsqu'il aura fini de l'utiliser.
Franais
Avertissement
Instructions gnrales de scurit

Les instructions suivantes servent de guide gnral d'installation et d'opration scurises des produits de tlcommunications. Des instructions supplmentaires sont ventuellement indiques dans le manuel.
Symboles de scurit
Ce symbole peut apparaitre sur l'quipement ou dans le texte. Il indique des risques potentiels de scurit pour l'oprateur ou le personnel de service, quant l'opration du produit ou sa maintenance.
Danger de choc lectrique ! Evitez tout contact avec la surface marque tant que le produit est sous tension ou connect des lignes externes de tlcommunications.
Mise la terre de protection : la cosse ou la borne marque devrait tre connecte la prise de terre de protection du btiment.
Avant la mise en marche de l'quipement, assurez-vous que le cble de fibre optique est intact et qu'il est connect au transmetteur. Ne tentez pas d'ajuster le courant de la commande laser. N'utilisez pas des cbles ou connecteurs de fibre optique casss ou sans terminaison et n'observez pas directement un rayon laser. L'usage de priphriques optiques avec l'quipement augmentera le risque pour les yeux.
L'usage de contrles, ajustages ou procdures autres que celles spcifies ici pourrait rsulter en une dangereuse exposition aux radiations. ATTENTION : Le rayon laser peut tre invisible !
Les utilisateurs pourront, dans certains cas, insrer leurs propres metteurs-rcepteurs Laser SFP dans le produit. Les utilisateurs sont avertis que RAD ne pourra pas tre tenue responsable de tout dommage pouvant rsulter de l'utilisation d'metteurs-rcepteurs non conformes. Plus particulirement, les utilisateurs sont avertis de n'utiliser que des produits approuvs par l'agence et conformes la rglementation locale de scurit laser pour les produits laser de classe 1. Respectez toujours les prcautions standards de scurit durant l'installation, l'opration et la maintenance de ce produit. Seul le personnel de service qualifi et autoris devrait effectuer l'ajustage, la maintenance ou les rparations de ce produit. Aucune opration d'installation, d'ajustage, de maintenance ou de rparation ne devrait tre effectue par l'oprateur ou l'utilisateur.
Manipuler des produits sous tension

Rgles gnrales de scurit
Ne pas toucher ou altrer l'alimentation en courant lorsque le cble d'alimentation est branch. Des tensions de lignes peuvent tre prsentes dans certains produits, mme lorsque le commutateur (s'il est install) est en position OFF ou si le fusible est rompu. Pour les produits aliments par CC, les niveaux de tension ne sont gnralement pas dangereux mais des risques de courant peuvent toujours exister. Avant de travailler sur un quipement connect aux lignes de tension ou de tlcommunications, retirez vos bijoux ou tout autre objet mtallique pouvant venir en contact avec les pices sous tension. Sauf s'il en est autrement indiqu, tous les produits sont destins tre mis la terre durant l'usage normal. La mise la terre est fournie par la connexion de la fiche principale une prise murale quipe d'une borne protectrice de mise la terre. Si une cosse de mise la terre est fournie avec le produit, elle devrait tre connecte tout moment une mise la terre de protection par un conducteur de diamtre 18 AWG ou plus. L'quipement mont en chssis ne devrait tre mont que sur des chssis et dans des armoires mises la terre. Branchez toujours la mise la terre en premier et dbranchez-la en dernier. Ne branchez pas des cbles de tlcommunications un quipement qui n'est pas mis la terre. Assurez-vous que tous les autres cbles sont dbranchs avant de dconnecter la mise la terre.
Franais
Certains produits peuvent tre quips d'une diode laser. Dans de tels cas, une tiquette indiquant la classe laser ainsi que d'autres avertissements, le cas chant, sera jointe prs du transmetteur optique. Le symbole d'avertissement laser peut aussi tre joint. Avertissement Veuillez observer les prcautions suivantes :
Connexion au courant du secteur

Assurez-vous que l'installation lectrique est conforme la rglementation locale. Branchez toujours la fiche de secteur une prise murale quipe d'une borne protectrice de mise la terre. La capacit maximale permissible en courant du circuit de distribution de la connexion alimentant le produit est de 16A (20A aux Etats-Unis et Canada). Le coupe-circuit dans l'installation du btiment devrait avoir une capacit leve de rupture et devrait fonctionner sur courant de court-circuit dpassant 35A (40A aux Etats-Unis et Canada). Branchez toujours le cble d'alimentation en premier l'quipement puis la prise murale. Si un commutateur est fourni avec l'quipement, fixez-le en position OFF. Si le cble d'alimentation ne peut pas tre facilement dbranch en cas d'urgence, assurez-vous qu'un coupe-circuit ou un disjoncteur d'urgence facilement accessible est install dans l'installation du btiment. Le disjoncteur devrait dconnecter simultanment les deux ples si le systme de distribution de courant est de type IT.
Franais
Connexion d'alimentation CC
Sauf s'il en est autrement spcifi dans le manuel, l'entre CC de l'quipement est flottante par rapport la mise la terre. Tout ple doit tre mis la terre en externe. A cause de la capacit de courant des systmes alimentation CC, des prcautions devraient tre prises lors de la connexion de l'alimentation CC pour viter des courts-circuits et des risques d'incendie. Assurez-vous que l'alimentation CC est isole de toute source de courant CA (secteur) et que l'installation est conforme la rglementation locale. La capacit maximale permissible en courant du circuit de distribution de la connexion alimentant le produit est de 16A (20A aux Etats-Unis et Canada). Le coupe-circuit dans l'installation du btiment devrait avoir une capacit leve de rupture et devrait fonctionner sur courant de court-circuit dpassant 35A (40A aux Etats-Unis et Canada). Avant la connexion des cbles d'alimentation en courant CC, assurez-vous que le circuit CC n'est pas sous tension. Localisez le coupe-circuit dans le tableau desservant l'quipement et fixez-le en position OFF. Lors de la connexion de cbles d'alimentation CC, connectez d'abord le conducteur de mise la terre la borne correspondante, puis le ple positif et en dernier, le ple ngatif. Remettez le coupe-circuit en position ON. Un disjoncteur facilement accessible, adapt et approuv devrait tre intgr l'installation du btiment. Le disjoncteur devrait dconnecter simultanment les deux ples si l'alimentation en courant CC est flottante.
Declaration of Conformity
Manufacturer's Name: Manufacturer's Address: Declares that the product: Product Name: Gmux-2000 RAD Data Communications Ltd. 24 Raoul Wallenberg St., Tel Aviv 69719, Israel
Conforms to the following standard(s) or other normative document(s): EMC: EN 55022:1998 + A1:2000, A2:2003 EN 55024:1998 + A1:2001, A2:2003 Safety: EN 60950-1:2001 Information technology equipment Radio disturbance characteristics Limits and methods of measurement. Information technology equipment Immunity characteristics Limits and methods of measurement. Information technology equipment Safety Part 1: General requirements.
Supplementary Information: The product herewith complies with the requirements of the EMC Directive 89/336/EEC, the Low Voltage Directive 73/23/EEC and the R&TTE Directive 99/5/EC for wired equipment. The product was tested in a typical configuration. Tel Aviv, 8 December 2005
Haim Karshen VP Quality
European Contact:
RAD Data Communications GmbH, Otto-Hahn-Str. 28-30, 85521 Ottobrunn-Riemerling, Germany
Quick Start Guide

If you are familiar with the Gmux-2000, use this guide to prepare it for operation, starting from its factory-default configuration.
Caution
Before performing the procedures described below, review the safety precautions given in Sections 3.1 and 3.2.
1.
Installing Gmux-2000
1. Refer to the site installation plan and install the Gmux-2000 enclosure in the prescribed position. 2. Install modules in accordance with the required service. Slot utilizations for the main types of service are identified below.
OC3 Module or C.OC3 Module or T1-PW/28 Module or T1-PW-SRV/28 Module Power Inlet (PI) Module
Gm ux-2000
OC3 Module or C.OC3 Module or T1-PW/28 Module or T1-PW-SRV/28 Module
Slot:
I/O 9 I/O 8 I/O 7 GbE/2 Module
I/O 6 I/O 5
GbE/2 Module
1 I/O 4 2 I/O 3 I/O 2 1 I/O 1 Fan Tray System Slots 2 Slots for CONTROL Modules 3 Slots for PS Modules I/O Slots C.OC3 M odule or T1-PW/28 Module or T1-PW-SRV/28 Module
Slot Utilization for TDM Traffic Transport Services
Gmux-2000 Ver. 4.0
Installing Gmux-2000
Quick Start Guide
Installation and Operation Manual

Alternate Slot for SONET Interface Module or Voice Compression Module Slot for SONET Interface Module or Voice Compression Module
INLET P.S . 3 P.S . 2 P.S . 1 CT RL. 2 CRTL. 1
I/O-9 I/O-8 I/O-7 I/O-6 I/O-5 I/O-4 I/O-3 I/O-2 I/O-1
Power Inlet (PI) Module
ALA RM S PW R T ST M AJ . ALARM M IN . ALA RM
FAN-TRAY
Gmux-2000
Slot:
PW R FLT
L ASER CL ASS 1
LOC REM TX
ACT LINK
LOC REM TX RX
RDY ALM
I/O-9
AC-IN
OC3
RX
I/O 9 Slot for PSN I/O 8 Interface Module I/O 7 I/O 6 Alternate Slot for PSN Interface Module I/O 5 I/O 4 I/O 3 I/O 2 I/O 1 Slots for Voice Compression Modules
L ASER CL ASS 1
GE 1 LINK TX
MONITOR
GE 2 PAUSE RX LINK TX PAUSE RX ACT FLT

I/O-8
POWER POWER
3
PS-AC
GbE
I/O-7
POWER POWER
2
PS-AC PS-AC
1 3 5 7 9 11 13 15 LOC REM 2 4 6 8 10 12 14 16 1 2 LOC REM ACT FLT
I/O-6
I/O-5
POWER POWER
VCA-T1/16
1-16 T1
LOC
LINK
1
1 3 5 7 9 11 13 15 LOC REM 2 OUT IN SD 1 3 5 7 9 11 13 15 LOC S TAT ION CLOCK 2 4 6 8 10 12 14 16 REM 4 6 8 10 12 14 16
REM ACT FLT I/O-4
PS-AC VCA-T1/16
1-16 T1
LOC
LINK
REM ACT FLT I/O-3
2
CONTROL
ACT
LINK
VCA-T1/16
ETH DCE ACT FLT 1 OUT IN SD 2 4 6 8 10 12 14 16 3 5 7 9 11 13 15 LOC REM
1-16 T1
LOC
LINK
REM ACT FLT I/O-2
CONTROL
VCA-T1/16
1-16 T1
LOC
LINK
1
CONTROL
ACT
LINK
S TAT ION CLOCK 1 3 5 7 9 11 13 15 LOC ACT FLT REM 2 4 6 8 10 12 14 16
REM ACT FLT I/O-1
ETH
CONTROL
DCE
VCA-T1/16
1-16 T1
LINK
Fan Tray System Slots 2 Slots for CONTROL Modules 3 Slots for PS Modules I/O Slots
Slot Utilization for Compressed Voice Transport Services (Voice Trunking Service)
3. Refer to the site installation plan, and connect the prescribed cables to the Gmux-2000 modules. 4. When ready, apply power.
2.
Note
Configuration Sequence
If Gmux-2000 is used in conjunction with an NPS-101 1:N protection switching device, refer to the NPS-101 Installation and Operation Manual for additional required connections. Do not change the default terminal settings when Gmux-2000 is connected to NPS-101.
To perform preliminary configuration: 1. Connect a terminal to the CONTROL DCE connector of the active CONTROL module (use a straight cable).
Note
You can also connect the terminal in parallel to the CONTROL DCE connectors of both CONTROL modules installed in the Gmux-2000, using a Y-cable.
You may use any standard ASCII terminal (dumb terminal or personal computer emulating an ASCII terminal) equipped with an RS-232 communication interface. Make sure to use VT-100 terminal emulation.
Gmux-2000 Ver. 4.0
Quick Start Guide
2. Configure the terminal for 115.2 kbps, one start bit, eight data bits, no parity, and one stop bit. Select the full-duplex mode, echo off, and disable any type of flow control. 3. Connect the Gmux-2000 to power. 4. Wait until all the PWR and the CONTROL ACT indicators stop flashing and the ACT indicator of one CONTROL module remains ON, and then press <Enter> once to obtain the log-in screen. 5. If the Gmux-2000 default user name and password have not yet been changed, log in as administrator using su as the user name and 1234 for password. If your password is accepted, you will see the Gmux-2000 main menu.
Note
If you cannot establish communication with the Gmux-2000 or the display is jumbled, reset the Gmux-2000 to the factory default parameters using section 2 of the internal switch SW1 located on the CONTROL modules. After configuring the desired CONTROL DCE port parameters, return section 2 of SW1 to the User Selected setting.
The following table provides an outline of the Gmux-2000 system configuration procedure. For module configuration procedures, use the Quick Start sections in the Installation and Operation Manuals of the modules installed in the Gmux-2000 chassis. For your convenience, a navigation map of the Gmux-2000 supervision terminal menus is also provided below.
Ste p
Action
Using
6.
If the Gmux-2000 is equipped with all the modules, load the hardware configuration. Alternatively, define the modules installed in the chassis manually
GMUX2000>admin# update-card-types GMUX2000>config>card# card-type
7.
Configure the Gmux-2000 router, bind its ports to device host and GbE interfaces and define peers Configure specific managers Configure the Gmux-2000 logistic parameters: system name, contact person, system location Set Gmux-2000 real-time clock:
GMUX2000>config>router(1)
8. 9.
GMUX2000>config# management manager GMUX2000>config>system# name GMUX2000>config>system# contact GMUX2000>config>system# location GMUX2000>config>system# date-and-time date-format
10. 11. 12.
1. Select the date format. 2. Set the system date 3. When the internal real time clock is used,
set the time of day. GMUX2000>config>system# date-and-time date GMUX2000>config>system# date-and-time time
Gmux-2000 Ver. 4.0
Quick Start Guide
Ste p
Action
Using
13. 14. 15. 16. 17. 18.
Configure physical layer parameters for each module, and each module port Configure timing flow Configure redundancy Configure Gmux-2000 internal routing Configure connection parameters for each bundle When necessary, configure the Gmux-2000 for VoIP service as follows:
GMUX2000>config>port# GMUX2000>config>system>clock# GMUX2000>config>protection# GMUX2000>config#>cross-connect GMUX2000>config>pwe#
Configuration > Physical Layer > I/O > IP Address Configure additional voice compression parameters needed for voice compression Configuration > Physical Layer > I/O > Media Configuration service Configure MEGACO application parameters Configuration > Applications > MEGACO Configure SIGTRAN parameters Configuration > Applications > SIGTRAN
Gmux-2000 Ver. 4.0
Contents
Chapter 1. Introduction 1.1 Overview.................................................................................................................... 1-1 Purpose and Use..................................................................................................... 1-1 Main Features ......................................................................................................... 1-2 PSN Interfaces ................................................................................................... 1-3 SONET Interfaces ............................................................................................... 1-4 Channelized OC-3 Modules ................................................................................. 1-5 Pseudowire (PW) Circuit Emulation Services ........................................................ 1-6 Voice Trunking Services ...................................................................................... 1-8 VoIP Services .................................................................................................... 1-10 Control Functions ............................................................................................. 1-11 Timing.............................................................................................................. 1-12 External Alarm Monitoring and Reporting .......................................................... 1-12 Power Supply Subsystem .................................................................................. 1-12 1.2 Typical Applications .................................................................................................. 1-13 Pseudowire Emulation Services for TDM Transport................................................. 1-13 Voice Compression Applications ............................................................................ 1-14 High Capacity Toll Bypass over SONET Networks ............................................... 1-14 High Capacity Toll Bypass over Packet Switched Networks ................................ 1-15 Connecting Multiple Remote Call Centers .......................................................... 1-15 Voice Trunking over Multiple T1 Streams ........................................................... 1-16 Voice Trunking over OC-3 Link .......................................................................... 1-17 Incorporating Gmux-2000 in a VoIP Network ..................................................... 1-17 Interoperability with Vmux Family Products ....................................................... 1-18 1.3 Equipment Description ............................................................................................. 1-20 System Structure .................................................................................................. 1-20 TDM Pseudowire Emulation Services ................................................................. 1-20 Voice Compression Services .............................................................................. 1-21 Physical Description .............................................................................................. 1-22 Front Side ........................................................................................................ 1-22 Rear Side ......................................................................................................... 1-23 Available Modules ................................................................................................. 1-26 Description of Gmux-2000 Modules ...................................................................... 1-27 Power Supply Modules ..................................................................................... 1-27 CONTROL Module ............................................................................................. 1-28 Description of I/O Modules.................................................................................... 1-29 OC3 SONET Interface Module............................................................................ 1-29 Channelized OC-3 Modules ............................................................................... 1-30 T1-PW-SRV/28 Pseudowire Emulation Server Module ........................................ 1-30 T1-PW/28 Pseudowire Emulation Module with External T1 Interfaces ................ 1-33 CT3-PW/1 Pseudowire Emulation Module with External Channelized T3 Interface ........................................................................................................................ 1-35 GbE/2 PSN Interface Module ............................................................................. 1-37 VCA-T1/16, VCA-T1/12 Voice Compression Modules .......................................... 1-39 1.4 Technical Specifications............................................................................................ 1-42 System Characteristics .......................................................................................... 1-42 OC3 Interface Module Characteristics .................................................................... 1-43 GbE Module Characteristics ................................................................................... 1-45 C.OC3 Module Characteristics ................................................................................ 1-46 GbE/2 Module Characteristics ................................................................................ 1-48
Gmux-2000 Ver. 4.0B i
Table of Contents
T1-PW/28 Pseudowire Emulation Module with External T1 Interfaces, Characteristics ............................................................................................................................ 1-49 CT3-PW/1 Pseudowire Emulation Module with Channelized T3 Interface Characteristics ............................................................................................................................ 1-51 T1-PW-SRV/28 Pseudowire Emulation Server Module Characteristics ...................... 1-53 VCA-T1/16, VCA-T1/12 Voice Compression Modules Voice Trunking Service Characteristics ...................................................................................................... 1-55 VCA-T1/16, VCA-T1/12 Voice Compression Modules VoIP Service Characteristics.. 1-59 Station Clock Interface .......................................................................................... 1-63 System Management ............................................................................................ 1-63 Power Requirements ............................................................................................. 1-65 Environment ......................................................................................................... 1-65 Physical ................................................................................................................ 1-66 Chapter 2. Functional Description 2.1 Scope ........................................................................................................................ 2-1 2.2 Gmux-2000 Functional Description ............................................................................. 2-1 Description of Gmux-2000 System Used for TDM Transport Services ....................... 2-1 TDM Traffic Flow within the Gmux-2000 ............................................................. 2-2 TDMoPSN Packet Processing ............................................................................... 2-4 HDLCoPSN Processing ........................................................................................ 2-6 SAToPSN Packet Processing ................................................................................ 2-6 CESoPSN Packet Processing ................................................................................ 2-7 Packetizing Considerations ................................................................................. 2-7 Backward Compatibility with Other RAD Equipment ............................................ 2-9 Jitter Buffer Functions ...................................................................................... 2-10 Adaptive Timing ............................................................................................... 2-12 OAM Protocol ................................................................................................... 2-12 Alarm Indications ............................................................................................. 2-13 Description of Gmux-2000 System Used for Voice Trunking Services ...................... 2-14 Voice Compression Operating Modes ................................................................ 2-17 Handling of Voice Signals ................................................................................. 2-19 Processing of Inband Signaling ......................................................................... 2-21 Automatic Fax Processing ................................................................................. 2-22 Handling of Voiceband Modem Signals .............................................................. 2-23 Handling of Voice Trunk Signaling ..................................................................... 2-23 Voice Packet Processing ................................................................................... 2-24 Estimating Bandwidth Requirements................................................................. 2-25 Preventing Excessive Bandwidth Consumption .................................................. 2-25 Processing of Transparent Timeslots ................................................................ 2-26 Description of Gmux-2000 System Used for VoIP Services ..................................... 2-26 VCA-T1/16 Operating Modes ............................................................................ 2-30 Handling of Voice Signals ................................................................................. 2-31 Processing of Inband Signaling ......................................................................... 2-32 Automatic Fax Processing ................................................................................. 2-33 Handling of Voiceband Modem Signals .............................................................. 2-34 Handling of SS7 Signaling ................................................................................. 2-34 2.3 Connection (Bundle) Handling .................................................................................. 2-35 Overview .............................................................................................................. 2-35 Bundle Configurations Storage ......................................................................... 2-35 Number of Active Connections (Bundles) .......................................................... 2-36 Bundle Configuration Parameters .......................................................................... 2-37 TDMoIP Bundle Parameters ............................................................................... 2-38
ii Gmux-2000 Ver. 4.0B
Table of Contents
TDMoIP CV (Compressed Voice) Bundle Parameters ........................................... 2-39 2.4 Redundancy (APS) Functions .................................................................................... 2-40 Redundancy for SONET Network Connections........................................................ 2-41 Overview of SONET Network Interfaces ............................................................ 2-41 Operation of 1+1 Unidirectional Protection Function ........................................ 2-42 1+1 Bidirectional and 1+1 Bidirectional Optimized Protection Schemes ............. 2-45 Redundancy for PSN Interface ............................................................................... 2-45 1:N Protection Mode ............................................................................................. 2-48 1:N Protection for I/O Modules with Internal Ports ............................................ 2-48 1:N Protection for I/O Modules with External Ports ........................................... 2-49 Pseudowire Redundancy ....................................................................................... 2-51 2.5 Timing Subsystem .................................................................................................... 2-52 Output Timing Signals ........................................................................................... 2-53 Timing Reference Sources ..................................................................................... 2-53 Internal Reference Signals ................................................................................ 2-53 External Reference Signals................................................................................ 2-54 Internal Oscillator ............................................................................................. 2-54 External Clock Interface ......................................................................................... 2-54 Timing Subsystem Redundancy ............................................................................. 2-55 2.6 Ethernet Service OAM (IEEE 802.1ag, ITU-T Y.1731) .................................................. 2-56 Maintenance Domains........................................................................................... 2-56 Maintenance Entities ............................................................................................ 2-56 MEG Endpoints ..................................................................................................... 2-56 Connectivity Fault Management Protocols ............................................................. 2-57 2.7 Management Subsystem .......................................................................................... 2-58 Functional Block Diagram ...................................................................................... 2-58 CONTROL Module Management Subsystem ....................................................... 2-58 Ethernet Connections to CONTROL Modules...................................................... 2-60 Serial Port Connections .................................................................................... 2-60 CONTROL Module Redundancy .............................................................................. 2-60 External Alarm Interfaces ...................................................................................... 2-61 Dry-Contact Alarm Interface ............................................................................. 2-61 External Sense Input......................................................................................... 2-61 2.8 Power Supply Subsystem.......................................................................................... 2-61 Chapter 3. Installation and Setup Safety .................................................................................................................... 3-1 Grounding .......................................................................................................... 3-2 Laser Safety ........................................................................................................... 3-3 Protection against ESD ....................................................................................... 3-3 Proper Handling of Modules .................................................................................... 3-4 3.1 Site Requirements and Prerequisites .......................................................................... 3-4 Power ..................................................................................................................... 3-4 AC Power ........................................................................................................... 3-5 DC Power ........................................................................................................... 3-5 Payload Connections ............................................................................................... 3-6 T1 Port Connections ........................................................................................... 3-6 SONET Port Connections .................................................................................... 3-7 PSN Connections ................................................................................................ 3-7 Optical Cable Requirements ................................................................................ 3-7 Station Clock Connections ....................................................................................... 3-8 Management Connections ....................................................................................... 3-8 Ethernet Connections to CONTROL Modules........................................................ 3-8
Gmux-2000 Ver. 4.0B iii
Table of Contents
Serial Port Connections ...................................................................................... 3-8 Alarm Port Connections .......................................................................................... 3-9 Front and Rear Panel Clearance ............................................................................... 3-9 Ambient Requirements ........................................................................................... 3-9 Electromagnetic Compatibility Considerations ........................................................ 3-10 3.2 Package Contents .................................................................................................... 3-10 3.3 Required Equipment ................................................................................................. 3-10 3.4 Gmux-2000 Enclosure .............................................................................................. 3-11 General Description .............................................................................................. 3-11 Front Panel ........................................................................................................... 3-12 Rear View ............................................................................................................. 3-13 3.5 Installing the Fan Tray .............................................................................................. 3-14 Fan Tray Description ............................................................................................. 3-14 Installation Procedure ........................................................................................... 3-15 3.6 Installing the Power Inlet (PI) Module ....................................................................... 3-16 PI Modules Description .......................................................................................... 3-16 PI/AC Module .................................................................................................... 3-16 PI/DC, PI/48 Modules ........................................................................................ 3-16 Installing Full-Width PI Modules ............................................................................. 3-18 Installing Half-Width PI Modules ............................................................................ 3-18 3.7 Installing the Gmux-2000 PS Modules ....................................................................... 3-20 PS Module Description .......................................................................................... 3-20 Installing PS Modules ............................................................................................ 3-20 Removing a PS Module .......................................................................................... 3-22 3.8 Installing CONTROL Modules ..................................................................................... 3-23 CONTROL Module Description ............................................................................... 3-23 Preparing the CONTROL Module for Installation ..................................................... 3-24 Clock Interface Selection .................................................................................. 3-24 Switch SW2 (Restore Factory-Default Parameters) ............................................ 3-25 Installing the CONTROL Module ............................................................................. 3-26 Removing the CONTROL Module ............................................................................ 3-26 Replacing a CONTROL Module During Equipment Operation ................................... 3-27 Gmux-2000 Chassis with two CONTROL Modules .............................................. 3-27 Gmux-2000 Chassis with Single CONTROL Module ............................................. 3-28 3.9 Installing I/O Modules ............................................................................................... 3-28 3.10 Installing Blank Panels .............................................................................................. 3-28 3.11 Installation of Gmux-2000 Enclosure ........................................................................ 3-28 Preparing for Installation in Rack ........................................................................... 3-28 Installation in Rack ................................................................................................ 3-31 3.12 Connecting to Gmux-2000........................................................................................ 3-31 Grounding ............................................................................................................ 3-31 Connecting to Power ............................................................................................ 3-32 Connecting to AC Power ................................................................................... 3-32 Connecting to DC Power ................................................................................... 3-32 Connecting to the CONTROL Module ..................................................................... 3-33 Connection Data for CONTROL DCE Connector .................................................. 3-33 Connection Data for CONTROL ETH Connectors ................................................ 3-33 Connection Data for CLOCK Connectors ............................................................ 3-33 Connecting to I/O Modules .................................................................................... 3-33 Chapter 4. Operation 4.1 Turning On the Gmux-2000 ........................................................................................ 4-1 Preparations for Monitoring Power-Up Sequence..................................................... 4-3
iv Gmux-2000 Ver. 4.0B
Table of Contents
4.2 Normal Indications ..................................................................................................... 4-3 System Indications .................................................................................................. 4-3 CONTROL ETH Interface Status Indications .............................................................. 4-4 PSN Interface Modules (GbE) Status Indications....................................................... 4-4 SONET Interface Modules (OC3, C.OC3) Module Status Indications ........................... 4-4 Pseudowire Emulation Server Modules (T1-PW-SRV/28) Module Status Indications ... 4-4 Pseudowire Emulation Modules with External T1 Interfaces (T1-PW/28) Status Indications .............................................................................................................. 4-4 Voice Compression Modules (VCA-T1/16 and VCA-T1/12) Status Indications............. 4-5 4.3 Configuration and Management Alternatives .............................................................. 4-5 Working with Supervision Terminal .......................................................................... 4-5 Preparing for Preliminary Configuration .............................................................. 4-5 Log-in for Supervision and Configuration ............................................................ 4-6 Preliminary Configuration Sequence.................................................................... 4-7 Using the CLI ...................................................................................................... 4-8 Changing between CLI and Menu-Driven Modes ................................................ 4-10 CLI Command Tree ........................................................................................... 4-10 Preparing New Configuration Parameters.......................................................... 4-20 Validity Checks ................................................................................................. 4-21 Power-up Process ............................................................................................ 4-21 Working with Telnet .............................................................................................. 4-21 Telnet (IP) Host Characteristics ......................................................................... 4-21 General Telnet Operating Procedures................................................................ 4-22 Using SSH ............................................................................................................. 4-22 Working with SNMP Management Stations ............................................................ 4-23 Support for SNMP Management ........................................................................ 4-23 4.4 Turning the Gmux-2000 Off ..................................................................................... 4-23 Chapter 5. Configuration 5.1 Managing Gmux-2000 Configuration Databases .......................................................... 5-1 5.2 Configuration Sequence ............................................................................................. 5-2 5.3 Programming Modules ................................................................................................ 5-3 Loading the Hardware Configuration ....................................................................... 5-3 Programming Modules in the Gmux-2000 Chassis Manually ...................................... 5-3 5.4 Configuring the Router ............................................................................................... 5-4 Configuring the Address Aging ................................................................................ 5-5 Configuring the Default Gateway............................................................................. 5-6 Adding and Configuring Router Interfaces ............................................................... 5-6 Adding a Router Interface .................................................................................. 5-6 Configuring a Router Interface............................................................................ 5-7 Adding and Configuring Remote Peers..................................................................... 5-8 Defining Static Routes ............................................................................................ 5-9 5.5 Configuring System Parameters ................................................................................ 5-10 Configuring Logistic Parameters ............................................................................ 5-10 Configuring Date and Time .................................................................................... 5-11 Configuring Ethernet Management Port ................................................................. 5-13 Configuring Terminal Page Length ......................................................................... 5-14 5.6 Configuring the Clock ............................................................................................... 5-14 Configuring Domain Timing ................................................................................... 5-15 Configuring the External (Station) Clock ................................................................ 5-15 5.7 Configuring Network Managers................................................................................. 5-16 5.8 Configuring SNMP Communities ................................................................................ 5-17 5.9 Configuring Protection ............................................................................................. 5-17
Gmux-2000 Ver. 4.0B v
Table of Contents
Configuring Gmux-2000 Control Subsystem Redundancy ....................................... 5-17 Configuring the SONET APS ................................................................................... 5-18 Configuring 1:N Protection .................................................................................... 5-19 Configuring Pseudowire Bundle Protection ............................................................ 5-21 5.10 Configuring the LAG ................................................................................................. 5-22 LAG Benefits ......................................................................................................... 5-23 Configuring the LAG .............................................................................................. 5-23 5.11 Configuring Service OAM .......................................................................................... 5-24 Configuring General OAM Parameters .................................................................... 5-25 Adding and Configuring Maintenance Domains ...................................................... 5-25 Adding and Configuring Maintenance Associations ................................................ 5-26 Adding and Configuring Maintenance Endpoints .................................................... 5-27 Adding and Configuring Maintenance Endpoint Services......................................... 5-28 Performing OAM Loopback .................................................................................... 5-29 Performing OAM Link Trace ................................................................................... 5-30 5.12 Configuring Pseudowire Connections ........................................................................ 5-32 Adding a Pseudowire Bundle ................................................................................. 5-33 Configuring a Pseudowire Bundle .......................................................................... 5-34 Configuring a TDMoIP (CE) Bundle..................................................................... 5-34 Configuring an HDLC Bundle ............................................................................. 5-38 Configuring a CESoPSN Bundle .......................................................................... 5-39 Configuring a SAToP Bundle.............................................................................. 5-41 Displaying Bundle Configuration Summary ........................................................ 5-42 5.13 Configuring Cross-Connects...................................................................................... 5-43 Configuring TDM PW Cross-Connects ..................................................................... 5-43 Configuring TDM Mapping ..................................................................................... 5-44 5.14 Performing Administration Functions ........................................................................ 5-46 Viewing Logistic (Inventory) Information ............................................................... 5-46 Performing File Operations.................................................................................... 5-47 Downloading/Uploading by TFTP ....................................................................... 5-47 Internal Software Downloading ........................................................................ 5-51 Updating Configuration Database .......................................................................... 5-52 Restoring Factory-Default Settings ........................................................................ 5-52 Rebooting a Module .............................................................................................. 5-52 Using the File System Utilities ............................................................................... 5-53 Displaying the Flash Disk Contents ................................................................... 5-53 Deleting Files ................................................................................................... 5-53 Formatting Flash Disk ....................................................................................... 5-54 Chapter 6. Configuring Typical Applications 6.1 Overview.................................................................................................................... 6-1 Outline of Preliminary Configuration Sequence ........................................................ 6-1 General Configuration Sequence ............................................................................. 6-2 6.2 Application 1 Transport of Unframed Bundle from T1 Trunk .................................... 6-3 Application Overview .............................................................................................. 6-3 Preliminary Configuration ................................................................................... 6-4 Configuring the Router ....................................................................................... 6-4 Configuring System Clock ................................................................................... 6-5 Configuring I/O Module Physical Layer Parameters .............................................. 6-5 Configuring the Bundle ....................................................................................... 6-6 Connecting the T1 Port to the Bundle ................................................................. 6-6 Updating Configuration Database ....................................................................... 6-7 IPmux-24 Configuration .......................................................................................... 6-7
vi Gmux-2000 Ver. 4.0B
Table of Contents
6.3
6.4
6.5
6.6
Host IP and NMS Settings ................................................................................... 6-7 E1 Physical Settings............................................................................................ 6-8 Bundle Connection Settings ................................................................................ 6-8 Application 2 Transport of Framed Bundle from T1 Trunk ........................................ 6-8 Application Overview .............................................................................................. 6-8 Gmux-2000 Configuration ....................................................................................... 6-9 Configuring I/O Module Physical Layer Parameters .............................................. 6-9 Configuring the Bundle Connection Parameters .................................................. 6-9 Connecting the T1 Port to the Bundle ............................................................... 6-10 Updating Configuration Database ..................................................................... 6-10 IPmux-24 Configuration .................................................................................... 6-10 Application 3 Transport of Unframed Bundle from SONET Network........................ 6-11 Application Overview ............................................................................................ 6-11 Gmux-2000 Configuration ..................................................................................... 6-12 Preliminary Configuration ................................................................................. 6-12 Configuring the Router ..................................................................................... 6-12 Configuring I/O Module Physical Layer Parameters ............................................ 6-12 Configuring the Bundle ..................................................................................... 6-14 Connecting the T1 Port to the Bundle ............................................................... 6-15 Performing Internal Mapping ............................................................................ 6-15 Updating Configuration Database ..................................................................... 6-15 IPmux-24 Configuration ........................................................................................ 6-15 Application 5 Voice Trunking Application ............................................................... 6-16 Application Overview ............................................................................................ 6-16 Configuring the West Gmux-2000 ......................................................................... 6-17 Preliminary Configuration ................................................................................. 6-17 Configuring Management and IP Communication Parameters ............................ 6-17 Configuring Physical Parameters of Voice Compression Module ......................... 6-19 Configuring Physical Parameters of GBE Module ................................................ 6-20 Configuring Physical Parameters of OC-3 Module .............................................. 6-20 Configuring System Clock ................................................................................. 6-21 Creating Bundles .............................................................................................. 6-21 Assigning Timeslots to Voice Ports.................................................................... 6-22 Map Voice Ports to the OC-3 Link ..................................................................... 6-23 Connecting Bundles .......................................................................................... 6-24 Configuring Voice Ports 2 to 6 .......................................................................... 6-25 Assigning Data Port Timeslots .......................................................................... 6-25 Configuring the East Gmux-2000 ........................................................................... 6-25 Inband Management of Gmux-2000 via Voice Compression TDM Links ...................... 6-26 Application Overview ............................................................................................ 6-26 Configuration Procedure ....................................................................................... 6-27
Chapter 7. Troubleshooting and Diagnostics 7.1 Troubleshooting ......................................................................................................... 7-1 Preliminary Checks .................................................................................................. 7-1 Troubleshooting Hardware Problems ....................................................................... 7-2 Handling Service Problems ...................................................................................... 7-6 7.2 Detecting Configuration (Sanity) Errors ................................................................... 7-6 Interpreting the Sanity Errors .................................................................................. 7-6 7.3 Handling Alarms and Traps ....................................................................................... 7-21 Overview of Alarm Collection and Reporting .......................................................... 7-21 Alarm Buffer .................................................................................................... 7-21 Alarm Relays .................................................................................................... 7-22
Gmux-2000 Ver. 4.0B vii
Table of Contents
Using the Event Log .............................................................................................. 7-22 Reading the Event Log ..................................................................................... 7-22 Clearing the Log ............................................................................................... 7-23 Displaying Alarms.................................................................................................. 7-23 Interpreting Alarms ............................................................................................... 7-24 System and CONTROL Module Alarms ............................................................... 7-24 GbE Module Alarms .......................................................................................... 7-29 OC3 Module External SONET Port Alarms........................................................ 7-30 OC3 Module Internal STS-1 Port Alarms ......................................................... 7-31 OC3 Module Internal VT1.5 Port Alarms ......................................................... 7-33 Pseudowire Emulation Server Module Alarms .................................................... 7-34 Bundle Alarms .................................................................................................. 7-35 VCA-T1/16, VCA-T1/12 Alarms .......................................................................... 7-36 Traps Generated by Gmux-2000 ............................................................................ 7-38 7.4 Testing Gmux-2000 Operation.................................................................................. 7-41 Overview .............................................................................................................. 7-41 Diagnostic Tests for SONET (OC-3) Ports ............................................................... 7-43 Remote OC-3 Port Loopback ............................................................................ 7-43 Local OC-3 Port Loopback ................................................................................ 7-43 T3 and T1 Diagnostic Functions for CT3-PW/1 Modules.......................................... 7-44 Remote T3 Port Loopback ................................................................................ 7-44 Local T3 Port Loopback .................................................................................... 7-44 Remote T1 Port Loopback ................................................................................ 7-45 Local T1 Port Loopback .................................................................................... 7-46 T1 Port Diagnostic Functions for T1-PW-SRV/28 Modules ...................................... 7-47 Remote Loopback on T1 Port (T1-PW-SRV/28 Module) ...................................... 7-47 Local Loopback on T1 Port (T1-PW-SRV/28 Module) .......................................... 7-47 T1 Port Diagnostic Functions for T1-PW/28 Modules ............................................. 7-48 Remote Loopback on External T1 Port (T1-PW/28 Module)................................ 7-48 Local Loopback on External T1 Port (T1-PW/28 Module) .................................... 7-49 VCA-T1/16, VCA-T1/12 Voice Port Diagnostic Functions ......................................... 7-49 Remote Loopback on Voice Port ....................................................................... 7-49 Local Loopback on Voice Port ........................................................................... 7-51 Test Tone Injection........................................................................................... 7-52 VCA-T1/16, VCA-T1/12 Data Port Diagnostic Functions .......................................... 7-53 Remote Loopback on Data Port ........................................................................ 7-53 Ping Function ........................................................................................................ 7-54 Activating Diagnostic Functions ............................................................................. 7-55 Pinging Remote Hosts ...................................................................................... 7-55 Performing Loopback Tests .............................................................................. 7-55 7.5 Frequently Asked Questions ..................................................................................... 7-56 7.6 Technical Support .................................................................................................... 7-60 Appendix A. Connection Data Appendix B. Installing New Software Releases Appendix C. Operating Environment
viii
Gmux-2000 Ver. 4.0B
Chapter 1 Introduction
1.1
Purpose and Use
Gmux-2000 is a high-capacity carrier-class pseudowire gateway. Gmux-2000 is designed to facilitate smooth and cost-effective migration to packet-switched networks for users of the existing TDM-based platforms and infrastructure, enabling transport of legacy circuit-switched TDM traffic (including voice traffic), over packet-switched networks (PSNs). The following main types of services are supported: TDM pseudowire emulation (PW) for T1, channelized T3, and channelized OC-3 over IP packet-switched networks, and also over metro Ethernet networks (MENs) per MEF 8. Using pseudowire emulation methods means that Gmux-2000 can support all the signaling methods and payload types. Voice trunking, using advanced, bandwidth-efficient voice compression techniques, enables transporting compressed T1 voice traffic, including inband signaling, modems and fax, over TDM links (T1 and OC-3) and over Gigabit Ethernet packet-switched networks using IP transport. Voice over IP, enables transporting voice calls (including inband signaling, modems, and fax) with extensive support of bandwidth-efficient voice compression codecs, over Gigabit Ethernet packet-switched networks using IP transport.
Overview
Gmux-2000 is compatible with other pseudowire equipment offered by RAD, for example, the IPmux family of TDM Pseudowire Access Gateways, the Vmux family of Voice Trunking Gateways, the ACE-3XXX family of Multiservice Pseudowire Access products, as well as with Megaplex equipment with IP main link modules, and is compliant with the emerging pseudowire edge-to-edge emulation (PWE3) standards, including TDMoPSN, HDLCoPSN, CESoPSN and SAToP. Advanced systems design confers the flexibility needed to meet the requirements of practically every TDM transport application. Full redundancy for all the critical subsystems ensures high availability for continuous, reliable service. Extensive management capabilities, starting with supervision terminals and Telnet/SSH hosts and up to SNMP-based network management, confer complete control over all aspects of equipment operation, and support efficient provisioning and rapid response to changing requirements. Automatic event notification in accordance with the syslog protocol and NTP-based automatic time-of-day synchronization of managed nodes enable effective management of large networks and easier isolation of the source of transmission problems.
Gmux-2000 Ver. 4.0
Overview
1-1
To protect network operations against unauthorized access, Gmux-2000 supports a wide range of security features for every management facility: RADIUS authentication for supervision terminal and Telnet access, SSH for secure Telnet access and SNMP management with authentication and privacy per SNMPv3 (using both user-based and view-based security models), with continued support for SNMPv1.
Main Features
Gmux-2000 is a flexible, modular system that can be provisioned in accordance with the current application requirements, while providing significant room for future growth. Its function is to transparently bridge between legacy circuit-switched TDM networks and packet-switched networks, by converting TDM data streams coming from the TDM ports into packets that are transported over the PSN. The current Gmux-2000 version offers the following maximum capacities: TDM ports: for SONET ports, the Gmux-2000 capacity is two full channelized SONET ports at the OC-3 level (155.52 Mbps) for a total of 168 T1 streams. For redundancy, the Gmux-2000 can be equipped with four OC-3 ports (two of them serving as backup ports). When using PDH ports at the T1 (1.544 Mbps) level, the maximum pseudowire emulation capacity is up to 196 T1 streams. The same capacity, 196 T1 data streams, is also available when using channelized T3 (44.736 Mbps) interfaces. The voice compression capacity is up to 168 T1 streams, with compressed voice transport over OC-3 and T1 links, as well as over PSN (though the PSN GbE links). PSN ports: up to two Gigabit Ethernet (GbE) ports. For redundancy, the Gmux-2000 can be equipped with four GbE ports (two of them serving as backup ports).
The Gmux-2000 system is built in a 6U high modular chassis that can be installed in standard 19 inch (ANSI) and ETSI racks. The chassis has a total of 9 I/O slots that can be used as follows: PSN interface modules: 2 slots SONET interface modules: Regular OC-3 modules 2 slots Channelized OC-3 modules 7 slots I/O modules: up to 7 slots (including the 2 slots that can be used for SONET interface modules). The I/O slots support pseudowire emulation modules, and voice compression modules.
Additional slots are dedicated to control logic, timing, and power supply. To enhance availability, redundancy is provided for all the critical subsystems (power supply, control and timing). Either AC or DC power can be used, in accordance with order. Built-in cooling fans enable dense mounting in racks.
1-2
Overview
Gmux-2000 Ver. 4.0
Internally, the Gmux-2000 uses redundant buses (one set of telecom buses for the TDM side, and high-speed dual-StarLAN buses for the packet side). The internal timing and management buses are also redundant. The current Gmux-2000 version supports a wide range of traffic protection options, including APS (Automatic Protection Switching) for the SDH and PSN interfaces, and 1:N protection for I/O modules (1:N protection uses an additional, spare, module to protect module a group of N modules of the same type that carry the traffic). 1:N protection can always be configured for pseudowire emulation server modules and for voice compression modules using internal ports; to provide 1:N protection to pseudowire emulation and voice compression modules with external ports, RAD offers a carrier-class protection device, NPS-101 (refer to the NPS-101 Installation and Operation Manual for details). Gmux-2000 supports a wide range of management capabilities: SNMP: the Gmux-2000 includes an internal SNMP agent that enables full SNMP management via SNMP-based network management, for example, by means of RADview network management stations, in particular the RADview-SC/TDMoIP and the RADview-SC/Vmux Service Centers. The internal agent supports SNMPv3, including the authentication and privacy features, with continued support for SNMPv1. Supervision terminal: ASCII terminal or a PC running a terminal emulation program, connected either directly to the Gmux-2000, or through a modem or any other type of full-duplex data link. This terminal can perform all the Gmux-2000 supervision and configuration functions, and in particular the preliminary system configuration. To enable reliable authentication of users, Gmux-2000 supports the RADIUS (Remote Authentication Dial In User Service) protocol. Telnet: by means of any host capable of IP communication with Gmux-2000. The functions available under the Telnet protocol are similar to those available from a supervisory terminal, including RADIUS authentication. SSH: secure access using the SSH (Secure Shell) protocol, using any standard SSH client utility running on a PC or laptop capable of IP communication with Gmux-2000.
Gmux-2000 also supports the syslog protocol per RFC3164. This protocol enables automatic reporting of traps and alarms, with user-configurable severity level filter, to a specified remote collector (syslog server).
PSN Interfaces
Gmux-2000 uses Gigabit Ethernet links for connection to packet-switched networks. The links use Gigabit Ethernet field-replaceable SFP transceivers with optical GbE interfaces, or copper GbE interfaces, for meeting a wide range of operational requirements. A separate, non-traffic carrying, Fast Ethernet copper port enables on-site monitoring by technical personnel. Only one dual-port PSN interface module is required in the chassis, however Gmux-2000 supports two PSN interface modules.
Gmux-2000 Ver. 4.0
Overview
1-3
Each external GbE port is assigned its own IP address, and can be independently provisioned, to enable load balancing. The two ports of a PSN interface module can also be configured to use link aggregation per IEEE 802.3ad without LACP (Link Aggregation Control Protocol), thereby providing a single logical link to the network. Alternatively, redundancy can be used by configuring 1:1 bidirectional APS (Automatic Protection Switching) at the port level, or at the module level: When redundancy is enabled at the port level (that is, between the two ports of the same PSN interface module), at any time one port is active and the other serves as a backup, and therefore each port can be routed along a different path over the network (dual-homing support). When redundancy is enabled at the module level (that is, between the two PSN interface modules installed in the chassis), at any time the two ports of one module are active, and the ports of the other module serve as backup. In addition, each active port can be routed along a different path, as for port-level redundancy.
The internal ports of each PSN interface module connect by pairs of Fast Ethernet ports, through the StarLAN packet bus of the chassis, to each I/O module and to each control module. All the external and internal ports of the module are handled by an internal high-performance Ethernet switch. The switch provides user-configurable VLAN support for the payload and management traffic. Class of service is ensured by supporting per-bundle configuration of IEEE 802.1p priority at Layer 2 and Type of Service (ToS/DiffServ) at Layer 3.
Note
Starting with Gmux-2000 software release V3.5, RAD offers a new high-performance PSN interface module based on an advanced network processor, which, in addition to the capabilities of previous PSN interface modules, also supports VoIP, and PDH circuit emulation over Ethernet per Metro Ethernet Forum Implementation Agreement MEF 8. The new module also supports link aggregation with load sharing between ports on different modules. The new module is identified as GbE/2, whereas previous module versions are identified as GbE.
Gmux-2000 provides OAM to monitor and troubleshoot the Ethernet network and quickly detect failures. OAM Connectivity Fault Management (CFM) based on IEEE 802.1ag and Y.1731 to enable Ethernet service providers to monitor their services proactively, measure end-to-end performance, and guarantee that the customers receive the contracted SLA. Fault monitoring and performance measurement include Frame Delay, Frame Delay Variation, Frame Loss, and Frame Availability.
SONET Interfaces
The SONET interfaces are provided by SONET interface modules. Each module has two channelized OC-3 ports. The module provides physical OC-3 interfaces for direct access to the Synchronous Digital Hierarchy (SONET) transmission cores at the OC-3 level (155.520 Mbps), and also handles the TDM traffic flow between Gmux-2000 internal T1 ports, and the SONET network.
1-4
Overview
Gmux-2000 Ver. 4.0
The physical OC-3 ports can be ordered with fixed intra-office electrical (75 coax) interfaces, fixed optical interfaces with various characteristics (850 and 1310 nm with laser and LED transmitters, for operation over multi-mode or single-mode fibers) that comply with the applicable requirements of ITU-T Rec. G.957, G.958 and I.432, or with field-replaceable SFP transceivers with optical interfaces, for meeting a wide range of operational requirements. The SONET interface module operates as a dual-port SONET terminal multiplexer (TM) for the Gmux-2000 chassis that terminates the external OC-3 links and their overhead. The two module ports support free mapping of any internal T1 port of any I/O module to any TU-11 tributary unit. Each port is capable of multiplexing up to 84 T1 streams, for a total module capacity of 168 T1 data streams. The SONET interface module ports can be configured to provide two independent OC-3 links, or one OC-3 link with line redundancy. Line redundancy is activated by configuring 1+1 unidirectional APS (Automatic Protection Switching) per ITU-T Rec. G.783. This means that the traffic is automatically switched to the other OC-3 port in case the active OC-3 port or its link fails. Only one SONET interface module is required in the chassis, however Gmux-2000 supports two modules, for a total of four OC-3 ports per chassis. The total chassis capacity is two OC-3 links, and therefore, the Gmux-2000 SONET interface can be used in the following application modes: TM with single OC-3 link (single module, second port not connected) TM with dual OC-3 links (single module, both OC-3 ports connected) TM with single OC-3 link, and with line redundancy (single module, both OC-3 ports connected). TM with dual OC-3 links, with both line and hardware redundancy (two modules, with all the OC-3 ports connected).
Channelized OC-3 Modules

Starting with Gmux-2000 software release V4.0, RAD offers a new high-performance channelized OC-3 module. The new module combines SONET mapping capabilities with pseudowire emulation on a single platform. The two module ports support free mapping of any internal T1 port to any TU-11 tributary unit. The C.OC3 modules are configured to provide one OC-3 link with line redundancy. Line redundancy is activated by configuring 1+1 unidirectional, 1+1 bidirectional or 1+1 bidirectional optimized APS (Automatic Protection Switching) per ITU-T Rec. G.841. This means that the traffic is automatically switched to the other OC-3 port in case the active OC-3 port or its link fails. Protected OC-3 links can be located on the same or different C.OC3 modules. The new module is identified as C.OC3, whereas previous module versions are identified as OC3.
Gmux-2000 Ver. 4.0
Overview
1-5
Pseudowire (PW) Circuit Emulation Services

Pseudowire circuit emulation services are provided by means of advanced RAD-developed ASIC packet processors that handle the TDM-to-packet conversion. The packet streams generated by packet processors (commonly referred to as bundles) can be independently routed through the packet-switched network to the desired destination (each bundle provides a pseudowire connection). Packet formats can be selected on a per-bundle basis for optimal transmission over PSN, and each bundle/pseudowire can be independently routed to any destination. The following user-configurable protocols are supported, independently for each pseudowire: TDMoIP (TDM over IP) in accordance with RFC5087 and ITU-T Rec. Y.1413 HDLCoPSN (HDLC over PSN) in accordance with RFC5087 and RFC4618 (except Clause 5.3 PPP) CESoPSN (structure-aware TDM circuit emulation over PSN) in accordance with RFC5086 SAToPSN (structure-agnostic TDM over PSN) in accordance with RFC4553
When CES or SAT is used over UDP/IP networks, pseudowire emulation modules operated in Gmux-2000 units with GbE/2 PSN interface modules support two pseudowire multiplexing methods: RAD proprietary method, referred to as source multiplexing Standard multiplexing method, referred to as destination multiplexing.
Gmux-2000 meets the requirements for edge-to-edge simulation of TDM circuits over PSN in accordance with RFC4197, including high-performance adaptive timing capabilities. When operated in a Gmux-2000 with GbE/2 PSN interface modules, pseudowire emulation modules also support emulation of PDH circuits over metro Ethernet networks (MENs) in accordance with the Metro Ethernet Forum Implementation Agreement 8 (MEF 8). Two emulation options are available: Structure-aware circuit emulation service over Ethernet (CESoETH) Structure-agnostic circuit emulation service over Ethernet (SAToETH).
The total number of pseudowire connections per pseudowire emulation module can be up to 784, and the maximum number of remote devices connected to one Gmux-2000 can be up to 256. Within the Gmux-2000, TDMoIP conversion is provided in two ways: By means of T1 pseudowire emulation server modules. RAD offers server modules capable of handling 28 T1 independent streams. Server modules are needed to process the payload received through a SONET interface module. Three such modules are needed to handle one full OC-3 payload (84 T1 streams). Gmux-2000 supports six T1 pseudowire emulation server modules and one SONET interface module in the chassis, for a
1-6
Overview
Gmux-2000 Ver. 4.0
maximum capacity of 168 T1 streams; with two SONET interface modules, the maximum is five modules, the corresponding capacity is 140 T1 streams. For critical applications, 1:N protection can be used: in this case, one server module serves as protection for the other modules (5 or 4, respectively). By means of pseudowire emulation modules with external PDH interfaces. RAD offers two types of pseudowire emulation modules with external PDH interfaces: Pseudowire emulation modules with 28 external T1 interfaces. A pseudowire emulation server module with external T1 interfaces has 28 independent T1 ports with balanced (100 ) interfaces. For critical applications, an NPS-101 can be attached to the Gmux-2000 to provide 1:N protection: in this case, one emulation module serves as protection for the other pseudowire modules in the chassis. Pseudowire emulation modules with channelized T3 interfaces. This type of module has an external channelized T3 (44.736 Mbps) interface, which provides the TDM payload connection. A T3 link carries 28 T1 data streams, and therefore, the module capacity is 28 T1 (1.544 Mbps) trunks, each served by an independent internal T1 interface. The external T3 interface supports two framing modes: Synchronous M13 (SYNTRAN): this mode uses synchronous multiplexing, and therefore all the 28 T1 streams must have a common timing source. Asynchronous C-bit parity: this mode uses asynchronous multiplexing, and therefore can handle T1 streams from independent sources. This mode is preferable for most pseudowire applications. The T1 interfaces of these modules provide an alternative to SONET interfaces. In a Gmux-2000 without SONET interfaces, up to seven pseudowire emulation modules (either with individual T1 interfaces, or with one channelized T3 interface) can be installed in the chassis, resulting in a maximum capacity of 196 T1 streams. For all types of pseudowire emulation modules, the T1 framing method is user-selectable per port, in accordance with the specific application requirements: Unframed for transparent T1 transport. This permits only one pseudowire per port Framed (SF (D4)) or ESF framing. Up to 16 independent pseudowires per port are supported, up to a maximum of 112 bundles per module.
Note
For compatibility, Gmux-2000 also supports the previous generation of pseudowire circuit emulation (CE) modules, which do not support the full range of pseudowire emulation protocols.
Gmux-2000 Ver. 4.0
Overview
1-7
Voice Trunking Services

Voice trunking services are provided by means of voice compression modules, containing complete voice compression subsystems with a compression capacity of 16 T1, respectively 12 T1, voice trunks. The voice trunks can be connected either via the external T1 (PDH) user-side links located on the voice compression module itself, or via the internal ports, which can be mapped to the desired TUs of the OC-3 (SONET) ports located on the SONET interface modules. These modules enable Gmux-2000 systems to deliver voice traffic, including inband signaling (DTMF, MFR2, and MFC), voiceband modems and Group III fax up to 14.4 kbps, over the following types of links: TDM links: T1 (PDH) links located on the voice compression module itself, or OC-3 (SONET) ports located on the SONET interface modules GbE links, located on the PSN interface modules.
In addition to voice traffic, voice compression modules can also transparently transfer selected timeslots of the voice trunks. The modules support the ITU-T Rec. G.723.1 and G.729 Annex A voice compression algorithms, as well as ITU-T Rec. G.711 (A-law and -law PCM), and use TDMoIP multiplexing for efficiently transporting the payload of T1 trunks over TDM (T1 or SONET) networks. Packet structure is user-selectable. In addition to standard packet structures, RAD proprietary versions of these protocols are also offered to achieve significantly higher bandwidth efficiency. Advanced digital signal processing techniques ensure highly-reliable service, unaffected by the use of voice compression. These techniques include: Per-channel voice activity detection (VAD) and silence suppression Built-in echo cancellation for delays up to 32 or 128 msec per ITU-T Rec. G.168 (depending on module model) Relaying of Group III fax, modems at commonly used rates and standards, inband signaling and custom tones. Where compression cannot be used, for example, for non-standard inband signaling and modem protocols, voiceband signals can be faithfully transmitted using selectable PCM or ADPCM coders.
To prevent voice degradation when traffic passes multiple modules, a RAD proprietary super-tandem mode ensures that voice signals pass compression only once, irrespective of the number of hops on the transmission path. At the highest compression ratio, the 16-port modules enable compressing up to 16 T1 voice trunks for transport over a single T1 network link (up to 16:1 compression ratio); for 12-port modules, the maximum compression ratio cannot exceed 12:1. Compressed voice traffic can be routed over up to 32 independently-configurable bundles, where a bundle can carry any number of timeslots, up to a full T1 voice port (24 channels). Each compressed voice bundle can be independently connected to any desired network-side port (either TDM port or GbE port). Moreover, the voice compression modules support both point-to-point and point-to-multipoint (channelized) applications over their T1 network-side links, with user-configurable link bandwidth assignment per destination (the timeslots
1-8
Overview
Gmux-2000 Ver. 4.0
available on each T1 network-side link can be assigned to up to 10 independent subchannels). To guarantee high service quality together with highly efficient utilization of transport links, voice compression modules support a proprietary bandwidth limiting algorithm that ensures quality degrades gradually during intervals of excessive traffic load. To preserve service quality, a separate mechanism makes it possible to block the setup of new modem calls when bandwidth utilization exceeds user-configurable, application-specific thresholds. The modules provide full support for a wide range of signaling protocols. This includes CAS (robed-bit) signaling (transferred end-to-end either transparently, or after translation in accordance with user-specified profiles) as well as optimized HDLC-based transfer of CCS protocols such as Signaling System 7 (SS7), etc. The CCS timeslots are user-selectable, independently for each voice port, with a maximum of two timeslots per port. The voice compression modules have both TDM and packet ports: The TDM ports comprise a set of 16, respectively 12, voice (user-side) T1 ports and a separate set of 2 data (network-side) T1 ports The packet ports comprise 2 network-side ports, for connection to Gmux-2000 internal packet buses.
To provide maximum application flexibility and avoid the need for additional equipment, each set of TDM ports have both external ports with ANSI T1.403 and ITU-T Rec. G.703 interfaces located on the module panel, and internal ports that can be connected via the Gmux-2000 telecom buses to the SONET ports located on the SONET interface modules that may be installed in the chassis (each internal module port can be independently mapped to any desired VT1.5). The maximum number of voice compression modules that may be installed in a Gmux-2000 chassis is 7. Note however that 2 out of the 7 Gmux-2000 I/O slots that support these modules also support SONET interface modules, and therefore the maximum voice compression capacity (7 modules) can be reached only when using the external module ports. The maximum number of modules decreases by one for each installed SONET interface module: For 16-port modules, the maximum chassis capacities are as follows: Without OC3 modules in the chassis, 7 Gmux-2000 modules yield 112 T1 voice trunks per chassis (2688 voice channels). One OC3 module and 6 Gmux-2000 modules yield a maximum capacity of 96 T1 trunks per chassis (2304 voice channels) Two OC3 modules and 5 Gmux-2000 modules yield a maximum capacity of 80 T1 trunks per chassis (1920 voice channels). With VC-T1/12 modules, the respective maximum capacities are 84, 72, and 60 T1 voice trunks (up to 2016, 1728, and 1440 voice channels, respectively).
To improve availability, the data ports of the voice compression modules can be configured to provide backup for the connection to the network. In this case, the data ports operate in pairs: in each pair, one port serves as the main (primary) port, and the other as backup (secondary) port. At any time, only one port of each pair carries traffic. As long as the primary port can carry the traffic, it is automatically selected as the active port; in case of a problem on the link or in
Gmux-2000 Ver. 4.0
Overview
1-9
the port hardware, the traffic is automatically switched to the backup port. Switching is revertive. When using only their internal ports, 1:N protection is also available for the voice compression modules.
VoIP Services
Note For VoIP applications, the Gmux-2000 chassis must be equipped with GbE/2 PSN interface modules. The application mode of voice compression modules (voice trunking or voice over IP) is determined by the software downloaded to the modules (downloading is performed by means of the Gmux-2000 internal software download facility). Unless specifically ordered otherwise, modules are supplied loaded with the voice trunking application software. For VoIP applications, it is necessary to acquire licenses for the media gateway, and optionally signaling gateway. After entering the license keys, the VoIP application software is automatically downloaded and the module starts providing VoIP services in accordance with the licensed capabilities.
In VoIP applications, the voice compression modules perform gateway services that enable Gmux-2000 to transport T1 voice traffic, including inband signaling, modems, and fax, over IP networks. Two types of gateway services are available: Media gateway. This service is mandatory for VoIP applications. As a media gateway, the module uses the MEGACO/ITU-T Rec. H.248 protocol, and supports a wide range of codecs. The modules have a processing capacity of 16 T1, respectively 12 T1, voice trunks, resulting in a maximum capacity of 496, respectively 372, compressed voice channels per module. Media is transmitted over IP using the RTP and RTCP protocols (defined in RFC3550 and RFC3551, respectively). Signaling gateway. This service is optional. As a signaling gateway, the voice compression module uses the SCTP protocol (defined in RFC2960, part of SIGTRAN suite of signaling transport protocols), to transport common channel signaling using Signaling System No. 7 over IP networks per ITU-T Rec. Q.703 and RFC3331. The maximum signaling processing capability is 5 signaling timeslots per module (usually, one SS7 signaling timeslot can support up to 8 T1 trunks, thus the module signaling gateway function can support up to 40 T1 voice trunks).
The voice compression modules enable Gmux-2000 systems to deliver voice traffic, including inband signaling (DTMF), voiceband modems, and Group III fax, received over TDM links (either the external T1 (PDH) links located on the VCA-T1/16 module itself, or via OC-3 (SONET) ports located on OC3 modules) to IP networks via the GbE links located on the GbE modules installed in the chassis. To enhance availability, the modules support MGC redundancy, where the user can specify up to four secondary MGCs in addition to the primary MGC. The voice compression subsystem supports a wide range of voice compression codecs (ITU-T Rec. G.723.1 and G.729 codecs, and Adaptive Multi-Rate (AMR) narrow-band codecs standardized by the European Telecommunications Standards Institute (ETSI) for GSM cellular systems), as well as 64 kbps PCM codecs per ITU-T Rec. G.711 (A-law and -law). For optimum performance,
1-10
Overview
Gmux-2000 Ver. 4.0
dynamic jitter buffers with a maximum depth of 150 msec are used, and the packetizing interval is configurable in the range of 10 to 60 msec, depending on codec. Advanced digital signal processing techniques ensure bandwidth-efficient, highly-reliable service, unaffected by the use of voice compression. These techniques include: Silence suppression Built-in echo cancellation for delays up to 128 msec per ITU-T Rec. G.165 and ITU-T Rec. G.168 Selectable handling of inband signaling, fax and modems in accordance with the following user-selectable options: For inband DTMF signaling: relaying per RFC2833, transfer using MEGACO/ITU-T Rec. H.248 packets, or handling as regular analog signals For Group III fax traffic: relaying per ITU-T Rec. T.38, transmission using a specified G.711 codec or transmission using ITU-T Rec. V.152. It is also possible to ignore fax signals, that is, handle them as analog signals For voiceband modem traffic: transmission using a specified G.711 codec or transmission using ITU-T Rec. V.152. It is also possible to ignore modem signals, that is, handle them as analog signals Support of ITU-T Rec. V.152 for voiceband data transfer over IP networks (fax and modems), using the MEGACO/ITU-T Rec. H.248 protocol Where compression cannot be used, for example, for non-standard inband signaling and modem protocols, voiceband signals can be transmitted using selectable A-law or -law PCM coders. Voice compression modules support ITU-T Rec. V.152 (using the MEGACO/ITU-T Rec. H.248 protocol) for voiceband data transmission over IP networks.
Control Functions
The Gmux-2000 management subsystem is located on a dedicated control module. The main functions of the control module are as follows: Interfacing with the external management functions (SNMP-based network management stations, supervision terminals, or Telnet/SSH hosts) syslog servers, and authentication servers (RADIUS). Each control module has several interfaces: Two out-of-band interfaces: a serial RS-232 asynchronous port and a 10/100BASE-TX Ethernet interface Ethernet inband interfaces toward the PSN, via a Layer 2 switch. Control of Gmux-2000 system operation. The modules installed in the chassis are controlled via redundant management buses. The control modules store the application software, which determines the system capabilities and characteristics. This software can be remotely updated through the management link. Storage of configuration databases. The configuration databases can be uploaded and downloaded through the management link.
Gmux-2000 Ver. 4.0
Overview
1-11
Collection of operational history (alarms, configuration error messages, performance statistics, etc). This information can be read by local management, as well as from remote locations through the management link. A real-time clock in the Gmux-2000 control module enables to time stamp each individual operational history item. The real-time clock can be set either manually, or be automatically synchronized to an external time reference, using the NTP (Network Time Protocol).
Timing
Gmux-2000 timing subsystem includes a central timing subsystem, located on the control module, and local timing subsystems located on the individual I/O modules. Since Gmux-2000 is normally equipped with two control modules, redundancy is also available for the central timing subsystem. The various clock signals needed by the Gmux-2000 are derived as follows: Receive clocks: the receive clock of each interface is extracted from the corresponding received data stream. For the TDM side, this is the received signal; for the PSN side ports, the clock is derived from the average rate of received data, by means of a special adaptive timing recovery circuit. Transmit clock: the transmit clock of the each TDM interface can be locked to one of the following sources: System (nodal) clock provided by the central timing subsystem TDM receive clock, or, when applicable, adaptive clock of the same interface. The Gmux-2000 system clock can be locked to any of the sources listed above for the transmit clocks. In addition, the system clock can also be locked to external station clocks (1.544/2.048 MHz or 1.544/2.048 Mbps), connected via interfaces located on the CONTROL module, or to an internal clock oscillator. A system clock output is also available in the same interface.
External Alarm Monitoring and Reporting

The Gmux-2000 chassis includes a connector for reporting chassis alarms, by means of dry-contacts, to external equipment (buzzers, dialers, etc.). The connector also has an external alarm input for monitoring external sensors, a useful capability in unmanned locations.
Power Supply Subsystem

The Gmux-2000 chassis can use AC (115 or 230 VAC, 50/60 Hz) or DC (48 VDC) sources. The chassis can be equipped with up to three power supply modules, thereby enabling redundancy for the power supply subsystem.
1-12
Overview
Gmux-2000 Ver. 4.0
1.2
Typical Applications
Pseudowire Emulation Services for TDM Transport

Figure 1-1 shows a basic TDM transport application, in which the Gmux-2000
provides the connection between the PSTN and a SONET network over a packet-switched network: The T1 or T3 trunks of the PSTN switches are connected to the T1 or T3 interfaces of a Gmux-2000. The Gmux-2000 converts the T1 payload carried by each of these trunks to data streams, which are sent via the GbE PSN interface to the packet-switched network. The individual packet streams reach the other Gmux-2000, which multiplexes them into an OC-3 signal. This signal is connected to an OC-3 ADM port, and thus reaches the SONET network.
Figure 1-1. Basic Transport Application Figure 1-2 shows another typical Gmux-2000 application in which it provides the equivalent of leased line services over the packet-switched network.
In the application of Figure 1-2, the Gmux-2000 receives individual packet streams from several TDMoIP or TDM pseudowire access gateways and/or legacy multiplexers with TDMoIP interfaces (for example, modular Megaplex-2100 E1/T1 Integrated Access Devices equipped with ML-IP IP main link modules). These packet streams reach the PSN interface of the Gmux-2000 via the packet-switched network. The Gmux-2000 retrieves the original T1 streams and multiplexes them into an OC-3 signal, which is connected via an ADM to the SONET network. In both applications, Gmux-2000 provides flexible, robust connections because it works over a packet-switched network, yet enables the users to design hierarchical, reliable timing distribution in accordance with the specific application requirements, despite the intervening packet-switched network. Another important Gmux-2000 advantage is that it provides grooming down to the DS0 level, thereby saving additional hardware: each T1 port, whether internal (i.e., connected to an OC-3 interface) or external, supports up to 16 bundles,
Gmux-2000 Ver. 4.0
1-13
each capable of being independently routed to a different destination over the packet-switched network. The timeslots carried by each bundle are individually selectable.
Figure 1-2. Gmux-2000 as Access Multiplexer
Voice Compression Applications

High Capacity Toll Bypass over SONET Networks
Figure 1-3 shows a Gmux-2000 equipped with voice compression modules used
to provide a high-capacity toll bypass link over the SONET network.
Up to 5 or 6 VC-T1/16 2 T1 16 T1
OC-3 16 T1 2 T1
VC-T1/16
OC3
Up to 80 or 96 T1
OC-3
SONET Network
OC-3
Up to 80 or 96 T1
PSTN Switch
Gmux-2000 with VC-T1/16 and OC3 Modules
Gmux-2000 with VC-T1/16 and OC3 Modules
PBX
Backup
Figure 1-3. High Capacity Toll Bypass over SONET Network
1-14
Gmux-2000 Ver. 4.0
In this application, a high-capacity PBX, located on customers premises, may be directly connected to a PSTN switch via a large number of T1 trunks. The maximum number of T1 trunks depends on the desired protection level for the OC-3 link: When only one SONET interface module is used (line redundancy only), the maximum number of T1 trunks supported by one Gmux-2000 chassis is 96 (up to 2304 compressed voice channels) When two SONET interface modules are used (line and hardware redundancy), the maximum number of T1 trunks supported by one Gmux-2000 chassis is 80 (up to 1920 compressed voice channels).
High Capacity Toll Bypass over Packet Switched Networks

Figure 1-4 shows a Gmux-2000 equipped with voice compression modules used
to provide a high-capacity toll bypass link over a packet switched network.
Figure 1-4. High Capacity Toll Bypass over Packet Switched Network
This application uses the internal packet ports of the voice compression modules to direct the compressed voice traffic (or any part of this traffic, as configured by the user) to the desired GbE port(s) installed in the Gmux-2000. The PSN connection characteristics are configured by defining bundles. Voice compression modules can operate over IP packet switched networks, in accordance with users configuration for each bundle. PSN connections can be used in parallel with any type of TDM network connections.
Connecting Multiple Remote Call Centers

Figure 1-5 shows a Gmux-2000 equipped with voice compression modules that
provides access links to from the corporate PBX or from a PSTN switch to several remote call centers, each using one Vmux-2100 Voice Trunking Gateway. When equipped with 16-port voice compression modules, the maximum capacity of the Gmux-2000 is 112 T1 trunks, using only one T1 link to connect a group of up to 16 T1 trunks to each call center. The connection to the Vmux-2100 units is made over the external data ports. In this application, a separate module is used for each remote location: in this way, availability can be greatly enhanced by using the backup function: each T1 link can be backed up by using the other data port. Using the point-to-multipoint capability of the voice compression modules enables connecting to an even larger number of remote locations, because each data port can connect to up to 10 separate locations. Voice compression modules also supports inband management of the Vmux-2100 units: in Figure 1-5, a network management station, for example,
Gmux-2000 Ver. 4.0
1-15
RADview-SC/Vmux, connected to a GbE port of the Gmux-2000 unit can manage inband the Vmux-2100 units connected via Gmux-2000 data ports.
Up to 7 VC-T1/16 16 T1 2 T1
16 T1
2 T1
16 x T1
Up to 112 T1s
Up to 7 Active T1s
PBX or PSTN Switch
Gmux-2000 with VC-T1/16 Modules
16 x T1
Figure 1-5. Remote Call Centers (Main Link Hot Standby Mode)
Voice Trunking over Multiple T1 Streams

provides voice trunks between two MSCs with OC-3 interfaces over T1 infrastructure, either as a replacement for access to SONET infrastructure, or when no SONET infrastructure is available. The maximum number of T1 trunks depends on the desired protection level for the OC-3 link to each MSC: When only one SONET interface module is used (line redundancy only), the maximum number of T1 trunks supported by one Gmux-2000 chassis is 96 When two SONET interface modules are used (line and hardware redundancy), the maximum number of T1 trunks supported by one Gmux-2000 chassis is 80.
Voice compression modules also support inband management of the Gmux-2000 units: in Figure 1-6, a network management station, for example, RADview-SC/Vmux, connected to a GbE port of one Gmux-2000 unit can manage inband the other Gmux-2000 unit, via the voice compression module data ports.
1-16
Gmux-2000 Ver. 4.0

Up to 5 or 6 VC-T1/16 16 T1 2 T1 OC-3 16 T1 2 T1
OC3
VC-T1/16
OC-3
Up to 10 or 12 T1s (Compressed)
OC-3
MSC
Gmux-2000 with VC-T1/16 Modules Backup
MSC
Figure 1-6. Voice Trunking over Multiple T1 Streams (Main Link Redundancy Mode)
Voice Trunking over OC-3 Link

provides voice trunks from a remote location over an OC-3 link. Using voice compression reduces the number of VT1.5s needed on the OC-3 link, thereby freeing bandwidth for other applications.
Up to 5 or 6 VC-T1/16 16 T1
2 T1 OC-3 SONET
16 T1
2 T1 OC3 OC-3 (Compressed) OC-3 (Uncompressed) OC-3 (Compressed) OC-3 (Uncompressed) VC-T1/16
Voice Switch
Digital Cross Connect
Figure 1-7. Voice Trunking over OC-3 Link
Incorporating Gmux-2000 in a VoIP Network

Gmux-2000 equipped with VCA-T1/16 modules complies with most widely used voice protocols, and therefore can be easily incorporated in VoIP networks using the MEGACO/ITU-T Rec. H.248 and SIGTRAN protocols, for example, networks serving mobile operators. In such VoIP networks, the call control functions are handled by one or more Media Gateway Controllers (MGCs), which manage all the voice traffic processing and flows within the network.
Gmux-2000 Ver. 4.0
1-17
Two options are available for connecting a users T1 voice trunk to a Gmux-2000 equipped with VCA-T1/16 modules serving as media gateways: Directly to the module external T1 voice ports. In this case, the maximum number of VCA-T1/16 modules that can be installed is 7, and therefore the maximum number of T1 trunks that may be served by one Gmux-2000 is 112 (84 for VCA-T1/12 models). When all the VCA-T1/16 modules in Gmux-2000 are used as media gateways, the resulting maximum transport capacity is 3472 voice channels per chassis Connecting the users voice trunks to the internal voice ports, via OC-3 links terminated on the OC3 modules installed in chassis. In this case, each T1 port can be independently mapped to any VT1.5. The maximum number of T1 trunks per chassis depends on the desired protection level for the OC-3 link: When only one OC3 module is used (line redundancy only), the maximum number of T1 voice trunks supported by one Gmux-2000 chassis with VCA-T1/16 modules is 96 (maximum of 2976 voice channels) When two OC3 modules are used (line and hardware redundancy), the maximum number of T1 trunks supported by one Gmux-2000 chassis with VCA-T1/16 modules is 80 (maximum of 2480 voice channels).
Figure 1-8 shows the integration of Gmux-2000 equipped with VCA-T1/16

modules in a 3G mobile operator network.
Figure 1-8. Gmux-2000 with VCA-T1/16 Modules in 3G Mobile Operator Networks
Interoperability with Vmux Family Products

Voice compression modules are fully interoperable with the RAD Vmux family of Voice Trunking Gateways. Figure 1-9 shows a Gmux-2000 equipped with voice compression modules connecting a large number of T1 voice trunks to multiple locations, using a much smaller number of T1 links to carry the compressed voice traffic. An important advantage of Gmux-2000 voice compression module is that it provides for inband management of the individual Vmux units by means of the
1-18
Gmux-2000 Ver. 4.0
same network management station, for example, RADview-SC/Vmux, that is used to manage the Gmux-2000 in which the module is installed. The management station can connect to the Gmux-2000 from a remote location, via the GbE module.
T1s T1 Up to 112 T1s or Single OC-3 Up to 14 T1s T1
T1 T1
Figure 1-9. Interoperability with Vmux Equipment over TDM Networks Figure 1-10 shows a similar application that uses an IP network for connecting to
the Vmux-2100 units.
Up to 112 T1 GbE
Packet Switched Network
GbE
T1
Gmux-2000 with VC-T1/16 and GbE Modules
Gmux-2000 with VC-T1/16 and GbE Modules
Vmux-2100 ETH
T1
Vmux-2100 ETH
T1
Figure 1-10. Interoperability with Vmux Equipment over PSN Networks
Gmux-2000 Ver. 4.0
1-19
1.3
Equipment Description
This section provides information on the physical construction and hardware configuration options available for the Gmux-2000.
System Structure
Gmux-2000 can simultaneously support pseudowire emulation and voice trunking services. The following sections describe each type of service.
TDM Pseudowire Emulation Services

The structure of a Gmux-2000 system equipped for TDM transport using pseudowire emulation is shown in Figure 1-11.
Management Ports Station Clocks (IN/OUT) RS-232 Ethernet Power Input
Management Subsystem
Timing Subsystem

Cooling Fans
OC-3 Ports
SONET Interface Subsystem
Pseudowire Emulation Server Subsystem
External T1 or T3 Ports
Pseudowire Emulation Subsystem with External T1 or Channelized T3 Interfaces
PSN Interface Subsystem
PSN Interfaces
Gmux-2000
Figure 1-11. Gmux-2000 System Structure for TDM Pseudowire Emulation Services
The Gmux-2000 configuration includes the following subsystems: TDM interfacing subsystem: provides interfaces to the TDM users equipment or network. Two types of interfaces are available: SONET interfaces, located on dedicated modules PDH interfaces (either external T1 interfaces, or internal T1 interfaces provided by modules with channelized T3 interfaces). The PDH interfaces are collocated with the packet processors of the pseudowire emulation subsystem
1-20
Gmux-2000 Ver. 4.0
Packet processing subsystem, part of the pseudowire emulation subsystem: performs the conversion between the circuit switched (TDM) and packet switched networks, using edge-to-edge pseudowire emulation techniques. The packet processors serving the SONET interfaces are located on separate pseudowire emulation server modules PSN interface subsystem: interfacing to the packet-switched network (PSN), and handling of the packet-switched traffic (Layer 3/4 routing and Layer 2 switching functions) Timing subsystem (collocated with the management subsystem): provides timing signals to all the Gmux-2000 circuits, and external (station and nodal) clock interfaces Management (control) subsystem: controls Gmux-2000 operation, stores its software and configuration, and provides interfaces for local and remote management Power supply subsystem: includes power inlet and power supply modules Cooling fans: for increased system reliability
The intrasystem connections (traffic, timing, power distribution and management) are located on the backplane. Two types of traffic buses are used: TDM bus: carries the TDM traffic between the SONET interface modules and the internal ports of other modules, in accordance with the required service: either pseudowire emulation server modules, or internal TDM ports of voice compression modules (see below). The TDM bus consists of multiple telecom (19.44 MHz) buses. Packet bus: carries the packet traffic between the PSN ports and I/O modules (pseudowire emulation and voice compression modules). Consists of multiple collision-free Fast Ethernet connections having a star (StarLAN) topology.
Voice Compression Services

The structure of a Gmux-2000 system equipped for voice compression services is shown in Figure 1-12. The Gmux-2000 configuration used for voice compression services is similar to that used for TDM pseudowire emulation, except that for voice trunking applications, a voice compression subsystem replaces the pseudowire emulation subsystem. The voice compression subsystem has its own set of TDM interfaces. These interfaces include (see description starting on page 1-7): PDH T1 interfaces, located on the voice compression modules Internal SONET interfaces, which connect to the SONET network via the SONET interface subsystem.
The voice compression subsystem is used to compress voice and the associated signaling for transmission over packet switched networks, and over T1 links (either links connected to the external T1 ports or mapped to the desired TUs of the OC-3 ports). In addition to the TDM links, the compressed voice can also be inserted in voice compression bundles, and connected via the Gmux-2000 packet buses to the PSN interface modules, for transport over the PSN.
Gmux-2000 Ver. 4.0
1-21
Management Ports Station Clocks (IN/OUT) RS-232 Ethernet
Power Input
Timing Subsystem

Cooling Fans
OC-3 Ports
SONET Interface Subsystem
Internal SONET Ports
External T1 Voice Ports
Voice Compression Subsystem
PSN Interfaces
External T1 Data Ports
Gmux-2000
Figure 1-12. Gmux-2000 System Structure for Voice Compression Services
Physical Description
Front Side
Figure 1-13 shows a general front view of a Gmux-2000 chassis. The Gmux-2000
chassis is modular, and has a height of 6U. The chassis is intended for installation in 19-inch (ANSI) and ETSI racks using rack mounting kits available from RAD (not shown in Figure 1-13), however it can also be installed on shelves. Air intake and discharge vents are located on the side walls.
1-22
Gmux-2000 Ver. 4.0
Figure 1-13. Gmux-2000 Front View
Rear Side
The rear side of the chassis has physical slots in which plug-in modules are installed to obtain the desired equipment configuration: The management and power supply modules, and the fan tray, are always installed in dedicated chassis slots, called system slots PSN interfacing modules, SONET interfacing modules, pseudowire emulation server modules (either with or without external interfaces), and voice compression modules are installed in the other chassis slots (called I/O slots). The I/O slots are identified as I/O-1 to I/O-9.
All the external connections are made to connectors located on the plug-in modules; the rear panel has only one connector for external alarms.
Figure 1-14 and Figure 1-15 show typical Gmux-2000 rear views, and identify the functions of the various slots. The unit shown in Figure 1-14 is equipped for TDM traffic transport services, and that shown in Figure 1-15 is equipped for voice
trunking services (when a Gmux-2000 is used exclusively for VoIP services, it is not necessary to install SONET interface modules in the chassis).
Gmux-2000 Ver. 4.0
1-23
Gm ux-2000
Slot:
I/O 6 I/O 5
GbE/2 Module
Figure 1-14. Typical Gmux-2000 Rear View (Unit Equipped for TDM Traffic Transport Services)
1-24
Gmux-2000 Ver. 4.0

Power Inlet (PI) Module
Alternate Slot for SONET Interface Module or Voice Compression Module Slot for SONET Interface Module or Voice Compression Module
Gmux-2000
INLET P.S . 3 P.S . 2 P.S . 1 CT RL. 2 CRTL. 1
I/O-9 I/O-8 I/O-7 I/O-6 I/O-5 I/O-4 I/O-3 I/O-2 I/O-1
ALA RM S PW R T ST M AJ . ALARM M IN . ALA RM
FAN-TRAY
Slot:
PW R FLT
L ASER CL ASS 1
LOC REM TX
ACT LINK
LOC REM TX RX
RDY ALM
I/O-9
AC-IN
OC3
RX
I/O 9 Slot for PSN I/O 8 Interface Module I/O 7 I/O 6 Alternate Slot for PSN Interface Module I/O 5 I/O 4 I/O 3 I/O 2 I/O 1 Slots for Voice Compression Modules
L ASER CL ASS 1
GE 1 LINK TX
MONITOR
GE 2 PAUSE RX LINK TX PAUSE RX ACT FLT

I/O-8
POWER POWER
3
PS-AC
GbE
I/O-7
POWER POWER
2
PS-AC PS-AC
1 3 5 7 9 11 13 15 LOC REM 2 4 6 8 10 12 14 16 1 2 LOC REM ACT FLT
I/O-6
I/O-5
POWER POWER
VCA-T1/16
1-16 T1
LOC
LINK
1
1 3 5 7 9 11 13 15 LOC REM 2 OUT IN SD 1 3 5 7 9 11 13 15 LOC S TAT ION CLOCK 2 4 6 8 10 12 14 16 REM 4 6 8 10 12 14 16
REM ACT FLT I/O-4
PS-AC VCA-T1/16
1-16 T1
LOC
LINK
REM ACT FLT I/O-3
2
CONTROL
ACT
LINK
VCA-T1/16
ETH DCE ACT FLT 1 OUT IN SD 2 4 6 8 10 12 14 16 3 5 7 9 11 13 15 LOC REM
1-16 T1
LOC
LINK
REM ACT FLT I/O-2
CONTROL
VCA-T1/16
1-16 T1
LOC
LINK
1
CONTROL
ACT
LINK
S TAT ION CLOCK 1 3 5 7 9 11 13 15 LOC ACT FLT REM 2 4 6 8 10 12 14 16
REM ACT FLT I/O-1
ETH
CONTROL
DCE
VCA-T1/16
1-16 T1
LINK
Fan Tray System Slots 2 Slots for CONTROL Modules 3 Slots for PS Modules I/O Slots
Figure 1-15. Typical Gmux-2000 Rear View (Unit Equipped for Voice Trunking Services)
The module types that can be installed in Gmux-2000 chassis slots are listed in Table 1-1. Note that slots I/O 6 and I/O 7 can also be used as alternative slots for PSN interface and SONET interface modules, respectively (their recommended slots appear in bold in Table 1-1). This alternative is also identified in Figure 1-14 and Figure 1-15.
Table 1-1. Gmux-2000 Chassis Slot Assignments

Slot Type Module Types Supporting Slot Designations
Power inlet module (115/230 VAC or 48 VDC) INLET System Slot Power supply module (115/230 VAC or 48 VDC) Control & clock module Pseudowire emulation server module Pseudowire emulation module with external T1 or channelized T3 interfaces I/O Slot Voice compression module SONET interface module Channelized SONET interface module PSN interface module PS.1, PS.2, PS.3 CTRL.1, CTRL.2 I/O-1 to I/O-5, I/O-7, I/O-9 I/O-1 to I/O-5, I/O-7, I/O-9 I/O-1 to I/O-5, I/O-7, I/O-9 I/O-7, I/O-9 I/O-1 to I/O-5, I/O-7, I/O-9 I/O-6, I/O-8
Gmux-2000 Ver. 4.0
1-25
Available Modules
Table 1-2 lists the modules currently available for the Gmux-2000, their
functions, and the corresponding chassis slots: System modules are described in Chapter 2. For a concise description of I/O modules, see the Description of I/O Modules section below; for additional details, refer to the corresponding module Installation and Operation Manual.
Table 1-2 also presents the Gmux-2000 system capacity. Table 1-2. Gmux-2000 Modules
Module PI/AC PI/48 PI/DC PS-AC PS-DC CONTROL OC3 C.OC3 GbE/2 T1-PW-SRV/28 T1-PW/28 CT3-PW/1 VC-T1/16 VCA-T1/16 VC-T1/12 VCA-T1/12 Function 3-port AC power input module (115/230 VAC, 50/60 Hz) 2-port DC power input module (48 VDC) Single-port, half-width DC power input module (48 VDC) AC power supply module (115/230 VAC, 50/60 Hz) DC power supply module (48 VDC) Control module, contains the Gmux-2000 control circuits and its timing subsystem Dual-port SONET interface module Dual-port channelized SONET interface module High-performance dual-port GbE PSN interface module 28-port T1 pseudowire emulation server module 28-port T1 pseudowire emulation module with external T1 ports 28-port T1 pseudowire emulation module with external channelized T3 port 16-port T1 voice compression module 12-port T1 voice compression module Can be Installed in INLET INLET INLET PS.1, PS.2, PS.3 PS.1, PS.2, PS.3 CTRL.1, CTRL.2 I/O-7, I/O-9 I/O-1 to I/O-5, I/O-7, I/O-9 I/O-6, I/O-8 I/O-1 to I/O-5, I/O-7, I/O-9 I/O-1 to I/O-5, I/O-7, I/O-9 I/O-1 to I/O-5, I/O-7, I/O-9 I/O-1 to I/O-5, I/O-7, I/O-9 I/O-1 to I/O-5, I/O-7, I/O-9 Maximum Chassis Capacity 1 1 2 3 3 2 2 7 2 7 7 7 7 7
1-26
Gmux-2000 Ver. 4.0
Note
For compatibility with previous Gmux-2000 versions, pseudowire circuit emulation (CE) modules, T1-CE/28 and T1-CE-SRV/28, are also supported. Starting with Gmux-2000 version V3.2, pseudowire emulation modules, which have enhanced capabilities, are used to provide the functions of the VC-T1/16, VC-T1/12 and VCA-T1/16, VCA-T1/12modules, and also support VoIP services.
Description of Gmux-2000 Modules

This section provides a concise description of the functions of the Gmux-2000 system modules. Refer to Chapter 2 for a functional description of these modules.
Power Supply Modules

The Gmux-2000 requires power supply (PS) modules and a separate power input (PI) module. The Gmux-2000 can use either AC or DC power sources. The PI and PS modules must match the selected power source (see Table 1-2). The Gmux-2000 chassis has three PS slots, thereby enabling the installation of three PS modules. The method used to connect power to the PS modules depends on the power source AC or DC: AC power: the AC power inlet module, PI/AC, has three separate inputs, one for each AC PS module: this enables connecting each PS module to an independent power circuit. Note that all the AC power inputs must be simultaneously connected/disconnected by means of an external ON/OFF switch or circuit breaker. DC power: the DC power inlet modules enable connecting simultaneously two separate DC power sources with the same nominal voltage (currently, 48 VDC), in parallel, to each DC PS module. This enables connecting one DC source to all the PS modules, or connecting in parallel two sources, for redundancy. Two types of DC power inlet modules are offered: DC power inlet module with two DC inputs. Currently, this version is available for 48 VDC sources DC power inlet module with single DC input. Currently, this version is only available for 48 VDC sources. This inlet is a half-width module, and therefore two such half-width modules can be installed in the PI slot (the two inlet modules plug into an internal FILTER module). Together, the two inlet modules provide two DC inputs, the same as the full-width version, but the advantage of using half-width PI modules is that each one can be removed and replaced, without disconnecting both power sources from the DC PS modules. RAD offers PS modules with two ratings: 200W and 300W, and therefore three PS modules can supply a maximum of 600W, respectively 900W, of power to the modules installed in the chassis. The actually required power depends on the modules installed in the chassis, but with the currently offered modules two 200W PS modules are sufficient to power a fully-equipped chassis.
Gmux-2000 Ver. 4.0
1-27
Note
Contact RAD Technical Support Department if it is necessary to use both 200W and 300W PS modules in the same chassis.
Installing more PS modules than is required to power the installed modules has the advantage of redundancy. For example, when the chassis requires two PS modules, it is still recommended to install the third PS module as well, for 2+1 redundancy: With a redundant PS module, all the three modules are connected to power, and when operating normally all share the load. In case any one PS module fails or loses its input power, the remaining PS modules continue to supply power to the chassis, without any service disruption. Therefore, a malfunctioning PS module can be replaced online; after replacement, the module starts again sharing the load. Switch-over is thus automatic and hitless.
Note
In this example, should the total required power exceed the maximum that can be provided by two PS modules (400W, respectively 600W), redundancy is no longer available, because three PS modules must be operational to supply the power. Load sharing is still active.
CONTROL Module
The CONTROL module performs two main functions: Control functions: Interfacing with the network management stations, supervision terminals, and Telnet hosts. Control of Gmux-2000 system operation. Storage of application software, which determines the capabilities and features provided by the Gmux-2000. Storage of configuration databases. Collection of operational history (alarms, performance statistics, etc.). Clock and timing generation functions: generates nodal clock signals for the Gmux-2000 system, locked to user-selected internal or external sources.
Only one CONTROL module is necessary per Gmux-2000 chassis, however the chassis has two slots dedicated to this type of module. The second slot is used to install a redundant CONTROL module, thereby providing a hot-standby capability for the Gmux-2000 system control and timing functions. When a second CONTROL module is installed, the two modules operate as a master/slave pair; one module is the active (master) module and the other serves as a hot standby (slave). Only the master module communicates with the management station/terminal and actively manages the Gmux-2000 system. The slave module is automatically updated by the master module with all the configuration and status data, and therefore the slave can take over at any time without disrupting system operation. The slave module communicates only with the master module. Moreover, the transmit line in the slave serial port connectors is disabled, to
1-28
Gmux-2000 Ver. 4.0
enable physical connection in parallel (e.g., by means of a Y cable) to a management facility.
Note
The station clock interfaces can also be configured to enable parallel connection by means of a Y-cable.
Description of I/O Modules

This section provides a concise description of the I/O modules available for the Gmux-2000 system. For complete functional descriptions of these modules, refer to the module Installation and Operation Manuals.
OC3 SONET Interface Module

The OC3 module operates as a dual-port SONET terminal multiplexer (TM) for the Gmux-2000 chassis that terminates OC-3 links and their overhead. The module has two independent channelized OC-3 ports, where each port is capable of multiplexing up to 84 T1 streams taken from any internal T1 ports of the I/O modules installed in the Gmux-2000 chassis into one OC-3 data stream. The total module capacity is 168 T1 data streams. The OC3 module ports can be configured to provide two independent OC-3 links, or one OC-3 link with line redundancy. Line redundancy is activated by configuring 1+1 unidirectional APS (Automatic Protection Switching). This means that the traffic is automatically switched to the other OC-3 port in case the active OC-3 port or its link fails. Installing two OC3 modules provides both line and hardware redundancy. The OC3 module supports free mapping of any internal T1 port of any I/O module to any TU-11 tributary unit carried in a STS-3 virtual container. The OC3 module can be used in conjunction with T1-PW-SRV/28 modules, which include pseudowire emulation processors needed to process the OC-3 payload, to prepare it for being transported over the packet-switched network, and in conjunction with VC-T1/16 and VC-T1/12 voice compression modules. OC3 modules can be ordered in the following versions, which differ with respect to the interface types of the external OC-3 ports: Fixed electrical interfaces for intra-office applications that require direct, short-range connection to higher-level SONET multiplexers. An electrical interface has two BNC connectors and requires two 75 coaxial cables per port. Fixed optical interfaces for short-haul and long-haul applications, complying with ITU-T Rec. G.957, terminated in SC connectors. These interfaces require two fibers per port (a transmit fiber and a receive fiber). RAD offers a wide range of fixed optical interfaces, which include LED and laser sources operating at 850 or 1310 nm over multi-mode and single-mode fiber, and therefore can optimally meet a wide range of system requirements. The long-haul optical interface has a range of up to 40 km (26 miles), thereby enabling remote access to regional and national SONET transmission networks.
Gmux-2000 Ver. 4.0
1-29
SFP sockets for field-replaceable standard SFPs with optical interfaces (typically, SFPs use LC connectors). This enables selecting the optimal interface for each application and fiber type. RAD offers a wide range of SFPs, including high-performance SFPs that are also offered in WDM versions using a single fiber instead of the customary two fibers, and can achieve ranges up to 80 km/50 miles.
The OC3 module supports flexible timing modes for its SONET ports: Receive path: the receive path recovers the clock signal from the OC-3 line signal. The recovered OC-3 receive clock can be provided as a timing reference for the Gmux-2000. Transmit path: the transmit timing of the OC-3 interface can be either derived from the Gmux-2000 system timing, or locked to the locally recovered OC-3 receive clock (loopback timing).
OC3 operating mode is determined by commands received from the Gmux-2000 CONTROL module. The CONTROL module can also download software updates to the module.
Channelized OC-3 Modules

Starting with Gmux-2000 software release V4.0, RAD offers a new high-performance channelized OC-3 module. The new module combines SDH mapping capabilities with pseudowire emulation on a single platform. Its TDM termination and internal mapping capabilities are similar to those of the regular OC-3 module described above. TDM pseudowire functions of C.OC3 modules are the same as of the T1-PW-SRV/28 server modules described below. The C.OC3 modules provide one channelized OC-3 link with line redundancy. Line redundancy is activated by configuring 1+1 unidirectional, 1+1 bidirectional or 1+1 bidirectional optimized APS (Automatic Protection Switching) per ITU-T Rec. G.841. This means that the traffic is automatically switched to the other OC-3 port in case the active OC-3 port or its link fails. Protected OC-3 links can be located on the same or different C.OC3 modules.
T1-PW-SRV/28 Pseudowire Emulation Server Module

T1-PW-SRV/28 is a server module intended for use in Gmux-2000 equipped with SONET interfaces that provides T1 pseudowire emulation services over UDP/IP packet-switched networks. The module has a capacity of 28 T1 (1.544 Mbps) trunks, each served by an independent T1 interface. Each T1 interface can be mapped to any desired VT1.5 in any OC3 module. Therefore, a Gmux-2000 equipped with one OC3 module and three T1-PW-SRV/28 modules enables transporting a whole OC-3 stream over the packet-switched network, with the added advantage that each T1 stream can be independently routed to the desired endpoints through the PSN network. The T1-PW-SRV/28 module supports T1 pseudowire emulation services over packet-switched networks using the following user-configurable protocols: TDMoIP (TDM over IP) in accordance with RFC5087 and ITU-T Rec. Y.1413
1-30
Gmux-2000 Ver. 4.0
HDLCoPSN (HDLC over PSN) in accordance with RFC5087 and RFC4618 (except Clause 5.3 PPP) CESoPSN (structure-aware TDM circuit emulation over PSN) in accordance with RFC5086 SAToPSN (structure-agnostic TDM over PSN) in accordance with RFC4553
T1-PW-SRV/28 meets the requirements for edge-to-edge simulation of TDM circuits over PSN in accordance with RFC4197, including high-performance adaptive timing capabilities. Availability is enhanced by support for 1:N redundancy at the module level. When installed in a Gmux-2000 equipped with GbE/2 PSN interface modules, T1-PW-SRV/28 also supports emulation of PDH circuits over metro Ethernet networks (MENs) in accordance with the Metro Ethernet Forum Implementation Agreement 8 (MEF 8). Two emulation options are available: Structure-aware circuit emulation service over Ethernet (CESoETH) Structure-agnostic circuit emulation service over Ethernet (SAToETH).
The number of pseudowires (bundles) supported by each port depends on the framing mode: Each framed T1 port can be served by up to 16 pseudowires, where each pseudowire can be separately routed to its desired destination, thus providing the equivalent of fractional T1 services over packet-switched networks, and a total of 112 destinations per module. The actual number of active pseudowires depends on timeslot assignment (any given timeslot can be included in a single pseudowire) An unframed T1 port is served by a single pseudowire.
Each pseudowire terminated on the T1-PW-SRV/28 can be independently configured to handle the desired type of traffic: Transparent transfer of data (unframed T1 streams) using TDMoPSN, or SAToPSN and SAToETH. Transfer of framed T1 streams (SF (D4) or ESF) in accordance with AT&T TR-62411 and ANSI T1.403, using TDMoPSN, CESoPSN and CESoETH. Note that when using CESoPSN or CESoETH, timeslots carrying signaling can be transparently transferred within the pseudowire, as regular data timeslots. Fractional T1 services, with or without channel associated (robbed bit) signaling, are supported by means of TDMoPSN. Without signaling, CESoPSN or CESoETH. HDLC traffic carried over framed and unframed T1 using HDLCoPSN. This enables efficient and transparent transfer of Frame Relay traffic.
Gmux-2000 Ver. 4.0
1-31
Note
When CES or SAT is used over UDP/IP networks, T1-PW-SRV/28 supports two pseudowire multiplexing methods:
RAD proprietary method, referred to as source multiplexing Standard multiplexing method, referred to as destination multiplexing.
At any time, all the pseudowires served by a given T1-PW-SRV/28 module must use the same multiplexing method.
Packet structure is independently selectable for each pseudowire, for compatibility with the various pseudowire protocols (TDMoPSN, CESoPSN, HDLCoPSN, SAToPSN) and network standards (UDP/IP and, when applicable, Ethernet per MEF 8). The functions performed by the T1-PW-SRV/28 module for each processing path include: Interfacing to the internal telecom buses. The module has an SONET mapper that can direct VT1.5 to any internal T1 port. The total mapping capacity is 28 VT1.5s, out of the 84 carried in the OC-3 payload. Interfacing to the local users T1 equipment. Each internal module port can be independently configured in accordance with the desired framing mode: unframed, SF (D4), or ESF. In the unframed mode, the whole data stream is transported over the packet-switched network by a single pseudowire, using the appropriate protocol. This mode can also be used to transfer framing overhead of framed T1 streams end-to-end, or transparently transfer a T1 data stream with proprietary framing. This enables transparently transferring T1 data streams with proprietary framing; with ESF framing, this enables transferring the FDL end-to-end. Note that the HDLCoPSN protocol can also handle unframed T1 data streams. In the framed modes, the T1 overhead is terminated at each internal port, except when using CESoPSN. For a port operating in a framed mode, the user can configure several pseudowires (up to 16), each carrying only user-selected timeslots, instead of transporting the whole T1 stream. The timing mode of each port can be independently selected, to support the timing mode used by the users equipment connected to each port, in accordance with the options listed in RFC4197. Availability is enhanced by support for 1:N redundancy at the module level. Conversion between TDM and packet formats. The conversion parameters are controlled by defining pseudowires, and can be optimized for the specific end-users equipment and the application requirements. T1-PW-SRV/28 supports TDMoIP version V2; for compatibility with other equipment, T1-PWSRV/28 also supports TDMoIP version V1 (the version is user-selectable).
Note
T1-PW-SRV/28 supports packet payload version V2, which includes a control word. For compatibility with other equipment, T1-PW-SRV/28 also supports payload version V1, which does not include a control word and thus has lesser capabilities, for example, does not support the OAM protocol. The payload version is user-selectable.
1-32
Gmux-2000 Ver. 4.0
Forwarding the pseudowire packet streams. Each pseudowire can be forwarded to the desired endpoint through the packet-switched network. The user can specify forwarding and priority/quality of service parameters. For forwarding, pseudowires are sent to the GbE/2 module, which sends them through the desired PSN interface.
The T1-PW-SRV/28 module operating parameters are determined by commands received from the Gmux-2000 CONTROL module. The CONTROL module can also download new software to the module, when the Gmux-2000 software is updated. The module supports comprehensive diagnostics, including power-up self-test, and local and remote loopbacks for each port. Front-panel indicators indicate at a glance the status of each module port.
T1-PW/28 Pseudowire Emulation Module with External T1 Interfaces

The T1-PW/28 module is a T1 pseudowire emulation module with external T1 interfaces for the Gmux-2000 system. The module has a capacity of 28 T1 (1.544 Mbps) trunks, each served by an independent external T1 interface, and therefore a Gmux-2000 fully equipped with T1-PW/28 modules can handle up to 196 T1 data streams, where each stream can be independently routed to the desired endpoints through the PSN network. The T1-PW/28 module supports T1 pseudowire emulation services over UDP/IP packet-switched networks using the following user-configurable protocols: TDMoIP (TDM over IP) in accordance with RFC5087 and ITU-T Rec. Y.1413 HDLCoPSN (HDLC over PSN) in accordance with RFC5087 and RFC4618 (except Clause 5.3 PPP) CESoPSN (structure-aware TDM circuit emulation over PSN) in accordance with RFC5086 SAToPSN (structure-agnostic TDM over PSN) in accordance with RFC4553
T1-PW/28 meets the requirements for edge-to-edge simulation of TDM circuits over PSN in accordance with RFC4197, including high-performance adaptive timing capabilities. When installed in a Gmux-2000 equipped with GbE/2 PSN interface modules, T1-PW/28 also supports emulation of PDH circuits over metro Ethernet networks (MENs) in accordance with the Metro Ethernet Forum Implementation Agreement 8 (MEF 8). Two emulation options are available: Structure-aware circuit emulation service over Ethernet (CESoETH) Structure-agnostic circuit emulation service over Ethernet (SAToETH).
The number of pseudowires supported by each port depends on the framing mode: Each framed T1 port can be served by up to 16 pseudowires, where each pseudowire can be separately routed to its desired destination, thus providing the equivalent of fractional T1 services over packet-switched networks, for a total of 112 destinations per module. The actual number of
Gmux-2000 Ver. 4.0
1-33
active pseudowires depends on timeslot assignment (a timeslot can be included in a single pseudowire) An unframed T1 port is served by a single pseudowire.
Each pseudowire terminated on the T1-PW/28 can be independently configured to handle the desired type of traffic: Transparent transfer of data (unframed T1 streams) using TDMoPSN, or SAToPSN (SAToETH is also supported when GbE/2 modules are installed) Transfer of framed T1 streams (SF (D4) or ESF) in accordance with AT&T TR-62411 and ANSI T1.403, using TDMoPSN, and CESoPSN (CESoETH is also supported when GbE/2 modules are installed). Note that when using CESoPSN or CESoETH, timeslots carrying signaling can be transparently transferred within the pseudowire, as regular data timeslots. Fractional T1 services, with or without channel associated (robbed bit) signaling, are supported by means of TDMoPSN (CESoETH per MEF 8 is also supported when GbE/2 modules are installed). Without signaling, CESoPSN can also be used HDLC traffic carried over framed and unframed T1 using HDLCoPSN. This enables efficient and transparent transfer of Frame Relay traffic.
Note
When CES or SAT is used over UDP/IP networks, T1-PW/28 operated in Gmux-2000 units with GbE/2 PSN interface modules support two pseudowire multiplexing methods:
At any time, all the pseudowires served by a given T1-PW/28 module must use the same multiplexing method.
Packet structure is independently selectable for each pseudowire, for compatibility with the various pseudowire protocols (TDMoPSN, CESoPSN, HDLCoPSN, SAToPSN) and network standards (UDP/IP and Ethernet per MEF 8). The functions performed by the T1-PW/28 module for each port include: Interfacing to the local users T1 equipment. Each module port can be independently configured to handle the desired type framing mode: unframed, SF (D4), or ESF. In the unframed mode, the whole data stream is transported over the packet-switched network by a single pseudowire, using the appropriate protocol. This mode can also be used to transfer framing overhead of framed T1 streams end-to-end, or transparently transfer a T1 data stream with proprietary framing. Note that the HDLCoPSN protocol can also handle unframed T1 data streams. In the framed modes, the T1 overhead is terminated at each port, except when using CESoPSN. The timing mode of each port can be independently selected, to support the timing mode used by the users equipment connected to each port, in accordance with the options listed in RFC4197. Availability is enhanced by support for 1:N redundancy at the module level.
1-34
Gmux-2000 Ver. 4.0
Conversion between TDM and packet formats. The conversion parameters are controlled by defining pseudowires, and can be optimized for the specific end-users equipment and the application requirements.
Note
T1-PW/28 supports packet payload version V2, which includes a control word. For compatibility with other equipment, T1-PW/28 also supports payload version V1, which does not include a control word and thus has lesser capabilities, for example, does not support the OAM protocol. The payload version is user-selectable.
Forwarding the pseudowire packet streams. Each pseudowire can be forwarded to the desired endpoint through the packet-switched network. The user can specify forwarding and priority/quality of service parameters. For forwarding, pseudowires are sent to the GbE/2 module, which sends them through the desired network interface.
The T1-PW/28 module operating parameters are determined by commands received from the Gmux-2000 CONTROL module. The CONTROL module can also download new software to the module, when the Gmux-2000 software is updated. The module supports comprehensive diagnostics, including power-up self-test, and local and remote loopbacks for each port. Front-panel indicators indicate at a glance the status of each module port.
CT3-PW/1 Pseudowire Emulation Module with External Channelized T3 Interface

The CT3-PW/1 module supports T1 pseudowire emulation services over UDP/IP packet-switched networks using the following user-configurable protocols: TDMoIP (TDM over IP) in accordance with RFC5087 and ITU-T Rec. Y.1413 HDLCoPSN (HDLC over PSN) in accordance with RFC5087 and RFC4618 (except Clause 5.3 PPP) CESoPSN (structure-aware TDM circuit emulation over PSN) in accordance with RFC5086 SAToPSN (structure-agnostic TDM over PSN) in accordance with RFC4553
Note
When CES or SAT is used over UDP/IP networks, CT3-PW/1 modules support two pseudowire multiplexing methods:
At any time, all the pseudowires served by a given CT3-PW/1 module must use the same multiplexing method.
CT3-PW/1 meets the requirements for edge-to-edge simulation of TDM circuits over PSN in accordance with RFC4197, including high-performance adaptive timing capabilities. CT3-PW/1 has an external channelized T3 (44.736 Mbps) interface, which provides the TDM payload connection. A T3 link carries 28 T1 data streams, and therefore, the module capacity is 28 T1 (1.544 Mbps) trunks, each served by an
Gmux-2000 Ver. 4.0
1-35
independent internal T1 interface. Therefore, a Gmux-2000 fully equipped with CT3-PW/1 modules can handle up to 196 T1 data streams. When installed in a Gmux-2000 equipped with GbE/2 PSN interface modules, Gmux-2000 also supports emulation of PDH circuits over metro Ethernet networks (MENs) in accordance with the Metro Ethernet Forum Implementation Agreement 8 (MEF 8). Two emulation options are available: Structure-aware circuit emulation service over Ethernet (CESoETH) Structure-agnostic circuit emulation service over Ethernet (SAToETH).
The number of pseudowires supported by each port depends on the framing mode: Each framed T1 port can be served by up to 16 pseudowires, where each pseudowire can be separately routed to its desired destination, thus providing the equivalent of fractional T1 services over packet-switched networks, and a total of 112 destinations per module. The actual number of active pseudowires depends on timeslot assignment (a timeslot can be included in a single pseudowire) An unframed T1 port can be served by a single pseudowire.
Each pseudowire terminated on the CT3-PW/1 can be independently configured to handle the desired type of traffic: Transparent transfer of data (unframed T1 streams) using TDMoPSN, or SAToPSN (SAToETH is also supported when GbE/2 modules are installed) Transfer of framed T1 streams (SF (D4) or ESF) in accordance with AT&T TR-62411 and ANSI T1.403, using TDMoPSN, and CESoPSN (CESoETH is also supported when GbE/2 modules are installed). Note that when using CESoPSN or CESoETH, timeslots carrying signaling can be transparently transferred within the bundle, as regular data timeslots. Fractional T1 services, with or without channel associated (robbed bit) signaling, are supported by means of TDMoPSN (CESoETH per MEF 8 is also supported when GbE/2 modules are installed). Without signaling, CESoPSN can also be used HDLC traffic carried over framed and unframed T1 using HDLCoPSN. This enables efficient and transparent transfer of Frame Relay traffic.
Packet structure is independently selectable for each bundle, for compatibility with the various pseudowire protocols and network standards. The functions performed by the CT3-PW/1 module for each internal port include: Interfacing to the local T3 users equipment. The CT3-PW/1 external port has an unbalanced T3 interface which provides the connection to the local T3 equipment. The receive path of the T3 interface demultiplexes the incoming signal to retrieve the 28 T1 streams, and the transmit path multiplexes the 28 T1 streams into a T3 stream. Two DS3 framing modes are available, in accordance with ANSI T1.107 and ANSI T1.107a: Synchronous M13 (SYNTRAN): this mode uses synchronous multiplexing, and therefore all the 28 T1 streams must have a common timing source.
1-36
Gmux-2000 Ver. 4.0
Asynchronous C-bit parity: this mode uses asynchronous multiplexing, and therefore can handle T1 streams from independent sources. This mode is preferable for most pseudowire applications. Processing of internal T1 port payload. Each internal T1 port can be independently configured to handle the desired type framing mode: unframed, SF (D4), or ESF. In the unframed mode, the whole data stream is transported over the packet-switched network by a single pseudowire, using the appropriate protocol. This mode can also be used to transfer framing overhead of framed T1 streams end-to-end, or transparently transfer a T1 data stream with proprietary framing. Note that the HDLCoPSN protocol can also handle unframed T1 data streams. In the framed modes, the T1 overhead is terminated at each port, except when using CESoPSN. The timing mode of each port can be independently selected, to support the timing mode used by the users equipment connected to each port, in accordance with the options listed in RFC4197. Conversion between TDM and packet formats. The conversion parameters are controlled by defining pseudowires, and can be optimized for the specific end-users equipment and the application requirements.
Note
CT3-PW/1 supports packet payload version V2, which includes a control word. For compatibility with other equipment, CT3-PW/1 also supports payload version V1, which does not include a control word and thus has lesser capabilities, for example, does not support the OAM protocol. The payload version is user-selectable.
Forwarding the pseudowire packet streams. Each pseudowire can be forwarded to the desired endpoint through the packet-switched network. The user can specify forwarding and priority/quality of service parameters. For forwarding, pseudowires are sent to the GbE/2 module, which sends them through the desired network interface.
The CT3-PW/1 module operating parameters are determined by commands received from the Gmux-2000 CONTROL module. The CONTROL module can also download new software to the module, when the Gmux-2000 software is updated. The module supports comprehensive diagnostics, including power-up self-test, and local and remote loopbacks for each port. Front-panel indicators indicate at a glance the status of each module port.
GbE/2 PSN Interface Module

GbE/2 is an PSN interface module supported by Gmux-2000 starting with release V3.5, which is based on an advanced network processor. In addition to the functionality of the GbE modules, GbE/2 modules provide new capabilities, mainly support for VoIP services, support for PDH circuit emulation over Metro Ethernet Networks per MEF 8, no practical restrictions on the number of destinations, etc. The GbE/2 module provides the interface to packet-switched networks for the Gmux-2000 packet traffic. The module supports IP and Ethernet networks, and is
Gmux-2000 Ver. 4.0
1-37
capable of processing data at wire speed. It has two external ports for connection to the packet-switched network. These ports can be ordered with SFP transceivers with optical interfaces, or short-haul electrical (copper) interfaces, for meeting a wide range of operational requirements. Each external port of the module has its own MAC address, and can be assigned its own IP address. Therefore, ports can be independently used, to enable load balancing. The module ports can also be configured to use link aggregation with load sharing per IEEE 802.3ad without LACP (Link Aggregation Control Protocol), thereby providing a single logical link to the network. Link aggregation is supported between ports of the same module, and also between ports on different modules, thereby providing hardware redundancy as well as link redundancy. The GbE/2 module also supports 1:N redundancy for I/O modules installed in the chassis. The internal ports of the GbE/2 module connect by pairs of Ethernet ports, through the StarLAN packet bus of the chassis, to each I/O module and to each CONTROL module (the current Gmux-2000 version uses Fast Ethernet ports). All the external and internal ports of the module are handled by an internal high-performance network processor with IP support. The network processor performs Layer 2 switching, and Layer 3/4 static routing for the internal packet traffic. No routing protocol is used for internal routing: the network processor routes each bundle in accordance with the static routing information configured by the user: For UDP/IP bundles, the internal routing is made only on the basis of the bundle IP address and UDP port For MEF 8 bundles, the internal routing is made on the basis of the destination MAC address.
The external GbE port used by each bundle can be independently selected, except when using link aggregation. GbE/2 also uses static routing for external routing. The static routing information is configured as entries in the manager list. Up to 100 entries can be defined, where up to 10 can be used for managers and the others serve as static routes. Static routes can also be defined for IP subnets. GbE/2 generates ARP requests when the destination MAC address is unknown, and answers ARP requests. The address aging interval is user-configurable, and can be disabled when necessary. GbE/2 also supports pinging for IP connectivity checks. GbE/2 provides user-configurable VLAN support for the payload and management traffic. Class of service is ensured by supporting per-bundle configuration of IEEE 802.1p priority at Layer 2 and Type of Service (ToS/DiffServ) at Layer 3. In addition to the external payload-carrying ports, the GbE module has a 10/100BaseTx monitoring interface, for use by technical support personnel or for special applications.
1-38
Gmux-2000 Ver. 4.0
VCA-T1/16, VCA-T1/12 Voice Compression Modules

VCA-T1/16 and VCA-T1/12 modules are universal voice compression modules with T1 voice ports for the Gmux-2000 Pseudowire Gateway, having a compression capacity of 16 T1, respectively 12 T1, voice trunks. VCA-T1/16 and VCA-T1/12 modules can be used in two types of applications: Voice trunking applications. The modules enable Gmux-2000 systems to deliver voice traffic, including inband signaling (DTMF, MFR2, and MFC), voiceband modems and Group III fax up to 14.4 kbps, over TDM links (T1 links located on the module itself, or OC-3 (SONET) ports located on OC-3 modules) and over GbE links, located on GbE and GbE/2 modules. In addition to voice traffic, the modules can also transparently transfer selected timeslots.
VCA-T1/16 and VCA-T1/12 support the ITU-T Rec. G.723.1 and G.729 Annex A voice compression algorithms, and Adaptive Multi-Rate (AMR) narrow-band codecs standardized by the European Telecommunications Standards Institute (ETSI) for GSM cellular systems), as well as ITU-T Rec. G.711 (A-law and -law PCM), and uses TDMoIP multiplexing for efficiently transporting the payload of T1 trunks over TDM (T1 or SONET) networks. Packet structure is user-selectable. The modules enable Gmux-2000 systems to deliver voice traffic, including inband signaling (DTMF, MFR2, and MFC), voiceband modems and Group III fax up to 14.4 kbps, over the following types of links: TDM links: T1 (PDH) links located on the VCA-T1/16 module itself, or OC-3 (SONET) ports located on OC3 modules GbE links, located on GbE modules.
In addition to voice traffic, VCA-T1/16 can also transparently transfer selected timeslots. VCA-T1/16 supports the ITU-T Rec. G.723.1 and G.729 Annex A voice compression algorithms, as well as ITU-T Rec. G.711 (A-law and -law PCM), and uses TDMoIP multiplexing for efficiently transporting the payload of T1 trunks over TDM (T1 or SONET) networks. Packet structure is user-selectable. In addition to standard packet structures, VCA-T1/16 also offers RAD proprietary versions of these protocols that achieve significantly higher bandwidth efficiency. Advanced digital signal processing techniques ensure highly-reliable service, unaffected by the use of voice compression. These techniques include: Per-channel voice activity detection (VAD) and silence suppression Built-in echo cancellation for delays up to 128 msec per ITU-T Rec. G.168, with option for automatic activation based on state of a user-selectable signaling bit Relaying of Group III fax, modems at commonly used rates and standards, inband signaling and custom tones. Where compression cannot be used, for example, for non-standard inband signaling and modem protocols, voiceband signals can be faithfully transmitted using selectable PCM or ADPCM coders.
Gmux-2000 Ver. 4.0
1-39
For compatibility, the number of bits per voice channel is selectable: 7 bits (56 kbps) or 8 bits (64 kbps). To prevent voice degradation when traffic passes multiple VCA-T1/16 or Vmux units, a special super-tandem mode ensures that voice signals pass compression only once, irrespective of the number of hops on the transmission path. At the highest compression ratio, VCA-T1/16 enables compressing up to 16 T1 voice trunks for transport over a single T1 network link (up to 16:1 compression ratio); for VCA-T1/12, the maximum compression ratio cannot exceed 12:1 because it has only 12 voice ports. VCA-T1/16 and VCA-T1/12 traffic can be routed over up to 32 independently-configurable bundles, where a bundle can carry any number of timeslots, up to a full T1 voice port (24 channels). Each compressed voice bundle can be independently connected to any desired network-side port (either TDM port or GbE port). Moreover, VCA-T1/16 and VCA-T1/12 support both point-to-point and point-to-multipoint (channelized) applications over their T1 network-side links, with user-configurable link bandwidth assignment per destination (the timeslots available on each T1 network-side link can be assigned to up to 10 independent subchannels). To guarantee high service quality together with highly efficient utilization of transport links, VCA-T1/16 and VCA-T1/12 support a proprietary bandwidth limiting algorithm that ensures service quality degrades gradually during intervals of excessive traffic load. To preserve service quality, a separate mechanism makes it possible to block the setup of new modem calls when bandwidth utilization exceeds user-configurable, application-specific thresholds. VCA-T1/16 and VCA-T1/12 provide full support for a wide range of signaling protocols. This includes CAS signaling (transferred end-to-end either transparently, or after translation in accordance with user-specified profiles) as well as optimized HDLC-based transfer of CCS protocols such as Signaling System 7 (SS7), etc. The CCS timeslots are user-selectable, independently for each voice port, with a maximum of two timeslots per port. VCA-T1/16 and VCA-T1/12 have both TDM and packet ports: The TDM ports comprise a set of 16, respectively 12, voice (user-side) T1 ports and a separate set of 2 data (network-side) T1 ports The packet ports comprise 2 network-side ports, for connection to Gmux-2000 internal packet buses.
To provide maximum application flexibility and avoid the need for additional equipment, each set of TDM ports has both external ports located on the module panel, and internal ports that can be connected via the Gmux-2000 telecom buses to the SONET ports located on the OC3 modules that may be installed in the chassis (each internal module port can be independently mapped to any desired VT1.5). The maximum number of VCA-T1/16 and VCA-T1/12 modules that may be installed in a Gmux-2000 chassis is 7. Note however that 2 out of the 7 Gmux-2000 I/O slots that support VCA-T1/16 modules also support OC3 modules, and therefore the maximum voice compression capacity (7 modules) can be reached only when using the external VCA-T1/16 or VCA-T1/12 module ports (when using internal ports, OC3 modules must be installed in the chassis, thereby
1-40
Gmux-2000 Ver. 4.0
reducing the number of slots available for modules by one for each OC3 module installed). The maximum number of VCA-T1/16 or VCA-T1/12 modules decreases by one for each installed OC3 module: With VCA-T1/16 modules, the maximum capacities are as follows: Without OC3 modules in the chassis, 7 VCA-T1/16 modules yield 112 T1 voice trunks per chassis (2688 voice channels). One OC3 module and 6 VCA-T1/16 modules yield a maximum capacity of 96 T1 trunks per chassis (2304 voice channels) Two OC3 modules and 5 VCA-T1/16 modules yield a maximum capacity of 80 T1 trunks per chassis (1920 voice channels). With VCA-T1/12 modules, the respective maximum capacities are 84, 72, and 60 T1 voice trunks (up to 2016, 1728, and 1440 voice channels, respectively).
To improve availability, VCA-T1/16 and VCA-T1/12 data ports can be configured to provide backup for the connection to the network. In this case, the data ports operate in pairs: in each pair, one port serves as the main (primary) port, and the other as backup (secondary) port. At any time, only one port of each pair carries traffic. As long as the primary port can carry the traffic, it is automatically selected as the active port; in case of a problem on the link or in the port hardware, the traffic is automatically switched to the backup port. Switching is revertive. This means that when using backup over the external T1 data (network-side) ports, only one T1 port is available; when using the internal (SONET) network ports with backup enabled, an additional set of internal data ports becomes available, and therefore the maximum number of T1 data ports is four (two primary and two secondary). For maximum service availability, Gmux-2000 offers 1:N protection for I/O modules. In the 1:N protection mode, one VCA-T1/16 module is assigned to serve as a hot standby for the other VCA-T1/16 modules installed in the chassis. VCA-T1/16 operating parameters are determined by commands received from the Gmux-2000 CONTROL module. The CONTROL module can also download new software to the module, when the Gmux-2000 software is updated. VCA-T1/16 modules also support inband management of remote Gmux-2000 units: a remotely located network management station, for example, RADview-SC/Vmux, connected to a GbE port of one Gmux-2000 unit can manage other Gmux-2000 units interconnected to it via VCA-T1/16 data ports. Vmux-2100 Voice Trunking Gateways connected to VCA-T1/16 ports can also be managed in the same way. The module supports comprehensive diagnostics, including power-up self-test, local and remote loopbacks and test tone injection for the voice ports, and remote loopbacks for the network ports. It also collects comprehensive performance statistics that can be uploaded via TFTP to a management station such as the RADview-SC/Vmux for analysis. Front-panel indicators indicate at a glance the status of each module port.
Gmux-2000 Ver. 4.0
1-41
1.4
Technical Specifications
System Characteristics
General
Function TDM Interfaces
Pseudowire gateway Depends on installed modules: SONET: OC-3 (155.52 Mbps), maximum capacity of 168 T1 streams PDH: T1 (1.544 Mbps), maximum capacity of 196 T1 streams
Packet Switched Network Interface Physical Protocols

GbE ports, maximum capacity of 2 GbE streams Ethernet IP
Main Types of Services
Depends on installed modules: TDM transport over PSN using pseudowire circuit emulation (PW) Voice trunking over PSN, using voice compression
Routing Capabilities Number of Stored Bundles Protection Modes SONET Links
Any T1 stream from any TDM interface to any IP destination Up to 2000
OC3 modules: 1+1 unidirectional APS per ITU-T Rec. G.783 C.OC3 modules: 1+1 unidirectional, 1+1 bidirectional and 1+1 bidirectional optimized APS
GbE Links I/O Modules
Link aggregation per IEEE 802.3ad, without LACP (Link Aggregation Control Protocol) 1:N protection for I/O modules with internal ports (one protection group per chassis) 1:N protection for I/O modules with external ports (using NPS-101 protection device)
1-42
Gmux-2000 Ver. 4.0
OC3 Interface Module Characteristics

General
Function External Ports Framing Port Payload Capacity Number of Telecom Buses Supported
OC-3 interface module for the Gmux-2000 system Two OC-3 ports GR-253-CORE and ANSI T1.105 84 T1 streams per port, each independently mapped to any VT Two telecom buses: Port 1 serves telecom bus A Port 2 serves telecom bus B
Operational Configurations Single OC3 Module in Chassis

TM with single OC-3 link (when second port is not connected) TM with dual OC-3 links (when both OC-3 ports are connected) TM with single OC-3 link, and with line redundancy (single Gmux-2000 module, both OC-3 ports connected).
Two OC3 Modules in Chassis
TM with dual OC-3 links, with both line and hardware redundancy (all the OC-3 ports connected) ITU-T Rec. G.703, Para. 12 CMI 155.520 Mbps Two BNC connectors ITU-T Rec. G.957 155.520 Mbps SONET
Electrical OC-3 Port Interface Characteristics
Physical Layer Line Code Nominal Bit Rate Connectors
Optical OC-3 Port Physical Layer Interface Nominal Bit Rate Characteristics
Standard
Gmux-2000 Ver. 4.0
1-43
Table 1-3. OC3 Module, Fiber Optic Interface Characteristics

Wavelength Fiber Type 9/125 m, single mode 1310 nm 9/125 m, single mode 62.5/125 m, multi-mode 850 nm 62.5/125 m, multi-mode Transmitter Type Laser Laser, long haul LED VCSEL Power Coupled Receiver into Fiber Sensitivity -15 to -8 dBm -5 to 0 dBm -31 dBm -34 dBm Typical Optical Budget 16 dB 29 dB 10 dB 10 dB Typical Max. Range (km/miles) 20/13 40/26 2/1.3 2/1.3
-20 to -14 dBm -30 dBm -20 to -14 dBm -30 dBm
SFP-Based OC-3 Port Interface Characteristics
Physical Layer Nominal Bit Rate Connectors Recommended RAD SFP Types
ITU-T Rec. G.957 155.520 Mbps One or two LC connectors, depending of SFP type Dual Fiber: SFP-1, SFP-2, SFP-3, SFP-4 Single Fiber: SFP-10a, SFP-10b, SFP-13, SFP-18a, SFP-19a, SFP-19b
Note
For detailed specifications of SFP transceivers, see the RAD SFP Transceivers data sheet.
Module Timing
OC-3 Receive Port Timing
Receive clock recovered from the received OC-3 line signal Gmux-2000 system clock can be locked to the recovered receive clock signal of an OC3 port
OC-3 Transmit Port Timing
Internal timing (locked to Gmux-2000 system clock) Loopback timing (transmit timing locked to clock recovered from selected received OC-3 line signal)
Internal Port Receive Timing
Receive clock recovered from the received OC-3 line signal
1-44
Gmux-2000 Ver. 4.0
Internal Port Transmit Timing Locked to the Gmux-2000 system clock

Locked to one of the recovered internal T1 port clock signals (which may itself use loopback timing or adaptive timing)
Port Indicators
L LOS (red) R LOS (red)
Local loss of OC-3 signal Remote loss of OC-3 signal Module is active and carries traffic Fault detected in module User-activated local loopback on each external OC-3 port User-activated remote loopback on each external OC-3 port
Module Indicators ACT (green)

FLT (red)
Diagnostics
Loopbacks
Self-Test
Automatically performed upon power-up or reset Occupies a single I/O module slot (slot 7 or 9) User-defined mapping, any internal T1 port to any TU-11 within the OC-3 payload
Physical Payload Routing
GbE Module Characteristics

General
Function External Ports
GbE PSN interface module Two GbE ports with SFP modules, with optical or copper interfaces One 10/100BASE-TX monitoring port
Internal Ports
Two Fast Ethernet internal ports toward the packet (StarLAN) bus to each I/O slot One Fast Ethernet internal port toward the packet (StarLAN) bus to each CONTROL module
Payload Handling
Gigabit Ethernet switch Optical 1000BASE-X port, full-duplex, with autonegotiation user-selectable Dual LC
Optical Port Interface Characteristics
Interface Type Link Connectors
Gmux-2000 Ver. 4.0
1-45
Copper Port Interface Characteristics GbE Port Indications
Interface Type Link Connector LINK Indicator (green) PAUSE Indicator (green) RX Indicator (green) TX Indicator (green)
1000BASE-T port, full-duplex, with or without autonegotiation user-selectable RJ-45 Lights when port is connected to an active Ethernet port or LAN Lights when port receives PAUSE frames Lights when port detects receive activity Lights when port detects transmit activity Monitoring port for technical support personnel 10/100BASE-TX Ethernet
MONITOR Port Characteristics
Function Interface Type
Interface Operating Modes 10 or 100 Mbps, full-duplex or half-duplex

(selection by auto-negotiation), MDI/MDIX polarity and cross-over detection, and automatic cross-over correction
Interface Connector
8-pin RJ-45 Module is active Fault detected in module Automatic, after power-up or reset Occupies a single I/O slot (slot 6 or 8)
Module Indicators
ACT (green) FLT (red)
Diagnostics Physical
Self-Test
C.OC3 Module Characteristics

General
Function External Ports Framing Port Payload Capacity Redundancy
Channelized OC-3 interface module with pseudowire functionality Two OC-3 ports with SFP-based optical interfaces GR-253-CORE and ANSIT1.105 84 T1 streams 1+1 unidirectional, 1+1 bidirectional and 1+1 bidirectional optimized APS
1-46
Gmux-2000 Ver. 4.0
PW Functionality
Protocols
TDMoIP in accordance with RFC 5087 HDLCoPSN in accordance with RFC 5087 and RFC 4618 (except Clause 5.3 PPP) CESoPSN in accordance with RFC 5086 SAToPSN in accordance with RFC 4553 CES and SAToP per MEF 8
Packet Switched Network Types Number of Pseudowire Bundles
UDP/IP Ethernet Up to 336
Internal T1 Ports
Type and Bit Rate Standards Compliance Framing Modes
T1, 1.544 Mbps AT&T TR-62411, AT&T Pub 54016, ANSI T1.107, ANSI T1.403 Unframed SF (D4) ESF
SFP-Based OC-3 Port Interface Characteristics
Physical Layer
ITU-T Rec. G.957
Nominal Bit Rate Connectors Recommended RAD SFP Types
155.520 Mbps One or two LC connectors, depending of SFP type Dual Fibers: SFP-1, SFP-2, SFP-3, SFP-4 Single Fiber: SFP-10a, SFP-10b, SFP-13, SFP-18a, SFP-19a, SFP-19b
Note
For detailed specifications of SFP transceivers, see the RAD SFP Transceivers data sheet.
Module Timing
OC-3 Receive Port Timing
Receive clock recovered from the received OC-3 line signal Gmux-2000 nodal clock can be locked to the recovered receive clock signal of an OC-3 port
Gmux-2000 Ver. 4.0
1-47
OC-3 Transmit Port Timing
Locked to Gmux-2000 nodal clock) Loopback timing (transmit timing locked to clock recovered from selected received OC-3 line signal)
Internal Port Receive Timing
Recovered from the received OC-3 line signal clock recovered from the T1 signal received from the SONET mapper)
T1 Port Transmit Path Timing Loopback timing (transmit timing locked to
Adaptive timing (transmit timing locked to the average rate of packets received from the packet-switched network) Gmux-2000 nodal timing
T1 Port Receive Path Timing
Locked to clock received from the SONET mapper Local loss of OC-3 signal Remote loss of OC-3 signal Module is active and carries traffic Fault detected in module Local loopback on each OC-3 or T1 port Remote loopback on each OC-3 or T1 port
Port Indicators
LOSS LOC (red) LOSS REM (red)

FLT (red)
Diagnostics
Loopbacks
Physical
Occupies a single I/O module slot (slot 1, 2, 3, 4, 5, 7, 9)
GbE/2 Module Characteristics

General
Function External Ports
GbE/2 PSN interface module Two GbE ports with optical SFPs, or two 10/100/1000BASE-T ports interfaces, in accordance with order One 10/100BASE-TX monitoring port
Internal Ports
Two Fast Ethernet internal ports toward the packet (StarLAN) bus to each I/O slot One Fast Ethernet internal port toward the packet (StarLAN) bus to each CONTROL module
Payload Handling
Internal network processor
1-48
Gmux-2000 Ver. 4.0
GbE Optical Port Interface Characteristics GbE Copper Port Interface Characteristics GbE Port Indications
Interface Type Link Connectors Interface Type Link Connector LINK Indicator (green) ACT Indicator (yellow)
Optical 1000BASE-FX port, full-duplex In accordance with SFP type 10/100/1000BaseT port, full-duplex, with user-selectable autonegotiation RJ-45 Lights when port is connected to an active Ethernet port or LAN Lights when port detects receive or transmit activity Monitoring port for technical support personnel, or special applications 10/100BASE-TX Ethernet Automatic selection by auto-negotiation (10 or 100 Mbps, full-duplex or half-duplex) Automatic polarity detection and correction
MONITOR Port Characteristics
Function Interface Type Interface Operating Modes
Interface Connector LINK Indicator (green) ACT Indicator (yellow)
8-pin RJ-45 Lights when port is connected to an active Ethernet port or LAN Lights when port detects receive or transmit activity Module is active Fault detected in module Automatic, after power-up or reset Occupies a single I/O slot (slot 6 or 8)

FLT (red)
Diagnostics Physical
Self-Test
T1-PW/28 Pseudowire Emulation Module with External T1 Interfaces, Characteristics

General
Function External TDM Ports Internal Packet Ports
T1 pseudowire emulation server with external T1 interfaces 28 external T1 ports 2+2 Fast Ethernet internal ports toward the packet (StarLAN) bus
Gmux-2000 Ver. 4.0
1-49
Number of Pseudowires
Up to 16 active pseudowires per T1 port Up to 112 pseudowires per Gmux-2000
Protocols
TDMoIP in accordance with RFC5087 HDLCoPSN in accordance with RFC5087 and RFC4618 (except Clause 5.3 PPP) CESoPSN in accordance with RFC5086 SAToPSN in accordance with RFC4553 CES and SAToP per MEF 8 (with GbE/2 modules in Gmux-2000)
Packet Switched Network Types
UDP over IP Ethernet User-defined internal routing (any packet processor to any PSN port), and connection parameters (each pseudowire to any destination) T1, 1.544 Mbps AT&T TR-62411, AT&T Pub 54016, ANSI T1.107, ANSI T1.403 4-wire, 100 balanced AMI (transparent no zero suppression) B7ZS B8ZS
Payload Routing
Packet Routing
T1 Interface Characteristics
Type and Bit Rate Standards Compliance Line Interface Line Code and Zero Suppression
Framing Modes
Unframed SF (D4) ESF
Transmit Levels Receive Level Connectors (per module)
DSU emulation: 3V 10%, software adjustable, measured at 0 through 655 ft 0 through -12 dB Two 62-pin D-type female connectors: one for channels 1 to 14, and the other for channels 15 to 28
1-50
Gmux-2000 Ver. 4.0
Module Timing
T1 Port Transmit Path Timing
Loopback timing (transmit timing locked to clock recovered from the T1 signal received from the line) Adaptive timing (transmit timing locked to the average rate of packets received from the packet-switched network) Gmux-2000 system timing
Locked to clock recovered from the received T1 signal Red alarm, or red alarm + AIS Yellow alarm Local loopback on each T1 port Remote loopback on each T1 port Inband code-activated local and remote loopbacks on each T1 port
Port Indicators
L (red) Indicator per Port R (red) Indicator per Port
Diagnostics
Loopbacks
Self-Test
Automatically performed upon power-up or reset Occupies a single I/O slot (slot 1 to 5, 7 and 9)
Physical
CT3-PW/1 Pseudowire Emulation Module with Channelized T3 Interface Characteristics

General
Function External TDM Port Internal TDM Ports Internal Packet Ports Number of Pseudowires
T1 pseudowire emulation server with external channelized T3 interface One T3 port 28 T1 ports Two Fast Ethernet internal ports toward the packet (StarLAN) bus Up to 16 active pseudowires per T1 port Up to 112 pseudowires per Gmux-2000
Protocols
Gmux-2000 Ver. 4.0
1-51
UDP over IP Ethernet User-defined connection parameters (each pseudowire to any destination) 1 ANSI T1.102, ANSI T1.107, ANSI T1.107a, ITU-T Rec. G.703 44.736 Mbps M13 synchronous multiplex C-bit parity asynchronous multiplex
Payload Routing T3 Interface Characteristics
Packet Routing Number of Ports Compatibility Nominal Data Rate Framing Option
Line Code Line Impedance Connector Timing
B3ZS 75 Two BNC female Loopback timing (transmit timing locked to clock recovered from the T3 signal received from the line) Gmux-2000 system timing
Port Indicators
LOC (red) Red alarm, or red alarm + AIS REM (red) Port yellow alarm
Loopback timing (transmit timing locked to clock recovered from the T1 signal received from the line) Adaptive timing (transmit timing locked to the average rate of packets received from the packet-switched network) Gmux-2000 system timing
Locked to clock recovered from the received T1 signal
1-52
Gmux-2000 Ver. 4.0
Diagnostics
Loopbacks
Local loopback on the T3 port Remote loopback on the T3 port Network-activated line loopback on the T3 port Local loopback on each T1 port Remote loopback on each T1 port Inband code-activated local and remote loopbacks on each T1 port
Self-Test
Physical
T1-PW-SRV/28 Pseudowire Emulation Server Module Characteristics

General
Function Internal TDM Ports Internal Packet Ports Number of Bundles
T1 pseudowire emulation server with internal T1 interfaces 28 internal T1 ports Two Fast Ethernet internal ports toward the packet (StarLAN) bus Up to 16 active bundles per T1 port Up to 112 bundles per Gmux-2000
Protocols
UDP over IP Ethernet (with GbE/2 modules in Gmux-2000) User-defined internal routing (any packet processor to any PSN port), and connection parameters (each bundle to any destination)
Payload Routing
Packet Routing
Gmux-2000 Ver. 4.0
1-53
Module Timing
Loopback timing (transmit timing locked to clock recovered from the T1 signal received from the SONET mapper) Adaptive timing (transmit timing locked to the average rate of packets received from the packet-switched network) Gmux-2000 nodal timing
Timing locked to clock received from the SONET mapper Off Port is disabled (not connected) Red Port is enabled, but a red alarm, red alarm with AIS or a critical alarm in the OC3 module serving the port, is present Green Port is enabled and none of the alarm conditions described above is present.
Port Indicators
Dual-Color Indicator
Flashes during module initialization and during software downloading. Lights steadily after initialization is successfully completed, if no fault is detected in the module.
FLT (red)
Hardware fault detected in module Local loopback on each T1 port Remote loopback on each T1 port Inband code-activated local and remote loopbacks on each T1 port
Diagnostics
Loopbacks
Self-Test
Physical
1-54
Gmux-2000 Ver. 4.0
VCA-T1/16, VCA-T1/12 Voice Compression Modules Voice Trunking Service Characteristics

General
Function Compression Capacity
Voice compression module VCA-T1/16: 16 T1 trunks VCA-T1/12: 12 T1 trunks
User-Side Voice Ports
16, respectively 12, external T1 ports or 16, respectively 12, internal T1 ports connected to SONET ports
Network-Side Data Ports
2 external T1 ports or 2 internal T1 ports and 2 backup ports, all connected to SONET ports
UDP over IP
Voice Port Characteristics
Port Type Compliance Framing
T1, 1.544 Mbps AT&T TR-62411, AT&T Pub 54016, ANSI T1.107, ANSI T1.403 SF (D4) ESF
Signaling
CAS (robbed bit signaling) CCS (transparent transport)
Number of Bits per Timeslots
User selectable: 7 bits (56 kbps) 8 bits (64 kbps)
Jitter Performance
ITU-T Rec. G.823 4W, 100 , balanced Transparent (no zero suppression) B7ZS B8ZS
External Voice Port Interface Characteristics
Line Interface Zero Suppression
Transmit Level
DSU mode: 3V 10%, software adjustable, measured at 0 through 655ft CSU mode: 0, -7.5, -15, -22.5 dB software-selectable LBO
Gmux-2000 Ver. 4.0
1-55
Receive Level
Software selectable: 0 through -12 dB for short-haul (DSU) mode 0 through -36 dB for long-haul (CSU) mode
Connector (per module)
64-pin TELCO female connector VT1.5 ITU-T Rec. G.783 and G.707
Internal Voice Port Interface Characteristics Data Port Characteristics
Interfacing Compliance
T1, 1.544 Mbps AT&T TR-62411, AT&T Pub 54016, ANSI T1.107, ANSI T1.403 SF (D4) ESF Unframed
Bandwidth Utilization
Framed modes: channelized mode with up to 10 independently configurable subchannels per port (1 to 24 timeslots per subchannel) Unframed: one subchannel, with a capacity of 24 timeslots
Jitter Performance
ITU-T Rec. G.823 4W, 100 balanced. User-selected for each port Transparent (no zero suppression) B7ZS B8ZS DSU mode: 3V 10%, software adjustable, measured at 0 through 655ft CSU mode: 0, -7.5, -15, -22.5 dB software-selectable LBO
External Data Port Line Interface Interface Characteristics

Zero Suppression
Transmit Level
Receive Level
Software selectable: 0 through -12 dB for short-haul (DSU) mode 0 through -36 dB for long-haul (CSU) mode
Connector
RJ-45 per port
1-56
Gmux-2000 Ver. 4.0
Internal Data Port Interfacing Interface Compliance Characteristics Backup Characteristics

Number of Ports
VT1.5 ITU-T Rec. G.783 and G.707 External: 1 primary, 1 secondary Internal: 2 primary, 2 secondary
Backup Switching Mode
Revertive Two Fast Ethernet interfaces to Gmux-2000 internal packet buses Up to 32 active bundles per module, each independently configurable 1 timeslot to full port (24 timeslots), user-configurable Selectable source and destination CBID for UDP/IP Destination IP address Next hop IP address Configurable VLAN support Selectable exit port and subchannel
Packet Bus Interfaces Internal Ports

Maximum Number Bundle Size Routing Parameters
Connectivity Check
Transmission rate: 1 to 60 seconds between packets Alarm threshold: 2 to 5 cycles
Voice Compression Algorithms Compression (per Bundle)
MP-MLQ per ITU-T Rec. G.723.1, at rates of 5.3 and 6.4 kbps Conjugate structure-algebraic-code-excited linear prediction (CS-ACELP) per Annex A of ITU-T Rec. G.729A, at a rate of 8 kbps ITU-T Rec. G.711 with A-law companding ITU-T Rec. G.711 with -law companding Voice activity detection with silence suppression Configurable comfort noise generation
Uncompressed Voice Algorithms Silence Suppression
Voice Companding Law Compression (per Echo Canceling Bundle) (Cont.)

Receive Signal Level
User-selectable, A-law or -law ITU-T Rec. G.168, maximum delay 32 msec Adjustable relative to nominal output level: -6 to +6 dB, in 1-dB steps
Gmux-2000 Ver. 4.0
1-57
Transmit Signal Level Encapsulation Method
Adjustable relative to nominal input level: -12 dB, -6 to +6 dB in 1-dB steps, +12 dB Standard TDMoIP RAD proprietary TDMoIP (TDMoIP+)
Encapsulation Parameters
Configurable packet size (100 to 1461 bytes) Configurable maximum inter-packet interval (10 to 90 msec)
Trunk Signaling Support
CAS (robbed bit): user-configurable signaling translation (up to 5 signaling profiles), idle code and OOS code CCS with user-selectable timeslots: supports SS7 protocol
CCS Signaling Support
Transparent transfer, using HDLC over AAL2 SSTED per ITU-T Rec. I.366.1 Selectable keep-alive message suppression ratio for SS7
Inband Signaling
Relaying (detection and generation) of DTMF, MFR2, MFC, complies with EIA/TIA-464B Configurable MFR2/MFC relaying parameters
Fax Support
Group III fax relay at rates of 4.8 to 14.4 kbps or Transmission of voiceband fax signals
Modem Support
V.22/V.22bis, V.32/V.32bis, V.34 up to 21.6 kbps or Transmission of voiceband modem signals
Voice Voiceband Fax/Modem Compression (per Coders Bundle) (Cont.)
ITU-T Rec. G.711 with A-law companding ITU-T Rec. G.711 with -law companding ITU-T Rec. G.726 at 32 kbps ITU-T Rec. G.726 at 24 kbps
Bandwidth Utilization Controls
Random discarding of packets when link bandwidth utilization exceeds selectable threshold. Available on all voice ports Modem call rejection when link bandwidth utilization exceeds selectable threshold. Configurable on a per-port/per-connection basis
1-58
Gmux-2000 Ver. 4.0
Module Timing
Loopback timing (transmit timing locked to clock recovered from the received T1 signal) Gmux-2000 nodal timing
T1 Port Receive Path Timing Locked to clock recovered from the received T1
signal (must be equal to transmit clock rate)
Module Indicators ACT (green) Indicator
Flashes during module initialization and during software downloading. Lights steadily after initialization is successfully completed, if no fault is detected in the module.
FLT (red) Indicator
Hardware fault detected in module
Port Indicators
LOC (red) Indicator per Port Lights for red alarm REM (red) Indicator per Port Lights for yellow alarm
Diagnostics
Loopbacks
Local loopback on each T1 voice port Remote loopback on each T1 voice port Local tone injection in selectable voice port timeslots Remote loopback on each T1 data port
Self-Test
Automatically performed upon power-up or reset Occupies a single I/O slot (I/O-1 to I/O-5, I/O-7 and I/O-9)
Physical
VCA-T1/16, VCA-T1/12 Voice Compression Modules VoIP Service Characteristics

General
Function
Voice compression module for VoIP applications, supports media gateway and signaling gateway functions 16, respectively 12, external T1 ports or 16, respectively 12, internal T1 ports connected to SONET ports on OC3 modules
User-Side Voice Ports
Packet Ports
Two packet ports connected to GbE/2 modules
Gmux-2000 Ver. 4.0
1-59
Compression Capacity
VCA-T1/16: 16 T1 trunks (maximum 384 channels) VCA-T1/12: 12 T1 trunks (maximum 288 channels)
General Port Characteristics
T1, 1.544 Mbps AT&T TR-62411, AT&T Pub 54016, ANSI T1.107, ANSI T1.403 SF (D4) ESF
Signaling Support (optional) Jitter Performance
CCS using Signaling System 7 ITU-T Rec. G.823 4W, 100 , balanced Transparent (no zero suppression) B7ZS B8ZS
External Port Interface Characteristics
Line Interface Zero Suppression
Transmit Level
DSU emulation: 3V 10%, software adjustable, measured at 0 through 655ft Long haul (CSU) mode: 0, -7.5, -15, -22.5 dB software-selectable LBO
Receive Level
DSU mode: 0 to -12 dB CSU mode: 0 to -36 dB
Connector (per module)
64-pin TELCO female connector VT1.5 ITU-T Rec. G.783 and G.707 Two Fast Ethernet interfaces to Gmux-2000 internal packet buses
Internal Port Interface Characteristics
Interfacing Compliance
Packet Bus Interfaces
1-60
Gmux-2000 Ver. 4.0
Voice Codecs
Compression Algorithms
MP-MLQ per ITU-T Rec. G.723.1, at rates of 5.3 and 6.4 kbps Conjugate structure-algebraic-code-excited linear prediction (CS-ACELP) per ITU-T Rec. G.729A, at a rate of 8 kbps Adaptive Multi-Rate (AMR) narrow-band (NB) voice compression in following modes: 0/4.75 4.75 kbps 1/5.15 5.15 kbps 2/5.90 5.90 kbps 3/6.70 6.70 kbps 4/7.40 7.40 kbps 5/7.95 7.95 kbps 6/10.20 10.20 kbps 7/12.20 12.20 kbps
Uncompressed Voice Algorithms Silence Suppression Echo Canceling Inband Signaling (DTMF)
ITU-T Rec. G.711 with A-law companding ITU-T Rec. G.711 with -law companding Configurable silence suppression ITU-T Rec. G.165 and G.168, maximum delay 128 msec Relaying per RFC2833 DTMF events transmitted via MEGACO/ITU-T Rec. H.248
Fax Support
Group III fax relay per ITU-T Rec. T.38 Voiceband transmission using PCM codec Voiceband transmission using PCM codec per ITU-T Rec. V.152 Inband analog transmission (no special handling)
Modem Support
Voiceband transmission using PCM codec Voiceband transmission using PCM codec per ITU-T Rec. V.152 Inband analog transmission (no special handling)
Gmux-2000 Ver. 4.0
1-61
Media Handling
Media Control Protocol Protocol Message Encoding
MEGACO/ITU-T Rec. H.248 V2 Binary Text (pretty or compact)
Media Transport Protocols
RTP per RFC3550 RTCP per RFC3551
Signaling Transport
Signaling Protocol
SS7 per ITU-T Rec. Q.703, termination of up to five MTP 2 signaling links per module
Signaling Transport Protocols SIGTRAN compliant:

SCTP per RFC2960 SS7 MTP 2 User Adaptation (M2UA) per RFC3331
Module Timing
T1 Port Transmit Path Timing Loopback timing (transmit timing locked to

Gmux-2000 nodal timing
clock recovered from the received T1 signal)
Locked to clock recovered from the received T1 signal (must be equal to transmit clock rate) Flashes during module initialization and during software downloading. Lights steadily after initialization is successfully completed, if no fault is detected in the module
Module Indicators ACT (green) Indicator
FLT (red) Indicator
Hardware fault detected in module Lights for red alarm Lights for yellow alarm Local loopback on each T1 voice port Remote loopback on each T1 voice port Local tone injection in selectable voice port timeslots
Port Indicators
LOC (red) Indicator per Port REM (red) Indicator per Port
Diagnostics
Loopbacks
Self-Test
Automatically performed upon power-up or reset
1-62
Gmux-2000 Ver. 4.0
Station Clock Interface

Interfaces
Signal Characteristics
2048 kbps, ITU-T Rec. G.703, 120 balanced or 75 unbalanced interface (input and output) 1544 kHz ITU-T Rec. G.703 100 balanced (input and output) 2048 kHz or 1544 kHz squarewave input and output (RS-485 levels)
Connectors
Balanced Interface Unbalanced Interface
8-pin RJ-45 BNC OFF no station clock configured Green station clock present Red station clock not present
Port Indicators
SD (dual color)
System Management
Management Capabilities
Supervision terminal compatible with VT-100, connected either directly or via modem Telnet SSH SNMP (RADview and other SNMP-based network management stations) User authentication based on RADIUS
SNMP Management Capabilities
SNMPv1 SNMPv2, with selectable security model: user-based (SNMPv2u) or community-based (SNMPv2c) SNMPv3, with selectable security model: user-based or view-based Selectable compatibility (any SNMP version, or specific version)
Management Interfaces
Serial ports on CONTROL modules, supports the supervision terminal 10/100BASE-TX ports on CONTROL modules, support Telnet and SNMP Inband via uplink ports, support for Telnet and SNMP
Gmux-2000 Ver. 4.0
1-63
Serial Control Port Interface Characteristics Data Rate

Data Word Format
RS-232 asynchronous DCE port 0.3, 1.2, 2.4, 4.8, 9.6, 19.2, 38.4, 57.6 and 115.2 kbps 1 start bit 7 or 8 data bits Parity: none/odd/even 1 or 2 stop bits
Connector
9-pin D-type female 10/100BASE-TX 10 or 100 Mbps, full-duplex or half-duplex, selection by autonegotiation 8-pin RJ-45 Real time clock, battery-backed Time and day with calendar support up to year 2099, with three user-selectable formats Manual setting: using supervision terminal, Telnet, SSH, or SNMP-based network management NTP-based: automatic setting, and resynchronization at user-selectable intervals, using a specified NTP server
Ethernet Control Port Characteristics
Interface Type Interface Operating Modes Interface Connector
Internal Time
Source Time Display Format Time Setting
Alarm Collection and Monitoring
Alarms
Last 256 time-stamped alarms stored in buffer Buffer reset upon power-up, or by users command
Monitoring Options
By management: using supervision terminal, Telnet, SSH, or SNMP Remote reporting using the syslog protocol per RFC3164
Syslog Capabilities
Device functionality per RFC3164 Reporting of all supported traps and alarms Configurable severity level filter, and optional configurable local message sources Configurable target syslog server (collector)
1-64
Gmux-2000 Ver. 4.0
External Alarm Interfaces
Alarm Outputs
Major alarm indication by floating change-over dry-contact contacts Minor alarm indication by floating change-over contacts
Output Contact Ratings
Max. 60 VDC/30 VAC across open contacts Max. 1 ADC through closed contacts Max. load switching capacity: 60W
External Alarm Input
One active-low input, RS-232 levels
Power Requirements
Power Sources
AC Power DC Power Number of Power Supply Modules AC DC
3 modules, each one with a separate power input circuit 3 modules, with 2 separate DC power inputs per module 100 to 240 VAC (115/230 VAC nominal), 50/60 Hz 48 VDC: 36 to 72 VDC
Power Supply Capacity

Number of PS Modules and PS Module Rating Max Power without Redundancy Max Power with Redundancy
Per following table

One PS Module 200W 200 W 300W 300 W Two PS Modules Three PS Modules 200W 400 W 200 W 300W 600 W 300 W 200W 600 W 400 W 300W 900 W 600 W
Environment
Temperature
Operating Storage
0 to 55C (32 to 131F) -20 to +70C (0 to 150F)
Humidity Cooling
0 to 90%, non-condensing Internal fan tray
Gmux-2000 Ver. 4.0
1-65
Physical
Number of Slots
1 power inlet slot 3 power supply slots 2 control slots 9 I/O slots 1 slot for cooling fan tray
Dimensions
Width Height Depth Weight
440 mm (17.3 inch) 265 mm (10.4 inch), 6U 210 mm (8.2 inch) 12 kg (26.4 lb), maximum
Mounting Method 19-inch (ANSI) rack, requires RM-2000 rack mounting kit
ETSI rack, requires RM-2000E rack mounting kit
1-66
Gmux-2000 Ver. 4.0
Chapter 2 Functional Description

2.1 Scope
This Chapter provides a functional description of the Gmux-2000 system that supplements the information presented in Chapter 1, and describes the main Gmux-2000 features. For background information regarding the Gmux-2000 operating environment, refer to Appendix C.
2.2
Gmux-2000 Functional Description
Gmux-2000 can simultaneously provide TDM transport services, using pseudowire emulation, voice trunking services and VoIP services. The following sections describe signal processing for each type of service.
Description of Gmux-2000 System Used for TDM Transport Services

Figure 1-11 shows the functional block diagram of a typical Gmux-2000 system
used for TDM transport services, and identifies the modules and physical interfaces that implement each function. The following description refers to Figure 1-11. The Gmux-2000 includes the following main subsystems: I/O interface and pseudowire emulation subsystem: includes two main subsystems: TDM interfacing subsystem: provides interfaces to the TDM users equipment or network. Three types of interfaces are available: SONET interfaces, located on separate modules SDH interface, collocated with the packet processors PDH (T1) interfaces, collocated with the packet processors. Pseudowire emulation processing subsystem: performs the conversion between the circuit-switched (TDM) and packet-switched networks, using pseudowire emulation technology. Refer to the Installation and Operation Manuals of the relevant interface modules for a detailed functional description.
Gmux-2000 Ver. 4.0
2-1
PSN interface subsystem: provides the interface to the packet-switched network (PSN), and handles the packet-switched traffic. Timing subsystem: (collocated with the management subsystem): provides timing signals to all the Gmux-2000 circuits, and external (station and nodal) clock interfaces. Management subsystem: controls Gmux-2000 operation, stores its software and configuration, and provides interfaces for local and remote management. Alarm interfacing subsystem: provides dry-contact relay interfaces for reporting chassis alarms, and an input interface for external sensors. Power supply subsystem: includes power inlet and power supply modules. Cooling fans: for increased system reliability. Traffic buses. Gmux-2000 has two types of traffic buses: TDM buses: carries the TDM traffic between the SONET interface modules and the associated pseudowire emulation server modules. Consists of multiple telecom (19.44 MHz) buses. Packet bus: carries the packet traffic between PSN port and TDMoIP modules. The traffic arrives either from the dedicated pseudowire emulation server modules, or from the pseudowire emulation modules with external PDH (T1 or channelized T3) interfaces. Consists of multiple collision-free Fast Ethernet connections having a star (StarLAN) topology.
Timing buses. Gmux-2000 has a dual timing bus system that has two functions: Carries reference signals from the I/O and pseudowire emulation modules to the timing subsystem Carries nodal clock signals from the timing subsystem to all the other modules.
Control buses. The control buses carry control signals from the management subsystem to each module installed in the chassis, and transfer status and monitoring data from the modules to the management subsystem. Power distribution bus: distributes supply voltages to the modules installed in the chassis.
TDM Traffic Flow within the Gmux-2000

The flow of traffic within the Gmux-2000 chassis depends on the type of TDM interfaces of the pseudowire emulation modules installed in the chassis: SONET or PDH (T1 or T3).
Figure 2-1 shows the flow within a Gmux-2000 equipped with modules using SONET interfaces:
The SONET interface subsystem provides the connection between the external link and the internal telecom buses. The payload appearing on the telecom buses is collected by means of a SONET mapper. The collected payload is processed by a T1 framer, which enables extracting signaling information and separating the timeslots assigned to each bundle in accordance with users assignment (the T1 framer
2-2
Gmux-2000 Ver. 4.0
creates an internal T1 port, which is connected through the SONET mapper to the SONET link). The resulting payload is provided to each packet processor. The packet processor converts the payload into packets suitable for transmission over the packet-switched network. The resulting TDMoIP packets are encapsulated in Ethernet frames and then sent via the Layer 2 Ethernet switch of the pseudowire emulation server module to the PSN interface module through the internal StarLAN packet bus. The Ethernet switch provides the flexibility needed to support multiple connections (bundles or pseudowires). The bandwidth available to each Ethernet switch for connecting to the PSN interface module is two Fast Ethernet ports. A Layer 2/3/4 Ethernet switch located on the PSN interface module analyzes the traffic received from each pseudowire emulation server module and directs it, via the configured PSN link, to the packet-switched network. The switch also provides ARP services and answers/generates pings for the bundles configured on the Gmux-2000, and for its management subsystem, using the static routing information configured by the user.
Figure 2-1. Traffic Flow within Gmux-2000 with SONET Interfaces Figure 2-2 illustrates a channelized OC-3 module which has both TDM termination
and pseudowire emulation subsystems.
Figure 2-2. Traffic Flow within Gmux-2000 with Channelized OC-3 Module Figure 2-3 shows the flow within a Gmux-2000 equipped with T1 external
interfaces: The T1 interface subsystem provides the connection to the external T1 links. When necessary, the T1 framer extracts signaling information and separates the payload of the timeslots assigned to each bundle in accordance with users assignment, and provides the payload to the corresponding packet processor.
Gmux-2000 Ver. 4.0
FE/GbE Switch
2-3
The payload is processed by the corresponding packet processor in accordance with users assignment and converted into packets for transmission over the packet-switched network. The resulting packets are then handled in the same way as explained above for the Gmux-2000 equipped with SONET interfaces.
Pseudowire Emulation Modules with External T1 Interfaces PSN Interfacing Subsystem
Layer 2 Switch
T1
T1 Interface Subsystem
T1 Framer
Packet Processor
Packet Bus (StarLAN)
Layer 2/3/4 Switch
GbE Transceiver GbE Transceiver
PSN Link 1 PSN Link 2
Figure 2-3. Traffic Flow within Gmux-2000 with External T1 Interfaces Figure 2-4 shows the flow within a Gmux-2000 equipped with external channelized T3 interface. The signal flow is similar to that shown in Figure 2-3,
except that now the external connection is provided by a T3 interface subsystem, comprising a T3 line interface unit (LIU), followed by a T3 framer which Implements 28 T1 internal ports. The processing of each T1 stream is similar to that described above.
Pseudowire Emulation Modules with External T3 Interface
T3 Port T3 Line Interface Unit
Layer 2 Switch
PSN Interfacing Subsystem

Packet Bus (StarLAN) Layer 2/3/4 Switch GbE Transceiver GbE Transceiver PSN Link 1 PSN Link 2
T3 Framer
28 T1 Framers
Packet Processor
Figure 2-4. Traffic Flow within Gmux-2000 with T3 Interfaces

As is apparent from Figure 2-1, Figure 2-3, and Figure 2-4, the three alternative payload processing methods converge, as they all generate packet traffic with identical characteristics on the internal packet buses. This approach, which is based on using flexible processing paths for various types of TDM payloads, enables future growth in both capacity (more modules and more ports) and services (more types of payload and enhanced software).
TDMoPSN Packet Processing

The packet processing subsystem consists of independent processors, one for each T1 stream. The functions performed by each packet processor depend on the user-configured pseudowire parameters, and the framing and signaling mode of the associated T1 port. This section explains the processing of TDMoPSN packets; see following sections for the processing of other types if packets.
Note
Appendix C presents an overview of the pseudowire emulation technology.

The main functions performed by the packet processor when using the TDMoPSN mode are as follows:
2-4
Gmux-2000 Ver. 4.0
In the transmit-to-network direction, the packet processor processes the data stream received through the T1 framer to generate the bundles in accordance with users specifications. When using a framed mode, the user can specify the timeslots to be transported end-to-end. To prepare a bundle, the packet processor extracts segments from the continuous data stream for insertion into the bundle payload section. The total size of the bundle payload section is specified by the user (n48 bytes, where n is 1 to 30): When operating in a framed mode, the slices are formed by collecting the appropriate timeslots from consecutive T1 frames until the TDM payload section of the packet is filled. Timeslot 0 is never included. When using channel-associated signaling (CAS) and the bundle is configured as a voice bundle with CAS, the signaling information associated with the timeslots transported by the bundle, taken from timeslot 16 of the T1 stream, is also inserted in the packet. When using common channel signaling (CCS), the signaling timeslot must be included in the bundle, and be transparently transferred end-to-end to the users equipment (for example, a PSTN switch or PBX) at the other end of the link, which can then extract the desired information from the CCS timeslot and process it in accordance with the users signaling protocol. Alternatively, the signaling payload can be transported by means of a separate HDLC bundle (see HDLCoPSN Processing section below) to the users equipment (for example, a PSTN switch or PBX) at the other end of the link, where the signaling information can be processed. When operating in the unframed mode, the slices are formed by collecting consecutive bytes from the received T1 stream until the TDM payload section of the packet is filled. After building the payload section, the packet processor adds the overhead necessary to transmit each slice to the desired destination over the packet switched network and builds TDMoIP packets for transmission to the desired destination. The main information needed to build the overhead is described in the Bundle Configuration Parameters section below. The resulting packets are encapsulated then sent via the packet bus interfacing subsystem of the module to the PSN interface module.
In the receive-from-network direction, the TDMoIP packets retrieved from the received Ethernet frames are temporarily stored in a packet buffer. Each bundle has its own buffer. The function of this buffer is to enable the packet processor to read out the received packets at a constant rate, and thus eliminate jitter in their arrival times. Therefore, this buffer is called jitter buffer. Note that the read-out rate must be equal to the average rate at which frames are received from the PSN. Assuming that the packet loss in the PSN is negligible, this rate is equal to the rate of the original data stream of each bundle. The adjustment of the read-out rate to the arriving packet rate is performed by the adaptive clock recovery mechanism of each packet processor (the recovered clock signal can also be used as a timing reference see the Adaptive Timing section on page 2-11).
Gmux-2000 Ver. 4.0
2-5
The packet processor recovers the payload carried by the packets and restores the original data stream of the bundle, in accordance with the selected framing mode. When the bundle carries only selected timeslots, the payload is reinserted in the appropriate timeslots. Therefore, when several bundles carry payloads destined to the same T1 port, all the useful payload is reinserted in the original timeslots, and only the remaining empty timeslots in the internal port T1 frame are filled with a user-selectable idle code. In a similar way, when the port uses the channel-associated signaling (CAS) mode, the signaling information related to the timeslots transported by each bundle is reinserted in the positions corresponding to the bundle timeslots. Since the TDMoPSN packet structure for framed ports does not depend on the port frame structure, packets carrying traffic from a T1 port can be directed to an E1 port at the far end, as long as the payload type is data (CAS cannot be transferred between E1 and T1 ports). The total number of timeslots cannot exceed 24.
HDLCoPSN Processing
HDLCoPSN packet processing is similar to the processing of TDMoPSN packets described above, except that the HDLCoPSN protocol is intended to provide port-to-port transport of HDLC-encapsulated traffic, in accordance with RFC4618, for example, Frame Relay or CCS protocols. For framed ports, the HDLC traffic is carried in specific timeslots of a T1 frame (these timeslots are specified during the configuration of a HDLCoPSN bundle and are always considered data timeslots).
Note
For HDLCoPSN, it is not necessary to configure the same number of timeslots at the bundle end points. The bundle bandwidth will be determined by the endpoint with the smaller number of assigned timeslots.
The HDLCoPSN protocol can also handle whole (unframed) T1 streams. When assembling packets for a HDLC bundle, HDLC idle flags are removed, and only the contents of HDLC packets with useful payload are inserted in packets. This results in better bandwidth utilization efficiency. At the receive end, HDLC packet structure is restored and inserted in the port data stream. Therefore, HDLC bundles can connect only ports with same framing mode.
SAToPSN Packet Processing

SAToPSN is different from the TDMoPSN and HDLCoPSN protocols, in that it is used to transfer transparently a bit stream at the nominal port rate (1.544 Mbps). Therefore, SAToPSN can be used only when the port uses the unframed mode, and thus only one bundle can be configured per port. In a Gmux-2000 with GbE/2 modules, SAToPSN is also supported over Ethernet networks in accordance with MEF 8. SAToPSN packet payload consists of a user-specified number of raw TDM bytes (24 to 1440 bytes), and is treated as data payload.
2-6
Gmux-2000 Ver. 4.0
Note
The SAToPSN packet overhead is large, and therefore, for efficient bandwidth utilization, the number of raw TDM bytes per packet should be as large as possible.
The receiving end restores the original bit stream, and therefore a SAToPSN bundle can only be directed to another unframed T1 port, or to a serial port operating at a rate of 1544 kbps.
CESoPSN Packet Processing

CESoPSN transports raw TDM data, that is, packets are formed by inserting a user-specified number of complete TDM frames (1 to 45 frames) in the packet payload area. Therefore, CESoPSN bundles can only be configured on framed ports. In a Gmux-2000 with GbE/2 modules, CESoPSN is also supported over Ethernet networks in accordance with MEF 8. The TDM frames are considered serial data, even if they carry voice and CAS. Since a CESoPSN bundle transports raw TDM frames, a CESoPSN bundle can only be directed to another T1 framed port.
Packetizing Considerations
The number of TDM bytes per frame affects several performance aspects: Bandwidth utilization: because of the relatively short payload (especially relevant to TDMoPSN/HDLCoPSN), the bandwidth utilization efficiency depends on the overhead that must be transmitted to the network in order to support the transmission of a certain amount of payload. The overhead depends on the packet structure: for example, for UDP/IP networks the overhead is 50 bytes when using VLANs, and 46 bytes without VLANs The payload depends on the number of TDM bytes (for example, for TDMoPSN, it varies between 48 to 1440 bytes). For example, when using the minimum payload size (48 bytes), bandwidth utilization efficiency is around 50%. Packetizing delay and the associated delay variance. Bandwidth utilization efficiency increases when using a large payload size per frame. However, there are additional aspects that must be considered when selecting the size of the packet payload: Packetization time: when a pseudowire emulation module builds a frame, a packetization delay is introduced. The packet creation time (PCT) is different for the different payload encapsulation methods. It is calculated according to the following formulas:
Gmux-2000 Ver. 4.0
2-7
Chapter 2 Functional Description Mode TDMoIP Delay PCT (ms) = Where: N=
47 N 0.125 TS
TDM bytes / frame 48
TS = number of assigned timeslots (in unframed mode = 32 for E1, 24 for T1). For a bundle that contains a few timeslots (i.e. 1 to 3), the recommended number of TDM bytes/frame is 48 in order to prevent excessive PCT
CESoPSN PCT (ms) = N 0.125 Where:
N = Number of TDM frames in packet

SAToP PCT (ms) =
N 0.125 TS
N Number of TDM bytes in packet TS Number of timeslots in one frame (32 for E1 or 24 for T1)
Intrinsic jitter: the transmission of packets to the network is performed at nominally equal intervals (usually, the interval is 1 msec). This means that every 1 msec the packet processor sends to the network all the frames ready for transmission. As a result, the actual payload transmission intervals vary in an apparently random way whose peak value depends on the bundle size, an effect called delay variance (or jitter). For example, a bundle with 6 timeslots will fill a 48-byte payload field of an Ethernet frame every 1 msec. If the sending instants are not perfectly synchronized with the filling instants, the sending time will sometimes occur just in time and sometimes will be delayed by 1 msec relative to the ideal, creating a peak delay variance of 1 msec at the transmitting side. The intrinsic jitter in other cases is lower, therefore the delay variance generated by the T1-PW-SRV/28 modules will not exceed 2 msec. Round-trip delay. The voice path round-trip delay is a function of all connections and network parameters. The delay value, 2 msec, is given by: RT Delay(msec) = 2 (PCT + Jitter Buffer Level) + network round trip delay Increasing payload size reduces the ratio between the TDMoIP/IP/Ethernet header segment in the packet and the payload, thus reducing the total Ethernet throughput. On the other hand, packetization delay is increased; this contributes to a higher end-to-end delay. This effect can be small and negligible when a full T1 (or many timeslots) are transferred, but can be very significant when few timeslots are transferred. Configuring the TDM bytes per frame (TDM bytes/frame) parameter has impact on the Ethernet throughput (bandwidth or traffic traveling through
2-8
Gmux-2000 Ver. 4.0
the Ethernet). This parameter controls the number of TDM bytes encapsulated in one frame. Sometimes, it is necessary to evaluate the transmission bandwidth required on the PSN, which also depends on the number of TDM bytes. To calculate Ethernet throughput as a function of TDM bytes/frame: 1. Ethernet load (bps) = [(frame overhead (bytes) + TDM bytes/frame) 8] Frames/Second 2. Frame overhead (IP) = Ethernet overhead + IP overhead = 46 bytes
Note
The frame overhead does not include:

Preamble field: 7 bytes SFD field: 1 byte Interframe gap: 12 bytes VLAN field (when used): 4 bytes. Frame/Second = Unframed: 5447/n for a full E1 4107/n for a full T1 Framed: 8000 k/(46.875 n) where: k = number of assigned timeslots n= The maximum Ethernet throughput is calculated by:
1 (VLAN + frame overhead + payload) 8 bits 14444444 4444444 2 3 PCT
frame size (in bytes)
TDM bytes / frame 48
Where: VLAN is an optional field: if enabled, it adds 4 bytes to the frame overhead payload = number of TDM bytes in frame, (48, 96, 144, 192, 1440) frame overhead = size of 46 bytes, include MAC, LLC, IP and UDP layer
The result is in bits per second (bps).
Backward Compatibility with Other RAD Equipment

When operating over UDP/IP networks, the multiplexing of different pseudowires for transmission over the network is based on the UDP port numbers. For CES over UDP/IP and SAT over UDP IP, two multiplexing methods evolved: Source multiplexing: RAD, as an early implementer of pseudowire technology, developed a proprietary multiplexing method, referred to as source multiplexing, that uses a fixed UDP destination port (085E hexa), and includes the destination CBID (circuit bundle identifier), that is, the pseudowire label, as the UDP source port. The receiving side identifies each packet of a
Gmux-2000 Ver. 4.0
2-9
pseudowire addressed to a local destination by checking the source UDP port in the received packet against the preconfigured source pseudowire labels. Destination multiplexing: the multiplexing method that eventually became standardized is referred to as destination multiplexing. In accordance with this method, the UDP destination port includes the destination pseudowire label, and the UDP source port includes the source pseudowire label. The allowed UDP port range, in accordance with the standards, is 49152 to 65535. The receiving side identifies each packet of a pseudowire addressed to a local destination by checking the destination UDP port in the received packet against the preconfigured local source pseudowire labels.
Note
The range of bundle labels supported by Gmux-2000 is 1 to 7000 (decimal). To determine the UDP port number associated with a certain pseudowire:
For source multiplexing: the destination CBID is also the UDP port number.
Thus, the UDP port range is 1 to 7000.

For destination multiplexing: using hexadecimal notation, the UDP port number
is obtained by adding C000 hexa to the hexa representation of the CBID value (that is, in hexadecimal notation, add the prefix C to the CBID value), and then convert back to decimal. Thus, the UDP port range starts at 49152, decimal.
For backward compatibility with RAD equipment, always select source multiplexing for CES over UDP/IP and SAT over UDP IP, whereas for compatibility with other vendors equipment you must select destination multiplexing. All the pseudowires terminated by a given pseudowire emulation module must use the same multiplexing method.
Jitter Buffer Functions

The packets of each bundle are transmitted by pseudowire emulation modules at essentially fixed intervals towards the PSN. The packets are transported by the PSN and arrive to the far end after some delay. Ideally, the PSN transport delay should be constant: in this case, the packets arrive at regular intervals (these intervals are equal to the intervals at which they had been transmitted). However, in reality packets arrive at irregular intervals, because of variations in the network transmission delay. The term Packet Delay Variation (PDV) is used to designate the maximum expected deviation from the nominal arrival time of the packets at the far end device.
Note
The deviations from the nominal transmission delay experienced by packets are referred to as jitter, and the PDV is equal to the expected peak value of the jitter. Note however that nothing prevents the actual delay from exceeding the selected PDV value.
To compensate for deviations from the expected packet arrival time, each pseudowire emulation module uses jitter buffers that temporarily store the packets arriving from the PSN (that is, from the far end equipment) before being transmitted to the local TDM equipment, to ensure that the TDM traffic is sent to the TDM side at a constant rate.
2-10
Gmux-2000 Ver. 4.0
For each bundle, the jitter buffer must be configured to compensate for the jitter level expected to be introduced by the PSN, that is, the jitter buffer size determines the Packet Delay Variation Tolerance (PDVT). Two conflicting requirements apply: Since packets arriving from the PSN are first stored in the jitter buffer before being transmitted to the TDM side, TDM traffic suffers an additional delay. The added delay time is equal to the jitter buffer size configured by the user. The jitter buffer is filled by the incoming packets and emptied out to fill the TDM stream. If the PSN jitter exceeds the configured jitter buffer size, underflow/overflow conditions occur, resulting in errors at the TDM side: A jitter buffer overrun occurs when it receives a burst of packets that exceeds the configured jitter buffer size + packetization delay. When an overrun is detected, the pseudowire packet processing subsystem clears the jitter buffer, causing an underrun. A jitter buffer underrun occurs when no packets are received for more than the configured jitter buffer size, or immediately after an overrun. When the first packet is received, or immediately after an underrun, the buffer is automatically filled with a conditioning pattern up to the PDVT level in order to compensate for the underrun. Then, the pseudowire packet processing subsystem starts processing the packets and empty out the jitter buffer toward the TDM side. To minimize the possibility of buffer overflow/underflow events, two conditions must be fulfilled: The buffer must have sufficient capacity. For this purpose, the buffer size can be selected by the user in accordance with the expected jitter characteristics, separately for each bundle, in the range of 0 to 200 msec. The read-out rate must be equal to the average rate at which frames are received from the network. For this purpose, the read-out rate must be continuously adapted to the packet rate, a function performed by the adaptive clock recovery mechanism of each packet processor.
After the jitter buffer mechanism reaches a stable state, there may still be temporary changes in network delay, which occur before the mechanism can readjust. To provide the best possible user experience the user can specify how to handle packets under such transient conditions: By specifying that the handling will be sensitive to delay, the user instructs the receiving end to automatically reset the jitter buffer when the buffer remains at its high value for a long time (this introduces a long delay). As a result, some packets are discarded, but for voice applications and under normal conditions, this results in negligible voice degradation. By specifying that the handling will be sensitive to data, the user instructs the receiving end to do nothing until eventually an under- or overrun occurs, or conditions return to normal. This achieves the best possible data integrity (error correction, or higher protocols, may sometimes compensate for the resulting problems).
Gmux-2000 Ver. 4.0
2-11
Adaptive Timing
Each PDH port can use the adaptive timing mode to lock its transmit timing to the clock signal associated with the payload carried by a user-specified bundle. The adaptive clock recovery mechanism estimates the average rate of the payload data received in the frames arriving from the packet-switched network. Assuming that the packet-switched network does not lose data, the average rate at which payload arrives will be equal to the rate at which payload is transmitted by the source.
Note
Generally, lost packets, as well as packets that did not arrive in the correct order, are replaced by special dummy packets. However, for CESoPSN and SAToPSN, packets can be reordered.
The method used to recover the payload clock of a bundle is based on monitoring the fill level of the selected bundle jitter buffer: the clock recovery mechanism monitors the buffer fill level, and generates a read-out clock signal with adjustable frequency. The frequency of this clock signal is adjusted so as to read frames out of the buffer at a rate that keeps the jitter buffer as near as possible to the half-full mark. This condition can be maintained only when the rate at which frames are loaded into the buffer is equal to the rate at which frames are removed. Therefore, the adaptive clock recovery mechanism actually recovers the original payload transmit clock. The performance of the clock recovery mechanism can be optimized for the operating environment, by specifying the following parameters: The accuracy of the original timing source, in accordance with the standard SONET terminology (Stratum 1, 2, 3, 3E, or 4/unknown) The type of PSN that transports the traffic: router-based network (for example, UDP/IP) versus switch-based network (for example, Ethernet).
OAM Protocol
The OAM protocol, supported only by packet payload version V2, is used by pseudowire emulation modules to check for a valid bundle connection: this includes checks for compatible configuration parameters at the packet processors at the two endpoints of a bundle, and detection of inactive bundle status. The information regarding bundle state is collected by the continuous, periodic handshake between the two endpoints of a bundle, which generates little traffic, but ensures that each endpoint recognizes the connection, and that it is enabled. In case no response is received to OAM packets within a predefined interval (a few tens of seconds), the bundle is declared inactive. When the use of the OAM protocol is enabled, little traffic flows until the connection between the two bundle endpoints is established: only after the connection is confirmed by the OAM exchange is transmission at the normal (full) rate started, and the bundle starts carrying traffic. In case the connection is lost, the transmitted traffic is again significantly decreased (several packets per second per connection). The OAM connectivity check also prevents network flooding in case the connection is lost.
2-12
Gmux-2000 Ver. 4.0
The user can specify the method used to identify OAM packets: In accordance with source port: in this case the OAM packets run over a UDP port number that is assigned only for OAM traffic, but use the same VLAN ID and ToS of the originating connection. In accordance with the contents of the control word, which is included in version V2 packets (Virtual Circuit Connection Verification VCCV): the first four bits of an OAM control word are always set to 0001.
Alarm Indications
For TDM ports, the applicable standards specify the methods used to report loss of signal, loss of frame alignment, AIS reception, reception of a remote defect indication (RDI) from the equipment connected to the TDM port, etc. However, to provide a complete picture of a packet transmission system, it is necessary to generate additional alarms that cover transmission problems through the packet-switched network, problems caused by incorrect or incompatible configuration, equipment malfunctions, etc. For example, the bundle payload cannot be reconstructed when one of the following conditions occurs: The far end cannot send packets because of a failure (loss of signal, loss of frame alignment, or reception of AIS by the far end port) Jitter buffer underflow or overflow at the local end. Failure of the transmission path that prevents the reception of packets at the local end.
In such cases, all the bundle timeslots in the recovered T1 stream are filled with the user-selected out-of-service (OOS) code; with CAS, the signaling information in timeslot 16 is also replaced by the user-selected signaling OOS code. Note however that the conditions listed above are detected at the local end of a trail (path through the network). When using a framed mode, a T1 port terminates timeslot 0, and therefore, when the users application requires that alarms be propagated to the far end of the trail, it is necessary to use a special alarm generation mode, called the trail extension mode, in contrast to the trail termination mode described above.
Note
The trail extension mode is supported only when bundles use the OAM protocol.
When the trail extension mode is selected, some alarm conditions are reported over the transmission path, and reflected in the signal generated by the port at the other end of the path (the far end port): AIS is transmitted by a far end T1 port toward the connected equipment when all the bundles connected to that port failed. RDI is transmitted by a far end T1 port toward the connected equipment when all the bundles connected to that port receive packets with the R bit (remote alarm flag) set.
Note that AIS can be transmitted even when using the unframed mode, whereas RDI can be transmitted only when using a framed mode.
Gmux-2000 Ver. 4.0
2-13
Description of Gmux-2000 System Used for Voice Trunking Services

When Gmux-2000 is used in voice trunking services, voice compression modules are installed, instead of the pseudowire emulation modules shown in Figure 1-12. A Gmux-2000 can include up to seven voice compression modules, each operating independently. For a description of the voice compression subsystem integration within the Gmux-2000, see the Voice Compression Operating Modes section on page 2-17.
Figure 2-5 shows the structure of a voice compression module.

The operation of the main voice compression module subsystems is described below. User Interfacing Subsystem. The user interfacing subsystem of each module includes 16 or 12 voice ports (depending on the voice compression module type), each comprising a T1 framer and a port interface. In the transmit path, each voice port synchronizes to the incoming T1 stream, terminates timeslot 0, collects the payload from the incoming T1 timeslots, and sends the audio signals to the voice compression subsystem. The port signaling information is collected by the signaling interface and sent to the payload processor for processing. In the receive path, each port collects the decompressed audio signals from the voice compression subsystem and the restored signaling information from the signaling interface, adds the framing overhead, and rebuilds the T1 frame in accordance with the selected framing mode. The voice ports support the following framing modes: D4 (SF) framing (12 frames per multiframe) ESF framing (24 frames per multiframe)
2-14
Gmux-2000 Ver. 4.0
Voice Compression Module

UE External T1 Voice Ports (1-16 or 1-12) Voice Port Line Interfaces Voice Compression and Signaling Processor
Payload Processor
External T1 Data Ports
Packet Bus Interface
LINK 1
LINK 2
Data Port Line Interfaces
NE NS
Data Port Mode Selection
Internal T1 Data Ports
Timeslot Cross Connect
Control and Status Signals To SONET Interface Subsystem
Management
SONET Interface (Mapper)

Clock Signals
Timing and Clock Generation
Figure 2-5. Voice Compression Subsystem Structure

The voice ports have two sets of interfaces: External physical interfaces for directly connecting to the users PBX/voice switch. Each voice port has a balanced ITU-T Rec. G.703 interface. Internal interfaces (internal ports) that connect through the voice compression module SONET mapper to the Gmux-2000 telecom buses. These logical ports are mapped to VT1.5s on the desired SONET ports, and the path parameters can be configured as for any other VT1.5 ports. At any time, only one set of voice port interfaces (either the external or the internal set) is active, that is, connected to the T1 voice framers, in accordance with the selected operating mode. Network Interfacing Subsystem. The network interfacing subsystem consists of data ports, each comprising a T1 framer and a port interface. In the transmit path, each data port collects the compressed audio signals from the payload processor and builds the data stream for transmission to the network. In the receive path, each data port synchronizes to the incoming data stream, collects the payload and sends it to the payload processor, for further processing (separation of signaling and compressed audio). The payload processor provides the information to be sent to the network, and it also handles the information received from the network. The connection between the data ports and the payload processor is made by a timeslot cross-connect matrix.
Gmux-2000 Ver. 4.0
2-15
To CONTROL Module
To PSN Interface Subsystem
Voice Port US Mode Selection
Internal T1 Voice Ports
The data ports support the following framing modes: D4 (SF) framing (12 frames per multiframe) ESF framing (24 frames per multiframe) Unframed mode. This mode provides 24 payload timeslots per port, and therefore enables full utilization of link bandwidth (1544 kbps), but can be used only for point-to-point applications (no channelizing the whole port is handled as a single subchannel). The data ports have two sets of interfaces: External T1 physical interfaces, for directly connecting to T1 transmission equipment. The number of external T1 data ports is 2. Internal interfaces (internal ports) that connect through the SONET mapper to the Gmux-2000 telecom buses. The number of internal data ports is either 2 (without backup) or 4 (backup enabled). These logical ports are mapped to VT1.5s on the desired SONET ports, and the path parameters can be configured as for any other VT1.5 ports. At any time, only one set of data port interfaces (either the internal or the external ports) is active, that is, connected to the T1 data framers, in accordance with the selected operating mode (see Voice Compression Operating Modes section on page 2-17). To improve service availability, the network interfacing subsystem can be configured to provide backup for the connection to the network. In this case, the data ports operate in pairs: When using the external T1 data ports, the maximum bandwidth of the network connection is the bandwidth available on a single port (1544 kbps for framed modes). When connecting through the internal (SONET) ports, the maximum bandwidth is the bandwidth available on two ports. Packet Bus Interfacing Subsystem. The packet bus interfacing subsystem includes an Ethernet switch that handles the traffic flow between the internal packet ports of the payload processor and the Gmux-2000 packet buses, en route to the GbE PSN interface module. This traffic flow is configured by defining bundles terminated on GbE ports. The internal packet ports are connected to the chassis packet buses via two Fast Ethernet transceivers. Voice Compression Subsystem. The transmit path of the voice compression subsystem converts each payload timeslot to a stream of packets for transmission through the network. The packets are sent to the payload processor, which transfers the packets of each bundle of timeslots either to the appropriate internal or external (network) data port and subchannel, or to GbE module, via the packet bus interface. The receive path receives from the payload processor streams of packets for each payload timeslot, and sends the decompressed voice streams to the corresponding voice port framer.
2-16
Gmux-2000 Ver. 4.0
Signaling Processing Subsystem. In the transmit path, the signaling interface retrieves the signaling information of each port from the appropriate timeslots, in accordance with the port signaling transfer mode (CAS or CCS), and transfers it to the payload processor for processing. In the receive path, the signaling interface inserts the signaling information of each port restored by the payload processor in the appropriate timeslots. Voice compression modules do not use the signaling information: the signaling information is only transmitted through the compressed voice connections, for use by the users equipment at the local and remote endpoints.
Timing and Clock Generation Subsystem. The timing of each T1 port is derived as follows: Transmit path: the transmit timing of each external port can be either: Derived from the Gmux-2000 nodal timing. In this case, the equipment connected to the corresponding port must use loopback timing. Locked to the clock signal recovered from the receive line signal of the port. This locks the port transmit timing to the transmit timing of the equipment connected to the port receive clock (loopback timing). All the T1 ports, whether data or voice, must use the same clock source. Receive path: the receive path of each T1 port always receives the clock signal from the external T1 port.
Note
The receive clock frequency must always be equal to the transmit clock frequency.
Voice Compression Operating Modes

Note The following description uses the mode designations as they appear on supervision terminal and Telnet screens.
Voice compression modules can be configured to operate in four modes, which differ with respect to signal flow among the TDM ports: UE_NE, US_NE, UE_NS, and US_NS. The various operating modes are described below. For clarity, the voice compression, signaling interface, and payload processor subsystems of Figure 2-5 have been shown as a single voice compression subsystem in the following figures (Figure 2-6 to Figure 2-9). Note that in operating mode modes, traffic from the active user ports can also be directed to the packet buses. This connection (from the payload processor, via the packet bus interface see Figure 2-5), has been omitted in Figure 2-6 to Figure 2-9, because it is always available, irrespective of the selected mode. UE_NE Mode: In this mode, Gmux-2000 voice compression subsystem accepts user traffic from the 16 or 12 external T1 ports (User External UE) and sends the compressed traffic through the external T1 network ports of the module (Network External NE) (see Figure 2-6).
Gmux-2000 Ver. 4.0
2-17
VMX_T1_UE_NE
1
1-16 T1
External Voice Ports

16
Voice Compression
LINK 1 External Data Ports LINK 2
Figure 2-6. Signal Flow in UE_NE Mode

US_NE Mode: In this mode, Gmux-2000 voice compression subsystem accepts user traffic from the SONET ports (User SONET US) located on the OC3 module, and sends the compressed traffic through the external T1 network ports of the module (Network External NE) (see Figure 2-7).
VMX_T1_US_NE
1
To OC3 Modules
SONET Mapper
16
Internal Voice Ports
Voice Compression
LINK 1 External Data Ports LINK 2
Figure 2-7. Signal Flow in US_NE Mode

UE_NS Mode. In this mode, Gmux-2000 voice compression subsystem accepts user traffic from the 16 or 12 external T1 ports (User External UE), and sends the compressed traffic in VT1.5s through SONET ports (Network SONET NS) located on the OC3 module (see Figure 2-8).
VMX_T1_UE_NS
1
1
1-16 T1

16
Voice Compression
Internal Data Ports
3 4
SONET Mapper
To OC3 Modules
Figure 2-8. Signal Flow in UE_NS Mode

US_NS Mode. In this mode, Gmux-2000 voice compression subsystem accepts user traffic from the SONET ports (User SONET US) located on the OC3 module, and sends the compressed traffic through the same, or other, SONET ports (Network SONET NS) (see Figure 2-9).
2-18
Gmux-2000 Ver. 4.0
VMX_T1_US_NS
1
1

16
Voice Compression
LINK 1 LINK 2
Internal Data Ports
3 4
SONET Mapper
To OC3 Modules
Figure 2-9. Signal Flow in US_NS Mode
Handling of Voice Signals

The 64 kbps PCM-encoded voice signals received through the voice compression module user (voice) ports can be compressed using one of the compression algorithms supported by the voice compression. To support voice transmission systems based on both T1 and T1 standards, the user can specify the companding law used by the PCM sections (A-law or -law, in accordance with ITU-T Rec. G.711). The supported low bit rate voice compression options and data rates are as follows: Voice compression using multiple-pulse, maximum likelihood code-excited linear prediction (MP-MLQ) per ITU-T Rec. G.723.1, at a channel data rate of 5.3 or 6.4 kbps. Voice compression using conjugate structure-algebraic-code-excited linear prediction (CS-ACELP) per Annex A of ITU-T Rec. G.729A, at a channel data rate of 8 kbps.
Note
When using the ITU-T Rec. G.729A coder, the user can configure the caller ID signaling protocol (Bellcore Type 1 or V.23), and delay the sending of the caller ID information by a selectable interval.
In addition, the user can also select uncompressed transmission, which requires a channel rate of 64 kbps, by specifying a PCM coder (that is, an ITU-T Rec. G.711 coder with A-law or -law companding). This option is not available when using the super-tandem mode. Although voice is not compressed when using PCM (ITU-T Rec. G.711) coders, all the other signal processing functions and services are active; moreover, the selected companding law, which is used towards the network, can be different from that used for the local traffic. With regular voice encoding methods, much bandwidth is wasted during the normal periods of silence in a call (it is often assumed that up to 60% of the call duration consists of quiet intervals). Therefore, to further reduce the actual bandwidth required for voice transmission, the voice compression subsystem
Gmux-2000 Ver. 4.0
2-19
supports voice activity detection (VAD), with silence detection and suppression. To improve silence detection in noisy environments, the user can select between the internal VAD policy, which complies with the standard silence detection methods, and the RAD-proprietary generic VAD policy, which allows the user to select the detection threshold: one for high background noise, another for normal background, or to cancel the VAD function altogether (this last option is not supported for uncompressed (ITU-T Rec. G.711) voice, because in this case the only way to improve bandwidth utilization efficiency is to use the VAD function). At the receiving side, the far end fills the silence interval with noise having characteristics similar to normal background noise (this capability is called comfort noise generation CNG), to give the far end subscriber the impression of a live line, and therefore the subjective quality of the call is not noticeably affected. The use of comfort noise generation is also a user-selectable option. To improve the perceived communication quality, the following additional capabilities are offered: Adaptive compensation for delay variations in voice packet transport over the network. The compensation is performed by a special mechanism which automatically adjusts the jitter buffer size to the actual delay variations, and thus keeps the end-to-end delay in the voice path to the minimum possible (see TDMoPSN Packet Processing section on page 2-4 for a description of jitter buffer functions). Adaptive echo canceling for near-end reflections (echo delay up to 128 msec). The echo canceling performance complies with ITU-T Rec. G.168 requirements, and is user-selectable for each bundle. Echoes are generated at the points the transmission path changes from 4-wire to 2-wire. Therefore, echo canceling is needed only when 2-wire equipment (phones, fax, modems) are used at the end points served by this bundle. Only one echo canceller should be used at each end point that connects to 2-wire equipment. Therefore, if another echo canceller is already inserted in the signal path of a bundle, for example, at a PBX, the echo canceling function of the module should be disabled for that bundle. Voice compression modules permit automatic activation and deactivation of the echo canceller function under the control of the far end equipment: when this option is enabled, the user can select one of the signaling bits, for example, bit C, as the echo canceller on/off control bit. Control over the transmit and receive levels of the audio path (the receive path transmits towards the local users equipment, for example, PBX, and the transmit path receives the signal from the local equipment). This function can be used to compensate for attenuation in the audio paths. For example, when a local subscriber is connected by a long line to the PBX, the input and output gains can be increased to compensate for the expected attenuation, and thus improve the perceived voice quality. Being able to select the correct nominal transmit input level (that is, a level that matches the nominal signal level received from the voice equipment) has an additional advantage: it ensures the best voice compression performance, because the compression DSP then operates at its optimum point.
2-20
Gmux-2000 Ver. 4.0
Support for super tandem links, that is, links which comprise several segments connected in tandem, where each segment could perform voice decompression and compression. Recompression would significantly degrade voice quality. Therefore, when the super tandem mode enabled, the voice compression module detects whether the arriving voice data has already been compressed by another voice compression module or Vmux Voice Trunking Gateway, and transfers such data unmodified. This is always required on the intermediate segments of tandem links. When the super tandem mode is enabled, the uncompressed voice option (that is, the use of ITU-T Rec. G.711 coders) is not available.
Processing of Inband Signaling

Inband signaling by means of tones, for example, DTMF, MFR2 and MFC, is widely used in modern telephony networks. Pure tones are also used for various functions, for example, 2000 Hz tones are sometimes used for continuity checks (COT). The waveform of such signals is very different from speech waveforms, therefore most compression algorithms distort them; for example, distortion of DTMF signals transmitted as analog signals through a compressed voice channel may cause errors to occur in the detection of the dialed digits by PBXs and other equipment. The method used to overcome this problem is referred to as relaying: when relaying is enabled, the transmit path demodulates the signal to retrieve the encoded data, and transmits the data through the link; the receiving end then synthesizes a clean signal carrying the data, for transmission to the users equipment. For example, to enable reliable transmission of DTMF signals, the DSP detects incoming DTMF signals, independently for each timeslot, and identifies the dialed digits. The detected digits are digitally transmitted through the link to the far end, where clean digital representations of DTMF signals are synthesized and inserted into the decompressed data stream sent in the corresponding timeslot. While inband signaling is received, the voice path is disconnected, to prevent interference by signals transmitted through the regular processing path. The method used for DTMF relaying is also used to transfer transparently call progress tones. Voice compression always relay DTMF signals, using preconfigured parameters that ensure optimal operation. With respect to 1780 and 2000 Hz tones, and for MF-based signaling (for example, MFR2/R2 and MFC), relaying can be enabled/disabled by the user. For MF signaling, the user can specify detection parameters, for example, then minimum level and duration a signal must exceed in order to be detected as a signaling code, and can also enable MFC spoofing, which shortens the call setup delay when using R2-MFC signaling by forcing an acknowledge after a user-selectable interval.
Gmux-2000 Ver. 4.0
2-21
Note
Uncompressed voice channels, using PCM (that is, ITU-T Rec. G.711 coders), can transmit inband signaling without significant distortion, yet DTMF and tone relaying are always preferable and should be enabled. MF relaying is always disabled when using an ITU-T Rec. G.711 coder.
Automatic Fax Processing

The processing of audio signals by low bit rate voice compression methods does not enable analog transmission of fax signals. Therefore, when it is expected that a compressed voice bundle will carry signals generated by fax machines, it is necessary to enable the automatic fax relaying function. When automatic fax relaying is enabled, a voice compression module will automatically recognize and transmit Group III fax messages at the standard rates in the range of 4.8 to 14.4 kbps. The maximum fax rate can be selected by the user. The module supports automatic fallback capability, that is, it will automatically switch to the next lower data rate supported by both communicating faxes. The whole fax transmission process is therefore handled as a data transmission, with the module DSP providing the fax signal modulation/demodulation functions and the detection and generation of the fax connection set up tones (in digital format), to enable the handshaking necessary to implement the standard fax communication protocol. Fax relaying works as follows: To set up a fax connection, the DSP processing the local timeslot (channel) emulates the remote fax machine toward the local machine, and the remote DSP emulates the local fax toward the remote machine. After the fax connection is established, the fax data stream is transmitted as a packetized data stream through the link. This means that the link must have enough free bandwidth to enable sustained transmission of a data stream at the fax data rate (and the additional connection supervision signals).
This process enables any standard Group III facsimile machine to transmit over the link. The only limitation is that the round-trip transmission delay through the link cannot exceed the time-out intervals specified by the fax communication protocol (about 700 msec); otherwise, the handshaking needed to establish a fax connection will fail.
Note
When necessary, the minimum time of 1100 Hz or 2100 Hz must be present for positive detection of a modem or fax signal can be fine-tuned.
For bundles expected to carry non-standard fax protocols, which are not recognized by the module DSPs, the user can configure voiceband fax transmission. In this case, a timeslot carrying a fax transmission is handled as an analog voiceband signal with unknown characteristics, and it is therefore transferred using one of the following types of coders, which are both capable of transferring complex waveforms with little distortion: ITU-T Rec. G.711 A-law or -law PCM coder (the same coders available for uncompressed voice), which require a channel rate of 64 kbps. PCM requires a bandwidth on the order of one timeslot on the network side
2-22
Gmux-2000 Ver. 4.0
ITU-T Rec. G.726 ADPCM coders, which compress the signal to a channel rate of 32 kbps (commonly used in Europe, and other countries using the T1-based hierarchy), or 24 kbps (commonly used in North America, and in countries using the T1-based hierarchy). ADPCM provides performance very close to PCM, but requires significantly less bandwidth (40% to 50% of that required by PCM) on the network side.
The selected voiceband coder is used for both fax and modem voiceband transmissions.
Handling of Voiceband Modem Signals

Voice compression modules handle voiceband modem signals using either relaying or voiceband signal transmission, as selected by the user: Modem relaying is similar to fax relaying, except that the DSP emulates a voiceband modem instead of a fax modem. The recognized modem protocols include V.22/V.22bis, V.32/V.32bis, and V.34 up to 21.6 kbps Voiceband transmission, using the selected voiceband coder, can be configured by the user for all the modem calls. When modem relaying is enabled, voiceband transmission is automatically used for any unrecognized modem protocol.
Handling of Voice Trunk Signaling

Two voice trunk signaling methods are in use, CAS (robbed-bit) and CCS. CAS Handling. Channel-associated signaling (CAS) can be used when a T1 voice port uses robbed-bit signaling. The signaling information of each voice channel is carried by means of up to four bits (signaling bits), designated by the applicable standards as bits A, B, C, and D: ports with SF (D4) framing use only bits A and B, whereas ports with ESF framing use all the four bits. With CAS, each voice port retrieves the CAS information of each channel (timeslot), and transfers it within the voice packets to the far end. To provide the flexibility needed to adapt to variations to the standard signaling codes that are sometimes implemented by PBX equipment manufacturers, voice compression modules support the definition of specific interpretation, or translation, rules called signaling profiles. The profile modifies the signaling information in the direction from the network to the PBX (local user) side. Each voice port of a voice compression module can use a different signaling profile. The total number of different signaling profiles that can be defined for each module is up to 5. In addition to signaling translation, each profile also enables defining the signaling code to be sent to the local user (PBX) to indicate idle timeslots, and the code sent to indicate the out-of-service state (that is, a timeslot that cannot carry traffic, for example, as a result of a test or maintenance activity). CCS Handling. Common-channel signaling (CCS) uses dedicated timeslots within the T1 structure to carry serial data channels for exchanging signaling
Gmux-2000 Ver. 4.0
2-23
information between the local and far end. CCS can be used when a T1 voice port uses the CCS signaling mode. With CCS, it is usually necessary to transfer the signaling information transparently through the link, in parallel with the voice payload, and let the end users equipment interpret the signaling. This transfer uses an optimized HDLC protocol, which is transparent to the endpoints. For one widely used protocol, Signaling System 7 (SS7), it is possible to increase bandwidth utilization efficiency, because SS7 uses two specific types of protocol signal units (messages) that do not carry signaling information: Link status signal units (LSSUs): used to exchange information regarding the status of the SS7 signaling link between two endpoints. After a signaling link is successfully set up between the SS7 link endpoints, the LSSUs carry little new information. Fill-in signal units (FISUs): used just to keep the HDLC signaling link alive. These messages do not carry any information payload, and are transmitted only when there no other types of SS7 signal units to transmit. In the absence of other signaling traffic, the signaling links carry a significant number of FISUs. To reduce the bandwidth wasted to transmit LSSUs and FISUs, the voice compression subsystem can be configured to suppress a certain fraction of these messages (up to 90%). When the suppression ratio is 0%, the channel performs the same as a HDLC channel. Voice compression modules support one HDLC timeslot and one SS7 timeslot per trunk.
Voice Packet Processing

The assembly and disassembly of voice packets for transport over the network is handled by the payload processor. Two sets of parameters for this purpose are needed: Parameters used to define compressed voice (CV) bundles. A bundle consists of selected timeslots from a common voice port that have the same destination, and require identical processing (same voice coding method, same voice processing parameters, etc.). Parameters used to define the network connection parameters, that is, a physical port and the assigned bandwidth (number of timeslots) on that port, for the compressed voice traffic. The bandwidth is determined by defining subchannel characteristics.
Note
Multiple bundles may be carried over a single subchannel, provided the available bandwidth is sufficient.
The voice packets transmitted to the network are inserted in a multiplexed frame structure. The frame can include a total of 100 to 1461 bytes, where a smaller number yields lower delays, and a larger size improves bandwidth utilization efficiency.
2-24
Gmux-2000 Ver. 4.0
A time-out interval (10 to 90 msec) is also defined, after which the current frame is sent even if it is not filled up completely.
Estimating Bandwidth Requirements

One basic method of encapsulation and multiplexing of voice packets is supported by voice compression modules: TDM for use over IP networks (TDMoIP). This method take the packets containing the compressed voice and add additional data for enabling transport over the PSN. The data includes UDP encapsulation followed by encapsulation in Ethernet frames, with or without VLAN information.
Note
In addition to traffic packets, voice compression modules also send connectivity check packets.
The size of the voice packets depends on the selected coding method, and on the encapsulation method. Since a significant fraction of the number of bytes in each packet is used to carry the headers data, the module supports an additional RAD-proprietary, bandwidth-efficient encapsulation method, identified as TDMoIP+. The actual number of packets generated depends on the voice activity, and may vary widely over short intervals, although over the long term the average number changes much less. Despite the statistical variations, it is necessary to make preliminary evaluations of the bandwidth needed to carry the expected traffic. RAD offers a dedicated Bandwidth Calculator, which can be used to predict the required bandwidth, taking into consideration the following main parameters: Packet size Selected coder Silence percentage.
With time, the bandwidth utilization statistics can be analyzed, and the assigned bandwidth be modified to better match actual traffic. For this purpose, each voice compression module in the Gmux-2000 automatically collects performance statistics, and stores the data in a file, STAT.DAT, that can be sent by TFTP to a RADview-SC/Vmux Service Center.
Preventing Excessive Bandwidth Consumption

To safely use as much bandwidth on the network connection as possible without degrading the quality of service, the following procedures are used: Voice compression modules have a mechanism that randomly discards a small portion of voice packets on each ongoing call when the available bandwidth is not sufficient to transfer the offered traffic. This mechanism does not depend on support by the connected equipment, and is always active. The user can configure the threshold at which voice packets start to be discarded.
Gmux-2000 Ver. 4.0
2-25
The algorithm used by voice compression modules for this purpose leads to a temporary degradation of voice quality that in many cases is quite tolerable, and is always preferable to call disconnection as a result of congestion. During congestion conditions, buffers may overflow and are flushed. Another bandwidth control mechanism at the voice compression module level is used to block new modem calls when bandwidth utilization reaches a certain threshold. Since modem calls can be transmitted either as analog (voiceband) signals or using relaying, separate thresholds are used for each type of modem call. A similar mechanism is used to limit the maximum number of modem calls carried by a connection (bundle).
Processing of Transparent Timeslots

To support a wider range of services, voice compression modules can also transfer transparently selected voice port timeslots. Timeslots configured for transparent transfer bypass the voice compression subsystem, and are converted to packets without any compression. At the receive side, the data contained in packets carrying the transparent timeslots is directly converted to a data stream that is inserted in the corresponding timeslots, without passing through the voice decompression subsystem. This restores the original payload carried in the selected timeslots. The user can specify the jitter buffer size used for the data carried by transparent timeslots, in the range of 20 to 100 msec. Since usually such timeslots carry data, this permits to select the most appropriate jitter buffer while restricting the round-trip delay to acceptable values. Transparent timeslots can be included in each compressed voice bundle. Note that the payload data rate for such timeslots is always equal to the timeslot rate, 64 kbps. The required bandwidth on the links is slightly higher than 64 kbps, because of the packet overhead.
Description of Gmux-2000 System Used for VoIP Services

Figure 2-10 shows the functional block diagram of the VCA-T1/16 module, as
applicable for VoIP applications. The functional block diagram of the VCA-T1/12 module is similar, except that it has only 12 T1 voice ports.
2-26
Gmux-2000 Ver. 4.0
1-16 T1
1
VCA-T1/16
UE T1 LIUs (Voice Ports) US To Packet Buses
Voice Port Mode Selection
T1 Framers (Voice Ports)
Voice Compression
Ethernet Switch
16
Signaling Interface
External Data Ports LINK 2 LINK 1
Main Processor T1 LIUs (Data Ports) NE NS
Data Port Mode Selection
T1 Framers (Data Ports)
Timeslot Cross-Connect
Not used in VoIP Applications
Control and Status Signals
Management
Clock Signals
Timing and Clock Generation
SONET Mapper
Figure 2-10. VCA-T1/16 Module, Functional Block Diagram for VoIP Applications
The operation of the main VCA-T1/16 subsystems is described below. User Interfacing Subsystem. The user interfacing subsystem includes 16 voice ports, each comprising an T1 framer and a port interface. In the transmit path, each voice port synchronizes to the incoming T1 stream, and collects the payload from the incoming T1 timeslots: Voice timeslots are sent to the voice compression subsystem, for processing. In addition, when VCA-T1/16 signaling gateway function is active and the voice port includes signaling timeslots, the signaling interface collects the signaling information from the corresponding timeslots and sends it to the main processor, for processing. In the receive path, each port collects the decompressed audio signals from the voice compression subsystem, and when relevant, the signaling information from the signaling interface, adds the framing overhead, and rebuilds the T1 frame.
Gmux-2000 Ver. 4.0
2-27
To Telecom Buses
To CONTROL Module
The voice ports use the basic G.704 framing, which enables using all the 31 timeslots in the T1 frame for payload. The user can enable/disable support for CRC-4 per ITU-T Rec. G.704 and G.706: the CRC-4 option should be enabled whenever possible, because it allows to monitor the T1 link transmission performance. Each voice port can be independently configured in accordance with the desired framing mode: D4 (SF) framing (12 frames per multiframe) ESF framing (24 frames per multiframe) The voice ports have two sets of interfaces: External physical interfaces terminated in the 1-16T1 or 1-12T1 connector, for directly connecting to the users equipment. The T1 physical link interfaces meet the applicable requirements of AT&T TR-62411, ANSI T1.403, and ITU-T Rec. G.703. Jitter performance complies with the requirements of AT&T TR-62411. Zero suppression over the line is user-selectable, separately for each port: transparent (AMI) coding, B7ZS, or B8ZS. For clear channel capability, it is necessary to use B8ZS. The line impedance is 100 balanced. Each T1 line interface has an integral CSU, which enables long-haul operation with line attenuations up to 36 dB. The nominal transmit level is 3V. The CSU transmit level can be attenuated by 7.5, 15, or 22.5 dB, for compliance with FCC Rules Part 68A. For short-haul applications, the line interface can also emulate a DSU interface. When configured for short-haul applications, the line transmit signal is user-adjustable for line lengths of 0 to 655 feet in accordance with AT&T CB-119. Internal interfaces (logical ports) that connect through the VCA-T1/16 SONET mapper to the Gmux-2000 telecom buses. These logical ports are mapped to VT1.5s on the desired SONET ports, and the path parameters can be configured as for any other VT1.5 ports. At any time, the voice port mode selector connects only one set of voice port interfaces (either the external or the internal set) to the T1 voice framers, in accordance with the selected operating mode. Packet Bus Interfacing Subsystem. The packet bus interfacing subsystem includes an Ethernet switch, controlled by the VCA-T1/16 main processor that handles the traffic flow between the internal packet ports of the voice compression subsystem, and the Gmux-2000 packet buses. The internal packet ports are connected to the chassis packet buses via two Fast Ethernet transceivers, which transfer the VCA-T1/16 packet traffic to the GbE/2 PSN interface module. The GbE/2 module provides the following services for the VCA-T1/16: In the receive direction, the GbE/2 module filters the IP traffic and passes to the VCA-T1/16 only traffic directed to the VCA-T1/16 IP address. It also filters Layer 4 (UDP) to transfer only traffic using UDP ports that are
2-28
Gmux-2000 Ver. 4.0
needed by the VCA-T1/16 media gateway, and when configured the VCA-T1/16 signaling gateway. In the transmit direction, the GbE/2 module provides gateway services for the outgoing VCA-T1/16 traffic, using the preconfigured static routes. Voice Compression Subsystem. The transmit path of the voice compression subsystem can convert each voice timeslot of a VCA-T1/16 T1 voice port to a stream of packets for transmission through the network. The relevant timeslots are the voice timeslots selected by the user. The conversion is performed in accordance with the user-selected media processing parameters, and the call parameters specified by the VCA-T1/16 media gateway function. The packets are sent to the Ethernet switch, which transfers the packets to GbE module, via the packet bus interface. The receive path of the voice compression subsystem receives from the Ethernet switch the streams of packets for each compressed voice timeslot, and sends the decompressed voice streams to the corresponding voice port framer. Signaling Processing Subsystem. The signaling processing subsystem is active only on VCA-T1/16 using the signaling gateway function. When configuring the signaling gateway parameters, the user also specifies the location of each signaling link handled by the module (voice port and port timeslot). In the transmit path, the signaling interface retrieves the signaling information from the designated timeslots of the appropriate ports, and transfers it to the main processor for processing. The SS7 MTP 2 signaling information is converted to M2UA over SCTP packets and transmitted through the packet buses and the GbE module to the designated MGC In the receive path, the signaling interface inserts the signaling information provided by the main processor in the appropriate timeslots. Timing and Clock Generation Subsystem. The timing of each T1 voice port is derived as follows: Transmit path: the transmit timing of each external port can be either: Derived from the Gmux-2000 nodal timing. In this case, the equipment connected to the corresponding port must use loopback timing. Locked to the clock signal recovered from the received signal of the port. This locks the port transmit timing to the transmit timing of the equipment connected to the port receive clock (loopback timing). All the T1 voice ports of the module must use the same clock source. Receive path: the receive path of each T1 port always receives the clock signal from the external T1 port.
Note
The receive clock frequency must always be equal to the transmit clock frequency, and therefore both must be derived from a common reference source.
Gmux-2000 Ver. 4.0
2-29
Management Subsystem. The module management subsystem controls the operation of the various circuits located on the VCA-T1/16 module, in accordance with the configuration parameters sent by the CONTROL module upon power-up, or after resetting. The configuration parameters are stored on the CONTROL module. The software necessary for the module operation is stored in a flash memory. The software can also be updated by downloading from the CONTROL module.
VCA-T1/16 Operating Modes

Note The following description uses the card designations as they appear on supervision terminal and Telnet screens.
VCA-T1/16 can be configured to operate in two modes, which differ with respect to signal flow among the TDM ports: UE and US. The two operating modes are described below, using a simplified functional block diagram (the full functional block diagram is shown in Figure 2-10). UE Mode. In this mode, VCA-T1/16 accepts user traffic from the external T1 ports of the module (User External UE), and sends the compressed traffic through the packet buses, as shown in Figure 2-11.
VMG16T1_UE
1
1-16 T1

16
Voice Compression
Ethernet Switch
Figure 2-11. Signal Flow in UE Mode

US Mode. In this mode, VCA-T1/16 accepts user traffic arriving through the Gmux-2000 telecom buses from the SONET ports (User SONET US) located on the OC3 module, and sends the compressed traffic through the packet buses, as shown in Figure 2-12.
2-30
Gmux-2000 Ver. 4.0
To Packet Buses
VMG16T1_US
1
SONET Mapper
16
Voice Compression
Ethernet Switch
Figure 2-12. Signal Flow in US Mode
Handling of Voice Signals

The 64 kbps PCM-encoded voice signals received through the VCA-T1/16 user (voice) ports can be processed using one of the compression algorithms supported by the VCA-T1/16 modules. To support voice transmission systems based on both E1 and T1 standards, the user can specify the companding law used by the PCM sections (A-law or -law, in accordance with ITU-T Rec. G.711). The VCA-T1/16 DSP subsystem can process the T1 voice port traffic using a wide range of codecs. The actual codec used at any instant depends on the call parameters, and may change, under the control of the VCA-T1/16 media gateway function, when the signal characteristics change (for example, detection of DTMF, switching from voice to fax, etc). The user can restrict the range of codecs that are available in accordance with the particular application requirements. The complete set of codecs supported by the VCA-T1/16 DSP subsystem includes: Low bit rate voice compression codecs. The supported codec types and their nominal channel rates are as follows: Voice compression using multiple-pulse, maximum likelihood code-excited linear prediction (MP-MLQ) per ITU-T Rec. G.723.1, at a channel data rate of 5.3 or 6.4 kbps. Voice compression using conjugate structure-algebraic-code-excited linear prediction (CS-ACELP) per ITU-T Rec. G.729A, at a channel data rate of 8 kbps. Adaptive Multi-Rate (AMR) narrow-band (NB) voice compression. The AMR speech codec is a multimode codec standardized by the European Telecommunications Standards Institute (ETSI) for GSM cellular systems. It supports 8 narrow-band speech encoding modes with bit rates between 4.75 and 12.20 kbps. When using AMR in the VoIP mode, the coding mode can change dynamically, to adapt to the link conditions. The user can enable/disable the use of each mode, and can specify the relative priority of each mode. PCM codecs: provide uncompressed transmission, which requires a channel rate of 64 kbps. The PCM coder is an ITU-T Rec. G.711 coder with selectable A-law or -law companding.
Gmux-2000 Ver. 4.0
2-31
To Packet Buses
To OC3 Modules
Irrespective of the voice encoding method, much bandwidth is wasted during the normal periods of silence in a voice call. Therefore, to further reduce the actual bandwidth required for voice transmission, the VCA-T1/16 modules support silence detection and suppression: When a silence interval is detected in a channel (timeslot), an indication is sent to the far end by means of special silence insertion descriptor (SID) packets, that require much less bandwidth than regular voice packets, and the transmitting side releases most of the bandwidth normally occupied by the channel traffic. When decompressing the voice, the far end usually fills the silence interval with noise having characteristics similar to normal background noise (this capability is called comfort noise generation CNG). This gives the far end subscriber the impression of a live line, and therefore the subjective quality of the call is not noticeably affected.
Another parameter that can be configured by the user to improve bandwidth utilization is the packetizing interval. The packetizing interval range is 10 to 60 msec (the allowed values depend on the specific codec type). To improve the perceived communication quality, VCA-T1/16 offers additional capabilities: Adaptive compensation for delay variations in voice packet transport over the network. The compensation is performed by inserting a jitter buffer; a special mechanism automatically adjusts the jitter buffer size to the actual delay variations, and thus keeps the end-to-end delay in the voice path to the minimum possible. The maximum jitter buffer size is 150 msec. Adaptive echo canceling for near-end reflections (echo delay up to 128 msec). The echo canceling performance complies with ITU-T Rec. G.165 and G.168 requirements. Echoes are generated at the points the transmission path changes from 4-wire to 2-wire. Therefore, echo canceling is needed only when 2-wire equipment (phones, fax, modems) are used at the endpoints. Only one echo canceller should be used at each end point that connects to 2-wire equipment. Therefore, if another echo canceller is already inserted in the signal path, for example, at a PBX or exchange, the echo canceling function should be disabled. Voice compression modules permit automatic activation and deactivation of the echo canceller function under the control of the far end equipment: when this option is enabled, the user can select one of the signaling bits, for example, bit C, as the echo canceller on/off control bit.
Processing of Inband Signaling

Inband signaling by means of tones, generally DTMF, is widely used in modern telephony networks. The waveform of such signals is very different from speech waveforms, therefore most compression algorithms distort them, even to the point that DTMF decoders may not be able to reliably recognize the dialed DTMF digits. VCA-T1/16 supports several methods to overcome this problem (the actual method can be selected in accordance with the application requirements):
2-32
Gmux-2000 Ver. 4.0
Relaying in accordance with RFC2833: the DTMF signaling received from the local voice ports is identified and demodulated. The resulting information is sent through the link as a packet encoded in accordance with RFC2833, with a user-specified payload type. While inband signaling is received, the voice path is disconnected, to prevent interference by signals transmitted through the regular processing path. When necessary, a clean DTMF signal is synthesized for transmission through the far end voice port, or the packet can be directly used by the far end equipment.
MEGACO/ITU-T Rec. H.248 encoding: DTMF signaling is identified and demodulated, and the resulting information is transmitted through the link using MEGACO/ITU-T Rec. H.248 packets. Inband transmission: DTMF signals are transmitted as regular analog signals, inband, using the currently selected codec. This may severely distort the DTMF signals, unless a PCM codec has been selected as the default codec. However, when DTMF signaling is not used, you may safely use this option.
Automatic Fax Processing

The processing of audio signals by low bit rate voice compression methods does not enable analog transmission of fax signals. Therefore, when it is expected that a compressed voice call will carry signals generated by fax machines, it is necessary to use a suitable processing method, which will recognize the fax transmission and enable selecting an appropriate processing method. The methods supported by VCA-T1/16 are as follows: Automatic fax relaying. When automatic fax relaying is enabled, VCA-T1/16 will automatically recognize and transmit Group III fax messages in accordance with ITU-T Rec. Rec. T.38. The whole fax transmission process is therefore handled as a data transmission, with the VCA-T1/16 DSP providing the fax signal modulation/demodulation functions and the detection and generation of the fax connection set up tones (in digital format), to enable the handshaking necessary to implement the standard fax communication protocol. Fax relaying works as follows: To set up a fax connection, the DSP processing the local timeslot (channel) emulates the remote fax machine toward the local machine, and the remote DSP emulates the local fax toward the remote machine. After the fax connection is established, the fax data stream is transmitted as a packetized data stream through the link and is reconverted to a clean fax signal at the other side. This process enables any standard Group III fax machine to transmit over the link. The only limitation is that the round-trip transmission delay through the link cannot exceed the time-out intervals specified by the fax communication protocol (about 700 msec); otherwise, the handshaking needed to establish a fax connection will fail. Voiceband transmission when a fax signal is identified, the codec is replaced by a user-configured PCM codec (a PCM codec can faithfully transmit the analog signal waveform). The fax signal is converted to a packetized data
Gmux-2000 Ver. 4.0
2-33
stream which is transmitted through the link, and is reconverted to a clean fax signal at the other side. The selected voiceband codec is used for both fax and modem voiceband transmissions. Voiceband transmission per ITU-T Rec. V.152 this method is similar to the regular voiceband transmission method described above, except that the codec (payload) type is negotiated using the MEGACO/ITU-T Rec. H.248 protocol when the association needed to set up the call is established. This enables selecting optimum DSP processing parameters. The selected payload type is used for both fax and modem voiceband transmissions. When the voice channel traffic is expected to carry non-standard fax protocols or it is desired to ignore fax transmissions, the user can disable fax signal identification, in which case none of the specific methods listed above can be applied. A timeslot carrying a fax transmission is handled as an analog (voice) signal (this may prevent the transmission of fax signals, unless a PCM codec has been selected as the default codec).
Handling of Voiceband Modem Signals

VCA-T1/16 handle voiceband modem signals in a similar way to fax signals, using either regular voiceband signal transmission, or voiceband transmission per ITU-T Rec. V.152 (see description above), as selected by the user. Alternatively, the user can disable modem signal identification, in which case a timeslot carrying a modem transmission is handled as an analog (voice) signal (this may prevent the transmission of modem signals, unless a PCM codec has been selected as the default codec).
Handling of SS7 Signaling

The handling of SS7 signaling by VCA-T1/16 is enabled when its signaling gateway function is enabled (by entering the appropriate license key). The user can then configure the resources that will be made available for call control, which include: The maximum number of SCTP associations and the maximum number of SCTP instances (SCTP parameters sets) The parameters that effect transport capabilities: maximum number of transport IP addresses per association, and maximum number of SCTP streams that can be supported.
After determining the resources, specific SCTP associations can be configured. The VCA-T1/16 signaling gateway supports up to five signaling links, where each link can use its own set of SCTP parameters (called SCTP instance), and can be directed to a specific MGC. For each signaling link, it is necessary to configure the SS7 MTP Level 1 parameters (physical interface, that is, port and timeslot), and assign an M2UA interface identifier. In addition, the user can configure the SS7 MTP 2 parameters, which are used globally, for all the signaling traffic handled by the module.
2-34
Gmux-2000 Ver. 4.0
Since in general several ASPs can be active in an MGC, it is possible to configure the SCTP traffic mode that will be expected by a VCA-T1/16: Override The designated ASP handles all the traffic, overriding any currently active ASPs in the MGC (this is relevant to primary/backup operation). The other ASPs are therefore switched to the standby mode. Load sharing The designated ASP will share in the traffic distribution with any other currently active ASP in the MGC. Broadcast All of the active ASPs in the MGC will receive all the SCTP message traffic.
All the ASPs within a given MGC must use the same traffic mode.
2.3
Overview
Connection (Bundle) Handling
The Gmux-2000 can provide large numbers of simultaneous pseudowire connections through the packet-switched network. When using the TDMoIP version V2 (the current standard version), the rated Gmux-2000 maximum is 784 pseudowire connections to up to 256 remote destinations. In this manual, as well as on management screens, pseudowire connections are also referred to as bundles. Gmux-2000 supports two basic types of bundles: Bundles for transport of TDM traffic, using pseudowire emulation, supported by CT3-PW/1, T1-PW-SRV/28 and T1-PW/28 modules. the protocol used by each bundle can be selected in accordance with the type of traffic and application requirements: Transparent transfer of data (unframed T1 streams) can use TDMoPSN, or SAToPSN, or HDLCoPSN Transfer of framed T1 streams can use TDMoPSN or CESoPSN Fractional T1 services, with or without CAS (robbed-bit), are supported by means of TDMoPSN. Without CAS, CESoPSN can also be used HDLC traffic, in particular Frame Relay traffic, carried over framed and unframed T1, can use HDLCoPSN. Bundles for compressed voice traffic, supported by VCA-T1/16 and VCA-T1/12 modules.
Each bundle can be configured for operation over UDP/IP networks; for CES and SAToP bundles, Ethernet networks per MEF 8 are also supported.
Bundle Configurations Storage

Storing large numbers of bundle configurations has the advantage that a stored inactive bundle configuration can be rapidly switched to the active state by changing its administrative status. The maximum number of bundle (connection)
Gmux-2000 Ver. 4.0
2-35
configurations that may be defined on the Gmux-2000 is 2000, where each bundle is assigned a unique index number in the range of 1 to 2000. However, the maximum number of bundle configurations the Gmux-2000 can actually store depends on the type and number of modules installed in the chassis: CT3-PW/1, T1-PW-SRV/28 and T1-PW/28: 16 bundle configurations for each T1 port (internal or external), and a maximum of 112 bundle configurations per module VCA-T1/16, VCA-T1/12: 32 bundles per module.
Number of Active Connections (Bundles)

The maximum number of active connections depends on the maximum number of active bundles at the source module: CT3-PW/1, T1-PW-SRV/28, T1-PW/28: maximum 16 active bundles per T1 port, and up to 112 per module VCA-T1/16, VCA-T1/12: maximum 32 active bundles per module. The number of bundles per voice port depends on users requirements (each bundle can carry any number of timeslots, up to 30).
The maximum number of active connections at the Gmux-2000 level, which is determined by the bandwidth and switching capacity of the GbE module. With respect to bandwidth, a single GbE port is sufficient to carry the traffic load generated by the maximum possible number of active bundles, whereas Gmux-2000 supports a maximum of two active GbE links. Each PSN interface module has two GbE ports, which can be configured either as independent ports, or as a single aggregated link, or as redundant ports. Therefore, it is possible to split the traffic among the two ports in accordance with the specific application requirements and load balancing considerations (when two GbE or GbE/2 modules are installed, redundancy must always be enabled). For Gmux-2000 equipped with GbE modules, additional restrictions apply to the maximum number of active connections at the Gmux-2000 level, which is determined by the bandwidth and switching capacity of the GbE module (these restrictions are not relevant for GbE/2 modules). With respect to switching, it is necessary to consider the capabilities of the Layer 2/3/4 Gigabit Ethernet switch of the module, versus the resources consumed by each bundle: each UDP/IP bundle uses one pair of Layer 3 and 4 addresses (e.g., UDP socket and IP address) for each endpoint. An IP address can be associated with a number of different Layer 4 sockets.
Note
TDMoIP bundles using TDMoIP Version V1 requires two UDP ports per bundle.
Therefore, to perform bundle routing operations, the internal GbE Ethernet switch must store pairs of Layer 4 (UDP) sockets and IP addresses, which require memory space for storage. To enable efficient utilization of the memory space, the switch has a total of four Layer 4 socket pools, where each pool has a different size. In each pool, the user can specify the number of Layer 4 sockets per IP address, and the total number
2-36
Gmux-2000 Ver. 4.0
of IP addresses. By design, pool 1 supports the smallest number of UDP sockets per IP address, and pool 4 supports the largest number. The maximum number of entries in all of the four pools is 4096. When configuring the Layer 4 pools, take into consideration the following factors: Each connection to a remote destination requires one IP address, and therefore the total number of IP addresses determines the total number of remote connections that can be simultaneously supported by the Gmux-2000. The number of UDP sockets per IP address determines the maximum number of bundles to that destination. For TDMoIP Version V2, the number of bundles is equal to the number of UDP sockets, whereas for TDMoIP V1 the number of bundles is half the number of UDP sockets.
Table 2-1. Default GbE Module Layer 4 Pool Configuration, and Resulting Bundle Handling Capacity
Pool 1 2 3 4 Number of UDP Sockets per IP Address in Pool 2 8 16 200 Total for all Pools Number of Remote IP Addresses in Pool 300 138 72 6 516 Total V2 Bundle Capacity per Pool 600 1104 1152 1200 4056
For efficient utilization, it is recommended to apportion the total pool capacity so that pool 1 handles the required number of remote connections (IP addresses) with the smallest number of bundles per IP address, and so on, up to pool 4, which handles the required number of remote connections with many bundles per IP address. When the total number of bundles and destinations is not too large, the apportioning of the available capacity is not very critical, and the default values are a good starting point. In more complex applications, the apportioning should be made by trial-and-error, i.e., by starting each trial from some arbitrary selection of the number of bundles per IP address and improving the guess on each trial.
Bundle Configuration Parameters

The bundle (connection) parameters define the way payload will be transported from a local Gmux-2000 TDM port, through the packet-switched network, and down to a remote destination supporting the same capabilities. The parameters depend on the bundle type, which determines the type of traffic handled by the bundle (compressed voice, data and/or voice traffic, or HDLC traffic), and on the PSN type (UDP/IP or Ethernet).
Gmux-2000 Ver. 4.0
2-37
TDMoIP Bundle Parameters

The user can configure the following bundle parameters: Parameters needed by the packet processor to determine the bundle structure and its handling, for example: The type of protocol used to build the bundle: TDMoPSN, HDLCoPSN, CESoPSN or SAToPSN. This protocol must match the type of traffic to be carried by the bundle (see page 2-35). The packet structure required by the PSN: UDP/IP, Ethernet. The payload section size. The framing mode (which determines the signaling method), and the various out-of-service signaling codes. These parameters are implicitly determined when the associated internal T1 port is configured. The transported payload: selected timeslots, versus all the timeslots or the whole stream. Adaptive timing: when you enable adaptive timing for a bundle, you also implicitly specify that the bundle will serve as the timing reference for the T1 port at which the bundle is connected (a bundle can be connected to only one port). Jitter buffer size needed to compensate for the expected delay variation of the PSN. Timing parameters: enable/disable the adaptive clocking. Out-of-service signaling, and response to bundle out-of-service conditions. Parameters that ensure compatibility with the remote end users equipment, for example: The packet payload format (version V1 versus V2).
Note
Packet payload version V1 requires two UDP sockets per bundle, whereas packet payload V2 requires a single UDP socket per bundle. The larger number of UDP sockets per bundle needed by packet payload V1 reduces the maximum number of bundles to a given destination supported by Gmux-2000 equipped with GbE modules (see the Number of Active Connections (Bundles) section on page 2-36).
The far end interface type. The use of the OAM connectivity protocol, and the method used to identify OAM packets. Routing parameters: Layer 2 parameters: VLAN tagging according to IEEE 802.1Q When using Ethernet per MEF 8 (CES and SAToP only): destination MAC address of the bundle
2-38
Gmux-2000 Ver. 4.0
Note
The same VLAN ID must be used for all the bundles addressed to a given IP address.
Layer 3 parameters: Destination IP address of the bundle Static routing information: next hop IP address and the PSN port (one of the GbE or GbE/2 module ports) through which the bundle will be sent. Layer 4 parameters: the source and the destination circuit bundle identifier (CBID) for UDP/IP.
Note
Configuring an inbound label for each bundle is mandatory. When no outbound label is configured, the inbound label is also used as the outbound label.
Quality of service parameters: Layer 2: VLAN priority labeling according to IEEE 802.1p Layer 3: user-configurable ToS (Type of Service) for outgoing IP packets.
TDMoIP CV (Compressed Voice) Bundle Parameters

The user can configure, for each TDMoIP CV bundle, the following specific types of parameters: The parameters needed by the voice compression processor to determine the bundle structure and its handling, for example: The packet structure and specific header format (regular or RAD-proprietary): TDMoIP or TDMoIP+ for UDP/IP PSN The maximum frame size and maximum packetizing interval. The transported payload: selected timeslots versus all the timeslots, and timeslots to be transparently transferred by the bundle, in addition to the voice traffic. Routing parameters: Layer 2 parameters: VLAN tagging according to IEEE 802.1Q.
Note
The same VLAN ID must be used for all the bundles addressed to a given IP address.
Layer 3 parameters: Destination IP address of the bundle. Static routing information: next hop IP address and the PSN port (one of the GbE ports) or the voice compression module port and subchannel through which the bundle will be sent. Layer 4 parameters: the source and the destination circuit bundle identifiers (CBID) for UDP/IP.
Gmux-2000 Ver. 4.0
2-39
Quality of service parameters: Layer 2: VLAN priority labeling according to IEEE 802.1p. Layer 3: user-configurable ToS (Type of Service) for the outgoing IP packets. Connectivity checking packet rate and time-out parameters Voice processing parameters: Coder type and rate Caller ID parameters (optional) Nominal audio input and output levels Fax and modem signal processing parameters: Fax and modem operation modes Voiceband signal coding method and rate Supported fax rates Maximum accepted number of modem calls Time required to detect a 1100 or 2200 Hz tone before switching to fax or modem mode Multifrequency signaling mode and processing parameters Custom tone detection parameters Use of super-tandem mode Use of echo cancelling Bundle voice coding parameters Voice activity detection parameters Jitter buffer size for transparent timeslots.
2.4

Redundancy (APS) Functions
Gmux-2000 provides protection for the following subsystems: SONET network interface subsystem PSN interface subsystem User interface subsystem (pseudowire emulation modules, and voice compression modules) Pseudowire bundle redundancy.
The following sections present the redundancy options for each type of connections.
2-40
Gmux-2000 Ver. 4.0
Redundancy for SONET Network Connections

Gmux-2000 supports 1+1 unidirectional (line) protection with APS per ITU-T Rec. G.783 for the links to the SONET network.
Overview of SONET Network Interfaces

Redundancy can be used when installing additional ports with bandwidth exceeding that required for carrying the maximum traffic. The Gmux-2000 payload reaches the SONET interface module (OC3) via telecom buses, where each telecom bus has a capacity of one OC-3 stream, and its payload can be independently mapped. The current Gmux-2000 version supports two telecom buses, designated A and B. Only one OC-3 port can be connected to each telecom bus, in accordance with the following fixed assignment: Port 1 of a SONET interface module (irrespective of the I/O slot, 7 or 9, in which the module is installed) is always connected to telecom bus A Port 2 of a SONET interface module is always connected to telecom bus B.
Considering the number of telecom buses, the maximum number of OC-3 ports that can be active at any time in the Gmux-2000 chassis is two (one on each telecom bus). This provides the following options: When one OC3 module is installed in the chassis, each port configured as connected provides a bandwidth of one OC-3. Therefore, when both ports are connected, the module provides a bandwidth of two OC-3 without redundancy. When the required bandwidth is only one OC-3, redundancy can be enabled when both ports can be connected to the SONET network via independent links. When two OC3 modules are installed in the chassis, redundancy must be enabled, because the total bandwidth cannot exceed two OC-3.
Redundancy is activated by configuring APS groups using 1+1 unidirectional protection. Considering the options described above, the supported APS configurations are as follows: When one OC3 module is installed in the chassis: one APS group including the two ports of the OC3 module When two OC3 modules are installed in the chassis: two APS groups, one for each pair of similarly named ports. Therefore, one APS group includes the LINK 1 ports of the OC3 modules, and the other APS group includes the LINK 2 ports.
Note that when redundancy is used, only one mapping is required for each telecom bus, because the ports connected to that bus must have identical configurations for line redundancy to work. The mapping can be configured only on the primary port of an APS group (actually, the secondary port cannot be included in an APS group before its mapping is deleted). Link capacity, mapping, and redundancy options are summarized in Table 2-2.
Gmux-2000 Ver. 4.0
2-41
Table 2-2. Summary of Mapping, Link Capacity, and Redundancy Options for SONET Interfaces
Number of OC3 Modules 1 1 Telecom Buses Served by Module Telecom Buses Served by Module Link Capacity and in Slot I/O 7 in Slot I/O 9 Redundancy Options Port 1 Port 2 Port 1 Port 2 Telecom Bus A Telecom Bus B Telecom Bus A Telecom Bus B 2 OC-3, no redundancy 1 OC-3 with redundancy (one APS group) 2 OC-3, with redundancy (two APS groups: one for ports 1, one for ports 2)
Telecom Bus A
Telecom Bus B
Telecom Bus A
Telecom Bus B
Operation of 1+1 Unidirectional Protection Function

Figure 2-13 illustrates the operation of the 1+1 unidirectional protection function
on a Gmux-2000 using a single OC3 module. 1+1 unidirectional protection works as follows: Both the working and protection ports of an APS group simultaneously transmit the same data toward the remote end, via two different paths. At each side, the signal received by each port of an APS group is evaluated in accordance with the alarm weighting criteria specified in ITU-T Rec. G.707, to determine the best signal (the signal with the lowest total alarm weight). The results of this evaluation are used to select the receive signal actually connected to the corresponding telecom bus (these tasks are performed by a processing function identified as an internal protection switch).
Figure 2-13.A shows the normal operating conditions, under which the signal received through the working port is selected for processing.
When a fault occurs, protection switching takes place. For example, Figure 2-13.B shows the change in case the working signal path ending at the LINK 1 port of the West Gmux-2000 fails: the received signal is now taken from LINK 2. Note that the same action would be taken in response to any problem along this path (fault at location A, fault at location B, transmit failure at the East LINK 1 port, or receive failure at the West LINK 1 port).
2-42
Gmux-2000 Ver. 4.0
A. Normal Operation
B. Operation after Protection Switching due to Fault in Path to one Port Figure 2-13. Operation of 1+1 Unidirectional Protection Function
The basic 1+1 unidirectional protection configuration shown in Figure 2-13 protects against failures on the transmission path through the SONET network, but the protection against failures on the OC3 module is very limited (only failures in the link interface are corrected). To enhance the protection to cover the whole module, the configuration can be extended to a dual-link configuration, by installing two OC3 modules at each side. In this case, protection switching replaces a port on the working module with the corresponding port on the protection module (in the example given above, a fault in the path ending at LINK 1 of one OC3 module would switch the traffic to LINK 1 of the second OC3 module). In the same way, a hardware failure in one OC3, or a break in the optical cable connecting to an OC3, would switch the traffic to the other module.
Gmux-2000 Ver. 4.0
2-43
With 1+1 unidirectional protection, each side independently selects the best signal (in Figure 2-13.B, no change occurred at the East Gmux-2000), and therefore no protocol is needed to coordinate protection switching with the remote side. For example, in Figure 2-13.B, the East side would also switch to the protection port (LINK 2) if the West side problem is a break in both fibers connected to the West LINK 1 port. The alarm criteria taken into consideration for protection switching are as follows (listed in decreasing weight order): The module with the other port in the APS group is not installed. Forced-flip command. Critical alarm. A critical alarm is caused by the detection of one or more of the following fault conditions: loss of SONET line signal, reception of AIS signal on the line, loss of SONET frame, or clock failure. Major alarm. A major alarm is caused by EED (excessive error degradation). The EED threshold can be selected by the user. Minor alarm. A minor alarm is caused by an SD (signal degraded) condition, where the threshold can be selected by the user. However, the user can configure APS parameters to ignore the SD criterion. Revert request (only when the revertive recovery mode is selected).
The working port always carries the traffic, as long as its total alarm weight does not exceed that of the protection. The user can however force switching (flipping) to the other port by a manual flip command: such command is always executed, except when the other port in the APS group by a manual command, except when it is located on a module not installed in the chassis. The two ports in an APS group can be assigned priorities: Gmux-2000 will generate alarm messages to notify managers (supervision terminal, Telnet hosts, management stations, etc.) that protection switching from the high priority port to the low priority port, or vice versa, occurred. The recovery mode after a protection switching can be selected in accordance with the application requirements: Non-revertive mode the OC3 module will not automatically flip back after the failed port returns to normal operation, but only when the currently used port fails (that is, when its alarm weight exceeds that of the standby port). However, as explained above, the user can always initiate flipping back by a manual flip command. Revertive mode the OC3 module will flip back to the original port when it returns to normal operation (that is, its alarm weight is equal to, or lower than, that of the currently active port).
To prevent switching under marginal conditions, the user can specify a restoration time, which is the minimum interval before flipping back to the original port. During the restoration time, alarms are ignored. As a result, the module starts evaluating the criteria for protection switching (flipping) only after the restoration time expires, thereby ensuring that another flip cannot occur before the specified time expires.
2-44
Gmux-2000 Ver. 4.0
1+1 Bidirectional and 1+1 Bidirectional Optimized Protection Schemes

Channelized OC-3 modules also support 1+1 bidirectional and 1+1 bidirectional optimized traffic protection. The 1+1 bidirectional APS functionality is implemented in accordance to the ITU-T G.841 (Chapter 7) requirements; 1+1 bidirectional optimized APS is implemented in accordance to the ITU-T G.841 (Annex B) requirements. They are similar to the 1+1 unidirectional APS, but switchover of the failed Rx patch is performed after negotiation with the opposite Gmux-2000. The opposite system must approve the switchover, even if the failure occurred at one end only. Figure 2-14 illustrates operation after protection switching due to fault in path to one port of the West Gmux-2000. Note that the switchover is performed at the West and at the East sides. Negotiation between the two systems during APS process is performed using standard K1 and K2 bits. The bits carry indications of failures, switch requests, clear to switch, wait to restore time expiration and other APS-relevant conditions.
Figure 2-14. Operation of 1+1 Bidirectional Protection Function

The alarm criteria taken into consideration for protection switching and the recovery mode configuration are the same as in the 1+1 unidirectional APS.
Redundancy for PSN Interface

The maximum total bandwidth of the Gmux-2000 connections to the PSN is 2 Gbps (2 GbE links). In most applications, this bandwidth exceeds the bandwidth needed for the traffic that can be generated by the chassis, and therefore redundancy can be used to increase availability. When a single PSN interface module is installed in the Gmux-2000, the two external ports of a PSN interface module can be configured to operate either independently, as two separate PSN interfaces, or used as a single PSN interface with line redundancy, using link aggregation mode in accordance with IEEE 802.3ad (without LACP), with load sharing. This mode inherently provides
Gmux-2000 Ver. 4.0
2-45
redundancy: if one of the GbE ports fails, the other can continue transferring traffic, albeit at half the bandwidth available when both ports are up. Link aggregation always provides revertive recovery, because that as soon as the down port returns to normal, the full bandwidth is again available. Link aggregation is configured by defining an LAG (Link Aggregation Group) on the GbE ports. When two PSN interface modules are installed in the Gmux-2000, the redundancy protection can be extended to include module hardware. This capability is achieved by configuring link aggregation per IEEE 802.3ad between ports on different modules.
Note
Redundancy partners use a common IP address, which can be configured only on the primary port.
Two ports of the same GbE or Gmux-2000 module, or two ports on different Gmux-2000 modules, can be operated as a single PSN interface, using link aggregation in accordance with IEEE 802.3ad without LACP (Link Aggregation Control Protocol). The two ports must connect to the same switch/router (see for example, Figure 2-15). Link aggregation is configured by defining an APS group. The APS group must include exactly two Gmux-2000 ports. The supported APS group configurations are as follows: One GbE or Gmux-2000 module: one APS group including the two module ports. This is the configuration shown in Figure 2-15 Two Gmux-2000 modules: in addition to the option of configuring an APS group on each Gmux-2000 module, it is also possible to configure APS groups for ports on different modules. In this case, either one or two APS groups can be defined (one group for each pair of similarly named ports): one APS group includes ports 1 of the two Gmux-2000 modules, and the other APS group includes the ports 2. A typical configuration for this case, which yields the maximum number of aggregated interfaces per Gmux-2000, is shown in Figure 2-16.
With link aggregation, the two GbE ports serve as a single logical interface with twice the bandwidth of one port. The aggregated interface is assigned a single MAC address, and a single IP address.
Gmux-2000 Gmux-2000 Port 1 Port 2 GbE/2 Module Port 1 Port 2 GbE/2 Module
Figure 2-15. Link Aggregation Application Single GbE or GbE/2 Module
2-46
Gmux-2000 Ver. 4.0
Network 1 Gmux-2000 Gmux-2000
Port 1 Port 2 PW Packet Buses GbE/2 Modules GbE/2 Modules PW
Network 2
Figure 2-16. Link Aggregation Application Gmux-2000 with Two GbE/2 Modules
Using link aggregation inherently provides redundancy, because when one of the GbE ports fails, the other can continue transferring traffic, albeit at half the bandwidth available when both ports are up. Therefore, link aggregation per IEEE 802.3ad has inherent APS (Automatic Protection Switching) characteristics. When the ports participating in the link aggregation are located on different modules (Figure 2-16), redundancy protection is extended to include hardware redundancy: service is available even when one Gmux-2000 module fails or is temporarily removed. Failure of one the links is detected by sensing the loss of valid signals at a port, in which case the whole traffic is sent through the remaining port (the switching time is less than a second). Link aggregation always provides revertive recovery, because that as soon as the down port returns to normal, the full bandwidth is again available.
Note
Although under link aggregation the two module ports have identical properties, it is necessary to arbitrarily select one port (the first port configured as part of link aggregation) as the primary port: all the bundles using this module as their network port must point to the primary port.
The equipment connected to the GbE ports must use compatible switching criteria for redundancy to be available: For networks using Layer 2 switching: the criterion is signal loss For networks using Layer 3 routing: the router must support IEEE 802.3ad or other link aggregation protocol that views the aggregated link as a single logical interface.
Gmux-2000 Ver. 4.0
2-47
1:N Protection Mode

Gmux-2000 supports 1:N protection (an APS function) for I/O modules installed in the chassis. The 1:N protection function is managed by the Gmux-2000 control subsystem, and operates independently of the other Gmux-2000 APS capabilities. The current Gmux-2000 version has the following capabilities: A Gmux-2000 unit always supports the 1:N protection mode for I/O modules with internal ports (that is, pseudowire emulation server modules and voice compression modules operating with internal ports only), because for such modules all the necessary rerouting is made internally, within the Gmux-2000 chassis. To add support for the 1:N protection mode for I/O modules with external ports (that is, pseudowire emulation modules with external ports and voice compression modules operating with external ports), it is necessary to use the NPS-101 1:N protection switching device, available for RAD (see NPS-101 Installation and Operation Manual for details).
An 1:N protection group is formed by adding a spare (standby, or protection) module to a group of N modules that carry the traffic (the protected modules). All the N+1 modules must be of the same type. Only one 1:N protection group can be configured in the chassis.
1:N Protection for I/O Modules with Internal Ports

1:N protection for I/O modules with internal ports operates as follows: When all of the N traffic-carrying (protected) I/O modules operate normally, the protection module is idle. When any one of the N traffic carrying modules reports a malfunction, the malfunctioning module is automatically replaced by the protection module, thereby restoring the original traffic capacity. The process used to replace a protected module by the protection module is as follows: The Gmux-2000 control subsystem automatically downloads the configuration of the malfunctioning module to the protection module. Therefore, no configuration data should be prepared by the user for the protection module. The Gmux-2000 control subsystem updates the internal traffic flow configuration within the chassis: At the telecom buses side: the malfunctioning module is disconnected from the telecom buses, and the protection module is connected in accordance with the downloaded configuration. Therefore, no change in SONET link mapping takes place At the packet buses side: the Fast Ethernet buses of the malfunctioning module are disconnected from the GbE module(s), and those of the protection module are connected in accordance with the downloaded configuration. Therefore, only the internal packet routing is affected: no change is visible from the outside
2-48
Gmux-2000 Ver. 4.0
The whole process may require up to 30 seconds, after which service is completely restored. To provide differential quality of service, it is possible to define two protection priority levels, low and high: in the event that protection is required for two modules at the same time, only the high priority module will be protected. The need for protection switching (flipping) is evaluated in accordance with the following criteria, arranged below in decreasing order of severity: 1. Module removed from chassis. 2. Hardware failure. 3. Users flip command (a diagnostic function for APS groups). 4. Priority flip. 5. Link failure. Therefore, when more than one module need protection at the same time, the protection will be activated only for the module with the more severe criteria, while still observing the user-defined protection priorities. Therefore, separate severity evaluations are made for each protection priority, to select the protected module with the highest severity score, yet a low priority module will get protected only when no protection is needed by a high priority module. After the protected malfunctioning module is replaced, and is again ready for service, there are two possibilities: If the user selected the revertive recovery mode, when the replaced protected module returns to normal operation after a protection flip, the reverse process automatically takes place. Therefore, the protected module is returned to service, and the protection module is again idle and ready to protect any other malfunctioning module in the group. To ensure a minimum interval before flipping back, the user can specify the time to wait before restore. If the user selected the non-revertive recovery mode, after a protection flip the protection module continues carrying the traffic even if the protected module replaced by it returns to normal operation. The protection module will stop carrying the traffic only shen a manual forceflip command is received. This returns the protected module to service, and the protection module is again idle and ready to protect any other malfunctioning module in the group. Note that irrespective of the selected recovery mode, when a malfunction occurs in a module with a higher priority, the protection module is switched to protect the other module, even if the originally replaced module has not yet returned to normal service.
1:N Protection for I/O Modules with External Ports

Figure 2-17 shows a system using an NPS-101 to protect traffic carried by I/O
modules with external ports (in this example, T1-PW/28 modules).
Gmux-2000 Ver. 4.0
2-49
Figure 2-17. Using the NPS-101 to Protect Traffic Carried by I/O Modules
In Figure 2-17, Gmux-2000 is equipped with the maximum number of T1-PW/28 I/O modules, which is 7 (this assumes a packet application, with two GbE or GbE/2 modules installed for redundancy, but without any OC3 module). Out of these T1-PW/28 modules, six are the protected I/O modules, configured to carry traffic, and the last one is assigned as backup (1:6 redundancy). The six protected I/O modules connect to NPS-62 protection switching modules in the NPS-101, and the backup I/O module is connected to the BU-62 backup module in the NPS-101. 1:N protection for I/O modules with external ports operates as follows: Normally, the NPS-62 modules in NPS-101 connect the external ports of each protected I/O module to the corresponding users equipment unit, and the backup I/O module is idle and disconnected. When a protected I/O module fails, Gmux-2000 control subsystem downloads the configuration of the replaced I/O module to the backup I/O module, redirects the internal signal routing to the backup module, and then commands the attached NPS-101 to redirect the traffic from the ports of the protected module to the ports of the backup module, thereby restoring the original traffic capacity. The process used to replace a protected module by the protection module is as follows: The Gmux-2000 control subsystem automatically downloads the configuration of the malfunctioning I/O module to the protection module.
2-50
Gmux-2000 Ver. 4.0
Therefore, no configuration data should be prepared by the user for the protection module. The Gmux-2000 control subsystem updates the required configuration data, and the internal and external traffic flow: At the external port sides, the NPS-62 module disconnects the T1 ports of the malfunctioning module from the users equipment, and the T1 ports of the protection module are connected in accordance with the downloaded configuration. Therefore, no change takes place from the point of view of users equipment. At the packet buses side: the Fast Ethernet buses of the malfunctioning Gmux-2000 module are disconnected from the GbE or GbE/2 module(s), and those of the protection Gmux-2000 module are connected in accordance with the downloaded configuration. Therefore, only the internal packet routing is affected: no change is visible from the outside. The whole process may require up to 30 seconds, after which service is completely restored. When using the revertive recovery mode, after the malfunctioning I/O module is replaced, and is again ready for service, the reverse process automatically takes place, with the result that the protected module is returned to service, and the protection module is again idle and ready to protect any other malfunctioning module in the group.
Pseudowire Redundancy
Gmux-2000 features a bundle redundancy capability. This feature enables the user to backup the pseudowire traffic in case of fault at the bundle connection level. This feature permits the user to set a different path for the primary bundle and for the secondary bundle (different packet-switched networks, different links, different TDM pseudowire gateways, etc) and thus rely on two routes, which are not influenced by the same faulty PSN conditions. Both bundles can be routed to the same or different destinations, as illustrated below.
Figure 2-18. Bundle Redundancy Application (A)
Figure 2-19. Bundle Redundancy Application (B)
Gmux-2000 Ver. 4.0
2-51
Redundant PW bundles operate in the 1+1 mode: both the primary and secondary bundles transmit pseudowire traffic, but only the active bundle receives pseudowire traffic, while the redundant bundle ignores the Rx path. This mode results in minimum recovery time between the bundles whenever switch/flip occurs, but on the other hand increases the total throughput.
2.5
Timing Subsystem
Gmux-2000 timing subsystem consists of up to three independent but interconnected sections, identified in Figure 2-20: PDH timing section: generates the transmit timing signals needed by the PDH (T1) ports of each I/O module installed in the chassis. Actually, each I/O module with PDH ports has its own timing subsystem. SONET timing section: generates the transmit timing signals needed by the SONET (OC-3) ports of each SONET interface module installed in the chassis. System timing section: generates a common system-wide (nodal) timing reference that can be used by all the modules installed in the chassis. This nodal timing signal can be locked to a variety of sources, including external (station) clocks.
Redundancy is used to ensure reliable timing. Therefore, each subsystem can provide two timing references, one configured as the master (higher priority) and the other as the fallback (lower priority) reference.
PDH Timing Receive (LBT) Clocks from T1 Ports Adaptive Receive Clocks from Bundles SONET Timing Transmit Clocks to SONET Ports Transmit Clocks to T1 Ports SONET Subsystem Timing Generator Receive (LBT) Clocks from SONET Ports
T1 Ports Timing Generator (PDH Subsystem)
Fallback
System Timing System B Master Fallback Input Output System A (Nodal) Timing Generator
STATION
System Clock
Internal Clock
Figure 2-20. Gmux-2000 Timing Subsystems

The implementation of the Gmux-2000 timing subsystem is shown in Figure 2-21. This figure shows the functional block diagram of the Gmux-2000 timing subsystem, located on the CONTROL module.
2-52
Timing Subsystem
Fallback
Master
Master
Gmux-2000 Ver. 4.0
Receive Clocks from I/O Modules
Master Fallback Master Fallback Reference Clock Selector Master Fallback Nodal Clock Generator Frame Sync Transmit Frame Sync
Receive Clocks from SONET Timing
Internal Clock
T1 Transmit T1 Clock (1.544 MHz) Clock (Nodal Clock Supplied to all T1 Cards)
STATION
Input Output
Station Clock Interface
Figure 2-21. Gmux-2000 Timing Subsystem, Functional Block Diagram
Output Timing Signals

The purpose of the timing subsystem is to generate stable timing signals needed by the various Gmux-2000 subsystems, all locked to one of the reference signals selected by the user. The timing signals generated by the subsystem are as follows: Nodal clock. The nodal clock is the source from which all the timing signals needed by the Gmux-2000 circuits are derived. Its nominal frequency is normally 1.544 MHz, however the user can also select 1.544 Mbps. T1 transmit clock. This signal has a frequency of 1.544 MHz and is made available to the transmit paths of the T1 ports (when the T1 ports are configured to use the system clock as their timing reference). Transmit frame sync signal. This signal has a frequency of 8 kHz and is made available to the transmit paths of the T1 and SONET ports.
Timing Reference Sources

Internal Reference Signals
The Gmux-2000 timing subsystem can use as reference the following types of internal signals, all derived from the receive paths of the various I/O modules installed in the chassis (see descriptions in the installation and operation manuals of the relevant interface modules): 1.544 MHz clock signal from a selected T1 port. The source of this signal may be selected from the following options: Clock signal recovered from an external T1 line signal of a pseudowire emulation module or voice compression module Clock signal recovered from an internal T1 port of a pseudowire emulation server module Clock signal recovered from a selected bundle by the adaptive timing recovery mechanism of a packet processor on a pseudowire emulation module
Gmux-2000 Ver. 4.0
Timing Subsystem
2-53
Timing reference signal from a selected SONET port.
The various reference signals are received via the Gmux-2000 timing bus. Each type of signal is received on two different lines, one designated as master source and the other as fallback. To ensure that a Gmux-2000 always has the best possible timing accuracy at all times, when all the configured sources (master and fallback) fail the timing subsystem enters the holdover mode. In the holdover mode, the timing subsystem maintains the internal reference frequency at the last value acquired before the failure. This situation persists until at least one of the configured reference source returns to normal, and thus is selected again. Control signals from the CONTROL module ensure that at any time only one module applies a signal on each timing bus line.
External Reference Signals

The Gmux-2000 timing subsystem can also use as reference a 1.544 Mbps or 1.544 MHz signal received from an external (station) source (2.048 MHz or 2.048 Mbps sources can also be used).
Internal Oscillator
The free-running internal Gmux-2000 oscillator can also be used as reference source.
Note
When the Gmux-2000 is turned on and no other reference sources are yet configured (factory defaults), or none of the configured sources is available, the internal source is automatically selected.
Considering the accuracy of the internal source, it is recommended to use it only when no other reference sources are available, for example, during maintenance activities on a Gmux-2000 unit, and also in stand-alone networks that are not connected to a backbone (connecting a Gmux-2000 to a backbone would enable using the network timing as nodal timing reference). In a stand-alone network, one Gmux-2000 unit, selected as the timing master of the network, uses its internal oscillator as master source, and all the other equipment units lock their timing to that Gmux-2000.
External Clock Interface

The external clock interface has two functions: Input for external (station) clock signal Output for the Gmux-2000 nodal clock. This output provides a convenient means for distributing the Gmux-2000 nodal clock signal to other equipment.
The interface characteristics are selected by the user: Nominal clock frequency: 1.544 MHz or 1.544 Mbps (however, a 2.048 MHz or 2.048 mbos source can also be used) Signal characteristics: AMI signal at ITU-T Rec. G.703 levels, or squarewave at RS-485 levels.
2-54
Timing Subsystem
Gmux-2000 Ver. 4.0
The interface has two sets of connectors: RJ-45 connector, is always used when the interface uses RS-485 levels. This connector is also used when the ITU-T Rec. G.703 balanced (120) interface is selected. Two BNC connectors, one serving an input and the other as output when the ITU-T Rec. G.703 unbalanced (75) interface is selected.
The selection between the balanced and unbalanced ITU-T Rec. G.703 interfaces is made by jumpers located on the CONTROL card.
Timing Subsystem Redundancy

When the Gmux-2000 is equipped with two CONTROL modules, two timing subsystems are actually available in the Gmux-2000, one on each CONTROL module. In this case, only one timing subsystem is active: that located on the CONTROL module serving as primary. The other timing subsystem, located on the slave CONTROL module, serves as a hot standby and is synchronized to the primary timing subsystem but does not supply any signals to the other Gmux-2000 circuits. When the slave CONTROL module becomes master, its timing subsystem also becomes primary. Note however that CONTROL module flipping can occur as a result of one of several causes: Management command Automatic switching in case a malfunction has been detected in the primary CONTROL module Automatic switching in case a malfunction has been detected in the timing subsystem of the primary CONTROL card Removal of the primary CONTROL module. This is the only cause that may disrupt the supply of stable timing signals, as it takes a few tens of milliseconds for the other timing subsystem to detect the event. Therefore, before the primary CONTROL module is removed from its slot, it is highly recommended to first force flipping to the slave module by management commands.
When using redundant CONTROL modules, only one of the two station clock interfaces must be connected to a station clock source. However, for best protection, it is recommended to connect the two station clock interfaces to two separate station clock sources. When only one station clock source is available, you can have better hardware protection by connecting the station clock inputs in parallel, by means of a simple Y-cable. In this case, configure the CONTROL module to use a Y-cable: this configuration ensures that at any time only one station clock interface (that of the active module) is active. The same arrangements are also effective with respect to the nodal clock outputs.
Gmux-2000 Ver. 4.0
Timing Subsystem
2-55
2.6
Ethernet Service OAM (IEEE 802.1ag, ITU-T Y.1731)
Ethernet Service OAM is a set of functions for managing Ethernet services as specified by the IEEE 802.1ag and ITU-T Y.1731 standards. It allows service providers to operate, administer, and maintain Ethernet services. The Connectivity Fault Management (CFM) uses an end-to-end Ethernet layer OAM protocol for proactive connectivity monitoring, fault verification, and fault isolation. These actions are performed using IEEE 802.1ag standard Layer 2 ping, Layer 2 traceroute, and end-to-end connectivity check of Ethernet networks.
Maintenance Domains
Ethernet service OAM defines a hierarchy of up to eight OAM levels or maintenance domains (MDs), allowing users, service providers and operators to run independent OAMs at their own level. By default, users are allocated three levels, service providers two levels, and operators three levels. OAM frames belonging to higher levels are transparently forwarded by lower level devices (e.g. user OAM frames are forwarded by service provider switches). Larger domains are assigned higher levels.
Maintenance Entities
Y.1731 defines a maintenance entity (ME) that requires management. Some examples of these entities are the entire Ethernet network between two customer switches, or the Ethernet network in the administrative domain of a single service provider, or even a single Ethernet link. Thus MEs can be nested, with link MEs internal to service provider, and MEs of successive providers internal to the customer end-to-end ME. In order to capture the multipoint-to-multipoint nature of Ethernet, MEs are grouped into ME groups (MEGs, referred to as Maintenance Associations or MAs in IEEE language). A multipoint-to-multipoint Ethernet network with N end-points has N (N-1)/2 MEs, while a point-to-point connection has only one. In order to enable detection of incorrect connectivity, each MEG is given a unique ID, and OAM messages specify the MEG ID for which the message is intended.
MEG Endpoints
At the ends of managed entities we find MEG End Points (MEPs), which are the functions that generate and process OAM frames to monitor and maintain the ME. There may also be MEG Intermediate Points (MIPs) that can respond to OAM messages, but cannot originate them. For point-to-point MEGs, a MEP has a single peer MEP, but in between there may be many MIPs. Hence a MEP can send CC messages to its peer MEP, or direct non-intrusive LB messages towards the peer MEP or to any MIP. It is the responsibility of the MEP to prevent OAM messages from leaking out of the administrative domain to which they belong, or entering another domain. However, MEPs transparently pass OAM frames from
2-56
Gmux-2000 Ver. 4.0
other domains when they belong to a higher OAM level, thus enabling end-to-end management of customer connectivity (see Figure 2-22).
Figure 2-22. Service OAM MEPs and MIPs
Connectivity Fault Management Protocols

Ethernet CFM comprises three protocols that work together to help administrators debug Ethernet networks. These are: continuity check, link trace and loopback protocols. Continuity Check "heartbeat" messages issued periodically by maintenance endpoints. They allow maintenance endpoints to detect loss of service connectivity amongst themselves. They also allow maintenance endpoints to discover other maintenance endpoints within a domain, and allow maintenance intermediate points to discover maintenance endpoints. Once enabled, a MEP sends a CC messages periodically at one of the following transmission periods: 100 msec, 1 sec, 10 sec, 1 min, 10 min. MIPs transfer CC messages transparently. In addition to detecting loss of continuity, CC messages also perform various other defect and performance monitoring activities, such as the discovery of other MEPs (by sending a CC to a multicast address), detection of unwanted connectivity between MEPs, and RDI.
Gmux-2000 Ver. 4.0
2-57
Link Trace messages are transmitted by a maintenance endpoint on the request of the administrator to track the path (hop-by-hop) to a destination maintenance endpoint. They allow the transmitting node to discover vital connectivity data about the path. Link trace is similar in concept to UDP traceroute. Loopback Messages are transmitted by an MEP upon demand by the administrator to verify bidirectional connectivity to a particular MIP or MEP. Similar to ping messages, LBs are sent upon demand and thus may be sent once, repetitively, or according to any other scheme dictated by the initiator. LB messages can be unicast to the MAC address of the desired entity, or multicast to all peer MEPs in the MEG. The unicast version infers connectivity by timely receipt of an LB response message, while the multicast version produces a list of MEPs with which connectivity was detected. LB messages may optionally carry test patterns, the length and content of which may be configured according to need.
2.7
Functional Block Diagram

Figure 2-23 shows the functional block diagram of the Gmux-2000 management subsystem, located on the CONTROL module. The alarm interfacing circuits are located on the ALARM card (part of the chassis).
Control Buses to All Cards To CLOCK Card To Alarm Card
CONTROL Card
CONTROL DCE Serial Port Interface Management Subsystem CONTROL ETH Ethernet Interface
Figure 2-23. Management Subsystem Functional Block Diagram
CONTROL Module Management Subsystem

The main functions of the management subsystem located on the CONTROL module are as follows: Interfacing with external management and monitoring functions. The following options are available: Supervision terminal: ASCII terminal or a PC running a terminal emulation program, connected either directly to the Gmux-2000, or through a
2-58
Gmux-2000 Ver. 4.0
modem or any other type of full-duplex data link. This terminal can perform all the Gmux-2000 supervision and configuration functions, and in particular the preliminary system configuration. Telnet: by means of any host capable of IP communication with Gmux-2000. The functions available under the Telnet protocol are similar to those available from a supervisory terminal. SSH: secure access using the SSH (Secure Shell) protocol, using any standard SSH client utility running on a PC or laptop capable of IP communication with Gmux-2000. SNMP: the Gmux-2000 includes an internal SNMP agent that enables full SNMP management by SNMP-based network management, for example, the RADview family of management stations for element and network management available from RAD, which are supplemented by dedicated RADview-SC/TDMoIP and RADview-SC/Vmux Service Centers, which enable efficient and effective management of TDMoIP and voice compression services. syslog: Gmux-2000 supports automatic event notification to user-specified syslog servers in accordance with the syslog protocol per RFC3164. Gmux-2000 can report all the supported traps and alarms, but also enables configuring the minimal severity level for reporting to each syslog server. To protect network operations against unauthorized access, Gmux-2000 supports a wide range of security features for every management facility: RADIUS authentication for supervision terminal and Telnet access, SSH for secure Telnet access, and SNMP management with authentication and privacy per SNMPv3 using selectable security models, with continued support for SNMPv1. Control of Gmux-2000 system operation. Storage of application software, which determines the capabilities and features provided by the Gmux-2000. This software can be remotely downloaded and updated through the management link without taking the equipment off-line. The stored software includes both system software, run by the CONTROL module, and software for the other modules installed in the chassis. Storage of configuration databases. The configuration databases can also be uploaded and downloaded through the management link. Collection of operational history (alarms, performance statistics, etc.), and of internal chassis temperature, as read by an internal temperature sensor. The collected information can be read by maintenance personnel through the management link. A real-time clock provides time stamps for all the collected information. The real-time clock can be set either manually or automatically, using the NTP (Network Time Protocol). A network operator can use NTP to periodically synchronize the local equipment time within the managed network to the accurate time provided by the worldwide network of NTP time servers, and thus is able to reliably correlate alarm reports from different sources. To use
Gmux-2000 Ver. 4.0
2-59
NTP, it is necessary to configure the IP address of the desired NTP server, and select a time zone. The performance statistics collected for the modules installed in the chassis are also synchronized to the real-time clock. The application software, as well as the configuration databases, are stored on a flash disk. The Gmux-2000 software includes file utilities that enable access to the flash disk file system: this provides powerful and efficient management capabilities, as it allows copying, deleting, and renaming the files located on the flash disk.
Ethernet Connections to CONTROL Modules

The CONTROL module has an internal Layer 2 Ethernet switch that serves management communications. This switch has the following access ports: Two Fast Ethernet ports that connect through the management bus to the GbE module. These ports provide management access to the Gmux-2000 management subsystem from the packet-switched network side. An internal port for the local management subsystem. External 10BASE-T/100BASE-TX Ethernet interface terminated in the CONTROL ETH RJ-45 connector. This interface supports MDI/MDIX crossover and therefore the port can always be connected through a straight (point-to-point) cable to any other type of 10/100BASE-T Ethernet port (hub or station).
A separate set of control buses carries the internal management traffic to the I/O modules installed in the chassis.
Caution The Gmux-2000 internal management traffic uses VLANs for identification and
internal routing. The VLAN IDs used for internal management traffic are 101, 102, and 103. Therefore, the VLAN IDs 101, 102, and 103 must be reserved, and must not be allocated to traffic reaching Gmux-2000 ports, as this may lead to unpredictable results.
Serial Port Connections

The supervisory port of the Gmux-2000 has a serial RS-232 asynchronous DCE interface terminated in a 9-pin D-type female connector, designated CONTROL DCE. This port can be directly connected to terminals using a cable wired point-to-point. A cross cable is required to use the DTE mode, for example, for connection through modems or digital multiplexer channels.
CONTROL Module Redundancy

When a second CONTROL module is installed, the two modules operate as a master/slave pair; one module is the active (master) module, and the other serves as a hot standby (slave).
2-60
Gmux-2000 Ver. 4.0
Only the master module communicates with the management station/terminal and actively manages the Gmux-2000 system. The slave module is automatically updated by the master module with all the configuration and status data, and therefore the slave can take over at any time without disrupting system operation. The slave module communicates only with the master module. Moreover, the transmit line in the slave serial port connectors is disabled, to enable physical connection in parallel (e.g., by means of a Y cable) to the supervision terminal or to a modem.
External Alarm Interfaces

The Gmux-2000 chassis includes a connector for reporting chassis alarms to external equipment (buzzers, dialers, etc.) by means of dry-contacts, for example, you can activate a bay alarm, dial out to report the alarm, etc. The connector also has an external alarm input for monitoring external sensors: when the alarm input is in its active state, Gmux-2000 generates an alarm with a configurable text string.
Dry-Contact Alarm Interface

The alarm port is terminated in a 9-pin D-type female connector located on the Gmux-2000 rear panel, designated ALARMS. This port includes floating change-over dry-contact outputs for the major and minor alarm relays. The alarm relay contacts are rated at maximum 60 VDC or 30 VAC across open contacts, and maximum 1 ADC through closed contacts (total load switching capacity of 60W). The relays are controlled by software, and therefore the default state (that is, the state during normal operation) can be selected by the user in accordance with the specific system requirements.
External Sense Input

The external sense input is referenced to pin 3 of the ALARMS connector, and uses an auxiliary voltage output (derived from the +12V internal supply voltage through a 340 series resistor and a protection diode). A dry-contact relay must be connected between this auxiliary output and the reference pin.
2.8
The Gmux-2000 power supply subsystem comprises up to three power supply (PS) modules connected to the power sources via a separate power input (PI) module. The Gmux-2000 can use either 115/230 VAC, 50/60 Hz or 48 VDC power sources. The PI and PS modules installed in the chassis must match the selected power source.
Gmux-2000 Ver. 4.0
2-61
RAD offers PS modules with two ratings: 200W and 300W, and therefore three PS modules can supply a maximum of 600 W, respectively 900W, of power to the modules installed in the chassis. The actually required power depends on the modules installed in the chassis, but for most applications, two PS modules are sufficient to power a fully-equipped chassis. However, it is recommended to install the third PS module as well, for 2+1 redundancy: With a redundant PS module, all the three modules are connected to power, and when operating normally share the load. In case any PS module fails or loses its input power, the remaining PS modules continue to supply power to the chassis, without any service disruption. Therefore, a malfunctioning PS module can be replaced online; after replacement, the module starts again sharing the load. Switch-over is thus automatic and hitless.
Redundancy is also available when the chassis requires a single PS module, and two PS modules are installed. To provide power source redundancy as well, the power inlet modules also have multiple inputs: The AC power inlet (PI/AC) module has three separate inputs, one for each PS module: this enables connecting each PS module to an independent power circuit. The standard DC power inlet (PI/DC) module has two separate inputs, each distributed to all the PS modules. This provides redundancy for the DC input power source. To extend redundancy to the DC power inlet module as well, RAD also offers DC power inlet modules with a single DC input. This inlet is a half-width module, and therefore two such half-width modules can be installed in the PI slot (the two inlet modules plug into an internal FILTER module). The half-width inlet modules include active circuits that protect against inrush currents when power is applied, and select the DC power source in use: At any time, only one of the sources is selected, and connects in parallel to all the PS modules. The other inlet module is idle, and only monitors the DC source voltages If the currently selected power source fails, its inlet module disconnect it from the PS modules, and the other inlet module automatically connects the operational DC source to the PS modules without any disruption Together, the two inlet modules provide two DC inputs, the same as the full-width version, but the advantage of using half-width PI modules is that each one can be removed and replaced, without disconnecting both power sources from the DC PS modules.
2-62
Gmux-2000 Ver. 4.0
Chapter 3 Installation and Setup

This Chapter provides installation instructions for the Gmux-2000 systems, including the installation of the modules that are part of the basic system configuration. The Chapter presents the following information: General description of the equipment enclosure and its panels. Mechanical and electrical installation instructions for the enclosure itself and the fan tray, PI, PS and CONTROL modules.
If Gmux-2000 is intended for operation with an NPS-101 1:N protection switching device, refer to the NPS-101 Installation and Operation Manual for additional installation instructions. After installing the system, it is necessary to configure it in accordance with the specific user's requirements. The preliminary system configuration is always performed by means of a supervision terminal (procedures for using the terminal are given in Chapter 4). The software necessary for using the terminal is stored in the CONTROL modules: if the CONTROL modules are not yet loaded with the required software, refer to Appendix B for detailed software installation instructions. After the preliminary configuration, the system can also be managed by means of Telnet hosts or SNMP-based network management stations, e.g., RADview. Refer to the User's Manual of the network management station for operating instructions.
Safety
Before starting, read the following safety precautions, which are applicable throughout the installation procedures. Where necessary, specific precautions also appear before certain procedures. No internal settings, adjustment, maintenance, and repairs may be performed by either the operator or the user; such activities may be performed only by a skilled technician who is aware of the hazards involved. Always observe standard safety precautions during installation, operation, and maintenance of this product.
Warning
Caution
Gmux-2000 modules contain components sensitive to electrostatic discharge (ESD). To prevent ESD damage, always hold the module by its sides, and do not touch the module components or connectors.
Gmux-2000 Ver. 4.0
Site Requirements and Prerequisites
3-1
Caution Delicate electronic components are installed on both sides of the printed circuit
boards (PCBs) of the Gmux-2000 modules. To prevent physical damage: Always keep modules in their protective packaging until installed in the Gmux-2000 chassis, and return them to the packaging as soon as they are removed from the enclosure. Do not stack modules one above the other, and do not lay any objects on PCBs. When inserting a module into its chassis slot, align it carefully with the chassis slot guides, and then push it in gently. Make sure the module PCB does not touch the adjacent module, nor any part of the chassis. If resistance is felt before the module fully engages the mating backplane connector, retract the module, realign it with the slot guides and then insert again.
Grounding
For your protection and to prevent possible damage to equipment when a fault condition, e.g., a lightning stroke or contact with high-voltage power lines, occurs on the lines connected to the equipment, the Gmux-2000 case must be properly grounded (earthed) at any time. Any interruption of the protective (grounding) connection inside or outside the equipment, or the disconnection of the protective ground terminal can make this equipment dangerous. Intentional interruption is prohibited.
Grounding
Dangerous voltages may be present on the electrical cables connected to the Gmux-2000 and its modules.
Warning
Never connect cables to Gmux-2000 if not properly installed and grounded. Disconnect all the cables connected to the electrical connectors of the Gmux-2000 before disconnecting its grounding connection. Before connecting any other cable and before applying power to this equipment, the protective ground terminal of the equipment must be connected to protective ground. The grounding connection is made to the grounding terminal located on the Gmux-2000 rear panel. Whenever Gmux-2000 units are installed in a rack, make sure that the rack is properly grounded and connected to a reliable, low-resistance grounding system, as the rack can also provide a connection to the ground. In addition, the grounding connection is also made through each one of the power cables. Therefore, the power cable plug must always be inserted in a socket outlet provided with a protective ground.
3-2
Gmux-2000 Ver. 4.0
Laser Safety
Gmux-2000 modules may be equipped with a laser diode. In such cases, a label with the laser class and other warnings as applicable will be attached near the optical transmitter. The laser warning symbol may be also attached. For your safety: Before turning on the equipment, make sure that the fiber optic cable is intact and is connected to the optical transmitter. Do not use broken or unterminated fiber-optic cables/connectors. Do not look straight at the laser beam, and do not directly into the optical connectors while the unit is operating. Do not attempt to adjust the laser drive current. The use of optical instruments with this product will increase eye hazard. Laser power up to 1 mW at 1300 nm and 1550 nm could be collected by an optical instrument. Use of controls or adjustment or performing procedures other than those specified herein may result in hazardous radiation exposure. ATTENTION: The laser beam may be invisible! Gmux-2000 modules equipped with laser devices provided by RAD comply with laser product performance standards set by governmental agencies for Class 1 laser products. The modules do not emit hazardous light, and the beam is totally enclosed during all operating modes of customer operation and maintenance. In some cases, the users may insert their own SFP laser transceivers into Gmux-2000 modules. Users are alerted that RAD cannot be held responsible for any damage that may result if non-compliant transceivers are used. In particular, users are warned to use only agency approved products that comply with the local laser safety regulations for Class 1 laser products. Wherever applicable, Gmux-2000 modules are shipped with protective covers installed on all the optical connectors. Do not remove these covers until you are ready to connect optical cables to the connectors. Keep the covers for reuse, to reinstall the cover over the optical connector as soon as the optical cable is disconnected.
Warning
Protection against ESD

An electrostatic discharge occurs between two objects when an object carrying static electrical charges touches, or is brought near enough, the other object. Static electrical charges appear as result of friction between surfaces of insulating materials, separation of two such surfaces and may also be induced by electrical fields. Routine activities such as walking across an insulating floor, friction between garment parts, friction between objects, etc. can easily build charges up to levels that may cause damage, especially when humidity is low.
Gmux-2000 Ver. 4.0
3-3
Caution Gmux-2000 modules contain components sensitive to electrostatic discharge
(ESD). To prevent ESD damage, always hold a module by its sides, and do not touch the module components or connectors. If you are not using a wrist strap, before touching a module, it is recommended to discharge the electrostatic charge of your body by touching the frame of a grounded equipment unit. Whenever feasible, during installation works use standard ESD protection wrist straps to discharge electrostatic charges. It is also recommended to use garments and packaging made of antistatic materials or materials that have high resistance, yet are not insulators.
Proper Handling of Modules

Gmux-2000 modules include small components installed on both sides of the printed circuit boards. These components are exposed as long as the modules are not installed in the chassis, are therefore may be unintentionally damaged. To prevent physical damage to modules: 1. Always keep the modules in their protective shipping containers until installed in the chassis. These containers also protect against ESD. 2. Avoid piling up modules. 3. While inserting modules in their chassis slots, support the modules and make sure their components do not touch the chassis structure, nor other modules while sliding into position.
3.1
Before connecting this product to a power source, make sure to read the Handling Energized Products section at the beginning of this manual.
Warning Caution Gmux-2000 does not have a power switch, and therefore it will start operating as
soon as power is applied to one of the power supply inlets. For proper equipment operation, at least two power supply modules must be operative and receive power simultaneously. It is recommended that the external circuit breaker used to protect the input power lines be also used as ON/OFF power switch.
Power
Gmux-2000 can be equipped with either AC or DC power supply modules. It is not allowed to mix power supply modules operating on different supply voltages in one chassis.
Warning
3-4
Gmux-2000 Ver. 4.0
Each type is available in 200W and 300W models (see description of PS modules in Section 1.3). Contact RAD Technical Support Department if it is necessary to use both 200W and 300W PS modules in the same chassis.
AC Power
AC-powered Gmux-2000 units should be installed within 1.5m (5 feet) of easily-accessible grounded AC outlets capable of furnishing 115 or 230 VAC, 50/60 Hz. The connection of AC power is made through the AC power inlet module. This module has a separate input connector for each AC power supply module installed in the chassis. Therefore, the connection of AC power to each power supply module installed in the chassis is made through a separate power cable: for a Gmux-2000 equipped with the full complement of power supply modules (three), three separate power cables are required. Therefore, it is necessary to make appropriate arrangements for simultaneously applying power to all the Gmux-2000 power inlets by means of a single ON/OFF power switch. Powering AC power supply modules one at a time may cause undesirable effects, for example, the GbE modules may be reset. When PS redundancy is required, at least two of the three PS modules must be able to supply power to modules installed in the chassis.
DC Power
DC-powered Gmux-2000 units require a 24 VDC or 48 VDC (nominal voltage) power source. Three DC power supply modules can be installed in the chassis. When PS redundancy is required, at least two of the three PS modules must be able to supply power to modules installed in the chassis. The connection of DC power is made through DC power inlet modules, which are available in two models: DC power inlet module with two DC inputs, occupies the full width of the PI slot in the Gmux-2000 chassis Half-width DC power inlet module with single DC input. Two half-width PI modules can be installed in the PI slot, and together they provide two DC inputs.
Irrespective of the DC power inlet model, each DC input voltage is distributed in parallel to all the PS power supply modules, and therefore it is sufficient to connect power to one input for all of the DC power supply modules to be simultaneously powered. The second DC input enables connecting a separate DC input voltage, and thus when power is connected to both DC input connectors, availability is increased by having a redundant power source. The two DC inputs are isolated, and therefore it is not possible for current to flow from one DC input to the other.
Caution The same nominal DC voltage must be supplied to both DC input connectors.
Within the Gmux-2000, the DC input supply lines are not referenced to the chassis (frame) ground.
Gmux-2000 Ver. 4.0
3-5
Caution Gmux-2000 is usually supplied with the internal digital ground (DGND) not
connected to the frame ground (FGND). However, you may order the Gmux-2000 with DGND connected to FGND. Contact your local distributor for more information.
Payload Connections
T1 Port Connections
Gmux-2000 systems may be equipped with external T1 ports. External T1 ports are located on T1-PW/28 pseudowire emulation modules with external ports, and on voice compression modules. The maximum allowable line attenuation between a Gmux-2000 T1 port and the network interface depends on the type of port interface, and therefore it is given in the Installation and Operation Manual of each specific module. The electrical T1 interfaces of Gmux-2000 systems must not be connected directly to unprotected public telecommunication networks. The connections must be made through a network termination unit that provides separation between the interface conductors and the telecommunication network conductors in accordance with the applicable local regulations. The T1 ports located on T1-PW/28 modules are terminated in 62-pin female D-type connectors (each module has one pair of connectors for its 28 T1 ports). RAD offers a special 1U-high patch panel, suitable for installation in standard 19 racks, which simplifies the connection of users equipment to the T1-PW/28 ports. This patch panel, Patch-28B, serves as an adapter that provides separate RJ-45 connectors for each port. Standard cables can then be used to connect the user's equipment to the patch panel connectors. The panel provides transparent connections to the module T1 port lines. The patch panel has two 64-pin TELCO connectors on the rear panel, for connection via adapter cables to the T1-PW/28 connectors. RAD also offers adapter cables, designated CBL-G703-14/PATCH, having a length of 2 meter, for connecting the patch panel to the module. Each panel serves one T1-PW/28 module, and requires two adapter cables. Voice compression modules have two types of external T1 ports: External T1 voice ports: these ports have balanced ITU-T Rec. G.703 interfaces, terminated in one 64-pin D-type female connector. RAD offers as optional accessories the following dedicated adapter cables: CBL-TELCO-RJ45/16T1, terminated in RJ-45 plugs, which is used to connect equipment with standard RJ-45 connectors to the module 64-pin D-type connector. CBL-TELCO-OPEN/2M and CBL-TELCO-OPEN/10M. These cables are terminated in free leads that can be connected to any terminal block, or to any connector appropriate for your application. External T1 data ports (not used for VoIP service): these ports have balanced or unbalanced ITU-T Rec. G.703 interfaces (interface type is
3-6
Gmux-2000 Ver. 4.0
software-selectable). Each port has one RJ-45 8-pin connector, used for both the balanced and unbalanced interface. The connection to equipment with balanced interface is made by any standard RJ-45-to-RJ-45 cable. For connection to equipment with unbalanced interface, RAD offers as an optional accessory an adapter cable, CBL-RJ45/2BNC/T1/X, with one RJ-45 plug at one end and two BNC female connectors at the other end.
SONET Port Connections

Optical Ports. SONET ports can be ordered with fixed OC-3 optical ports (OC3 modules only), or with SFP-based ports. Each optical fixed port has two SC optical connectors, one for the receive input and the other for the transmit output. The optical ports can be ordered with 850 nm short-haul interfaces for use over multimode fibers, or with various 1310 nm interfaces, from LEDs for short haul to lasers for long haul applications, for use over single-mode fibers. Each SFP-based port accepts field-replaceable standard SFPs with optical interfaces, and thus enables selecting the optimal SFP for each application and fiber type. RAD offers a wide range of SFPs, including high-performance SFPs that are also offered in WDM versions using a single fiber instead of the customary two fibers, and can achieve ranges up to 80 km (50 miles). Electrical Ports (OC3 nodules only). SONET ports can also be ordered with electrical OC-3 ports. Each port has two 75 BNC connectors, one for the receive input and the other for the transmit output. The electrical interface is intended for short intra-office cable runs (typically up to 135 meter over RG-59B/U coax). This interface must not be directly connected to unprotected public telecommunication networks.
PSN Connections
The PSN interfaces are located on the GbE/2 modules. These modules have ports with Gigabit Ethernet interfaces that support auto-negotiation. In accordance with order, the links use either Gigabit Ethernet hot-swappable SFP transceivers with optical GbE interfaces, or copper GbE interfaces, for meeting a wide range of operational requirements. GbE ports equipped with optical SFPs always operate at 1 Gbps, full duplex. The ports support auto-negotiation, however auto-negotiation can be disabled for compatibility with equipment that does not support this feature. For optical ports, auto-negotiation, even when enabled, does not change the GbE port operating mode. GbE ports with copper interfaces, support rates of 10/100/1000 Mbps, full duplex and half duplex. The ports support auto-negotiation, however auto-negotiation can be disabled, in which case the operating rate and mode are user-selectable.
Optical Cable Requirements

The cables connected to Gmux-2000 optical ports should use 2-mm optical fibers terminated in the corresponding type of connectors.
Gmux-2000 Ver. 4.0
3-7
When routing fibers, make sure to observe the minimum bending radius (35 mm). RAD recommends installing plastic supports on each cable connector: these supports determine the fiber bending radius at the connector entry point and also prevent stress at this point.
Station Clock Connections

The Gmux-2000 station clock ports can accept and generate 2.048 MHz or 1.544 MHz signals. Each port is terminated in one RJ-45 connector for the balanced (100/120) interface, and two BNC connectors for the unbalanced (75) interface. Two types of signals can be accepted and generated: all-ones AMI-coded clock signal, or a squarewave signal at RS-485 levels. The station clock outputs provide a convenient means for distributing the Gmux-2000 nodal clock signal to other equipment.
Note
When using redundant CONTROL modules, only one of the two station clock ports must be connected to a station clock source. For best protection, it is recommended to connect the two station ports to two separate station clock sources. When only one clock source is available, you can have better protection by connecting the station clock inputs in parallel, by means of a simple Y-cable. In this case, configure the CONTROL module to use a Y-cable: this configuration ensures that at any time only one station clock interface (that of the active module) is active.
Management Connections
Ethernet Connections to CONTROL Modules
The CONTROL modules have 10BASE-T/100BASE-TX Ethernet interfaces terminated in RJ-45 connectors. These interfaces support MDI/MDIX crossover and therefore the ports can always be connected through a straight (point-to-point) cable to any other type of 10/100BASE-T Ethernet port (hub or station).
Serial Port Connections

The out-of-band supervisory port of the Gmux-2000 has a serial RS-232 asynchronous DCE interface terminated in a 9-pin D-type female connector, designated CONTROL DCE. This port can be directly connected to terminals using a cable wired point-to-point. A cross cable is required to use the DTE mode, for example, for connection through modems or digital multiplexer channels.
3-8
Gmux-2000 Ver. 4.0
Note
When using redundant CONTROL modules, you can connect the terminal, respectively the modem, in parallel to the corresponding serial port connectors of the two modules by means of a simple Y-cable, because at any time only one serial port (that of the active module) is active. Ethernet ports of redundant CONTROL modules do not require any special connections: each one can be connected to a separate Ethernet hub port.
Alarm Port Connections

The alarm port is terminated in a 9-pin D-type female connector located on the Gmux-2000 rear panel, designated ALARMS. This port includes: Floating change-over dry-contact outputs for the major and minor alarm relays. The alarm relay contacts are rated at maximum 60 VDC/30 VAC across open contacts, and maximum 1 ADC through closed contacts (total load switching capacity of 60W).
Caution Protection devices must be used to ensure that the contact ratings are not
exceeded. For example, use current limiting resistors in series with the contacts, and place voltage surge absorbers across the contacts. The relays are controlled by software, and therefore the default state (that is, the state during normal operation) can be selected by the user in accordance with the specific system requirements. External alarm sense input. The input is intended for connection by means of a dry-contact relay that provides open-circuit/short-circuit to an auxiliary voltage output (derived from the +12V internal supply voltage through a 340 series resistor and a protection diode). Either the open- or short-circuit state can be configured as the active state, that will be reported as an alarm.
Front and Rear Panel Clearance

Gmux-2000 can be installed on shelves and in telecommunication racks. RAD offers rack mount kits for installation in 19 inch (ANSI) racks or in ETSI racks. Allow at least 90 cm (36 inches) of frontal clearance for operator access. Allow the same clearance at the rear of the unit for cables and module replacement.
Ambient Requirements
The ambient operating temperature range of the Gmux-2000 is 32 to 131F (0 to +55C), at a relative humidity of up to 90%, non-condensing. The Gmux-2000 chassis has a cooling fan tray that exhausts air from the chassis. The chassis cooling vents are located in the side covers. Do not obstruct these vents.
Caution Do not operate Gmux-2000 without the fan tray installed. Irreversible damage to
hardware will occur if the chassis is operated without the fan tray installed, even for a few minutes (maximum allowed at room temperature is 5 minutes). When the Gmux-2000 is installed in a rack, it is recommended to allow at least 1U of space below and above the unit.
Gmux-2000 Ver. 4.0 Site Requirements and Prerequisites 3-9
Electromagnetic Compatibility Considerations

The Gmux-2000 is designed to comply with the electromagnetic compatibility (EMC) requirements of Sub-Part J of FCC Rules, Part 15, for Class A electronic equipment, and additional applicable standards. To meet these standards, it is necessary to perform the following actions: Connect the Gmux-2000 case to a low-resistance grounding system. Install blank panels to cover all empty slots. Appropriate blank panels can be ordered from RAD. Whenever possible, use shielded telecommunication cables.
Covering all empty slots is also required for reasons of personal safety and for efficient cooling of the chassis.
Warning
3.2

Package Contents
The Gmux-2000 package includes the following items: Gmux-2000 chassis Power cords Hardware kit for rack installation (if ordered) Technical documentation CD.
Modules are shipped either separately, or preinstalled in the chassis, in accordance with your order.
3.3
Required Equipment
The cables you need to connect to the Gmux-2000 depend on your specific application. You can prepare the appropriate cables yourself in accordance with the information given in Appendix A, or order cables from RAD. For information regarding the cables needed to connect to Gmux-2000 I/O modules, refer to the module Installation and Operation Manuals. For cables needed to connect to an NPS-101, refer to the NPS-101 Installation and Operation Manual.
3-10
Required Equipment
Gmux-2000 Ver. 4.0
3.4
Gmux-2000 Enclosure
General Description
Figure 3-1 shows a general view of the Gmux-2000 enclosure, as seen from its
front side. The front panel includes only status indicators: the various modules and all the connectors are reached on the rear side. Cooling vents are located on the side covers of the enclosure. The Gmux-2000 enclosure can be ordered with brackets for installation in various types of racks. The brackets are attached to the sides of the enclosure, near the front or rear panel.
Figure 3-1. Gmux-2000 Enclosure, General View
Gmux-2000 Ver. 4.0
Gmux-2000 Enclosure
3-11
Front Panel
The front panel of the Gmux-2000 enclosure includes labels for the system status indicators. Figure 3-2 identifies the status indicators, and Table 3-1 describes the indicator functions.
Figure 3-2. Gmux-2000 Enclosure, Front Panel Table 3-1. Gmux-2000 Status Indicators
Indicator PWR (green) Description Lights when the Gmux-2000 is powered. Turns off when the CONTROL module is not installed of software download is in progress. TST (yellow) MAJ ALARM (red) MIN ALARM (red) Lights when a test (or test loopback) is active in the local or remote Gmux-2000 Flashes when a major alarm condition is detected in the local Gmux-2000 Lights when a minor alarm condition is detected in the local Gmux-2000
3-12
Gmux-2000 Enclosure
Gmux-2000 Ver. 4.0
Rear View
Figure 3-3 shows a typical rear view of the Gmux-2000 enclosure (this figure presents a Gmux-2000 equipped for pseudowire emulation applications). The rear side includes the following main sections:
16 slots: 6 of them are slots for system modules, 9 slots (identified as I/O-1 to I/O-9), are used to install I/O modules, and the last slot is occupied by the fan tray that provides air flow through the enclosure. Top panel, includes the chassis grounding terminal, a group of status indicators that replicate the status indications provided on the front panel, and a connector for alarm outputs and inputs.
Gm ux-2000
Slot:
I/O 6 I/O 5
GbE/2 Module
Figure 3-3. Gmux-2000 Enclosure, Typical Rear View
Gmux-2000 Ver. 4.0
Gmux-2000 Enclosure
3-13
3.5
Installing the Fan Tray
This section provides instructions for installing a fan tray in an empty chassis. The same procedure may be used to replace the fan tray.
Fan Tray Description

The fan tray includes a total of 8 independently controlled fans that provide cooling air. The rotation speed of the fans, and thus the airflow, can be varied to adapt to the cooling requirements: for example, when the temperature inside the enclosure is sufficiently low, the speed is decreased to reduce wear and noise. The proper operation of the fans is monitored by the CONTROL modules.
Figure 3-4 shows a general view of the fan tray. The fan tray has two indicators:
PWR (green) lights when the fan tray receives power FLT (red) lights when a malfunction is detected in the fan tray, for example, a faulty fan, is detected in the tray.
Figure 3-4. Fan Tray, General View Note The I/O slots labels are located on the fan tray panel.
3-14
Gmux-2000 Ver. 4.0
Installation Procedure
To install the fan tray: 1. Carefully check the fan tray for foreign objects and dirt that may have been trapped inside, and remove them. 2. Insert the fan tray in the chassis slot as shown in Figure 3-5, and slide it backward until its rear connector engages the mating connector on the backplane. 3. Secure the fan tray by tightening its two screws.
Figure 3-5. Installing the Fan Tray Caution When replacing the Gmux-2000 fan tray in an operating chassis, do it quickly:
irreversible damage to hardware will occur if the chassis is operated without the fan tray installed, even for a few minutes (maximum allowed at room temperature is 5 minutes).
Gmux-2000 Ver. 4.0
3-15
3.6
Installing the Power Inlet (PI) Module
PI Modules Description
The connection of power to the Gmux-2000 power supply modules is made through a PI module. Figure 3-6 shows the offered PI modules.
+
PWR DC-IN 48V
+
PWR
A. PI/DC Module for 48V DC Input Voltage

DC-IN 48V
AC-IN 1 3
DC-IN ACT 48V ACT
FLT
FLT
PI/AC Module
B. PI/48 Modules for 48V DC Input Voltage Figure 3-6. Typical PI Module Panels
PI/AC Module
The PI/AC module is used for AC-powered power supply modules. The PI/AC module has 3 AC input connectors, one for each PS/AC module that may be installed in the chassis.
PI/DC, PI/48 Modules

The PI/DC and PI/48 modules are used for DC-powered power supply modules. PI/DC full-width PI module for 48 VDC-powered power supply modules. The PI/DC module enables connecting two DC power sources to the Gmux-2000. Each DC power source is connected in parallel to the three PS-DC modules that may be installed in the chassis. The PI/DC module has a single indicator, PWR, which lights when DC power is present at the corresponding input. Each source is protected by a separate fuse, located behind the corresponding power connection terminals (see Figure 3-7). These fuses, designated H1 and H2, are 20-A super-time-lag (TT) high-breaking capacity ceramic fuses, type 172600 by Chess Schurter or equivalent.
3-16
Gmux-2000 Ver. 4.0
Fuse H1
Fuse H2
Figure 3-7. Location of Fuses on Typical Full-Width PI/DC Module

When replacing fuses, observe the following precautions:
Warning
For continued protection against risk of fire, replace only with same type and rating of fuse. Disconnect power before replacing a fuse. PI/48 half-width PI module for 48 VDC-powered power supply modules. The PI/48 module enables connecting one DC power source to Gmux-2000; installing two PI/48 modules in the PI slot of the Gmux-2000 chassis enables connecting two DC power sources, the same as the full-width PI/DC module, where each power source is connected in parallel to the three PS-DC modules that may be installed in the chassis.
Warning
When using the half-width PI module option, connect the chassis to protective ground using a grounding strap attached to the grounding lug located on the Gmux-2000 rear panel. Together, the two PI/48 inlet modules select one of the DC sources connected to them as the Gmux-2000 power source; each half-width PI/48 can be separately removed without disconnecting Gmux-2000 from power.
Table 3-2 explains the functions of the indicators located on the PI/48
module panel.
Table 3-2. Half-Width PI/48 Module Indicators

Item ACT Indicator (green) FLT Indicator (red) Function Lights steadily on the active module (the module that provides power to Gmux-2000). When the module is in standby, this indicator is off Lights in case of malfunction in the module. When the module is in standby, this indicator is always off, even in case a problem is present
Gmux-2000 Ver. 4.0
3-17
Installing Full-Width PI Modules

Caution Make sure to install the PI/DC module matching the supply voltage required by
the PS modules.
To install a PI module: 1. Check that the two fastening screws of the PI module are free to move. 2. Insert the PI module in its chassis slot (see Figure 3-3), and slide it backward until its rear connector engages the mating connector on the backplane. 3. Secure the PI module by tightening its two screws.
Installing Half-Width PI Modules

The two half-width PI modules are installed on a FILTER module, which fits in the PI slot of the chassis. The FILTER module creates the two installation positions for the separate half-width PI modules. To convert a Gmux-2000 using a full-width PI/DC module for use with half-width PI modules: 1. Remove the existing PI/DC module by reversing the installation procedure. 2. Install the FILTER module. 3. Install each half-width PI module in the corresponding position. To install the FILTER module: Insert the FILTER module in the PI chassis slot (see Figure 3-8). Slide it backward until its rear connector engages the mating connector on the backplane.
FILTER Module
Figure 3-8. Installing the FILTER Module
3-18
Gmux-2000 Ver. 4.0
To install a half-width PI module: 1. Check that the two fastening screws of the half-width PI module are free to move. 2. Insert the module in its half slot, and slide it backward as far as it goes (see Figure 3-9). Make sure that its front panel is flush with the PS front panel.
PI Module
Figure 3-9. Installing a Half-Width PI Module

3. Secure the module by tightening its two screws. 4. Repeat the process for the other module. Figure 3-10 shows the two half-width PI modules in place.
Figure 3-10. Half-Width PI Modules After Installation
Gmux-2000 Ver. 4.0
3-19
3.7
Installing the Gmux-2000 PS Modules
PS Module Description
The Gmux-2000 may be equipped with PS modules of the following types: PS-AC: operate on 115/230 VAC, 50/60 Hz; available in 200W and 300W models PS-DC: operates on 48 VDC; available in 200W and 300W models.
Note
200W and 300W PS models look quite similar. To identify the module before being installed in the chassis, look at its manufacturer label attached to the internal shield. While Gmux-2000 operates, you can read the PS model using the management station (for a supervision terminal, use the Inventory menu).
PS-DC modules have two indicators: POWER lights when the module is powered ALARM lights when a malfunction is detected in the module.
The PS-AC module has only a POWER indicator. The chassis accepts three modules that share the load. The maximum power that may be supplied by each module is either 200W or 300W, and therefore three PS modules can supply a maximum of 600 W, respectively 900W. In general, only two PS modules are sufficient for powering a Gmux-2000 chassis, and therefore, by installing three PS modules, 2:1 redundancy is achieved. In this case, a PS module may be replaced without disrupting chassis operation (hot hitless swapping).
POWER
POWER
ALARM
PS-AC
PS-DC
PS-AC Module
PS-DC Module for 48V DC Input Voltage
Figure 3-11. Typical PS Module Panels
Installing PS Modules
To install a PS module: 1. If necessary, disconnect the power cable connected to the corresponding PI/AC connector or PI/DC terminal strip. 2. Check that the two fastening screws of the module are free to move. 3. Insert the PS module in its chassis slot (see Figure 3-3) and slide it backward as far as it goes (see Figure 3-12).
3-20
Gmux-2000 Ver. 4.0
Figure 3-12. Installing a PS Module

4. Refer to Figure 3-13 and press the extractor handle toward the center of the module to fully insert its rear connector into the mating connector on the backplane. 5. Secure the PS module by tightening its two screws.
1 2
Figure 3-13. Securing the PS Module to the Chassis
Gmux-2000 Ver. 4.0
3-21
Removing a PS Module
To remove a PS module: 1. If necessary, disconnect the power cable connected to the corresponding PI/AC connector or PI/DC terminal strip. 2. Fully release the two screws fastening the module to the chassis. 3. Press the release button of the extractor (located on the side, and 4. push the extractor handle in the direction shown in Figure 3-14 to disengage the rear connector. 5. Pull the module out.
4 2 3 1
Figure 3-14. Removing a PS Module
3-22
Gmux-2000 Ver. 4.0
3.8
Installing CONTROL Modules
CONTROL Module Description

The Gmux-2000 chassis can be equipped with two CONTROL modules. At any time, only one module is active, and the other serves as hot standby.
Figure 3-15 shows the front panel of the CONTROL module, and Table 3-3
explains the functions of the components located on the panel.
OU T IN SD
ACT
LINK
S TATION CLO CK
AC T CO NTR OL 2
ETH CO NTRO L
D E C
FL T
Figure 3-15. CONTROL Module Panel Table 3-3. CONTROL Module, Panel Components
Item ACT Indicator (green) FLT Indicator (red) Function Lights steadily on the master (active) module. Flashes when this module is in standby Lights in case of malfunction in this module. When the module is in standby, this indicator is always off, even in case a problem is present 9-pin D-type female connector with serial RS-232 DCE interface, for connection to a supervision terminal or system management. RJ-45 connector for the 10/100BASE-T interface, for connection to system management through an Ethernet LAN RJ-45 connector for connection to the balanced station clock interface
CONTROL-DCE Connector CONTROL-ETH Connector STATION CLOCK Balanced Interface Connector STATION CLOCK IN Connector STATION CLOCK OUT Connector SD Indicator
BNC connector for unbalanced connection of an external clock signal, for use as a reference for the CONTROL module clock subsystem BNC connector for the unbalanced output clock provided by the CONTROL module clock subsystem Signal-detect indicator for the station clock input: Off when the Gmux-2000 is not configured to use the station clock as a main or fallback reference source. Lights in green when the station clock has been configured as reference, and a good signal is detected. Lights in red when the station clock has been configured as reference, but no clock signal is detected
Gmux-2000 Ver. 4.0
3-23
Preparing the CONTROL Module for Installation

The CONTROL module has two types of internal settings: Jumpers located on the upper card (the CLOCK card), used to select the station clock interface Switch located on the CONTROL card. One of the sections of this switch can be used to restore the configuration database to the factory-default values.
Figure 3-16 shows the location of the user settings located on the CONTROL
module.
CONTROL Card
Interface Se lection - Clock Ou tput JP4

UB L
Unbalanced Jumper JP2 FGND

NO
B alanced
BAL
OUT BAL NO IN BAL UBL JP 1 UBL YE S FGND JP4 JP2
Pin s 3,6 of RJ-45 Connector not Connected to Fra me Ground

YES Connector
Pin s 3,6 of RJ-45 Connected to Fra me Ground
CLOCK Card
Interface Se lection - Clock Input JP1

UBL
Unbalanced
Balanced
BAL
Figure 3-16. CONTROL Module, Clock Settings
Clock Interface Selection

Table 3-4 describes the jumper functions, and lists the factory (default) settings. If the default settings meet your specific requirements, you may skip this section and proceed with the installation of the module in the Gmux-2000 enclosure.
In addition to these settings, the CONTROL module includes additional jumpers and switches that are preset by the manufacturer and must not be moved.
3-24
Gmux-2000 Ver. 4.0
Table 3-4. CONTROL Module, Panel Components

Jumper Jumper JP1 Function Selects the station clock input interface: BAL 120 balanced interface. When using this interface, connect the station clock input cable to the RJ-45 connector. UNBAL 75 unbalanced interface. When using this interface, connect the station clock input cable to the BNC female coaxial connector designated IN. Default setting: BAL Jumper JP4 Selects the station clock output interface: BAL 120 balanced interface. When using this interface, connect the station clock output cable to the RJ-45 connector. UNBAL 75 unbalanced interface. When using this interface, connect the station clock output cable to the BNC female coaxial connector designated OUT. Default setting: BAL Jumper FGND JP2 Controls the connection of the frame ground to pins 3, 6 in the RJ-45 station clock connector. YES Connected. NO Not connected. Default setting: YES
Switch SW2 (Restore Factory-Default Parameters)

During normal operation, all the sections of this switch must be set to OFF. When you cannot establish communication with the CONTROL module, the only solution is to restore the factory-default parameters and then configure the Gmux-2000 as required. This is performed by means of section 2 of the switch, which selects the source of the configuration database parameters:
Gmux-2000 Ver. 4.0
3-25

ON
SW2
DB INIT Section
Figure 3-17. CONTROL Module, Setting Factory Defaults

ON OFF The CONTROL module loads the factory-default parameters upon power-up. The CONTROL module loads the user-selected parameters from its non-volatile memory on power-up.
ON
OFF
CONTROL Card
Note User-selected parameter values are not erased by setting the switch section to ON. Only after the CONTROL module is powered off and then on again, do the default values replace the user values.
Installing the CONTROL Module

Use the procedure described on page 3-20 for the PS modules. The only difference is that the CONTROL module has two extractors, which must be simultaneously operated.
Removing the CONTROL Module

Use the procedure described on page 3-22 for the PS modules. The only difference is that the CONTROL module has two extractors, which must be simultaneously operated.
3-26 Installing CONTROL Modules Gmux-2000 Ver. 4.0
Replacing a CONTROL Module During Equipment Operation

Gmux-2000 Chassis with two CONTROL Modules
In a Gmux-2000 equipped with two good CONTROL modules, the standby module can be removed/replaced without disrupting Gmux-2000 services. If you replace the on-line CONTROL module, the Gmux-2000 will automatically switch to the standby module, provided that module is OK. However, because the active CONTROL module also provides clock signals to all the Gmux-2000 subsystems, there will be a short disruption in service. This disruption can be avoided by first switching (flipping) to the standby module before replacing the on-line module. You can identify the active and standby modules by their ACT indicators.
Caution
To prevent service disruption, check that the ACT indicator of the CONTROL module you want to remove is flashing. If not, use the supervisory terminal (or any other management facility) to command the Gmux-2000 to flip to the other CONTROL module, and wait for execution of this command before continuing. To flip to the other CONTROL module using the supervision terminal: 1. Identify the on-line CONTROL module: this is the module with the lit ACT indicator. 2. Connect the supervision terminal directly to the CONTROL DCE connector of the on-line CONTROL module, and log in as administrator. 3. Use the mode command in the config>protection>cl-card# prompt to change the CL (CONTROL module) redundancy mode, which is normally auto, to the setting corresponding to the standby CONTROL module (the module with the flashing indicator): Select manual cl-a to flip to the module installed in the CTRL.1 slot, or manual cl-b for the module installed in the CTRL.2 slot. Save the change. 4. Wait for the flipping to be executed. After it is executed, the ACT indicator of the CONTROL module to which the supervision terminal is connected starts flashing, while the indicator of the other module stops flashing and lights steadily.
Note
The command will not be executed if a fault is detected in the module that is to become the on-line module. In this case, the ACT indicators state will not change.
5. You can now disconnect the supervision terminal, and remove the module. 6. After installing again a CONTROL module in the slot of the removed module, it is recommended to return the CL redundancy mode to AUTO. For this purpose, the supervision terminal must again be connected to the online CONTROL module.
Gmux-2000 Ver. 4.0
3-27
Gmux-2000 Chassis with Single CONTROL Module

In a Gmux-2000 equipped with a single CONTROL module, it is recommended that before replacing that CONTROL module, a good CONTROL module is installed in the free CTRL slot. The replacement can be temporary. In this case, after inserting the additional CONTROL module, first let it update its database from the information provided by the existing CONTROL module: for this purpose, change the CL redundancy mode to AUTO and wait about 10 minutes before starting the replacement procedure in accordance with the steps listed above for a Gmux-2000 with two CONTROL module. If the only CONTROL module in the chassis is replaced, Gmux-2000 services will always be disrupted to some extent while no CONTROL module is present. Therefore, be prepared and perform the replacement as rapidly as possible. Among other steps, make sure to upload the existing configuration database to a host, using TFTP. After replacement is completed, download the database to the new CONTROL module, to continue normal operation in accordance with the previous configuration.
3.9
Installing I/O Modules
Install each I/O module in the prescribed I/O slot, in accordance with the installation plan. For installation instructions, refer to the corresponding I/O module Installation and Operation Manual.
3.10 Installing Blank Panels

Install blank panels in all the chassis slots that are not occupied by modules.
3.11 Installation of Gmux-2000 Enclosure

Preparing for Installation in Rack
The Gmux-2000 is intended for installation on shelves and racks. Do not connect power to the enclosure before it is installed in the designated position. For rack installation, it is necessary to install two brackets to the sides of the unit. RAD offers two rack mount kits: RM-2000, for 19 inch (ANSI) racks RM-2000E, for ETSI racks.
As illustrated in Figure 3-18 and Figure 3-19, you may install the brackets in two ways, to orient the unit in accordance with your requirements (either with the
3-28
Installation of Gmux-2000 Enclosure
Gmux-2000 Ver. 4.0
Gmux-2000 front panel toward the front of the rack, or the module panels toward the front).
Figure 3-18 shows how to attach the brackets supplied in the RM-2000 kit for
installing the Gmux-2000 in 19 inch racks.
Install Bra ckets Here You Want if the Front toward the Pa Front of th nel e Rack
Figure 3-18. Attachment of Brackets for Installing the Gmux-2000 in 19 inch Racks
Gmux-2000 Ver. 4.0
3-29
Figure 3-19 shows how to attach the brackets supplied in the RM-2000E kit for
installing the Gmux-2000 in ETSI racks.
Install Brac kets Here You Want if the Front toward th Panel e Front of the Rack
Figure 3-19. Attachment of Brackets for Installing the Gmux-2000 in ETSI Racks
After attaching the brackets, you may attach handles on each side as shown in Figure 3-20.
Figure 3-20. Attaching Handles to Brackets
3-30
Gmux-2000 Ver. 4.0
Installation in Rack
To install the Gmux-2000 in the rack: 1. Identify the prescribed position of each Gmux-2000 in the rack, in accordance with the rack installation plan. 2. Obtain help from an additional person to place the Gmux-2000 in its prescribed position, and then insert the guide posts located on each bracket in the matching holes in the rack side rails. This will help keep the Gmux-2000 in position until it is fastened to the rack with the screws. 3. Have the other person hold the Gmux-2000 in place, and fasten the chassis to the rack side rails with four screws, washers and nuts. 4. After installing the enclosure, check and install the required modules, in accordance with the installation plan and the detailed instructions given in each module Installation and Operation Manual.
3.12 Connecting to Gmux-2000

Before connecting any cables and before switching on this instrument, the protective ground terminal of this instrument must be connected to the protective ground conductor of the (mains) power cord. The mains plug shall only be inserted in a socket outlet provided with a protective ground contact. Any interruption of the protective (grounding) conductor (inside or outside the instrument) or disconnecting the protective ground terminal can make this instrument dangerous. Intentional interruption is prohibited. Make sure that only fuses of the required rating are used for replacement. The use of repaired fuses and the short-circuiting of fuse holders is forbidden. Whenever it is likely that the protection offered by fuses has been impaired, the instrument must be made inoperative and be secured against any unintended operation.
Warning
Note
The mounting brackets used for installing a Gmux-2000 in ETSI racks have special openings for routing cables to one side of the chassis. You may also route optical fibers through these openings, provided that the fibers are not stressed under the other cables.
Grounding
Connect a short, thick copper braid between the grounding screw on the Gmux-2000 rear panel and a nearby grounding point. When the Gmux-2000 is powered by DC sources, connect additional grounding leads from the grounding terminal of each PI/DC power connection terminal strip to the nearest grounding point.
Gmux-2000 Ver. 4.0
Connecting to Gmux-2000
3-31
Connecting to Power
Caution Gmux-2000 does not have a power switch, and therefore it will start operating as
soon as power is applied to one of the power supply inlets. For proper equipment operation, at least two power supply modules must be operative and receive power simultaneously. Therefore, for AC-powered PS modules, it is necessary to simultaneously connect the power to all of the power supply modules. It is recommended that the external circuit breaker used to protect the input power lines be also used as ON/OFF power switch.
Connecting to AC Power
Connect each power cable first to the connector on the PI/AC module, and then to the power outlet.
Note
When redundant power supplies are used, it is recommended to connect the power cables to outlets powered by different circuits. However, it is necessary to use one ON/OFF switch to simultaneously connect/disconnect all of them.
Connecting to DC Power
Note This section provides information for connecting DC power to full-width PI/DC modules. Refer to the Terminal Block Connector for DC Power Supply Connection at the end of the manual, for details on connecting to half-width PI modules.
Before starting, prepare the leads for connection to the PI/DC terminals as shown in Figure 3-21.
Lead d itive oun Pos e Gr ectiv Prot ead ive L e ga t N
Strip 7mm (1/4 in)
Figure 3-21. Connection to Full-Width PI/DC Terminals
3-32
Gmux-2000 Ver. 4.0
Caution Pay attention to polarity. For each source, connect the protective ground lead,
then the positive lead, and the negative lead as the last one. 1. Refer to the Connection of DC Mains section at the beginning of this manual. 2. Use a narrow blade screwdriver to release the terminal screw. 3. Push the lead into the terminal up to its insulating sleeve. 4. When the lead is in position, fasten the screw to secure the lead. 5. Verify that the lead is securely held by pulling on it lightly.
Connecting to the CONTROL Module

This section provides information on the connections required by the CONTROL module. For a Gmux-2000 connected to NPS-101, use the connection instructions given in the NPS-101 Installation and Operation Manual.
Connection Data for CONTROL DCE Connector

The CONTROL DCE connector is an RS-232 asynchronous DCE port, terminated in a 9-pin D-type female connector, intended for direct connection to terminals. Since terminals usually have DTE interfaces, the connection to this port is made by means of a straight-through cable. For connection to a modem, you need a cross cable (also called null modem cable).
Connection Data for CONTROL ETH Connectors

The CONTROL ETH connector can be connected directly to an Ethernet hub port using a straight cable.
Connection Data for CLOCK Connectors

To connect to the balanced clock interface, terminated in the CLOCK RJ-45 connector, use a cable prepared in accordance with your particular application requirements, using the information presented in Appendix A. The unbalanced (75) clock interface is relevant only when using 2.048 MHz or 2.048 Mbps clock sources. Use two 75 coaxial cables to connect to the two BNC connectors for the interface. Pay attention to the function of each connector, marked next to it: OUT output, IN input.
Connecting to I/O Modules

Refer to the corresponding module Installation and Operation Manual. See also the NPS-101 Installation and Operation Manual.
Gmux-2000 Ver. 4.0
3-33
3-34
Gmux-2000 Ver. 4.0
Chapter 4 Operation
This Chapter provides general operating instructions and preliminary configuration instructions for Gmux-2000 units. The information presented in this Chapter is as follows: Turning on: Section 4.1 Indications: Section 4.2 Configuration and management alternatives for Gmux-2000: Section 4.3 Turning off: Section 4.4.
When using Gmux-2000 with NPS-101 1:N protection switching device, review the NPS-101 Installation and Operation Manual for additional information.
4.1
Turning On the Gmux-2000
When turning the Gmux-2000 on, it is useful to monitor the power-up sequence. You can monitor the power-up sequence using any standard ASCII terminal (dumb terminal or personal computer emulating an ASCII terminal) equipped with an RS-232 communication interface (same terminal that can be used to control the Gmux-2000 operation). Make sure to use VT-100 terminal emulation: using a different terminal type will cause display problems, for example, the cursor will not be located at the proper location, text may appear jumbled, etc. To monitor the Gmux-2000, configure the terminal for 115.2 kbps, one start bit, eight data bits, no parity, and one stop bit. Select the full-duplex mode, echo off, and disable any type of flow control.
Note
Always use these terminal parameters when connected to an NPS-101.

To prepare the Gmux-2000 for first-time turn-on: 1. Before first-time turn-on, inspect Gmux-2000 installation and check that the required cable connections have been correctly performed in accordance with
Chapter 3.
To monitor the Gmux-2000 during power up and preliminary configuration procedures, connect a terminal to the CONTROL DCE connector of the active CONTROL module in the Gmux-2000, using a straight (point-to-point) cable.
Gmux-2000 Ver. 4.0
4-1
Chapter 4 Operation
Note
You can also connect the terminal in parallel to the CONTROL DCE connectors of both CONTROL modules installed in the Gmux-2000, using a Y-cable. When connected to an NPS-101, see the NPS-101 Installation and Operation Manual for connection instructions.
To turn on the Gmux-2000:
Caution
Gmux-2000 does not have a power on/off switch, and therefore it will start operating as soon as power is applied. For a Gmux-2000 equipped with AC-powered PS modules, make sure to simultaneously connect the power to all the installed PS modules, for example, by means of a common circuit breaker or ON/OFF switch. For a fully equipped Gmux-2000, at least two of the three power supply (PS) modules installed in the Gmux-2000 must be connected to power. 2. Connect the Gmux-2000 to power (see detailed instructions in Chapter 3). The PWR indicators on all the PS modules that are powered light up, and remain lit as long as the Gmux-2000 is powered. You may also hear the fans in the Gmux-2000 fan tray start operating. 3. Wait for the completion of the power-up initialization process (this takes about one minute). During this interval, monitor the power-up indications: After power is applied, all the Gmux-2000 indicators turn on for a few seconds. This enables you to check that the equipment indicators are OK. After a few seconds, all the indicators turn off (except for the PS and PI PWR indicators; for half-width PI modules, check that the ACT indicator of one of the modules is also on). The Gmux-2000 starts decompressing its software. During this process, the ACT indicators of the CONTROL modules flash. The other indicators (except for the PS and PI PWR indicators, or a PI ACT indicator) remain off while the ACT indicators flash.
Note
At this stage, also turn on any attached NPS-101 device.

After software decompression is completed, all the indicators turn off for a few seconds (except for the PS and PI PWR indicators, or a PI ACT indicator) as the Gmux-2000 performs its power-up initialization. You can monitor the progress of the decompression and initialization process on the terminal connected to the Gmux-2000. A typical display is shown in Figure 4-1.
4-2
Gmux-2000 Ver. 4.0
Chapter 4 Operation
Booting Loading ... Decompressing to RAM. Processing archive: FLASH Extracting GMUXCL.BIN .......................................................... ........ CRC OK Running ... ******************************************************************* * In order to start working - press the ENTER button for few times* *******************************************************************
Figure 4-1. Typical Power-Up Display

4. After the power-up initialization ends, all the PWR indicators must light steadily, and the ACT indicator of the active CONTROL module lights (for half-width PI module, an ACT indicator must also light). At this stage, the indicators display the actual Gmux-2000 status. 5. At this stage, you may log in, using the supervision terminal.
Preparations for Monitoring Power-Up Sequence

Any standard ASCII terminal (dumb terminal or personal computer emulating an ASCII terminal) equipped with an RS-232 communication interface can be used to control the Gmux-2000 operation.
4.2
System Indications
Note
Normal Indications
For a description of Gmux-2000 front panel indicator functions, refer to Chapter 3.

1. As long as the Gmux-2000 is powered, all its PWR indicators lights steadily. When using half-width PI modules, one of the PI module ACT indicators must also light. 2. The ACT indicator of one of the CONTROL modules must light steadily. 3. The TST indicators must be off, unless a test has been activated on Gmux-2000. 4. The MAJ ALARM and/or MIN ALARM indicators must be off. However, they may flash, respectively light, as long as one or more of the Gmux-2000 ports is not connected to operational equipment. 5. All the FLT indicators on the Gmux-2000 chassis and on the panels of the modules installed in the chassis must be off.
Gmux-2000 Ver. 4.0
Normal Indications
4-3
Chapter 4 Operation
CONTROL ETH Interface Status Indications

If a Gmux-2000 CONTROL ETH port is not yet connected to an active LAN, the corresponding LINK and ACT indicators are off. After connecting the CONTROL ETH port to an active LAN, the corresponding LINK indicator must light. The ACT indicator of the port will flash, or appear to light steadily, in accordance with the traffic.
PSN Interface Modules (GbE) Status Indications

The ACT indicators of GbE modules must light. When the equipment at the other end of the GbE links is operational, and the link is physically connected: The LINK indicators must light The TX and RX indicators light in accordance with the transmit, respectively receive, activity at the corresponding port. The PAUSE indicator of a port may light from time to time, to indicate the reception of PAUSE frames, used during temporary congestion conditions to throttle traffic.
SONET Interface Modules (OC3, C.OC3) Module Status Indications

The ACT indicators of OC-3 modules must light. If an OC-3 port is not yet connected to operational equipment, the corresponding port LOSS LOC indicator lights. If the equipment at the other end of the links is operational and the link is physically connected, the port LOSS LOC and LOSS REM indicators must turn off.
Pseudowire Emulation Server Modules (T1-PW-SRV/28) Module Status Indications

The ACT indicator of each pseudowire emulation server module must light. Each T1 port indicator must light in green, provided the T1 equipment served by the corresponding port is operational and the link is physically connected.
Pseudowire Emulation Modules with External T1 Interfaces (T1-PW/28) Status Indications

The ACT indicator of each pseudowire emulation module must light. For each external T1 port, if the port is not yet connected to operational equipment, the corresponding L port indicator lights. If the equipment at the other end of the link is operational and the link is physically connected, both the L and R indicators of the external port must turn off.
4-4
Normal Indications
Gmux-2000 Ver. 4.0
Chapter 4 Operation
Voice Compression Modules (VCA-T1/16 and VCA-T1/12) Status Indications

The ACT indicator of each voice compression module must light. For each external T1 port (either voice or data port), if the port is not yet connected to operational equipment, the corresponding LOC port indicator lights. If the equipment at the other end of the link is operational and the link is physically connected, both the LOC and REM indicators of the external port must turn off.
Note
In the VoIP mode the data ports of voice compression modules are not used, and their indicators are always off.
4.3
Configuration and Management Alternatives
The Gmux-2000 configuration activities can be performed by means of the following: Supervision terminal Telnet host SSH client SNMP-based network management system, e.g., the RADview-SC/Vmux network management system (refer to the RADview User's Manual for instructions).
Note
Gmux-2000 is managed via a command-line interface (CLI), except for when used in voice trunking and VoIP applications (VCA-T1/16 and VCA-T1/12 modules). In the voice applications a menu-driven management utility is used.
The user can select whether to enable management by means of Telnet and/or network management systems: only the supervision terminal is always able to configure Gmux-2000. The capabilities of the four options listed above are similar, except that before using Telnet, SSH, and/or network management systems, it is necessary to perform a preliminary configuration using the supervision terminal. Gmux-2000 supports simultaneous management sessions: it is users responsibility to prevent access conflicts and other errors that may occur when multiple users simultaneously access the same equipment.
Working with Supervision Terminal

Preparing for Preliminary Configuration
This section covers the preliminary configuration activities needed for a new Gmux-2000. The activities presented below assume that Gmux-2000 uses its factory-default configuration.
Gmux-2000 Ver. 4.0
4-5
Chapter 4 Operation
Note
If you cannot establish communication with Gmux-2000, reload the factory defaults to each CONTROL module installed in the chassis, using the switch located on the CONTROL module. Refer to the CONTROL module installation section in Chapter 3. If Gmux-2000 is used in conjunction with an NPS-101 1:N protection switching device, refer also to the NPS-101 Installation and Operation Manual for additional required connections. Do not change the default terminal settings when Gmux-2000 is connected to NPS-101.
The preliminary activities are performed by means of an ASCII terminal (or a PC running a terminal emulation program) directly connected to one of the Gmux-2000 CONTROL DCE connectors. Any standard ASCII terminal (dumb terminal or personal computer emulating an ASCII terminal) equipped with an RS-232 communication interface can be used to configure and control the Gmux-2000 operation. The software necessary to run the Gmux-2000 supervision program is contained in the Gmux-2000 CONTROL modules. Moreover, the Gmux-2000 CONTROL modules store all the configuration information generated or altered during the communication with the terminal: no information is stored in the terminal.
Note
For proper display of screens on terminals, you must: 1. Select a fixed-pitch system font for the display. Use your operating system documentation to find how to select a proper font. 2. Configure the terminal utility to use VT-100 terminal emulation.
Log-in for Supervision and Configuration

Gmux-2000 supports two access levels, which determine the functions the users can perform using supervisory terminals, Telnet hosts, and SSH clients. The access level is determined by the user name, and the protection against unauthorized access is conferred by passwords. The access levels supported by Gmux-2000 are described in Table 4-1.
Table 4-1. Gmux-2000 Access Levels

Access Level Administrator Monitoring Default User Name su user, tech Functions Accessible at this Level All the functions Only functions that do not affect equipment configuration and service
The default passwords for both levels are identical, 1234. The passwords can be changed at the administrator level, using Configuration > System > Management > Management Access > User Access.
Notes
1. Pay attention to case: the password is case-sensitive. 2. If the administrator password has been changed and is not known, contact RAD Technical Support Department for help.
4-6
Gmux-2000 Ver. 4.0
Chapter 4 Operation
To log in: 1. Connect a terminal to one of the Gmux-2000 CONTROL DCE connectors. 2. Turn the Gmux-2000 on as described in Section 4.1. 3. If the terminal is configured with the default parameters as explained above, after the power-up initialization ends it will display the cursor (a blinking underscore) at the home position of the screen (top left-hand corner). 4. Establish communication with the Gmux-2000 by pressing <Enter> once. You may also see a few status messages, and then you will see the log-in screen. Typical screen is shown below.
user> password>
Figure 4-2. CLI-Based Terminal Log-In Screen Note If the terminal is configured to different communication parameters (for example, to another rate), you may see only random strings of characters, or there will be no response to the pressing of the <Enter> key. Refer to Chapter 3 for instructions on reloading the factory-default parameters using the internal switch of the CONTROL module.
5. If the Gmux-2000 default user name and password have not yet been changed, log in as follows: Type the default user name, su, and then press <Enter>. Type the default password, 1234, and then press <Enter>.
Note
If RADIUS authentication is enabled, you will see a Please wait prompt at the bottom of the screen, followed by an alive indicator (a rotating line). Wait for authentication to end. However, if the RADIUS server does not authenticate the log in (or its response is not received before timeout), you will see Login Failed.
6. If your password is accepted, you will see the Gmux-2000 prompt.
GMUX2000#
Figure 4-3. Gmux-2000 Prompt
Preliminary Configuration Sequence

The purpose of the preliminary configuration session is to prepare the minimal set of parameters needed to manage the Gmux-2000. In particular, after preliminary configuration you will enable management access by Telnet hosts, SSH clients, and management stations, for example, RADview, that are attached to a LAN directly connected to the CONTROL ETH Ethernet ports of the Gmux-2000 CONTROL module, or at a remote location from which IP communication to the CONTROL module Ethernet ports is possible.
Gmux-2000 Ver. 4.0
4-7
Chapter 4 Operation
Note
To enable management access to the Gmux-2000 from any relevant location, it is necessary to fully configure the Gmux-2000: only full configuration can permit management traffic to reach the Gmux-2000 via inband paths. Full configuration is particularly important when using authentication by a remote RADIUS server which is not located on the same LAN with the CONTROL ETH ports of the Gmux-2000.
Using the CLI

The CLI consists of commands organized in a tree structure, starting at the base promptGMUX2000>. The base prompt is the device name, which can be configured in the system level. Commands that are not global are available only at their specific tree location, while global commands can be typed at any level. To find out what commands are available at the current location, type ?. To navigate down the tree, type the name of the next level. The prompt then reflects the new location, followed by #. To navigate up, use the global command exit. To navigate all the way up to the root, type exit all. At the prompt, one or more level names separated by a space can be typed, followed (or not) by a command. If only level names are typed, navigation is performed and the prompt changes to reflect the current location in the tree. If the level names are followed by a command, the command is executed, but no navigation is performed and the prompt remains unchanged.
Note
To use show commands without navigating, type show followed by the level name(s) followed by the rest of the show command.
In the following example, the levels and command were typed together and therefore no navigation was performed, so the prompt has not changed. ETX 201A# ETX 201A# configure port ethernet 1 loopback local ETX 201A# show configure port ethernet 1 loopback Loopback : Local Forever ETX 201A#
Figure 3-4. Commands without Level Navigation
4-8
Gmux-2000 Ver. 4.0
Chapter 4 Operation
In the following example, the levels were typed separately and the navigation is reflected by the changing prompt. ETX 201A# ETX 201A# configure ETX 201A>config# port ETX 201A>config>port# ethernet 1 ETX 201A>config>port>eth(1)# loopback local ETX 201A>config>port>eth(1)# show loopback Loopback : Local Forever ETX 201A>config>port>eth(1)#
Figure 3-5. Commands with Level Navigation Note Level names are abbreviated in the prompt.
You can type only as many letters of the level or command as required by the system to identify the level or command, for example you can enter config manag to navigate to the management level. In addition to being the default prompt, the # symbol also indicates a static or already configured entity. The $ symbol indicates a new dynamic entity that takes several commands to configure. After the configuration is completed, it must be activated by using the no shutdown command, as shown in the following example. ACE-3200# configure pwe pw 1 type atm-vc-1-to-1 psn mpls manually ACE-3200>config>pwe>pw(1)$ label in 16 out 16 ACE-3200> config>pwe>pw(1)$ no shutdown
Figure 3-6. Creating and Activating Dynamic Entity

The shutdown command disables a hardware element (such as a port), while no shutdown enables/activates it. CLI commands have the following basic format, used in the device help:
command [parameter] {value1 | value2 | | valuen} [optional_parameter <value>]
where:
{} [] <> Indicate that one of the values must be selected Indicate an optional parameter Indicate a value to be replaced by user text
In this manual, keywords (text that the user should type as is) appear in bold, while values that the user needs to replace with his/her own text appear in italics, as shown below:
command [parameter] {value1 | value2 | | valuen} [optional_parameter value]
The following keys are available at any time: ? Lists all commands available at the current level
Gmux-2000 Ver. 4.0
4-9
Chapter 4 Operation Tab
Command autocomplete Displays the previous command at the current level Displays the next command at the current level Delete character Interrupt current command Log out

<Backspace> <Ctrl-C> <Ctrl-Z>
CLI commands can be gathered into text files called scripts. Although scripts can be created using a text editor, it is recommended to save the configuration file and then edit it rather than write a script from scratch. The sequence of the commands is very important and if a script fails during startup at a certain command, the entire configuration file is discarded.
Changing between CLI and Menu-Driven Modes

You can switch between CLI and menu-driven modes. To switch from menu-driven to CLI mode: Select Change to CLI from the Utilities menu.
To switch from CLI to menu-driven mode: Type change_mode in the GMUX2000# prompt.
CLI Command Tree

At the CLI root, the following command categories are available: admin configure file.
Each category is detailed in the tables below.
Table 4-2. Global Commands

Command | | | | | | | | ping trace-route exit tree help history echo exec Description Verifies the reachability of a remote host Determines the route to a destination address Returns to previous level in the commands hierarchy Displays the commands hierarchy from current context Displays help Displays commands history Echos the text that is typed in Executes a file
4-10
Gmux-2000 Ver. 4.0
Installation and Operation Manual Command | | logout info Description Logs out Displays configuration info
Chapter 4 Operation
Table 4-3. Commands in the admin Category

Command | | | | reboot factory-default update-card-types save Description Reboots a module Restores factory-default parameters Loads current hardware configuration into database Saves the changes
Table 4-4. Commands in the configure Category

Command configure | | | | | | | | | | | | | | | | | | | | card | card-type Description Configuration commands Card-level commands Programs modules in the chassis manually Configures system parameters Configures name of device Configures contact person Configures location of device Configures TFTP timeouts Configuressdate and time parameters Configures system date format Configures system date Configures system time Configures time zone and offest Configures Simple Network Time Protocol parameters Creates/deletes SNTP server for unicast client mode Saves the changes Configures system clock Configures clock domain Configures master clock Configures fallback clock Configures station clock
system | | | | | | | | | | | | | | | | | name contact location tftp date-and-time | | | | | | | date-format date time zone sntp | server
save
clock | | | | domain | | master fallback
station
Gmux-2000 Ver. 4.0
4-11
Chapter 4 Operation Command | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | shutdown clock-mode interface-type Description
Enables/disables station clock Selects station clock mode Selects station clock interface type Saves the changes Saves the changes Displays current system time Displays system inventory Displays event log Displays system alarms Clears event log Configures management parameters Defines network managers Enables/disables sending traps to an NMS Saves the changes Configures SNMP parameters Defines SNMP communities Saves the changes Port-level commands Configures Gigabit Ethernet parameters Administratively enables/disables the port Defines autonegotiation mode Saves the changes Configures speed and duplex mode of a Gigabit Ethernet port when autonegotiation is disabled Saves the changes Configures Fast Ethernet parameters Defines autonegotiation mode Configures speed and duplex mode of a Fast Ethernet port when autonegotiation is disabled Saves the changes Configures E1 parameters
save
save show time show inventory-table show event-log show alarms clear-event-log
management | | | | | | manager | | trap-mask save
snmp | | community save
port | | | | | | | | | | | | | | giga-ethernet | | | | | shutdown auto-negotiation save max-capability speed-duplex
fast-ethernet | | | e1 | | | shutdown tx-clock-source line-type auto-negotiation speed-duplex save
Administratively enables/disables the port Configures transmit clock source Specifies the framing mode
4-12
Gmux-2000 Ver. 4.0
Installation and Operation Manual Command | | | | | | | | | idle-code out-of-service restoration-time Description
Chapter 4 Operation
Defines byte pattern of the data received/transmitted in the idle timeslots Selects the code transmitted during out-of-service periods Defines synchronization algorithms which reduce time required for the port to return to normal operation Controls the propagation of alarm indications Specifies the quality of the original timing source, using the standard SDH terminology Specifies the type of packet switched network used to transport the bundle Enables/disables a loopback on the port Specifies a Gigabit Ethernet interface 1 connected to a PW server card Specifies a Gigabit Ethernet interface 2 connected to a PW server card Displays the port status Displays the port statistics Clears the port statistic counters Displays loopback status Displays the port alarms Configures T1 parameters
| | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | t1 | | | | | | |
trail-mode source-quality network-type loopback giga-if-1 giga-if-2 show status show statistics clear-statistics show loopback show alarms
shutdown tx-clock-source line-type line-interface idle-code out-of-service restoration-time
Administratively enables/disables the port Configures transmit clock source Specifies the framing mode Defines the line interface type Defines byte pattern of the data received/transmitted in the idle timeslots Selects the code transmitted during out-of-service periods Defines synchronization algorithms which reduce time required for the port to return to normal operation Controls the propagation of alarm indications Specifies the quality of the original timing source, using the standard SONET terminology
| |
| |
| |
trail-mode source-quality
Gmux-2000 Ver. 4.0
4-13
Chapter 4 Operation Command | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | t3 | | | | | | | shutdown tx-clock-source line-type loopback giga-if-1 giga-if-2 save network-type loopback giga-if-1 giga-if-2 save show status show statistics clear-statistics show loopback show alarms line-code inband-loopback Description
Specifies the type of packet switched network used to transport the bundle Enables/disables a loopback on the port Specifies a Gigabit Ethernet interface 1 connected to a PW server card Specifies a Gigabit Ethernet interface 2 connected to a PW server card Saves the changes Displays the port status Displays the port statistics (show) Clears the port statistic counters Displays loopback status Displays the port alarms Selects the line code type Controls inband loopback activation Configures T3 parameters Administratively enables/disables the port Configures transmit clock source Defines T3 framing mode Enables/disables a loopback on the port Specifies a Gigabit Ethernet interface 1 connected to a PW server card Specifies a Gigabit Ethernet interface 2 connected to a PW server card Saves the changes Configures VC-12 parameters Administratively enables/disables the port Controls the sending and checking of the path trace label (carried in byte J2 of the SDH overhead) by the port. Controls the sending of AIS and RDI indications by the port, in case the received signal label (SDH overhead byte C2) is different from the expected signal label Controls the sending of AIS and RDI indications by the port, in case the received path trace label (carried in SDH overhead byte J1) is different from the expected path trace label
vc12 | | shutdown j2-pathtrace
plm-response
tim-response
4-14
Gmux-2000 Ver. 4.0
Installation and Operation Manual Command | | | | | | | | | | | | | | | eed-response loopback save Description
Chapter 4 Operation
Controls sending AIS and RDI upon EED Enables/disables a loopback on the port Saves the changes Configures VT1-5 parameters Administratively enables/disables the port Controls the sending and checking of the path trace label (carried in byte J1 of the SONET overhead) by the port. Controls the sending of AIS and RDI indications by the port, in case the received signal label (SONET overhead byte C2) is different from the expected signal label Controls the sending of AIS and RDI indications by the port, in case the received path trace label (carried in SONET overhead byte J1) is different from the expected path trace label Controls sending AIS and RDI upon EED Enables/disables a loopback on the port Saves the changes Configures SDH port parameters Administratively enables/disables the port Enables/disables a loopback on the port Selects the timing reference source used by the port for the transmit-to-network direction Selects EED (error rate degradation) and SD (signal degrade) thresholds Controls AIS sending when one or more SDH fault conditions is present Specifies VC-4 port number in the range from 1 to N where N is the STM level Administratively enables/disables the port Controls the sending and checking of the path trace label (carried in byte J1 of the SDH overhead) by the port Controls the sending of AIS and RDI indications by the port, in case the received signal label (SDH overhead byte C2) is different from the expected signal label
vt1-5 | | shutdown j2-pathtrace
plm-response
tim-response
| | | | | | | | | | | |
| | | | | | | | | | | |
| | |
eed-response loopback save
sdh | | | | | | | | shutdown loopback tx-clock-source threshold ais-on-failure au4 | | shutdown j1-pathtrace
plm-response
Gmux-2000 Ver. 4.0
4-15
Chapter 4 Operation Command | | | | tim-response Description
Controls the sending of AIS and RDI indications by the port, in case the received path trace label (carried in SDH overhead byte J1) is different from the expected path trace label Controls sending AIS and RDI upon EED Selects the BER value, which if exceeded results in the generation of the error rate degradation or signal-degraded alarms for the port Saves the changes Saves the changes Configures SONET port parameters Administratively enables/disables the port Enables/disables a loopback on the port Selecting the timing reference source used by the port for the transmit-to-network direction Selects EED (error rate degradation) and SD (signal degrade) thresholds Controls AIS sending when one or more SONET fault conditions is present Specifies OC-3 port number in the range from 1 to N where N is the STM level Administratively enables/disables the port Controls the sending and checking of the path trace label (carried in byte J1 of the SONET overhead) by the port. Controls the sending of AIS and RDI indications by the port, in case the received signal label (SONET overhead byte C2) is different from the expected signal label Controls the sending of AIS and RDI indications by the port, in case the received path trace label (carried in SONET overhead byte J1) is different from the expected path trace label Controls sending AIS and RDI upon EED Selecting the BER value, which if exceeded results in the generation of the error rate degradation or signal-degraded alarms for the port Saves the changes Saves the changes Configures LAG parameters
| |
| |
| |
| |
eed-response threshold
| | | | | | | | | | |
| | | | | | | | | | |
| |
save
save
sonet | | | | | | | | shutdown loopback tx-clock-source threshold ais-on-failure oc3 | | shutdown j1-pathtrace
plm-response
tim-response
| |
| |
| |
| |
eed-response threshold
| | |
| | |
| | lag
save
save
4-16
Gmux-2000 Ver. 4.0
Installation and Operation Manual Command | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | name bind Description Assigns a name to the LAG
Chapter 4 Operation
Adds a Gigabit Ethernet port to the LAG Configures cross-connect Configures internal TDM mappings Assigns timeslots in TDM links Configures port and module protection modes Configures APS parameters Defines operation mode of the APS Defines standby and active links in the APS Selects the recovery (service restoration) mode Defines the wait-to-restore period for the revertive recovery mode Selects whether to take the SD condition into consideration for the link flip Saves the changes Configures 1:N protection for I/O modules installed in the chassis Defines operation mode of the I/O protection group Defines active and standby modules and set the active module priority Selects the recovery (service restoration) mode Defines the wait-to-restore period for the revertive recovery mode Saves the changes Configures the CONTROL module protection Defines CONTROL module redundancy mode Saves the changes Configures the OAM parameters Configures the service OAM parameters Defines a multicast MAC address for the OAM CFM messages Defines an EtherType of the OAM CFM messages Configures the OAM maintenance domain Specifies the name format and the name of the maintenance domain Defines a maintenance domain level
cross-connect | | tdm-mapping pw-tdm
protection | | | | | | | | | | | | | | | | aps | | | | | | oper-mode bind revertive wait-to-restore flip-upon-sd save
io-group | | | | | mode bind revertive wait-to-restore save
cl-card | | mode save
oam | | | | | | cfm | | | | | multicast-addr ethertype maintenance-domain | | name md-level
Gmux-2000 Ver. 4.0
4-17
Chapter 4 Operation Command | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | proprietary-cc maintenance-association | | | | | | | | | | | | | | | | | | | name ccm-interval mep | | | | | | | | | | | | | | | | bind vlan remote-mep dest-addr-type dest-mac-addr continuity-verification ccm-initiate ccm-priority lbm linktrace shutdown service | | | | shutdown delay-threshold delay-var-threshold priority Description
Specifies the OAM mechanism type Configures the OAM maintenance association Specifies the name format and the name of the maintenance association Specifies an interval between continuity check messages. Configures the OAM maintenance endpoints Binds a MEP to a Gigabit Ethernet port Specifies VLAN ID Defines remote MEP Specifies destination MAC address type Defines destination MAC address Specifies continuity verification method Controls CCM initiation by the MEP Selects CCM priority Enables/disables OAM loopback Enables/disables OAM linktrace Administratively enables/disables the OAM MEP Confgures OAM services Administratively enables/disables the OAM service Defines a delay threshold Defines delay variation threshold Specifies priority of OAM messages originating from the service Configures the pseudowire connection parameters Configures a PW
pwe | | | | | | pw | | | | | peer label oam vlan tos
Defines a remote peer Selecting source and destination circuit bundle identifiers (CBID) Controls the use of the OAM connectivity protocol for the PW Configures VLAN tagging for the traffic generated by the PW Specifies the Layer-3 priority assigned to the traffic generated by the PW
4-18
Gmux-2000 Ver. 4.0
Installation and Operation Manual Command | | | | | | tdm-payload jitter-buffer Description
Chapter 4 Operation
Specifies the number of TDM payload bytes to be inserted in each packet Defines the jitter buffer size in msec. Specifies the handling of packets received after a delay exceeding that compensable for by means of the jitter buffer.
| | | | | | | | | | | |
| | | | | |
| | | | | |
version far-end-type psn-oos adaptive-clock multiplexing save
Selects the payload format Specifies the type of framing used by the equipment at the destination endpoint Selects the response to out-of-service conditions detected at the local E1 physical port Controls the adaptive timing recovery mechanism for the PW Selects the pseudowire multiplexing method Saves the changes Configures router parameters and entities Adds or deletes a router interface Assigns IP address and subnet mask to the router interface Assigns a name to router interface Binds the router interface to a PSN or common logic module Controls VLAN tagging and defining VLAN ID to be attached to the traffic coming via the router interface Controls management access via the router interface, using SNMP, Telnet, SSH Saves the changes Enables/disables the router interface Adds/deletes static route entities Specifies default gateway for the router interface traffic Defines the aging time for the ARP entries. Configures remote peers Saves the changes Sets terminal-related parameters Defines a number of lines displayed between two consecutive more entries
router | | | | | interface | | | | address name bind vlan
| | | | | | | | | |
| | | | | | | |
| | |
management-access save shutdown
static-route default-gateway arp-timeout peer save
terminal | length
Gmux-2000 Ver. 4.0
4-19
Chapter 4 Operation
Table 4-5. Commands in the file Category

Command file | | | | copy swap delete dir Description Performs file operations Transfers files via TFTP, download files internally, restores factory defaults Swaps files on flash disk Deletes files from the flash disk Displays contents of the flash disk on the online CONTROL module
Preparing New Configuration Parameters

Gmux-2000 operating mode, and all of its functions, are controlled by a set of configuration parameters organized as a database. The parameters in the database are selected by the user in accordance with the requirements of each specific application. To provide a starting point for the user, RAD gives a fixed set of factory-default parameters. The factory defaults are not modified by user configuration activities, and therefore these factory-defaults can be reloaded whenever needed. The preparation of the desired set of configuration parameters is made in accordance with a set of rules, which together form the Gmux-2000 supervision language. The supervision language is used to communicate with the central control subsystem of the Gmux-2000 located in the CONTROL modules, using a supervision terminal connected to the control port of the CONTROL module. The same language can also be used by Telnet hosts. The Gmux-2000 set can store several databases (up to 5). These databases are stored on a flash disk, and the supervision utility includes the utilities needed to manage the file system of this disk. At any time, one of these databases serves as the active (online) database. Gmux-2000 operation is controlled by the parameters contained in its active database. The active database is stored in flash memory, and therefore the latest configuration parameters are always available upon power-up. During the preparation of configuration parameters, the central control subsystem of the Gmux-2000 dedicates a section of its RAM, called editing buffer, to this process. The editing buffer contains a copy of a user-selected database (any of the five databases that can be stored by the Gmux-2000, including the currently-active database), and only this copy is modified by the commands entered by the user. Therefore, you can make configuration changes and cancel them as required without affecting the traffic flow through the Gmux-2000. Any changes take effect (that is, are activated and thus become the active, or online, database) only when they are saved: in this case, the contents of the edited database are first copied to the flash disk, and then the Gmux-2000 control system reinitializes the modules in accordance with new database.
4-20
Gmux-2000 Ver. 4.0
Chapter 4 Operation
Validity Checks
The Gmux-2000 control subsystem automatically checks the validity of each new subset of parameters selected by the user as soon as an attempt to save them is made, alerts the user to potential conflicts, and rejects erroneous selections. In addition, when the preparation of a new database is completed, the user can initiate a preliminary check of its validity by means of a special command (Check Sanity). The sanity check is performed on the configuration parameters stored in the editing buffer. This function provides messages which help identify conflicting parameters, inconsistent selection of related parameter values, etc., so that the parameters can be corrected before proceeding. Only after all the validity and sanity checks are successfully passed, can the user save the new (or modified) set of configuration parameters as a database. If the new set is saved under the number of the active configuration database, the Gmux-2000 system will start operating in accordance with the new configuration. Since the last validated sets of configuration parameters are stored in flash memory, Gmux-2000 configuration is not affected when the power is turned off. However, any changes not yet saved will be lost in case the Gmux-2000 is reset or powered down.
Power-up Process
Upon turn-on, the Gmux-2000 central control subsystem checks the validity of the stored configuration data, and if everything is OK, it loads the data into the working memory and reconfigures the system accordingly. Therefore, the Gmux-2000 is ready for operation in accordance with the last active database immediately after power is applied. However, if the configuration data is not valid, the stored database will not be activated; instead, the default database will be activated. To facilitate the correction of the database, you may edit the original database that was not activated and correct whatever was wrong. After the operating parameters have been loaded, a process called configuration set-up, the Gmux-2000 no longer requires operator attendance.
Note
Unless otherwise specified, all the parameter values appearing in the following screens are given for illustration purposes only and do not reflect recommended values.
Working with Telnet

Telnet (IP) Host Characteristics
Typically, the Telnet host is a PC or a Unix station with the appropriate suite of TCP/IP protocols. To enable a Telnet host to communicate, it is necessary to configure the IP address of the Gmux-2000 management subsystem. After this preliminary configuration, you can use a Telnet host directly connected to the CONTROL ETH
Gmux-2000 Ver. 4.0
4-21
Chapter 4 Operation
port of the active CONTROL module in the managed Gmux-2000 to perform additional configuration tasks. However, after configuring the communication parameters of the Gmux-2000 management subsystem, you may also use a Telnet host located at a remote site, the only requirement being that IP communication be established between the LAN serving that site and the LAN connected to the active Gmux-2000 CONTROL ETH port.
General Telnet Operating Procedures

Telnet uses the terminal utility screens for configuration. The only difference is that Telnet management access is possible only after performing a preliminary configuration of the Gmux-2000. To prepare for using Telnet: 1. Configure the Gmux-2000 host IP address.
Note
When the Telnet host is not on a LAN directly connected to the active Gmux-2000 CONTROL ETH port, it is necessary to configure all the IP communication parameters of the CONTROL module.
2. Enable Telnet access.
Using SSH
To secure the management communications, Gmux-2000 uses SSH. Therefore, the PC used to manage the Gmux-2000 via SSH must run an SSH client program, for example, PuTTY (a free, widely available SSH client, running under Windows() and other operating systems). To prepare for using SSH: 1. Configure the Gmux-2000 host IP address.
Note
When the PC running the SSH client is not on a LAN directly connected to the active Gmux-2000 CONTROL ETH port, it is necessary to configure all the IP communication parameters appearing on the Configuration > System > Host IP screen.
2. Enable SSH access. 3. Connect the Ethernet port of the PC to the CONTROL ETH port of the active CL module, or to the same LAN the CONTROL ETH port is attached to. 4. Start the SSH client program, and select the following parameters: Connection type: SSH IP address: use the preconfigured host IP address Port: 54322 (the default SSH port) 5. Open the SSH session with the Gmux-2000.
4-22
Gmux-2000 Ver. 4.0
Chapter 4 Operation
6. You will see the log-in prompt: type the prescribed user name, for example, su, and then press <Enter>. 7. You will see a request for password: enter the prescribed password, for example, 1234, and then press <Enter>. 8. If log in is successful, you will see the main menu.
Working with SNMP Management Stations

Support for SNMP Management
Gmux-2000 can be configured by any SNMP-based network management station, for example, RADview, provided IP communication is possible with the management station. Gmux-2000 supports several management information bases (MIBs). A MIB (Management Information Base) is a hierarchically-organized database of managed objects, where each characteristic of the element to be managed is defined as an object in the MIB. Gmux-2000 supports the following standard MIBs: IANAifType-MIB (ifType table) RFC3418 (SNMPv2 MIB) RFC3592 (SONET-MIB) RFC3635 (EtherLike-MIB) RFC3636 (MAU-MIB) RFC4133 (ENTITY-MIB physicalTable) RFC2819 (RMON MIB) RFC2863 (IF-MIB) RFC2494 (DS0-MIB) RFC3895 (DS1-MIB) RFC3273 (HC-RMON-MIB).
Gmux-2000 also supports the RAD private MIB. Additional MIB information can be obtained from your local RAD Authorized Business Partner. For information on traps, see Chapter 7.
4.4
Turning the Gmux-2000 Off
To turn the Gmux-2000 off: Disconnect its power.
Note
You may also turn any attached NPS-101 off.
Gmux-2000 Ver. 4.0
4-23
Chapter 4 Operation
4-24
Gmux-2000 Ver. 4.0
Chapter 5 Configuration
This chapter provides detailed configuration instructions for Gmux-2000 systems. In addition to the procedures given in this chapter, a complete system configuration also requires configuring the individual modules in accordance with the instructions given in the Installation and Operation Manuals of each module.
Note
Appendix C describes the Gmux-2000 operating environment, and provides technical background information on the various Gmux-2000 configuration parameters.
The configuration activities presented in this Chapter assume that Gmux-2000 is configured using a standard ASCII terminal, as explained in Chapter 4. If you are not familiar with the general supervision terminal operating instructions, review Chapter 4. However, after performing the preliminary configuration of the Gmux-2000 in accordance with Chapter 4, the same configuration activities can also be performed by means of a Telnet host or an SNMP network management station.
Note
Unless otherwise specified, all the parameter values appearing in the following screens are given for illustration purposes only. They do not reflect recommended values.
5.1
Managing Gmux-2000 Configuration Databases
Before starting configuration activities, it is important to understand the Gmux-2000 database tools, used to manage Gmux-2000 databases.
Chapter 4 explains the boot sequence of Gmux-2000 and details different types
of configuration files used at startup.
Gmux-2000 Ver. 4.0
Managing Gmux-2000 Configuration Databases
5-1
5.2
Table 5-1 lists the steps needed to configure a new Gmux-2000. Table 5-1. Gmux-2000 Configuration Sequence
Step 1 Action If the Gmux-2000 is equipped with all the modules, load the hardware configuration. Alternatively, define the modules installed in the chassis manually 2 Using GMUX2000>admin# update-card-types GMUX2000>config>card# card-type
Configure the Gmux-2000 router, bind its ports GMUX2000>config>router(1) to device host and GbE interfaces and define peers Configure specific managers Configure the Gmux-2000 logistic parameters: system name, contact person, system location GMUX2000>config# management manager GMUX2000>config>system# name GMUX2000>config>system# contact GMUX2000>config>system# location
3 4
Set Gmux-2000 real-time clock:
set the time of day. 6 7 8 9 10 Configure physical layer parameters for each module, and each module port Configure timing flow Configure redundancy Configure Gmux-2000 internal routing Configure connection parameters for each bundle
GMUX2000>config>system# date-and-time dateformat GMUX2000>config>system# date-and-time date GMUX2000>config>system# date-and-time time GMUX2000>config>port# GMUX2000>config>system>clock# GMUX2000>config>protection# GMUX2000>config#>cross-connect GMUX2000>config>pwe#
5-2
Gmux-2000 Ver. 4.0
5.3
Programming Modules
Use the following procedure to program modules in the Gmux-2000 chassis. You can program modules even if they are not installed in the chassis.
Loading the Hardware Configuration

If the required system and I/O modules are already installed in the chassis, use the update-card-types command to instruct Gmux-2000 to recognize all card types and record them into its database. To load the hardware configuration: 1. Verify that all necessary system (power supplies, common logic) and I/O cards are installed in the chassis. 2. Navigate to admin. The admin# prompt is displayed. 3. Type the update-card-types command. Gmux-2000 identifies all cards installed in the chassis and writes them into its database.
Programming Modules in the Gmux-2000 Chassis Manually

The system allows you to define the modules installed in the chassis manually. This can be done without actual module installation. To program modules in the Gmux-2000 chassis manually: 1. Navigate to configure card. The config>card# prompt is displayed. 2. Use the card-type command to perform the tasks listed below. 3. Use the no card-type to delete a module from the Gmux-2000 database.
Task Defining power supply modules Defining CONTROL (common logic) modules Defining PSN modules Slot {ps-a | ps-b | ps-c} {cl-a | cl-b} {6 | 8} Module power-supply {ps-ac | ps-dc} cl eth {gbe | gbe-2} SFP-based ports eth eth-2 RJ-45 ports Defining TDM PW server modules Defining TDM PW modules {1 | 2 | 3 | 4 | 5 | 7 | 9} {1 | 2 | 3 | 4 | 5 | 7 | 9} server {srv-28t1 | srv-21e1 | pwsrv-28t1 | pw-srv-21e1} tdm-pw {ces-28t1 | ces-28e1 | pw-28t1 | pw-28e1 | pw-t3 | c.stm1 | c.oc3} sdh-sonet {stm1/d | oc3/d}
Defining SDH/SONET modules
{1 | 2 | 3 | 4 | 5 | 7 | 9}
Gmux-2000 Ver. 4.0
Programming Modules
5-3
For example: To configure a chassis with: Three AC power supply modules Two CONTROL modules One GbE/2 module in slot 6 Five T1-PW/28 modules in slots 15. card-type card-type card-type card-type card-type card-type card-type card-type card-type card-type card-type ps-a power-supply ps-ac ps-b power-supply ps-ac ps-c power-supply ps-ac cl-a cl cl-b cl 6 eth gbe-2 1 tdm-pw pw-28t1 2 tdm-pw pw-28t1 3 tdm-pw pw-28t1 4 tdm-pw pw-28t1 5 tdm-pw pw-28t1
GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card#
To delete the GbE/2 module in slot 6 from the database: GMUX2000>config>card# no card-type 6 To display information on modules defined in the database: At the card# prompt, enter the info command. ps-ac
GMUX2000>config>card# info card-type ps-a power-supply card-type cl-a cl card-type 1 tdm-pw pw-28t1 card-type 2 tdm-pw pw-28t1 card-type 3 tdm-pw pw-28t1 card-type 4 tdm-pw pw-28t1 card-type 5 tdm-pw pw-28t1 card-type 6 eth gbe-2
5.4
Configuring the Router
The Gmux-2000 router is an internal interworking device that forwards user and management traffic between its interfaces. Each router interface is assigned an IP address and can be bound to one of the ports on a PSN module or active CONTROL module. The router supports up to 24 interfaces. Remote devices operating opposite router interfaces are called peers. You can define up to 1000 peers. Network managers (for example, Telnet, SSH hosts or network management stations) that can manage the Gmux-2000, and the parameters controlling their access are added by creating static routes. It is also possible to specify whether a station will receive or not traps generated by the local Gmux-2000.
5-4
Gmux-2000 Ver. 4.0
For each entry, it is possible to define a subnet by specifying the corresponding subnet masks. The total number of entries (managers and static entries) supported by the Gmux-2000 is 100, where the maximum number of managers is 10.
Note
You must include in the manager list all the IP addresses (or IP subnets) to which you want to send pings, and all the static routes that may be needed for GbE ports to reach destination IP addresses which are not within the IP subnet of an exit port. In particular, make sure to include routes for the RADIUS server.
Follow this procedure to configure the Gmux-2000 router: 1. Configure ARP refresh period 2. Configure default gateway 3. Add a router interface and: 1. Define the IP address and subnet mask 2. Bind the router interface to a Gigabit Ethernet port or CONTROL module 3. Choose its management access mode 4. Enable or disable VLAN tagging 4. Add remote peers for outgoing traffic 5. Define static routes to all required destinations that may be needed to reach destination IP addresses which are not within the IP subnet of an exit port. The router is configured at the router(1) level.
Configuring the Address Aging

The aging mechanism allows Gmux-2000 to automatically remove address information regarding dynamically discovered hosts if no traffic is received for a time exceeding the selected aging interval. When the aging is disabled, information is retained even if no traffic is received from discovered addresses. This selection prevents incidental removal of active endpoints if not included in the newly refreshed information. To configure the address aging: 1. Navigate to configure router 1. The config>router(1)# prompt is displayed. 2. Type the arp-timeout command and enter the desired timeout value: 3010000 (seconds). For example: To enable address aging with a 30-second ARP timeout: GMUX2000# config router 1 GMUX2000>config>router(1)# arp-timeout 30
Gmux-2000 Ver. 4.0
5-5
To disable address aging: GMUX2000# config router 1 GMUX2000>config>router(1)# no arp-timeout
Configuring the Default Gateway

If a destination IP address is not within the router interface subnet, you have to specify an IP address of a default gateway. To configure a default gateway: 1. Navigate to configure router 1. The config>router(1)# prompt is displayed. 2. Type the default-gateway command and enter a valid IP address. For example: To a host with the 172.17.160.35 IP address as a default gateway: GMUX2000# config router 1 GMUX2000>config>router(1)#default-gateway 172.17.160.35 To remove a default gateway: GMUX2000# config router 1 GMUX2000>config>router(1)# no default-gateway
Adding and Configuring Router Interfaces

Each router interface is assigned an IP address and can be bound to one of the ports on a PSN module or active CONTROL module. The Gmux-2000 router supports up to 24 interfaces.
Adding a Router Interface

To add a router interface: 1. Navigate to configure router 1. The config>router(1)# prompt is displayed. 2. Type the interface command and enter an interface number in the 124 range. An interface is added and the config>router(1)>interface(number)# prompt is displayed.
Note
Router interfaces must be added in consecutive order. This means interface 5 must be added after interface 4.
5-6
Gmux-2000 Ver. 4.0
For example: To add router interface 5: GMUX2000# config router 1 GMUX2000>config>router(1)# interface 5 To delete router interface 5: GMUX2000# config router 1 GMUX2000>config>router(1)# no interface 5
Configuring a Router Interface

After adding a router interface, you have to configure it. To configure a router interface: At the config>router(1)>interface(number)# prompt, enter all necessary commands according to the tasks listed below:
Command address <valid IP address with mask in the address/mask format> bind {ethernet | giga-ethernet [slot/port]} management-access no management-access vlan <04094> no vlan Comments
Task Assigning IP address and subnet mask to the router interface Binding the router interface to a PSN or common logic module Controlling management access via the router interface, using SNMP, Telnet, SSH Controlling VLAN tagging and defining VLAN ID to be attached to the traffic coming via the router interface Specifying VLAN priority assigned to the traffic coming via the router interface Saving the changes
priority <07>
store
For example: To configure a router interface 1: IP address 10.10.10.10, subnet mask 24 Bound to port 1 of a Gigabit Ethernet module installed in slot 6 Management access disabled VLAN tagging enabled with VLAN ID 100 and priority 4.
Gmux-2000 Ver. 4.0
5-7
GMUX2000# config router 1 interface 1 GMUX2000>config>router(1)>interface(1)# GMUX2000>config>router(1)>interface(1)# GMUX2000>config>router(1)>interface(1)# GMUX2000>config>router(1)>interface(1)# GMUX2000>config>router(1)>interface(1)# To delete router interface 1: GMUX2000>config router 1 no interface 1 Delete interface? (Y/N)? [yes/no] y
address 10.10.10.10/24 bind giga-ethernet 6/1 no management-access vlan 100 priority 4 store
Adding and Configuring Remote Peers

Peers are remote devices operating opposite router interfaces. These devices serve as destinations for pseudowire connections (bundles) for transporting a TDM payload over packet-switched networks. You can define up to 1000 peers. To add and configure a peer: At the config>router(1) # prompt, enter all necessary commands according to the tasks listed below:
Command peer <11000> no peer <11000> Comments Remote peers must be added in consecutive order. This means peer 5 must be added after peer 4.
Task Adding/deleting a peer
Defining IP address of a remote peer in IP network Assigning a name to a remote peer Defining MAC address of a remote peer in a MEF-8 network Selecting a router interface connected to the remote peer in a MEF-8 network
ip <valid IP address> name <alphanumeric string> mac <valid MAC address> interface <124>
For example: To configure remote peer 1: IP address 20.20.20.20 Name west.
GMUX2000>config router 1 peer 1 ip 20.10.20.20 name west To delete remote peer 1: GMUX2000>config router 1 no peer 1 Delete peer? (Y/N)? [yes/no] y
5-8
Gmux-2000 Ver. 4.0
Defining Static Routes

You can add fixed (static) routes to the Gmux-2000 routing table. Paths to network management stations must be defined as static routes. The total number of entries (managers and static entries) supported by the Gmux-2000 is 100, where the maximum number of managers is 10. To configure a static route: At the config>router(1) # prompt, enter the static-route command according to the tasks listed below:
Command static-route <1100><IP address/mask> Comments The static-route command is followed by valid IP address with mask in the address/mask format
Task Adding a static route and defining its IP address and mask
Defining IP address of a next hop host Selecting the interface through which traffic is sent to this manager/destination
address <valid IP address> static-if { cl-interface | giga-a-port-1 | giga-a-port-2 | giga-b-port-1 | giga-bport-2 | vmux-slot-1 | vmux-slot-2 | vmux-slot-3 | vmux-slot-4 | vmux-slot5 | vmux-slot-6 | vmux-slot-7} When the Gmux-2000 includes a voice compression module (or such modules are programmed in the database), you may also see in the list of selectable interfaces the programmed voice compression modules: these interfaces can be used only to manage inband RAD Vmux Voice Trunking Gateway equipment connected to the external data ports of the voice compression modules. At this stage, it is not recommended to configure such interfaces.
Controls the use of VLAN tagging on the static route. If VLAN tagging is enabled you have to specify a VLAN ID and priority.
vlan {tag [id <04094> priority <07>] | no-tag}
For example: To configure a static route:

Gmux-2000 Ver. 4.0
IP address 10.10.10.10 Mask 24 Next hop address 172.17.144.1 Interface CONTROL module VLAN ID 100 VLAN priority 5.
Configuring the Router 5-9
GMUX2000>configure router 1 static-route 10.10.10.10/24 address 172.17.144.1 static-if cl-interface vlan tag id 100 priority 5 To delete a static route: GMUX2000>configure router 1 no static-route 10.10.10.10/24 address 172.17.144.1
5.5
Configuring System Parameters
Use the following procedure to specify logistic information that can be used to identify the specific Gmux-2000 unit, provide contact information for operators of management stations, etc. In addition, you can configure physical layer parameters of the Ethernet management port on CONTROL modules.
Configuring Logistic Parameters

You configure the following logistic information for Gmux-2000: Logical name to distinguish it from the other devices installed in your system Contact information for the person/organization in charge of this unit Location information.
To assign a name to Gmux-2000: 1. Navigate to configure system. The config>system# prompt is displayed. 2. Type the name command and enter a system name: up to 32 alphanumeric characters. For example: To assign the hq name to Gmux-2000: GMUX2000>config>system# name hq To specify a contact information: 1. Navigate to configure system. The config>system# prompt is displayed. 2. Type the contact command and enter contact information: up to 32 alphanumeric characters. For example: To define team1 as a contact: GMUX2000>config>system# contact team1
5-10
Gmux-2000 Ver. 4.0
To specify location information: 1. Navigate to configure system. The config>system# prompt is displayed. 2. Type the location command and enter location information: up to 32 alphanumeric characters. For example: To specify bonn as system location: GMUX2000>config>system# location bonn
Configuring Date and Time

Use the following procedures to: Select the date format. Select the method (source) used to synchronize the internal real-time clock of the Gmux-2000. You have the following options: Manual setting of the initial date and time (identified as the NVRAM method). After the initial setting, the internal clock is free running. Use the NTP (Network Time Protocol) to periodically synchronize the internal clock to the accurate time provided by the worldwide network of NTP time servers (identified as the NTP method). In the interval between consecutive updates, the internal clock is free running In accordance with the selected time synchronization method, perform the following related tasks: Manually update the time-of-day and date of the internal real-time clock Select a time zone and configure the IP address of the desired NTP server.
Note
The internal real-time clock is used to time-stamp various messages, alarms, etc. The previously attached time stamps are not changed when the time-of-day is changed as a result of updates.
To select the Gmux-2000 date format: 1. Navigate to configure system date-and-time. The config>system>date-and-time# prompt is displayed. 2. Type the date-format command and select the required date format: yyyy-mm-dd ISO format dd-mm-yyyy European format mm-dd-yyyy US format Default: yyyy-mm-dd
Note
Gmux-2000 Ver. 4.0
dd stands for day, mm for month and yyyy for year.

Configuring System Parameters 5-11
For example: To define dd-mm-yyyy as a date format: GMUX2000>config>system>date-and-time# date-format dd-mm-yyyy To set the Gmux-2000 date: 1. Navigate to configure system date-and-time. The config>system>date-and-time# prompt is displayed. 2. Type the date command and enter the required date in the correct format. For example: To define January 1, 2010 as the Gmux-2000 date: GMUX2000>config>system>date-and-time# date 2010-01-01 To set the Gmux-2000 time: 1. Navigate to configure system date-and-time. The config>system>date-and-time# prompt is displayed. 2. Type the time command and enter the required time in the hh:mm [:ss] format.
Note
Seconds are optional. It is recommended to set the time about one minute beyond the desired time,
and then save at the correct instant.

For example: To define 18:23 as the Gmux-2000 time: GMUX2000>config>system>date-and-time# time 18:23 To set the Gmux-2000 time zone: At the config>system>date-and-time# prompt, enter the zone command according to the tasks listed below:
Command zone {gmt <-12 | -11 | -10 | -9 | -8 | -7 | -6 | -5 | -4 | -3 | -2 | - 1 | 0 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +10 | +11 | +12 | +13> | user-defined} Comments
Task Defining time zone and offset from the GMT
For example: To set the time zone to GMT +12 hours: GMUX2000>config>system>date-and-time# zone gmt +12
5-12
Gmux-2000 Ver. 4.0
To define an SNTP server: After setting a time zone to GMT, display the config>system>date-time# prompt and enter the sntp command followed by IP address of the SNTP server. no sntp deletes the SNTP server. For example: To define an SNTP server with IP address 30.30.30.30: GMUX2000>config>system>date-and-time# sntp 30.30.30.30
Configuring Ethernet Management Port

Use the following procedure to configure the physical layer parameters of the CONTROL ETH Ethernet port. To configure the Ethernet port parameters: 1. Navigate to configure port. The config>port# prompt is displayed. 2. Select the management Ethernet port by entering a port type (eth), followed by the CONTROL module slot (cl-a or cl-b) and port number (1). The config>port>eth(cl-a | cl-b/1)# prompt is displayed. 3. Configure the physical layer parameters according to the tasks listed below:
Task Controlling autonegotiation Command auto-negotiation no auto-negotiation Define data rate and duplex mode, when autonegotiation is disabled speed-duplex {10-half-duplex | 10-fullduplex | 100-half-duplex | 100-fullduplex} Comments
For example: To configure the CONTROL ETH port: CONTROL module is installed in slot A Autonegotiation is disabled Data rate 100 Mbps Duplex mode full
GMUX2000>configure port eth cl-a/1 GMUX2000>config>port>eth(cl-a/1)# GMUX2000>config>port>eth(cl-a/1)# no auto-negotiation GMUX2000>config>port>eth(cl-a/1)# speed-duplex 100-full-duplex
Gmux-2000 Ver. 4.0
5-13
Configuring Terminal Page Length

When the info command is entered, amount of text displayed in a terminal window may exceed screen capacity. In this case Gmux-2000 truncates text flow with more. To continue, the user must press <Enter>. If there is a need to capture terminal window content, truncated text becomes unusable for saving it as a .txt file for future use. To prevent this, Gmux-2000 allows setting a number of lines displayed between two consecutive more entries, using the length command in the config>terminal# prompt. Setting number of lines to 0 cancels breaks in text flow after executing info command. To configure terminal page length: 1. Navigate to configure terminal. The config>terminal# prompt is displayed. 2. In the config>terminal# prompt, enter terminal and set its value: 0255. For example: GMUX2000>configure teminal GMUX2000>config>terminal# GMUX2000>config>terminal length 0
5.6
Configuring the Clock
The system timing flow is determined by selecting the timing reference of the Gmux-2000 timing system. The Gmux-2000 timing subsystem can use as reference the following types of signals: Timing reference signal from a selected SDH port. This option is preferable for Gmux-2000 units connected to an SDH backbone, because large SDH networks usually have highly accurate and stable master timing sources. External (station) signal (2.048 MHz or 1.544 MHz) received from a station clock port of the CONTROL module. This option also provides a convenient way for using a high-quality master timing source available at the equipment site. Internal oscillator. This source is sufficient for use as reference in a stand-alone network, not connected to a backbone (or during maintenance activities). In this configuration, the Gmux-2000 unit selected as the timing master of the network uses its internal oscillator as source, and all the other equipment units lock their timing to that Gmux-2000. Note that only one Gmux-2000 unit in the whole network may use this source. Signal from a selected E1 port. The source of this signal may be selected from the following options: Clock signal recovered from an external E1 port
5-14
Gmux-2000 Ver. 4.0
Clock signal recovered from an internal E1 port This timing mode is suitable for tail-end Gmux-2000 units, which can extract a good-quality clock from a directly connected E1 port.
Configuring Domain Timing

The domain timing reference of Gmux-2000 consists of a master source and a fallback clock source. Both can be configured to use separate timing references. The internal oscillator is automatically selected as source in case all the other sources (master and fallback) fail: therefore, it cannot be selected as fallback source. To define the domain timing: At the config>system>clock#, enter domain 1. domain 1# prompt is displayed. At the config>system>clock>domain 1#enter the master and fallback commands according to the tasks listed below:
Command master {internal | rx-port port <slot/port> [port-type {e1 | t1 | stm | voice-e1 | data-e1 | voice-t1 | data-t1} | station id <1 | 2>} fallback {rx-port port <slot/port> | station id <1 | 2>} no fallback Comments
Task Defining a master clock source
Defining a fallback clock source
For example: To configure the domain clock to receive timing: Receive clock source E1 port 7 of a module installed in slot 1 Fallback clock is disabled
GMUX2000>config>system>clock>domain# master rx-port port 1/7 port-type e1 GMUX2000>config>system>clock>domain# no fallback
Configuring the External (Station) Clock

You need to configure the external (station) clock interfaces when using an external clock port, station, as timing reference. To configure the station clock: At the config>system>clock>station# prompt, enter all necessary commands according to the tasks listed below:
Gmux-2000 Ver. 4.0
5-15
Task Defining the station clock mode Selecting the interface type
Command clock-mode {normal | y-cable} interface-type {e1 <balanced | unbalanced> | t1 | RS-485-e1 | RS-485t1} no shutdown
Comments
Enabling the station clock
For example: To configure the station clock: Normal mode Balanced E1 interface type
GMUX2000>config>system>clock>station# clock-mode normal GMUX2000>config>system>clock>station# interface-type e1 balanced GMUX2000>config>system>clock>station# no shutdown
5.7
Configuring Network Managers
For static route destinations you can specify whether they serve as management stations (see Defining Static Routes). You can also define if a network manager is going to receive traps generated by Gmux-2000. To define a network manager: 1. Navigate to configure management. The config>mgmt# prompt is displayed. 2. Type the manager command and enter an IP address of a management station. The NMS must be already defined as a static route destination. 3. Use the trap-mask/no trap-mask command to control sending traps to the manager. For example: To configure network managers: Add NMS with IP address 10.10.10.10 to the manager list, disable sending traps to this destination. Remove NMS with IP address 20.20.20.20 from the manager list.
GMUX2000>config>mgmt# manager 10.10.10.10 trap-mask GMUX2000>config>mgmt# no manager 20.20.20.20
5-16
Configuring Network Managers
Gmux-2000 Ver. 4.0
5.8
Configuring SNMP Communities
If you want to enable SNMP management, you must define SNMP community names. To define SNMP communities: At the config>mgmt>snmp# prompt, enter the community command according to the tasks listed below:
Command community {read value | write value | trap value} Comments
Task Defining the community names
For example: To configure SNMP community gmux with read-write access rights: GMUX2000>config>mgmt>snmp# community write gmux
5.9

Configuring Protection
Two types of redundancy are supported: Gmux-2000 control subsystem redundancy. Redundancy at the I/O module level. Currently, Gmux-2000 supports the following redundancy capabilities: APS for the SDH and PSN interface modules. 1:N protection. The current Gmux-2000 version supports 1:N protection for the following types of modules: When connected to a NPS-101, Gmux-2000 supports 1:N protection for voice compression modules and pseudowire emulation modules with external ports Without an NPS-101, the 1:N protection mode is supported only for pseudowire server modules, and for voice compression modules operating with internal ports only Only one 1:N protection group can be configured in the chassis. Refer to Chapter 2 for a description of the I/O redundancy options. Pseudowire bundle redundancy
This section explains how to configure redundancy for Gmux-2000.
Configuring Gmux-2000 Control Subsystem Redundancy

Redundancy for the Gmux-2000 control subsystem is supported only when the Gmux-2000 chassis includes two operational CONTROL modules: if only one is installed, it is automatically selected and redundancy cannot be activated.
Gmux-2000 Ver. 4.0 Configuring Protection 5-17
You can also use the redundancy control function to force the Gmux-2000 to use a specific CONTROL module, for example, in preparation for CONTROL module replacement. To select the desired CONTROL redundancy mode: At the config>protection>cl-card# prompt, enter the mode command according to the tasks listed below:
Command mode {auto | manual <cl-a | cl-b> Comments
Task Defining CONTROL module redundancy mode
Caution
To prevent CONTROL module lockout, always change manual mode to automatic after forcing to use a specific common logic module. For example: To force CONTROL module installed in the CTRL.1 slot to be the online common logic module:
GMUX2000>config>protection>cl-card# mode manual cl-a GMUX2000>config>protection>cl-card# mode automatic cl-a To display the CONTROL module redundancy status: GMUX2000>config>protection>cl-card# show status Mode : Manual Current Working : CL A Redundancy Status : OK
Configuring the SONET APS

Use the following procedure to configure redundancy for the Gmux-2000 SONET interface subsystem. Refer to Chapter 2 for a description of the redundancy options available for the SONET interface subsystem when using the dual-port OC-3 modules. Redundancy is activated by configuring APS (Automatic Protection Switching) groups using 1+1 unidirectional, 1+1 bidirectional or 1+1 bidirectional optimized protection on the appropriate OC-3 ports.
Note
APS group cannot be created between C.OC3 links in slots 7 and 9. When configuring APS and PW redundancy on C.OC3 modules, configure APS
first, and PW redundancy second.

To add an APS group: 1. Navigate to configure protection. 2. Type aps and enter an APS group name. The config>protection>aps(group name)# prompt is displayed.
5-18
Gmux-2000 Ver. 4.0
To configure the SDH APS: At the config>protection>aps(group name)# prompt, enter all necessary commands according to the tasks listed below:
Command bind {protection sdh-sonet <slot/port> | working sdh-sonet <slot/port>} no bind Selecting whether to take the SD condition into consideration for the link flip Defining operation mode of the APS Selecting the recovery (service restoration) mode Defining the wait-to-restore period for the revertive recovery mode Saving the changes flip-upon-sd no flip-upon-sd oper-mode {uni-directional | optimized1-plus-1 | compatible-1-plus-1} revertive no revertive wait-to-restore <0720> The unit of time is seconds All three APS modes are supported by the C.OC3 modules only Comments Using no before bind removes a link from protection group
Task Defining standby and active links
store
For example: To add and configure an APS group: APS group name test Active link Port 2 of the module installed in slot 9 Standby link Port 1 of the module installed in slot 9 Recovery mode revertive Wait-to-restore period 200 seconds.
GMUX2000# configure protection aps test bind working sdh-sonet 9/2 GMUX2000>config>protection>aps(test)# bind protection sdh-sonet 9/1 GMUX2000>config>protection>aps(test)# revertive GMUX2000>config>protection>aps(test)# wait-to-restore 200 GMUX2000>config>protection>aps(test)# store To delete APS group named test: GMUX2000#configure protection no aps test
Configuring 1:N Protection

Gmux-2000 modules support 1:N protection for I/O modules installed in the chassis. The current Gmux-2000 version has the following capabilities: When connected to NPS-101, Gmux-2000 supports 1:N protection for voice compression modules and pseudowire emulation modules with external ports
Gmux-2000 Ver. 4.0
5-19
Without an NPS-101, the 1:N protection mode is supported only for pseudowire server modules, and for voice compression modules operating with internal ports only
Only one 1:N protection group can be configured in the chassis. An 1:N protection group for I/O modules is formed by adding a spare (standby, or protection) module to a group of N modules that carry the traffic (the protected modules). All the modules in an 1:N protection group must be of the same type. To provide differential quality of service, it is possible to define two protection priority levels, low and high: in the event that protection is required for two modules in the 1:N protection group at the same time, only the high priority module will be protected.
Note
Gmux-2000 supports a single 1:N protection group for I/O modules per chassis. Therefore, if another 1:N protection group for I/O modules is already configured, first delete it.
To add an I/O protection group: 1. Navigate to configure protection. 2. Type io-group and enter a group ID (116). The config>protection>io-group(group id)# prompt is displayed. To configure the I/O protection group: At the config>protection>io -group(group id)# prompt, enter all necessary commands according to the tasks listed below:
Command bind protection {io-1 | io-2 | io-3 | io-4 | io-5 | io-7 | io-9} bind working {<io-1 | io-2 | io-3 | io-4 | io-5 | io-7 | io-9> <priority 0 | priority 1>} no bind oper-mode n-to-1 revertive no revertive wait-to-restore <120720> The unit of time is seconds Comments Using no before bind removes a module from protection group
Task Defining active and standby modules and set the active module priority
Defining operation mode of the I/O protection group Selecting the recovery (service restoration) mode Defining the wait-to-restore period for the revertive recovery mode Saving the changes
store
For example: To add and configure a 1:N protection group: Protection group ID 2 Active module 1 (low priority) Module installed in slot 1
5-20
Gmux-2000 Ver. 4.0
Active module 2 (high priority) Module installed in slot 2 Standby module Module installed in slot 3 Recovery mode revertive Wait-to-restore period 200 seconds. 2 bind working io-1 priority 0 bind working io-2 priority 1 bind protection io-3 revertive wait-to-restore 200 store
GMUX2000# configure protection io-group GMUX2000>config>protection>io-group(2)# GMUX2000>config>protection>io-group(2)# GMUX2000>config>protection>io-group(2)# GMUX2000>config>protection>io-group(2)# GMUX2000>config>protection>io-group(2)#
To delete protection group named test: GMUX2000#configure protection no io-group 2 To display status of protection group 2: GMUX2000>config>protection>io-group(2)#s how status Group ----------------------------------------------------------------------------Current Working : 4 Operational : Up Current Working : 5 Operational : Up
Configuring Pseudowire Bundle Protection

Gmux-2000 features a bundle protection (redundancy) capability. This feature enables the user to backup the pseudowire traffic in case of fault at the bundle connection level. This feature permits the user to set a different path for the primary bundle and for the secondary bundle (different packet-switched networks, different links, different TDM pseudowire gateways, etc) and thus rely on two routes, which are not influenced by the same faulty PSN conditions. Gmux-2000 supports 1+ 1 bundle redundancy.
Note
When configuring APS and PW redundancy on C.OC3 modules, configure APS first, and PW redundancy second.
To add a PW protection group: 1. Navigate to configure protection. The config>protection# prompt is displayed. 2. Type pw and enter a PW APS number (17600). The config>protection>pw(number)# prompt is displayed.
Note
PW redundancy groups must be added in consecutive order. This means APS 5 must be added after APS 4.
Gmux-2000 Ver. 4.0
5-21
To configure the PW protection group: At the config>protection>pw(number)# prompt, enter all necessary commands according to the tasks listed below:
Command bind {primary <number> | secondary <number>} no bind Defining operation mode of the APS Saving the changes mode 1-plus-1 store Comments Using no before bind removes a bundle from protection group
Task Defining primary and secondary bundles
For example: To add and configure a PW protection group: Protection group number 17 Active bundle 1 Standby bundle 2.
GMUX2000# configure protection pw 17 bind primary 1 GMUX2000>config>protection>pw(1)# bind secondary 2 GMUX2000>config>protection>pw(1)# store To delete protection group 17: GMUX2000#configure protection no pw 17
5.10 Configuring the LAG

Link aggregation is a method of setting up a high-speed Ethernet link that transfers more data than any one single port of the device can deliver. It also provides inherent, automatic redundancy on point-to-point links. In other words, if one of the ports used in a link fails, network traffic is dynamically redirected to flow across the remaining good port in the link. Link Aggregation Groups (LAGs) are created by combining several interfaces into one logical link to increase bandwidth and improve reliability while saving the cost of upgrading the hardware. By increasing the link speed beyond limits of any one single port, LAGs offer network channels tailored to need, filling the gaps between 10 Mbps, 100 Mbps and 1 Gbps with intermediate bandwidth values. This allows networks to grow incrementally as demand on the network increases, without having to replace everything and buy new hardware.
5-22
Configuring the LAG
Gmux-2000 Ver. 4.0
Figure 1. Two Gigabit Ethernet Ports Combined into a LAG

The load sharing is automatically readjusted if a failure or recovery from failure occurs in any of the links that participate in a LAG. The load sharing is automatically readjusted if a failure or recovery from failure occurs in any of the links that participate in a LAG. Port aggregation is available for GbE ports on the same or different modules.
LAG Benefits
Static LAGs provide the following benefits: Increased bandwidth The capacity of multiple interfaces is combined into one logical link. Besides increasing bandwidth, link aggregation also provides intermediate data rate levels between the standard data rates of 10 Mbps, 100 Mbps, 1000 Mbps. Increased availability If a link within a LAG fails or is replaced, the traffic is not disrupted and communication is maintained (even though the available capacity is reduced). Load sharing Traffic is distributed across multiple links, minimizing the probability that a single link could be overwhelmed. Use of existing hardware Software replaces the need to upgrade the hardware to higher bandwidth capacity. Link aggregation always provides revertive recovery, because that as soon as the down port returns to normal, the full bandwidth is again available.
Configuring the LAG

LAG configuration includes the following steps: 1. Assigning a number to a LAG. 2. Binding ports to the LAG 3. Assigning a name to the LAG 4. Storing the LAG.
Gmux-2000 Ver. 4.0
Configuring the LAG
5-23
To add a LAG: 1. Navigate to configure port. The config>port# prompt is displayed. 2. Type lag and enter a LAG number (116). The config>port>lag(number)# prompt is displayed.
Note
LAGs must be added in consecutive order. This means LAG 5 must be added after LAG 4.
To configure the LAG: At the config>port>lag(number)# prompt, enter all necessary commands according to the tasks listed below:
Command bind giga-ethernet <slot/port> no bind name <alphanumeric string> Comments Using no before bind removes a link from LAG
Task Adding a Gigabit Ethernet port to the LAG Assigning a name to the LAG
For example: To create a LAG: LAG number 1 LAG members Port 1 of a PSN module installed in slot 6 and port 1 of a PSN module installed in slot 8.
GMUX2000#configure port lag 1 GMUX2000>config>port>lag(1)# bind giga-ethernet 6/1 GMUX2000>config>port>lag(1)# bind giga-ethernet 8/2 To delete a LAG 1: GMUX2000# configure port no lag 1 To display information on existing LAG: GMUX2000#configure>port>lag(1)# info name test bind giga-ethernet 6/1 bind giga-ethernet 8/2 store
5.11 Configuring Service OAM

Ethernet Service OAM is a set of functions for managing Ethernet services as specified by the IEEE 802.1ag and ITU-T Y.1731 standards. It allows service providers to operate, administer, and maintain Ethernet services.
5-24
Configuring Service OAM
Gmux-2000 Ver. 4.0
The Connectivity Fault Management (CFM) uses an end-to-end Ethernet layer OAM protocol for proactive connectivity monitoring, fault verification, and fault isolation. These actions are performed using IEEE 802.1ag standard Layer 2 ping, Layer 2 traceroute, and end-to-end connectivity check of Ethernet networks. To configure the service OAM: 1. Configure general OAM parameters (EtherType and multicast MAC address) 2. Add and configure maintenance domain(s) (MD). 3. Configure maintenance associations for the added MDs. 4. Configure MA endpoints, referred as MEPs. 5. Configure MEP services.
Configuring General OAM Parameters

If necessary you can define EtherType or multicast MAC address for OAM CFM messages. To configure general OAM parameters: 1. Navigate to configure oam cfm. The config>oam>cfm# prompt is displayed. 2. Enter the ethertype command and define an EtherType of the OAM CFM messages: 0ffff. 3. Enter the multicast-addr command and define a multicast MAC address for the OAM CFM messages. For example: To define 12-34-56-78-90-AB as multicast MAC address for OAM CFM messages: GMUX2000>config>oam>cfm# multicast-addr 12-34-56-78-90-AB
Adding and Configuring Maintenance Domains

MDSs are domains for which the connectivity faults are managed. Each MD is assigned a name which must be unique among all those used or available to an operator. The MD name facilitates easy identification of administrative responsibility for the maintenance domain. You can add up to 16 maintenance domains. To add a maintenance domain: 1. Navigate to configure oam cfm. 2. Type maintenance-domain and enter a domain number (116). The config>oam>cfm>md (number)# prompt is displayed. To configure a maintenance domain: At the config>oam>cfm>md (number)# prompt, enter all necessary commands according to the tasks listed below:
Gmux-2000 Ver. 4.0
5-25
Task Defining a maintenance domain level Specifying the name format and the name of the maintenance domain Specifying the OAM mechanism type
Command md-level <0 | 1 | 2 | 3 | 4 | 5 | 6 | 7>
Comments
name {string <value> | dns <value> | mac-and-uint <value> <value>} no name proprietary-cc no proprietary-cc
For example: To create an MD: MD number 1 MD name test.
GMUX2000# configure oam cfm maintenance-domain 1 GMUX2000>config>oam>cfm>md(1)# name string test To delete MD 1: GMUX2000>config>oam>cfm# no maintenance-domain 1
Adding and Configuring Maintenance Associations

A maintenance domain contains up to 16 maintenance associations, for each of which you can configure the continuity check interval and up to 8191 maintenance endpoints (MEPs). To add a maintenance association: In the config>oam>cfm>md(number)# prompt, type maintenance-association and enter an association number (116). The config>oam>cfm>md (number)>ma(number)# prompt is displayed. To configure a maintenance association: At the config>oam>cfm>md (number)> ma(number)# prompt, enter all necessary commands according to the tasks listed below:
Command ccm-interval <100ms | 1s | 10s | 1min | 10min> name {string <value> | primary-vid <value> | uint <value> icc <value>} no name Comments
Task Specifying an interval between continuity check messages. Specifying the name format and the name of the maintenance association
5-26
Gmux-2000 Ver. 4.0
For example: To create an MA: MA number 1 MA name test.
GMUX2000# configure oam cfm maintenance-domain 1 maintenance-association 1 GMUX2000>config>oam>cfm>md(1)>ma(1)#name string test To delete MA1: GMUX2000>config>oam>cfm>md(1)#no maintenance-association 1
Adding and Configuring Maintenance Endpoints

Maintenance endpoints reside at the edge of a maintenance domain. They initiate and respond to CCMs, linktrace requests and loopbacks to detect, localize and diagnose connectivity problems. A maintenance association contains up to 8191 maintenance endpoints (MEPs). To add a maintenance endpoint: At the config>oam>cfm>md(number)>ma(number)# prompt, type mep and enter an endpoint number (18191). The config>oam>cfm>md (number)>ma(number)>mep(number)# prompt is displayed. To configure a maintenance endpoint: At the config>oam>cfm>md (number)>ma(number)>mep(number)# prompt, enter all necessary commands according to the tasks listed below.
Command bind <slot/port> ccm-initiate no ccm-initiate ccm-priority <0 | 1 | 2 | 3 | 4 | 5 | 6 | 7> dest-addr-type <multicast | unicast> dest-mac-addr <valid MAC address> remote-mep <18191> no remote-mep <18191> Specifying VLAN ID Specifying continuity verification method Enabling MEP vlan <14094> continuity-verification <cc-based | lbbased> no shutdown Comments
Task Binding a MEP to a Gigabit Ethernet port Controlling CCM initiation by the MEP Selecting CCM priority Specifying destination MAC address type Setting destination MAC address Defining remote MEP
Gmux-2000 Ver. 4.0
5-27
For example: To configure a MEP 1: Bound to GbE port 1 in slot 6 CCM activated CCM priority 2 Destination MAC address unicast 12-34-56-78-90-ab VLAN ID 7 Remote MEP 8.
GMUX2000# configure oam cfm maintenance-domain 1 maintenance-association 1 mep 1 GMUX2000>config>oam>cfm>md(1)>ma(1)>mep(1)# bind giga-ethernet 6/1 GMUX2000>config>oam>cfm>md(1)>ma(1)>mep(1)# ccm-initiate GMUX2000>config>oam>cfm>md(1)>ma(1)>mep(1)# ccm-priority 2 GMUX2000>config>oam>cfm>md(1)>ma(1)>mep(1)# dest-addr-type unicast GMUX2000>config>oam>cfm>md(1)>ma(1)>mep(1)# dest-mac-addr 12-34-56-78-90-ab GMUX2000>config>oam>cfm>md(1)>ma(1)>mep(1)# vlan 7 GMUX2000>config>oam>cfm>md(1)>ma(1)>mep(1)# remote-mep 8 GMUX2000>config>oam>cfm>md(1)>ma(1)>mep(1)# no shutdown To delete a maintenance endpoint 1: GMUX2000>config>oam>cfm>md(1)>ma(1)> no mep 1
Adding and Configuring Maintenance Endpoint Services

You can configure up to eight services in one MEP. Each service sets delay and delay variation thresholds. If the thresholds are exceeded the service is declared as degraded. You can also define priority of OAM messages originating from this service. To add a MEP service: At the config>oam>cfm>md(number)>ma(number)>mep(number)# prompt, type service and enter a MEP service number. The config>oam>cfm>md (number)>ma(number)>mep(number)>service(number)# prompt is displayed. To configure a MEP service: At the config>oam>cfm>md (number)>ma(number)>mep(number) service (number)# prompt, enter all necessary commands according to the tasks listed below.
Command delay-threshold <11000> delay-var-thres <11000> Comments The unit of time is milliseconds The unit of time is milliseconds
Task Defining a delay threshold Defining s delay variation threshold
5-28
Gmux-2000 Ver. 4.0
Task Specifying priority of OAM messages originating from the service Activate the MEP service
Command priority <07>
Comments
no shutdown
For example: To configure a MEP service 1: Delay threshold 200 msec Delay variation threshold 20 msec Priority 2. delay-threshold 200 delay-var-thres 20 priority 2 no shutdown
GMUX2000>config>oam>cfm>md(1)>ma(1)>mep(1)# service 1 GMUX2000>config>oam>cfm>md(1)>ma(1)>mep(1)>service(1)# GMUX2000>config>oam>cfm>md(1)>ma(1)>mep(1)>service(1)# GMUX2000>config>oam>cfm>md(1)>ma(1)>mep(1)>service(1)# GMUX2000>config>oam>cfm>md(1)>ma(1)>mep(1)>service(1)# To delete a MEP service 1:
GMUX2000>config>oam>cfm>md(1)>ma(1)>mep(1)# no service 1
Performing OAM Loopback

This diagnostic utility verifies OAM connectivity on Ethernet connections. You can execute the loopback according to the destination MAC address or the remote maintenance end point (MEP) number.
Note
The option for remote MEP ID is available only if Gmux-2000 can resolve at least one remote MEP MAC address.
To run an OAM loopback: At the config>oam>cfm>md (number)>ma(number)>mep(number)# prompt, enter all necessary commands according to the tasks listed below.
Command address <valid MAC address> remote-mep <18191> Comments
Task Defining a MAC address of the destination device Defining s a MEP ID of another MEP in the same MA to which to the loopback will be sent Specifying number of loopback messages to send
repeat-num <050>
Gmux-2000 Ver. 4.0
5-29
For example: To check connectivity to a remote MEP: Remote MEP number 2 Number of loopbacks 30.
GMUX2000>config>oam>cfm>md(1)>ma(1)>mep(1)# lbm remote-mep 2 repeat 30 To display OAM loopback results: At the config>oam>cfm>md (number)>ma(number)>mep(number)# prompt, enter show lbm-results. : : : : : : : 1 11:11:11:11:11:11 1 1 1 1 1
Remote MEP ID Destination Address Messages Sent Replies In Order Replies Out Of Order Messages Lost/Timed Out Messages Lost/Timed Out %
Figure 5-2. OAM Loopback Results Table 5-2. OAM Loopback Results
Parameter Remote MEP ID Destination Address Messages Sent Replies In-Order Replies Out-ofOrder Messages Lost/Timed out Messages Lost/Timed out % Description IP of the remote MEP The target MAC address of the loopback message Number of loopback messages that were sent The number of replies to loopback that were received in order The number of replies to loopback that were received out of order The number of loopback messages that were lost or timed out, calculated by the total number of loopback messages sent minus the number of successful and unsuccessful replies received The percentage of loopback messages that were lost or timed out 050 050 050 050 Possible Values
04,294,967,295
Performing OAM Link Trace

This diagnostic utility traces the OAM route to the destination, specified either by the MAC address or the maintenance end point (MEP).
Note
The option to specify the destination MEP ID is available only if Gmux-2000 can resolve at least one remote MEP MAC address.
5-30
Gmux-2000 Ver. 4.0
To run an OAM link trace: At the config>oam>cfm>md (number)>ma(number)>mep(number)# prompt, enter all necessary commands according to the tasks listed below.
Command address <Valid MAC address> remote-mep <18191> Comments
Task Defining a MAC address of the destination device Defining s a MEP ID of another MEP in the same MA to which to the link trace will be sent Specifying number of hops. Each unit in the link trace decrements the TTL until it reaches 0, which terminates the link trace.
ttl <164>
To display OAM link trace results: At the config>oam>cfm>md (number)>ma(number)>mep(number)# prompt, enter show linktrace-results.
Ingress ----------------------------------------------------------------------------Hop MAC Address Ingress Action Port Relay Action ----------------------------------------------------------------------------1 11:11:11:11:11:11 No TLV port-ingr* Hit -----------------------------------------------------------------------------
Figure 5-3. Link Trace Results (Ingress) Table 5-3. Link Trace Result Parameters
Parameter Hop MAC Address Description The hop number on the way to the target, calculated by the sent TTL value minus the received TTL value The MAC address of the entity that sent the LTR Possible Values 164 00-00-00-00-00-00 through FF-FF-FF-FF-FF-FF IngOK, IngDown, IngBlocked, IngVID; EgrOK, EgrDown, EgrBlocked, EgrVID Port ID Relay Action Port that was used for hop The relay action RlyHit, RlyFDB, RlyMPDB
Ingress/Egress Action
Ingress or egress action that was taken in hop
Gmux-2000 Ver. 4.0
5-31
5.12 Configuring Pseudowire Connections

A bundle is a collection of parameters that define the way payload will be transported from a local Gmux-2000 port, through the transport network, and down to a remote destination supporting the same capabilities. Packet formats can be selected on a per-bundle basis for optimal transmission over UDP/IP-based networks, and when applicable over metro Ethernet network. Each bundle can be independently routed to any destination. The following user-configurable protocols are supported, independently for each bundle: TDMoIP (TDM over IP) in accordance with RFC5087 HDLCoPSN (HDLC over PSN) in accordance with RFC5087 and RFC4618 (except Clause 5.3 PPP) CESoPSN (structure-aware TDM circuit emulation over PSN) in accordance with RFC5086. In a Gmux-2000 with GbE/2 modules, CESoPSN is also supported over Ethernet networks in accordance with MEF 8. SAToPSN (structure-agnostic TDM over PSN) in accordance with RFC4553. In a Gmux-2000 with GbE/2 modules, SAToPSN is also supported over Ethernet networks in accordance with MEF 8. TDMoIP compressed voice (CV) bundles
Note
TDMoPSN, HDLCoPSN, CESoPSN and SAToPSN bundles are supported by
pseudowire modules.
TDMoIP (CV) bundles are supported by voice compression modules operating
in the voice trunking mode.

The maximum number of bundle (connection) configurations that may be stored in the Gmux-2000 is 2000, where each bundle is assigned a unique index number in the range of 1 to 2000. The actual maximum number, however, depends on the number and type of modules installed in the chassis. Chapter 2 provides information regarding the number of modules of each type that are supported by the current Gmux-2000 version. No bundles are included in the Gmux-2000 factory defaults: you must define your own in accordance with your application requirements. To be able to create a bundle, first make sure that all the TDM external and internal ports, as well as the network ports that will carry the bundle and participate in its processing, have already been configured and defined as no shutdown. The configuration of a bundle includes the following main activities: 1. Select the bundle structure: the structure is determined by the connection mode and PSN type. 2. Configure the bundle parameters corresponding to the selected structure. During bundle configuration, you can also choose whether to activate the bundle configuration data, or just save it in the database without the bundle being used by any module (as long as it is in shutdown state).
5-32 Configuring Pseudowire Connections Gmux-2000 Ver. 4.0
When you try to save the bundle configuration, the Gmux-2000 automatically checks its parameters to verify that the bundle appears to be correctly defined, without configuration conflicts or obvious errors such as incorrect IP addresses, etc. Any errors are reported; they must be corrected for the bundle to be saved.
Note
After a bundle becomes active, it is not recommended to change bundle
parameters or parameters of the ports and subsystems handling the bundle. You should first delete the bundle defined on a module when that module is removed from the Gmux-2000.
It is not recommended to delete a bundle while it is active (no shutdown); first
change its state to shutdown.
Adding a Pseudowire Bundle

New pseudowire bundles are added by defining their number (12000), type (connection mode) and a PSN type. To add a bundle: At the config>pwe# prompt, enter the command according to the tasks listed below.
Command pw<12000> no pw<12000> type {ces-psn-data | e1satop | t1satop | tdmoip | tdmoip-cv | hdlc} Comments Using no before pw(number) deletes the bundle hdlc: bundle for carrying HDLC traffic using the HDLCoPSN protocol tdmoip: bundle for TDMoPSN circuit emulation, can carry data and voice timeslots, as well as unframed data e1satop/ t1satop: bundle using the SAToPSN protocol, for carrying an unframed data stream ces-psn-data: bundle using the CESoPSN protocol, for carrying framed data streams. tdmoip-cv: bundle carrying compressed voice (CV) using the TDMoPSN protocol. Defining PSN type psn {udp-over-ip | ethernet} udp-over-ip UDP over IP with standard packet structure (see note below) ethernet only for SAToP and CES bundles (supported only when Gmux-2000 is equipped with GbE/2 modules). Defining label distribution mode manually Currently this parameter is permanently set to manually
Task Defining bundle number Specifying bundle type
Gmux-2000 Ver. 4.0
Configuring Pseudowire Connections
5-33
Note N t
If you need to know the number of the source UDP port of a bundle, you can find it as follows (unless noted otherwise, all numbers are in hexadecimal notation): For TDMoIP (CE) bundles using packet payload Version V1: During normal operation, the source UDP port is given by: UDP Source Port = 1 + Destination Bundle Number This means that during normal operation, the UDP ports numbers are in the range of 0 to 8191 decimal. While the bundle is in the local fail state, the source UDP port changes to: UDP Source Port = 8000 + Destination Bundle Number This means that in the local fail state, the UDP ports numbers are higher than 8000 hexa (32768 decimal). For TDMoIP (CE) bundles using packet payload Version V2: UDP Source Port = 2000 + Destination Bundle Number This means that all the UDP ports numbers are higher than 2000 hexa (8192 decimal). For CESoPSN and SAToPSN bundles using packet payload Version V2: UDP Source Port = C000 + Destination Bundle Number This means that all the UDP ports numbers are higher than C000 hexa (49152 decimal).
For example: To create a PW: PW number 1 PW type CESoPSN PSN type UDP/IP.
GMUX2000>config>pwe# pw 1 type ces-psn-data psn udp-over-ip manually To delete PW 1: GMUX2000> config>pwe# no pw 1 Delete Bundle? (Y/N)? [yes/no]
Configuring a Pseudowire Bundle

Gmux-2000 presents configuration parameters relevant only to the current bundle and PSN type.
Configuring a TDMoIP (CE) Bundle

To configure TDMoIP (CE) bundle: 1. Add a TDMoIP bundle with UDP/IP network encapsulation as explained in Adding a Pseudowire Bundle above. 2. At the config>pwe>pw(number)# prompt, enter all necessary commands according to the tasks listed below.
5-34
Gmux-2000 Ver. 4.0
Task Controlling the adaptive timing recovery mechanism for the PW Selecting source and destination circuit bundle identifiers (CBID), also referred to as PW labels
Command adaptive-clock no adaptive-clock
Comments If adaptive clock is enabled, the bundle is automatically selected as timing reference for the E1 port to which it is connected when the port timing mode is Adaptive. Each bundle must have a unique in (source) label. Do not reuse the same out (destination) value on bundles terminating at the same peer, and/or using the same VLAN ID (when VLAN tagging is enabled).
label [out <17000>] [in <1 7000>]
Specifying the type of framing used by the equipment at the destination endpoint Defining the jitter buffer size in msec. Specifying the handling of packets received after a delay exceeding that for which the jitter buffer can compensate. Controlling the use of the OAM connectivity protocol for this PW Defining a remote peer Selecting the response to out-of-service conditions detected at the local E1 physical port Specifying the number of TDM payload bytes to be inserted in each packet
far-end-type {e1 | t1-esf | t1-sf | unframed}
The selected value also determines the encoding law used on PCM voice channels
jitter-buffer <0200> [sensitivity <data | delay>]
Use the shortest feasible buffer, to minimize connection latency
oam {disable | proprietary}
The selection must be compatible with the equipment at the far end of the connection
peer <11000> psn-oos {l-bit | stop-tx} OOS conditions are reported by setting the L bit within the TDMoIP packet overhead A larger value increases the bandwidth utilization efficiency, but also increases the connection intrinsic latency, in particular when the bundle is configured to carry a small number of timeslots. Refer to the Selection Guidelines for TDM Payload Bytes per Frame section below for selection consideration. The number is specified as a multiple of 48 bytes, for example, 1 means 48 bytes, and 30 means 1440 bytes.
tdm-payload {size <130>}
Specifying the Layer-3 priority assigned to the traffic generated by the PW
tos <0255>
In accordance with RFC 2474, it is recommended to use only values which are multiples of 4
Gmux-2000 Ver. 4.0
5-35
Task Configuring VLAN tagging for the traffic generated by the PW Selecting the payload format Activating the PW bundle
Command vlan {no-tag | tag-tagged | tagdouble} [c-id <04094>] [c-priority <07>] [s-id <0 4094>] [s-priority <07>] version {v1 | v2} no shutdown
Comments
For example: To configure a TDMoIP PW with UDP/IP network encapsulation: PW number 1 PW type TDMoIP PSN type UDP/IP Adaptive clock disabled Out (destination) label 3 In (source) label 2 Far end type T1 ESF Jitter buffer 10 OAM proprietary Peer 1 TDM payload size 10. type tdmoip psn udp-over-ip manually no adaptive label out 3 in 2 far-end-type t1-esf jitter-buffer 10 oam proprietary peer 1 tdm-payload size 10 no shutdown store
GMUX2000>config>pwe# pw 1 GMUX2000>config>pwe>pw(1) GMUX2000>config>pwe>pw(1) GMUX2000>config>pwe>pw(1) GMUX2000>config>pwe>pw(1) GMUX2000>config>pwe>pw(1) GMUX2000>config>pwe>pw(1) GMUX2000>config>pwe>pw(1) GMUX2000>config>pwe>pw(1) GMUX2000>config>pwe>pw(1)
Selection Guidelines for TDM Payload Bytes per Frame

The TDMoIP technology enables transmitting the continuous data stream generated by TDM equipment as a stream of discrete packets with a structure suitable for transmission over packet-switched networks. This process is called packetizing (see Appendix C for a concise description of this process, and of the reverse process used to reconstruct the TDM data stream). As part of this process, the continuous TDM data stream is sliced in accordance with the TDM Byte per Frame parameter, and 44 bytes of overhead are added to create a TDMoIP packet (additional overhead is latter added to form frames for transmission over Ethernet).
5-36
Gmux-2000 Ver. 4.0
The number of TDM bytes inserted in each packet affects two important performance parameters: Bandwidth utilization efficiency the smaller the number of TDM bytes per packet, the lower the efficiency. The overhead can be a significant fraction of the total packet when the TDM Byte per Frame parameter is small. The worst efficiency occurs at the minimum packet size, 48 bytes of payload versus 44 bytes of overhead. Packetizing delay and the associated delay variance Considering that any given TDM byte is received only once in every TDM frame, the rate at which TDM bytes are received for filling packets is 8000 bytes per timeslot per second. Since a packet will be sent only after its payload field has been filled, the maximum possible filling rate occurs for bundles carrying 32 timeslots (unframed mode) and a payload of 48 bytes per frame. In this case, the filling of the 48 bytes takes 1.5 internal TDM frames (with CAS signaling, the maximum number of timeslots decreases to 30). However, the filling time increases significantly for bundles with few timeslots; for example, a voice channel could be carried by a single-timeslot bundle. Considering the nominal filling rate (approximately one byte every 0.125 msec), the filling time can easily become very significant. As a worstcase example, consider the time needed to fill a single-timeslot bundle: At 48 TDM bytes per frame: approx. 5.5 msec with CAS support and 5.9 msec without CAS support At 1440 TDM bytes per frame: approx. 165 msec with CAS support and 177 msec without CAS support. The round-trip (or echo) delay for voice channels is at least twice the packetizing delay; any other delays encountered along the end-to-end transmission path only add to this minimum. Another problem introduced by packetizing is intrinsic jitter: because as soon as a packet is filled up is usually not synchronized with its transmission to network, but occurs after an essentially random delay, some jitter is inherently introduced.
Selecting an Optimal Jitter Buffer Size

For reliable operation, the jitter buffer must be large enough to ensure that it is not emptied when the transmission delay increases temporarily (an effect called underflow, or underrun), nor fills up to the point that it can no longer accept new frames when the transmission delay decreases temporarily (an effect called overflow). The minimum size of the jitter buffer depends on the intrinsic jitter, and the maximum size is 200 msec. The theoretically correct value for the size of the jitter buffer of any given bundle is slightly more than the maximum variation in the transmission delay through the network, as observed on the particular link between the bundle source and the destination. For practical reasons, it is sufficient to select a value that is not exceeded for any desired percentage of time: for example, a value of 99.93% means that the jitter buffer will overflow or underflow for an accumulated total of only one minute per day. Jitter buffers are located at both ends of a link, therefore the delay added by the buffers is twice the selected value. The resultant increase in the round-trip delay
Gmux-2000 Ver. 4.0 Configuring Pseudowire Connections 5-37
of a connection may cause problems ranging from inconvenience because of long echo delays on audio circuits (similar to those encountered on satellite links) to time-out of data transmission protocols (especially polling protocols). Therefore, the size of each jitter buffer must be minimized, to reduce the round-trip delay of each connection as much as possible, while still maintaining the link availability at a level consistent with the application requirements.
Configuring an HDLC Bundle

To configure an HDLC bundle: 1. Add an HDLC bundle with UDP/IP network encapsulation as explained in Adding a Pseudowire Bundle above. 2. At the config>pwe>pw(number)# prompt, enter all necessary commands according to the tasks listed below.
Task Selecting source and destination circuit bundle identifiers (CBID), also referred as PW labels Defining a remote peer Selecting the response to out-of-service conditions detected at the local E1 physical port Specifying the Layer-3 priority assigned to the traffic generated by this bundle Configuring VLAN tagging for the traffic generated by this bundle Activating the PW bundle Command See Configuring a TDMoIP (CE) Bundle above Comments
See Configuring a TDMoIP (CE) Bundle above See Configuring a TDMoIP (CE) Bundle above
See Configuring a TDMoIP (CE) Bundle above
For example: To configure an HDLC PW with MEF-8 network encapsulation: PW number 1 PW type HDLC PSN type Ethernet Out (destination) label 3 In (source) label 2 Peer 1
5-38
Gmux-2000 Ver. 4.0
GMUX2000>config>pwe# pw 1 GMUX2000>config>pwe>pw(1) GMUX2000>config>pwe>pw(1) GMUX2000>config>pwe>pw(1) GMUX2000>config>pwe>pw(1)
type hdlc psn ethernet manually label out 3 in 2 peer 1 no shutdown store
Configuring a CESoPSN Bundle

To configure a CESoPSN bundle: 1. Add a CESoPSN bundle with UDP/IP or Ethernet network encapsulation as explained in Adding a Pseudowire Bundle above. 2. At the config>pwe>pw(number)# prompt, enter all necessary commands according to the tasks listed below.
Task Enabling the adaptive timing recovery mechanism for this bundle Selecting the pseudowire multiplexing method Command See Configuring a TDMoIP (CE) Bundle above multiplexing {source | destination} Refer to Chapter 1 for details. Make sure that all the bundles terminated on a given Gmux-2000 pseudowire module use the same multiplexing method. This parameter is displayed only when the PSN type is UDP/IP. Selecting source and destination circuit bundle identifiers (CBID), also referred as PW labels Specifying the type of framing used by the equipment at the destination endpoint. Defining the jitter buffer size in msec. Specifying the handling of packets received after a delay exceeding that compensable for by means of the jitter buffer. Controlling the use of the OAM connectivity protocol for this bundle Defining a remote peer See Configuring a TDMoIP (CE) Bundle above See Configuring a TDMoIP (CE) Bundle above For MEF-8 PSNs, verify that you have defined a MAC address for a remote peer. See Adding and Configuring Remote Peers above. See Configuring a TDMoIP (CE) Bundle above Comments
Always select e1, unless the total number of timeslots does not exceed 24: in this case, you can also select t1-esf or t1-sf
Gmux-2000 Ver. 4.0
5-39
Task Selecting the response to out-of-service conditions detected at the local E1 physical port Specifying the number of TDM payload bytes to be inserted in each packet Specifying the Layer-3 priority assigned to the traffic generated by this bundle Configuring VLAN tagging for the traffic generated by this bundle Activating the PW bundle
Command See Configuring a TDMoIP (CE) Bundle above
Comments
tdm-payload {size<145>}
The TDM payload value range is equivalent to 32 to 1440 bytes of payload per packet
For example: To configure a CESoPSN PW with Ethernet network encapsulation: PW number 1 PW type CESoPSN PSN type Ethernet Multiplexing destination Adaptive clock disabled Out (destination) label 3 In (source) label 2 Jitter buffer 10 Peer 1 TDM payload size 10. type ces-psn-data psn ethernet manually multiplexing destination no adaptive label out 3 in 2 far-end-type t1-esf jitter-buffer 10 peer 1 tdm-payload size 10 no shutdown store
5-40
Gmux-2000 Ver. 4.0
Configuring a SAToP Bundle

To configure a SAToP bundle: 1. Add a SAToP bundle with UDP/IP or Ethernet network encapsulation as explained in Adding a Pseudowire Bundle above. 2. At the config>pwe>pw(number)# prompt, enter all necessary commands according to the tasks listed below.
Task Enabling the adaptive timing recovery mechanism for this bundle Selecting the pseudowire multiplexing method Command See Configuring a TDMoIP (CE) Bundle above multiplexing {source | destination} Refer to Chapter 1 for details. Make sure that all the bundles terminated on a given Gmux-2000 pseudowire module use the same multiplexing method. This parameter is displayed only when the PSN type is UDP/IP. Selecting source and destination circuit bundle identifiers (CBID), also referred as PW labels Specifying the type of framing used by the equipment at the destination endpoint. Defining the jitter buffer size in msec. Specifying the handling of packets received after a delay exceeding that compensable for by means of the jitter buffer. Controlling the use of the OAM connectivity protocol for this bundle Defining a remote peer See Configuring a TDMoIP (CE) Bundle above See Configuring a TDMoIP (CE) Bundle above For MEF-8 PSNs, verify that you have defined a MAC address for a remote peer. See Adding and Configuring Remote Peers above. See Configuring a TDMoIP (CE) Bundle above Comments
Only unframed is available
Selecting the response to out-of-service conditions detected at the local E1 physical port
Gmux-2000 Ver. 4.0
5-41
Task Specifying the number of TDM payload bytes to be inserted in each packet Specifying the Layer-3 priority assigned to the traffic generated by this bundle Selecting the payload format Configuring VLAN tagging for the traffic generated by this bundle Activating the PW bundle
Command tdm-payload {size <241440>}
Comments
See Configuring a TDMoIP (CE) Bundle above See Configuring a TDMoIP (CE) Bundle above See Configuring a TDMoIP (CE) Bundle above
Only v2 is available
For example: To configure a SAToP PW with UDP/IP network encapsulation: PW number 1 PW type SAToP PSN type UDP/IP Multiplexing destination Adaptive clock disabled Out (destination) label 3 In (source) label 2 Jitter buffer 10 Peer 1 TDM payload size 30. type e1satop psn udp-over-ip manually multiplexing destination no adaptive label out 3 in 2 far-end-type t1-esf jitter-buffer 10 peer 1 tdm-payload size 30 no shutdown store
Displaying Bundle Configuration Summary

Once you complete bundle creation, you can display summary of configuration parameters of all existing bundles.
5-42
Gmux-2000 Ver. 4.0
To display bundle configuration summary: At the config>pwe# prompt, enter the show pw-summary command.
For example: GMUX2000>config>pwe# show pw-summary PW PSN Type Out Label Peer Time Slots : : : : 1 udp-over-ip 1 1 PW Type Status In Label Slot/Port : : : : tdmoip Up 1 5/1
: [1..31] Payload Size : 1
Jitter Buffer : 3.00
PW PSN Type Out Label Peer Time Slots
: : : :
2 udp-over-ip 2 1
PW Type Status In Label Slot/Port
: : : :
ces-psn-data Up 2 5/2
: [1..31] Payload Size : 4
Jitter Buffer : 3.00
5.13 Configuring Cross-Connects

Cross-connects are: TDM PW cross-connects Internal connections of individual timeslots comprising E1/T1 streams to pseudowire bundles ( TDM mapping Internal mapping of T1 payload to higher order SONET ports.
Configuring TDM PW Cross-Connects

With pseudowire emulation modules, timeslot assignment can be used to perform two functions: To specify the port timeslots served by bundle(s) configured for pseudowire emulation modules, when the bundle(s) serve only some of the port timeslots. To specify the bundle that serves as timing reference when the port uses adaptive timing. This is performed by connecting a single bundle with enabled adaptive clock function to the port.
To configure TDM PW cross-connects: At the config>cross-connect# prompt, enter the tdm-pw command as follows:
Gmux-2000 Ver. 4.0
Configuring Cross-Connects
5-43
tdm-pw pw <12000> {e1 | t1} <slot/port> [time-slots <value>] [{data | voice-cas}] where: pw selects a pseudowire bundle number e1 or t1 and slot/port selects interface type, I/O slot and port number time-slots selects timeslots to be assigned to the PW bundle
Note
Use the following syntax, when assigning timeslots:

[1..6] assigns timeslots 1 through 6 [1..1] or [1] assigns timeslot 1 [1..6, 8..12] assigns timeslots 1 through 6 and timeslots 8 through 12. data or voice-cas specifies payload type: data or voice with CAS
Notes
When the bundle payload type is voice-cas, make sure to connect timeslot 16, because it carries the CAS information.
For example: To assign timeslots 16, 8, and 1015: PW number 1 T1 port 1 of the module installed in slot 1 Payload type data.
GMUX2000>config>cross-connect# pw-tdm pw 1 t1 1/1 time-slots [1..6, 8..8, 10..15] data To remove timeslots 110: PW number 1 T1 port 1 of the module installed in slot 1 Payload type data.
GMUX2000>config>cross-connect# no pw-tdm pw 1 To display information on all assigned timeslots: GMUX2000>config>cross-connect# info pw-tdm pw 1 t1 1/1 [1..24] pw-tdm pw 1 t1 2/1 [1..24]
Configuring TDM Mapping

The Gmux-2000 module enables free mapping of any internal T1 payload port to any TU-11 within any STS-1 contained in an STS-3. During mapping, the telecom bus used to carry payload between the T1 port and the TU-11 is also selected, and therefore mapping also specifies the utilization of the Gmux-2000 internal telecom buses.
5-44
Gmux-2000 Ver. 4.0
Note
On the supervisory terminal screens, STS-1 is referred to as vt1-5. When an APS group is configured on the external ports, only the mapping to
the three STS-1 (VC-3) channels associated with the primary external OC-3 port of the group needs to be configured (the configuration data is automatically copied to the matching secondary STS-1 (VC-3) port).
Internal T1 payload ports are located on circuit emulation server modules (T1-CE-SRV/28), pseudowire emulation server modules (T1-PW-SRV/28), and voice compression modules (VC-T1/12, VC-T1/16, VCA-T1/12, VCA-T1/16) using internal ports (US_and/or_NS). In accordance with the SONET multiplexing structure, the STS-3 structure carries 84 TU-11s, organized in three STS-1. Each STS-1 carries 7 VT groups (identified as TUG-2s on the supervisory terminal screen), each carrying four TU-11s. This structure is illustrated in Figure 5-4.
STS-1 No. 1 TUG-2 No. 1 TUG-2 No. 2 TUG-2 No. 3 TUG-2 No. 4 TUG-2 No. 5 TUG-2 No. 6 TUG-2 No. 7 28 56 84 1 29 STS-1 No. 2 57 STS-1 No. 3
Figure 5-4. SONET Multiplexing Structure

To configure TDM mapping: At the config>cross-connect# prompt, enter the tdm-mapping command as follows: tdm-mapping {vc12 | vt1-5} <slot/port[/tributary]> {e1 | t1} <slot/port> where: vt1-5 selects a VC-12 port to be mapped. It is identified by the module slot, STS-1 port (13) and TU (184) t1 selects a payload T1 port to be mapped. It is identified by the module slot, T1 port (184).
Note
A payload port can be mapped to only one port in the whole Gmux-2000 chassis.
For example: To map payload T1 port 6 to VT1-5 port 5: T1 port belongs to T1-PW-SRV/28 module in slot 1 VT1-5 port belongs to STS-1 port 1 of OC3 module in slot 9.
Gmux-2000 Ver. 4.0
5-45
GMUX2000>config>cross-connect# tdm-mapping vt1-5 9/1/5 t1 1/6 To remove mapping of payload T1 port 6 to VT1-5 port 5: GMUX2000>config>cross-connect# no tdm-mapping vt1-5 9/1/5 To display information on all mapped interfaces: GMUX2000>config>cross-connect# info tdm-mapping vt1-5 9/1/5 t1 1/6
5.14 Performing Administration Functions

Administration functions supported by Gmux-2000 include the following: Viewing inventory information Performing file operations Updating configuration database Restoring factory-default settings Rebooting a module Using the file system utilities.
Viewing Logistic (Inventory) Information

Use the following procedure to display logistics information on the Gmux-2000 system, and its subsystems. The displayed information is automatically retrieved from the various system components and from the Gmux-2000 configuration and software files. Therefore, it cannot be directly modified. To display the system inventory: At the config>system# prompt, enter the show inventory-table.
For example:
5-46
Performing Administration Functions
Gmux-2000 Ver. 4.0
GMUX2000# configure system show inventory-table Physical Class Description HW Rev SW Rev ----------------------------------------------------------------------------Fan Module cl-a 1.0 4.00A01 Clk clk-2 Module io-1, CES PW T1 4.00A1 Module io-1, CES PW T1 SC Main Board 2.0 SC Firmware 4.0 Module io-1, CES PW T1 RAD TDMoIP ASIC 2.0 0.0 Module io-2, Server E1 1.00A3 Module io-2, Server E1 SC Main Board 0.0 SC Firmware 1.0 Module io-2, Server E1 RAD TDMoIP ASIC 1.0 0.0 Module io-6, GBE-8 2.00A1 Module io-6, GBE-8 GE Main Board 1.0 GE Firmware 2.0 Module io-6, GBE-8 Switch Ezchip NP-2 0 5.24 Module io-6, GBE-8 Ample A2510 0.2 0.0 Module io-9, ---------------------------Module io-9, ---------------------------Module io-9, ---------------------------For each chassis slot, the Inventory screen presents two types of information: HW Lists the module installed in the corresponding chassis slot. ----- in this column indicates that the slot is empty. SW Lists the module programmed in the corresponding chassis slot. ----- in this column indicates that no module is programmed in the corresponding slot. The information displays logistics data that may be needed by RAD technical support personnel when servicing the unit. The information is retrieved from the modules installed in chassis.
Performing File Operations

Use the following procedure to perform the following tasks: Transfer files by TFTP Download software from files stored on the CONTROL module flash disk to the CONTROL module itself or to Gmux-2000 I/O modules that support this capability.
Downloading/Uploading by TFTP
TFTP always transfers files to/from the online CONTROL module. In general, you must repeat the transfer for the other CONTROL module, after flipping (interchanging) between the online and offline modules. Once a file is saved on the CONTROL module flash disk it must be downloaded to the CONTROL module itself or to an I/O module. In addition, you can upload application or database files from the CONTROL module flash disk to a remote server.
Gmux-2000 Ver. 4.0
5-47
Setting TFTP Timeouts

Before initiating TFTP file transfer, it is recommended to configure retry and total timeouts for TFTP session. The retry timeout specifies the time to wait for connecting to the server. After this interval expires, the CONTROL module tries again, and so on, until the transfer can be started, or the total timeout interval expires. In this case, the downloading fails. To configure TFTP timeouts: At the config>system>tftp# prompt, enter the following: timeout <0255> and retry-timeout <0255>.
For example: To configure TFTP timeouts: Retry timeout 30 sec Total timeout 250 sec
GMUX2000# configure system tftp GMUX2000>config>system>tftp# timeout 250 retry-timeout 30
TFTP Application
The TFTP protocol is typically used for remote IP-to-IP file transfers via the product unit's Ethernet interface. It can be used, however, for local file transfer as well, as the transfer rate of the Ethernet interface is much faster than that of the RS-232 interface. For TFTP file transfers, a TFTP server application must be installed on the local or remote computer. As it runs in the background, the TFTP server waits for any TFTP file transfer request originating from the product unit, and carries out the received request automatically. A variety of third-party applications, such as 3Cdaemon (available from www.3com.com) or PumpKIN (available from http://kin.klever.net/pumpkin/), allow the instant creation of a TFTP server on a client computer. For more information, refer to the documentation of these applications.
Figure 5-5. Downloading a Software Application File to Gmux-2000 via TFTP
Setting-up a TFTP Server

If you use a local laptop and TFTP is the preferred transfer method, a TFTP server application must be installed on it. As mentioned above, third-party applications are available and you should refer to their setup documentation.
5-48
Gmux-2000 Ver. 4.0
Checking the Firewall Settings

TFTP file transfers are carried out through Port 69. You should check that the firewall you are using on the server computer allows communication through this port. To allow communication through Port 69 in Windows XP: 1. Double-click the My Network Places icon, located on the desktop. The My Network Place window appears. 2. On the Network Tasks sidebar, click View network connections. The available network connections are displayed.
Figure 6. View Network Connections

3. On the Network Tasks sidebar, click Change Windows Firewall settings. The Windows Firewall dialog box appears.
Figure 7. Change Firewall Settings

4. Click the Exceptions tab.
Gmux-2000 Ver. 4.0
5-49
Figure 8. Windows Firewall Dialog Box Exceptions Tab

5. Check whether Port 69 appears on the exceptions list. If it does not, click Add Port and add it to the list of exceptions.
Note
Different firewall types require different configuration. Refer to your firewall's documentation to check how TFTP file transfers can be allowed to pass through it using a UDP-type port.
To download a file via TFTP: At the file# prompt, enter the copy command, as follows: copy tftp://<TFTP server IP address>/<source file name> <destination file name>
Note N t
The maximum copy command string length is limited to 100 characters.

For example: TFTP server address 10.10.10.10 Source file name GMUXCL.img Destination file name GMUXCL.img.
GMUX2000>file# copy tftp://10.10.10.10/GMUXCL.img GMUXCL.img
5-50
Gmux-2000 Ver. 4.0
To upload a file via TFTP: At the file# prompt, enter the copy command, as follows: copy <source file name> tftp://<TFTP server IP address>/<destination file name>
Note
The maximum copy command string length is limited to 100 characters.

For example: TFTP server address 10.10.10.10 Source file name db1conf.ol Destination file name db1conf.cfg.
GMUX2000>file# copy db1conf.ol tftp://10.10.10.10/db1conf.cfg
Internal Software Downloading

The Internal Download screen is used to download software from the flash disk of the online CONTROL module to a selected module that supports this option. To perform an internal download: 1. At the file# prompt, enter the copy command, as follows: copy <source file name> {main-sw | io-1-sw | io-2-sw | io-3-sw | io-4-sw | io5-sw | io-6-sw | io-7-sw | io-8-sw | io-9-sw} where: main-sw indicates CONTROL module application file io-1-sw io-9-sw indicates application file of a module installed in I/O slot 19 Once the internal download is complete, Gmux-2000 displays the following message: RESET IO FOR NEW SW TO BE ACTIVE. 2. Reboot the module to activate the downloaded software (see Rebooting a Module section below). For example: To download an application file internally: Application file name 1 GMUXCL.img Target module 1 online CONTROL module Application file name 2 OC3.img Target module 2 C.OC3 module installed in slot 5.
GMUX2000>file# copy GMUXCL.img main-sw GMUX2000>file# copy OC3.img io-5-sw
Gmux-2000 Ver. 4.0
5-51
Updating Configuration Database

All the changes made to the Gmux-2000 configuration are stored in the offline-config file. To make the changes active the offline-config file must be copied to the running-config file. To update configure database: At the file# prompt, enter the copy command, as follows: copy offline-config running-config For example: GMUX2000>file# copy offline-config running-config
Restoring Factory-Default Settings

Factory-default settings are restored by: 1. Overwriting the offline-config file with the factory-default-config file 2. Updating configuration database as explained above. To restore factory-default settings: At the file# prompt, enter the copy command, as follows: copy factory-default-config offline-config For example: GMUX2000>file# copy factory-default-config offline-config GMUX2000>file# copy offline-config running-config
Rebooting a Module
Use the following procedure to reboot a module installed in a specified slot.
Note
Resetting a module will temporarily disrupt services supported by that module.

To reboot a module: At the admin# prompt, enter the reboot command, as follows: reboot active to reboot the online CONTROL module reboot slot <19> to reboot a module in I/O slot 19
For example: To reboot the module installed in I/O slot 5: GMUX2000>admin# reboot slot 5 YOU ARE GOING TO RESET IO 5. CONTINUE? [yes/no] y
5-52
Gmux-2000 Ver. 4.0
Using the File System Utilities

Use the following procedure to provide management utilities for the disk file system, located on the CONTROL modules of the Gmux-2000. These functions are similar to those available under Windows and other PC operating systems. The files utilities should be used by knowledgeable personnel, familiar with PCs.
Note
The file names are not case-sensitive.
Displaying the Flash Disk Contents

The dir command is used to display contents of the flash disk on the online CONTROL module. To display the flash disk contents: At the file# prompt, enter the dir command. The display includes the file names, their size, and the time they were last updated. For example: GMUX2000>file# dir FILE NAME SYSTEM.INI DB1CONF.OL ALARM.CFG PASSCONF DB1CONF.BAK ALARM.BAK GMUXCL.IMG TFTP_DB.CFG SSLPUB SSLPRV SSLPUB.BAK SSLPRV.BAK SSHPUB SSHPRV SSHPUB.BAK SSHPRV.BAK PASSCONF.BAK RDOS.0 RDOS.1 SIZE 2 964939 31344 560 278225 31344 771072 964939 684 277 0 0 279 24 0 0 560 8234 46 DATE 2000-01-01 2000-07-17 2000-06-16 2000-04-23 2000-04-03 2000-06-16 2000-02-23 2000-07-17 2000-01-01 2000-01-01 2000-01-01 2000-01-01 2000-01-01 2000-01-01 2000-01-01 2000-01-01 2000-04-23 2000-07-23 2000-09-05 TIME 0:00:00 22:26:56 22:16:32 7:06:42 23:46:02 22:16:32 6:49:28 22:27:18 0:03:12 0:03:12 0:03:12 0:03:12 0:08:24 0:08:24 0:08:24 0:08:24 7:06:42 0:35:04 0:27:06
bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes
Deleting Files
You can delete files from the flash disk. Before deleting the file, make sure the file is not in use, for example, it is not an online database file. To delete a file: At the file# prompt, enter the delete command, followed by the file name.
Gmux-2000 Ver. 4.0
5-53
For example: GMUX2000>file# delete db2conf.cfg
Formatting Flash Disk

It is not recommended to format the flash disks of the two CONTROL modules at the same time, unless the Gmux-2000 is not in service. Always take the CONTROL module on which you wish to format the flash disk offline. To format a flash disk: 1. At the file# prompt, enter the format command. A confirmation message is displayed. 2. Confirm the format. For example: GMUX2000>file# format All files except Running DB will be deleted, are you sure?? [yes/no]
Note
Formatting process may take up to 4 minutes.
5-54
Gmux-2000 Ver. 4.0
Chapter 6 Configuring Typical Applications

6.1 Overview
This Chapter provides configuration guidelines for Gmux-2000 systems for several typical applications. Contact RAD Technical Support Department if you need help with your particular applications. The configuration activities presented in this Chapter assume that Gmux-2000 is configured using a standard ASCII terminal, and that you are familiar with the Gmux-2000 management, as described in Chapter 4. Detailed descriptions and instructions for using each screen identified below appear in Chapter 5.
Note In Appendix C, you can find concise descriptions of the Gmux-2000 operating environment, and technical background information on many Gmux-2000 configuration parameters.
For your convenience, you can find below outlines of the preliminary configuration sequence, and of the general configuration sequence.
Outline of Preliminary Configuration Sequence

The purpose of the preliminary configuration is to prepare the minimal set of parameters needed to manage the Gmux-2000. In particular, after preliminary configuration you will enable management access by Telnet hosts and management stations, for example, RADview-SC/TDMoIP Service Center, that are attached to a LAN directly connected to the Ethernet port of the Gmux-2000 CONTROL module, or at a remote location from which IP communication with the CONTROL module is possible. After completing the preliminary configuration, you may also use Telnet hosts and SNMP-based management stations to manage the Gmux-2000.
Note
To enable management access to the Gmux-2000 from any relevant location, it is necessary to fully configure the Gmux-2000: only full configuration can permit management traffic to reach the Gmux-2000 via inband paths.
The steps usually included in the preliminary configuration, when starting from the factory defaults, are described in Table 6-1. For detailed operating instructions, refer to the Chapter 5 section describing each activity.
Gmux-2000 Ver. 4.0
Overview
6-1
Table 6-1. Gmux-2000, Outline of Preliminary Configuration Procedure

Step Action If the Gmux-2000 is equipped with all the modules, load the hardware configuration. Alternatively, define the modules installed in the chassis manually Using GMUX2000>admin# update-card-types GMUX2000>config>card# card-type
Configure the Gmux-2000 router, bind its ports GMUX2000>config>router(1) to device host and GbE interfaces and define peers Configure specific managers Configure the Gmux-2000 logistic parameters: system name, contact person, system location GMUX2000>config# management manager GMUX2000>config>system# name GMUX2000>config>system# contact GMUX2000>config>system# location Set Gmux-2000 real-time clock: GMUX2000>config>system# date-and-time dateformat GMUX2000>config>system# date-and-time date GMUX2000>config>system# date-and-time time GMUX2000>config>port# GMUX2000>config>clock# GMUX2000>config>protection# GMUX2000>config#>cross-connect GMUX2000>config>pwe#
set the time of day Configure physical layer parameters for each module, and each module port Configure timing flow Configure redundancy Configure Gmux-2000 internal routing Configure connection parameters for each bundle
General Configuration Sequence

Table 6-2 lists the additional steps needed to configure a Gmux-2000 for typical applications. Table 6-2. Gmux-2000, Outline of Configuration Sequence for Typical Applications
Step 1 2 3 4 5 Action Configure physical layer parameters for each module, and each module port Configure timing flow Configure redundancy Configure connection parameters for each bundle Configure Gmux-2000 internal routing Using GMUX2000>config>port# GMUX2000>config>system>clock# GMUX2000>config>protection# GMUX2000>config>pwe# GMUX2000>config#>cross-connect
6-2
Overview
Gmux-2000 Ver. 4.0
Installation and Operation Manual Step 6 Action When necessary, configure the Gmux-2000 for VoIP service as follows: Configure additional voice compression parameters needed for voice compression service Configure MEGACO application parameters Configure SIGTRAN parameters
Chapter 6 Configuring Typical Applications Using
Configuration > Physival Layer > I/O > IP Address Configuration > Physival Layer > I/O > Media Configuration Configuration > Applications > MEGACO Configuration > Applications > SIGTRAN GMUX2000>config>system# alarms GMUX2000# file copy offline-config runningconfig GMUX2000>file# copy tftp://x.x.x.x/oc3.img sonet.img GMUX2000>file# copy db1conf.cfg tftp:/x.x.x.x/db1conf.cfg GMUX2000>file# copy config-x startup-config
7 8
Configure Gmux-2000 alarm handling Update database
Download application or database file
Download application or database file
Switch to database x
6.2
Application 1 Transport of Unframed Bundle from T1 Trunk
Application Overview
The following procedure explains the main configuration actions for transparently connecting a T1 trunk from an external port of an T1-PW/28 pseudowire emulation module installed in a Gmux-2000 to the T1 user port of an IPmux-24, by configuring an unframed bundle. The application is shown in Figure 6-1.
Figure 6-1. Connecting T1 Trunk to IPmux-24
Gmux-2000 Ver. 4.0
6-3
Preliminary Configuration
When powering on the Gmux-2000 for the first time, the first step is to load the hardware configuration, which means to configure the Gmux-2000 to recognize the modules installed into the chassis. To configure a chassis with: Three AC power supply modules One CONTROL module One GbE/2 module in slot 6 One T1-PW/28 module in slot 1. card-type card-type card-type card-type card-type card-type ps-a power-supply ps-ac ps-b power-supply ps-ac ps-c power-supply ps-ac cl-a cl 6 eth gbe-2 1 tdm-pw pw-28t1
GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card#

Add and configure router interfaces, and define a remote peer. To add router interface 1 to router 1: IP address 172.17.92.234 Subnet mask 24 Bound to common logic module Management access is allowed.
GMUX2000# config router 1 interface 1 GMUX2000>config>router(1)>interface(1)# GMUX2000>config>router(1)>interface(1)# GMUX2000>config>router(1)>interface(1)# GMUX2000>config>router(1)>interface(1)# GMUX2000>config>router(1)>interface(1)#
address 172.17.92.234/24 bind ethernet management-access no vlan store
To add router interface 2 to router 1: IP address 10.10.10.10 Subnet mask 24 Bound to port 1 of a Gigabit Ethernet module installed in slot 6 Management access is allowed.
6-4
Gmux-2000 Ver. 4.0
GMUX2000# config router 1 interface 1 GMUX2000>config>router(1)>interface(1)# GMUX2000>config>router(1)>interface(1)# GMUX2000>config>router(1)>interface(1)# GMUX2000>config>router(1)>interface(1)# GMUX2000>config>router(1)>interface(1)#
address 10.10.10.10/24 bind giga-ethernet 6/1 management-access no vlan store
To define a remote peer with IP address 10.10.10.12: GMUX2000>config router 1 peer 1 ip 10.10.10.12 GMUX2000>config>router(1)# store
Configuring System Clock

Use internal clock as a timing reference. To configure system clock: GMUX2000>config>system>clock>domain(1)# master internal GMUX2000>config>system>clock>domain(1)# no fallback GMUX2000>config>system>clock#store
Configuring I/O Module Physical Layer Parameters

Configure the physical payer parameters for port 1 of the GbE module and port 1 of the T1-PW/28 module. To configure Gigabit Ethernet port 1: Slot 6 Port 1 Autonegotiation enabled.
GMUX2000# configure port giga-ethernet 6/1 GMUX2000>config>port> giga-eth(6/1)# auto-negotiation GMUX2000>config>port> giga-eth(6/1)# no shutdown MUX2000>config>port> giga-eth(6/1)# store To configure T1 port 1: Slot 1 Outgoing PSN port port 1 of the GbE/2 module installed in slot 6 Tx clock source domain 1 Line type unframed Idle code 0x7e Restoration time 62411 Trail mode terminated.
Gmux-2000 Ver. 4.0
6-5
GMUX2000# configure port t1 1/1 GMUX2000>config>port>t1(1/1)# giga-if-1 6/1 GMUX2000>config>port>t1(1/1)# tx-clock-source domain 1 GMUX2000>config>port>t1(1/1)# line-type T1-unframed GMUX2000>config>port>t1(1/1)# idle-code 0x7e GMUX2000>config>port>t1(1/1)# restoration-time 62411 GMUX2000>config>port>t1(1/1)# out-of-service data 0xdd GMUX2000>config>port>t1(1/1)# trail-mode terminated GMUX2000>config>port>t1(1/1)# no shutdown GMUX2000>config>port>t1(1/1)# store
Configuring the Bundle

To configure a SAToP PW with UDP/IP network encapsulation: PW number 1 PW type SAToP PSN type UDP/IP Multiplexing source Adaptive clock disabled Out (destination) label 1 In (source) label 1 Jitter buffer 10 Sensitivity data Far end type unframed Peer 1 TDM payload size 32 VLAN tagging disabled.
GMUX2000>config>pwe# pw 1 type e1satop psn udp-over-ip manually GMUX2000>config>pwe>pw(1)# multiplexing source GMUX2000>config>pwe>pw(1)# no adaptive GMUX2000>config>pwe>pw(1)# label out 1 in 1 GMUX2000>config>pwe>pw(1)# vlan no-tag GMUX2000>config>pwe>pw(1)# jitter-buffer 10 sensitivity data GMUX2000>config>pwe>pw(1)# far-end-type unframed GMUX2000>config>pwe>pw(1)# peer 1 GMUX2000>config>pwe>pw(1)# tdm-payload size 32 GMUX2000>config>pwe>pw(1)# no shutdown GMUX2000>config>pwe>pw(1)# store
Connecting the T1 Port to the Bundle

Now associate the bundle with the T1 port 1 of the T1-PW/28 installed in I/O slot 1 by assigning the whole T1 port to PW1.
6-6
Gmux-2000 Ver. 4.0
To assign T1 port to bundle: PW number 1 E1 port 1 of the module installed in slot 1 Payload type data.
GMUX2000>config>cross-connect# pw-tdm pw 1 t1 1/1 data

All the changes made to the Gmux-2000 configuration are stored in the offline-config file. To make the changes active the offline-config file must be copied to the running-config file. To update configure database: GMUX2000>file# copy offline-config running-config
IPmux-24 Configuration
For the following configuration steps, use the latest IPmux-24 Installation and Operation Manual.
Host IP and NMS Settings

1. Open Configuration > System > Host IP.
Note
Disable DHCP and save before setting the Host IP parameters.
1. 2. 3. 4.
IP address IP mask Default gateway DHCP
...(<IPmux-24(1) Host IP>) ...(<IPmux-24(1) Host Mask>) ...(-) (Disable)
2. Open Configuration > System > Management > Manager list. 1. 2. 3. 4. 5. Manager IP address Manager location Link up/down trap Alarm trap VLAN tagging ... (<NMG Station IP>) > (All) (Disable) (Disable) (Disable)
3. Open Configuration > System > Management > Authentication/Community.
Gmux-2000 Ver. 4.0
6-7
1. 2. 3. 4.
Authentication failure trap Trap Read Write
(Disable) ... (SNMP_trap) ... (public) ... (public)
E1 Physical Settings
1. Configure the E1 Line Type and verify the correct clock settings. Use Configuration > Physical Layer > TDM configuration (E1). 1. 2. 3. 4. 5. Channel ID Admin status Transmit clock source Trail mode Line type Line interface (1) (Enable) (Adaptive) (Termination) (Unframed) (DSU)
> >
Bundle Connection Settings

1. Open Configuration > Connection. 1. 2. 3. 4. Bundle ID[1] Connection mode PSN type Bundle connection ... (1) > (TDMoIP CE) (UDP/IP) >
2. Configure the bundle connection parameters to connect it to the bundle configured on the Gmux-2000: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Destination IP address Next hop IP TOS[0 - 255] Connection status Destination bundle[1 - 8063] TDM bytes in frame(x48 bytes)[1 - 30] Payload format OAM connectivity Jitter buffer [msec][3 - 300] VLAN tagging ... (<Gmux router interface IP>) ... <Next Hop IP Add> ... (0) (Enable) ... (1) ... (5) (V2) (Enable) ... (15.0) (Disable
6.3
Application 2 Transport of Framed Bundle from T1 Trunk
The following procedure explains the main configuration actions for connecting selected timeslots of a T1 trunk from an external port of a T1-PW/28 pseudowire
6-8
Gmux-2000 Ver. 4.0
emulation module installed in a Gmux-2000 to the T1 user port of an IPmux-24, by configuring a framed TDMoIP (CE) bundle. The application is as shown in Figure 6-1. For efficiency, this section presents only the differences between the configuration steps explained in Section 6.2 and those needed to configure a framed CESoPSN bundle.
Gmux-2000 Configuration
Configure the physical payer parameters for T1 port 2 of the T1-PW/28 module. To configure T1 port 2: Slot 1 Outgoing PSN port port 1 of the GbE/2 module installed in slot 6 Tx clock source domain 1 Line type ESF Idle code 0x7e Restoration time 62411 Trail mode terminated.
GMUX2000# configure port e1 1/2 GMUX2000>config>port>e1(1/2)# giga-if-1 6/1 GMUX2000>config>port>e1(1/2)# tx-clock-source domain 1 GMUX2000>config>port>e1(1/2)# line-type t1-esf-frame GMUX2000>config>port>e1(1/2)# idle-code 0x7e GMUX2000>config>port>e1(1/2)# restoration-time 62411 GMUX2000>config>port>e1(1/2)# out-of-service data 0xdd GMUX2000>config>port>e1(1/1)# trail-mode terminated GMUX2000>config>port>e1(1/2)# no shutdown GMUX2000>config>port>e1(1/2)# store
Configuring the Bundle Connection Parameters

To configure a CESoPSN PW with UDP/IP network encapsulation: PW number 2 PW type CESoPSN PSN type UDP/IP Multiplexing source Adaptive clock disabled Out (destination) label 1 In (source) label 1 Jitter buffer 15
Gmux-2000 Ver. 4.0
6-9
Sensitivity data Far end type T1 ESF Peer 1 TDM payload size 10 VLAN tagging disabled.
GMUX2000>config>pwe# pw 2 type ces-psn-data psn udp-over-ip manually GMUX2000>config>pwe>pw(2)# multiplexing source GMUX2000>config>pwe>pw(2)# no adaptive GMUX2000>config>pwe>pw(2)# label out 1 in 1 GMUX2000>config>pwe>pw(2)# vlan no-tag GMUX2000>config>pwe>pw(2)# jitter-buffer 15 sensitivity data GMUX2000>config>pwe>pw(2)# peer 1 GMUX2000>config>pwe>pw(2)# far-end-type t1-esf GMUX2000>config>pwe>pw(2)# tdm-payload size 10 GMUX2000>config>pwe>pw(2)# no shutdown GMUX2000>config>pwe>pw(2)# store

Now assign timeslots 15 of the T1 port 2 of the T1-PW/28 installed in I/O slot 1 to the bundle 2. To assign timeslots 15 to bundle 2: PW number 2 T1 port 1 of the module installed in slot 1 Payload type data.
GMUX2000>config>cross-connect# pw-tdm pw 2 t1 1/2 time-slots [1..5] data

See the Updating Configuration Database section above.
For the following configuration steps, use the latest IPmux-24 Installation and Operation Manual. The differences between the configuration steps explained in Section 6.2 and those needed to configure the IPmux-24 for the framed TDMoIP (CE) bundle are as follows: 1. Configure as follows: Host IP address: Host IP Mask: Manager IP Address: E1 Port Line Type: <IPmux-24 Host IP> <IPmux-24 Host Mask> <NMG Station IP> ESF
6-10
Gmux-2000 Ver. 4.0
E1 Port 2 Tx CLK source: Bundle ID:
Adaptive 1
2. Configure TS Assignment as follows: 1. Open TS Assignment. Connection mode PSN type 1. Bundle ID[1 - 1] 2. DS0 bundle 3. Bundle connection (TDMoIP CE) (UDP/IP) ... (1) []> >
DS0 bundle TDM channel ID: 1 +1 +2 TS 0 1 1 TS 10 0 0 TS 20 0 0 TS 30 0 1. Change cell [0
Bundle ID: 1 +3 1 0 0 - 1] +4 1 0 0 +5 1 0 0 +6 0 0 0 +7 0 0 0 +8 0 0 0 +9 0 0 0 +10 0 0 0
... (1)
2. Open Bundle connection. 3. Configure bundle parameters as follows: Destination IP: Destination ID: TDM bytes: Jitter buffer: OAM TDMoIP <Gmux-2000 router interface IP> 2 1 15 Enable V2
6.4
Application 3 Transport of Unframed Bundle from SONET Network
The following procedure explains the main configuration actions for transparently connecting a T1 stream, received from an external port of an OC3 SONET interface module, through a T1-PW-SRV/28 pseudowire emulation server module installed in a Gmux-2000, to the T1 user port of an IPmux-24, by configuring an unframed bundle. The application is shown in Figure 6-2.
Gmux-2000 Ver. 4.0
6-11
Note
The configuration procedures illustrated below are based on the use of SNMPv1.
Figure 6-2. Connecting T1 Stream from SONET Network to IPmux-24
Gmux-2000 Configuration
When powering on the Gmux-2000 for the first time, the first step is to load the hardware configuration, which means to configure the Gmux-2000 to recognize the modules installed into the chassis. To configure a chassis with: Three AC power supply modules One CONTROL module One GbE/2 module in slot 6 One T1-PW-SRV/28 module in slot 1 One OC3 module in slot 9. card-type card-type card-type card-type card-type card-type card-type ps-a power-supply ps-ac ps-b power-supply ps-ac ps-c power-supply ps-ac cl-a cl 6 eth gbe-2 1 server pw-srv-28t1 9 sdh-sonet oc3/d
GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card# GMUX2000>config>card#

Add and configure router interfaces, and define a remote peer, as explained in the Configuring the Router section above.

Configure the physical payer parameters for port 1 of the GbE module, port 1 of the T1-PW-SRV/28 module and OC-3 port 1 of the OC-3 module (including STS-1 port 1). To configure Gigabit Ethernet port 1:
6-12
Slot 6
Gmux-2000 Ver. 4.0
Port 1 Autonegotiation enabled.
GMUX2000# configure port giga-ethernet 6/1 GMUX2000>config>port>giga-eth(6/1)# auto-negotiation GMUX2000>config>port>giga-eth(6/1)# no shutdown MUX2000>config>port>giga-eth(6/1)# store To configure T1 port 1: Slot 1 Outgoing PSN port port 1 of the GbE/2 module installed in slot 6 Tx clock source domain 1 Line type unframed Idle code 0x7e Restoration time 62411 Trail mode terminated.
GMUX2000# configure port t1 1/1 GMUX2000>config>port>t1(1/1)# giga-if-1 6/1 GMUX2000>config>port>t1(1/1)# tx-clock-source domain 1 GMUX2000>config>port>t1(1/1)# line-type unframed GMUX2000>config>port>t1(1/1)# idle-code 0x7e GMUX2000>config>port>t1(1/1)# restoration-time 62411 GMUX2000>config>port>t1(1/1)# trail-mode terminated GMUX2000>config>port>t1(1/1)# no shutdown GMUX2000>config>port>t1(1/1)# store To configure OC-3 port 1: Slot 9 AIS on failure enabled Tx clock source loopback EED threshold 10-3 SD threshold 10-6 Loopback disabled.
GMUX2000# configure port sonet 9/1 GMUX2000>config>port>sonet(9/1)# no loopback GMUX2000>config>port>sonet(9/1)# tx-clock-source loopback GMUX2000>config>port>sonet(9/1)# ais-on-failure GMUX2000>config>port>sonet(9/1)# eed 1e-3 sd 1e-6 GMUX2000>config>port>sonet(9/1)# no shutdown GMUX2000>config>port>sonet(9/1)# store To configure STS-1 port 1:
Gmux-2000 Ver. 4.0
Slot 9 OC-3 port 1

Application 3 Transport of Unframed Bundle from SONET Network 6-13
STS-1 port 1 J1 pathtrace disabled PLM response disabled TIM-response disabled EED-response disabled EED threshold 10-3 SD threshold 10-6.
GMUX2000# configure port sonet 9/1 oc3 1 GMUX2000>config>port>sonet(9/1)>oc3(1)# no j1-pathtrace GMUX2000>config>port>sonet(9/1)>oc3(1)# no plm-response GMUX2000>config>port>sonet(9/1)>oc3(1)# no tim-response GMUX2000>config>port>sonet(9/1)>oc3(1)# threshold eed 1e-3 sd 1e-6 GMUX2000>config>port>sonet(9/1)>oc3(1)# no shutdown GMUX2000>config>port>sonet(9/1)# store
Configuring the Bundle

To configure a SAToP PW with UDP/IP network encapsulation: PW number 1 PW type SAToP PSN type UDP/IP Multiplexing source OAM proprietary ToS 0 Adaptive clock disabled Out (destination) label 1 In (source) label 1 Jitter buffer 10 Sensitivity data Far end type unframed PSN OOS L-bit Peer 1 TDM payload size 32 VLAN tagging disabled Payload format version 2.
6-14
Gmux-2000 Ver. 4.0
GMUX2000>config>pwe# pw 1 type e1satop psn udp-over-ip manually GMUX2000>config>pwe>pw(1)# multiplexing source GMUX2000>config>pwe>pw(1)# no adaptive GMUX2000>config>pwe>pw(1)# label out 1 in 1 GMUX2000>config>pwe>pw(1)# oam proprietary GMUX2000>config>pwe>pw(1)# vlan no-tag GMUX2000>config>pwe>pw(1)# jitter-buffer 10 sensitivity data GMUX2000>config>pwe>pw(1)# far-end-type unframed GMUX2000>config>pwe>pw(1)# peer 1 GMUX2000>config>pwe>pw(1)# psn-oos l-bit GMUX2000>config>pwe>pw(1)# tdm-payload 3size 2 GMUX2000>config>pwe>pw(1)# version v2 GMUX2000>config>pwe>pw(1)# no shutdown GMUX2000>config>pwe>pw(1)# store

Now associate the bundle with the T1 port 1 of the T1-PW-SRV/28 installed in I/O slot 1 by assigning timeslots 124 to PW1. To assign timeslots 124: PW number 1 T1 port 1 of the module installed in slot 1 Payload type data.
GMUX2000>config>cross-connect# pw-tdm pw 1 t1 1/1 time-slots [1..24] data
Performing Internal Mapping

Map T1 port 1 to VT1-5 port 1. GMUX2000>config>cross-connect# tdm-mapping vt1-5 9/1/1 t1 1/1

See the Updating Configuration Database section above.
For the following configuration steps, use the latest IPmux-24 Installation and Operation Manual. Configure as follows: Host IP address: Next Hop Host IP Mask: Manager IP Address: T1 Line Type: Tx CLK source:
Gmux-2000 Ver. 4.0
<IPmux-24 Host IP> <Next Hop IP Add> <IPmux-24 Host Mask> <NMG Station IP> Unframed Adaptive
6-15
Bundle ID: Destination IP: Destination ID: TDM bytes: Jitter buffer: OAM TDMoIP
1 <Gmux-2000 router interface IP> 3 5 15 Enable V2
6.5
Application 5 Voice Trunking Application
The following procedure explains the main configuration actions for transporting compressed voice between two MSCs (referred to as West and East) using a pair of Gmux-2000 units equipped with VCA-T1/16 voice compression modules. A network management station (not shown) is connected to the West Gmux-2000. The application is shown in Figure 6-3.
Note
The configuration procedures illustrated below are based on the use of SNMPv1. All the following configuration procedures assume that you are using SNMP without SNMPv3 security features. To disable SNMPv3: 1. Select Configuration > System > Management. 2. Change SNMPv3 to Disabled. 3. Save and update the database.
MSC OC-3 (60 T1) Gmux-2000 5 T1 Gmux-2000 OC-3 (60 T1) MSC
Figure 6-3. Voice Trunking Application

In the following examples, the following IP parameters are used: The IP addresses used at the West Gmux-2000 are as follows:
IP Address CL Interface GbE Module Port Management Station 172.17.92.70 192.168.5.70 192.168.5.100 Mask 255.255.255.0 255.255.255.0 255.255.255.0 Default Gateway 172.17.92.1 192.168.5.1 192.168.5.70
The IP addresses used at the East Gmux-2000 are as follows:

IP Address Mask Default Gateway
6-16
Gmux-2000 Ver. 4.0
Installation and Operation Manual CL Interface GbE Module Port 172.17.92.71 192.168.5.71
Chapter 6 Configuring Typical Applications 255.255.255.0 255.255.255.0 172.17.92.70 192.168.5.1
Configuring the West Gmux-2000

When powering on the Gmux-2000 for the first time, the first step is to load the hardware configuration, which means to configure the Gmux-2000 to recognize the modules installed into the chassis 1. Select Configuration > Database Tools > Load Hardware. 2. Save and update the database. 3. Open Configuration > System > Card Type and then verify proper the correct hardware configuration: manually update to include any missing modules. Pseudowire Gateway Configuration>System>Card type SLOT: DB : SLOT: DB : SLOT: DB : PS-1 PS-AC IO/1 VCA16T1-US-NE IO/6 GbE PS-2 PS-AC PS-3 -----------CL-1 CL CL-2 CL
IO/2 IO/3 IO/4 IO/5 ------------ ------------ ------------ -------IO/7 IO/8 ------------ -----------IO/9 SONET-2
Configuring Management and IP Communication Parameters

1. Configure the Gmux-2000 IP addresses which will be used for the bundle connectivity and management. Open Configuration > System > Host IP and enter the following parameters. Pseudowire Gateway Configuration>System>Host IP INTERFACE ONLINE CL: GbE 1/IF 1: GbE 1/IF 2: 1. Change cell IP ADDRESS 172.17.92.70 192.168.5.70 0.0.0.0 IP MASK 255.255.255.0 255.255.255.0 0.0.0.0 DEFAULT GATEWAY 172.17.92.1 192.168.5.1 0.0.0.0
... (255.255.255.0)
2. Press S to Save, then % to update the database. 3. To allow the West Gmux-2000 to be managed via Telnet from the network management station, the management station IP address should be added to West Gmux-2000 manager list. 4. Open Configuration > System > Management > Manager List. 5. Press A to add a manager to the Manager List.
Gmux-2000 Ver. 4.0
6-17
Pseudowire Gateway Configuration>System>Management>Manager list VLAN ID[1 - 4094] VLAN PRIORITY[0 - 7] IP ADDRESS SUBNET MASK NEXT HOP INTERFACE TYPE TRAP(FOR MANAGER) VLAN VALID 4. Save. 5. To allow the East Gmux-2000 to be managed via Telnet from the West management station, the East CL IP address should be added to the West Gmux-2000 Manager List. Press <ESC> and then press A to add a second manager. Pseudowire Gateway Configuration>System>Management>Manager list VLAN ID[1 - 4094] VLAN PRIORITY[0 - 7] IP ADDRESS SUBNET MASK NEXT HOP INTERFACE TYPE TRAP(FOR MANAGER) VLAN VALID 6. Save. 7. Set the SNMP communities to later allow parameters change using SNMP. Use Configuration > System > Management > Authentication/Community. Pseudowire Gateway Configuration>System>Management>Authentication/Community 1. 2. 3. 4. 5. Trap community Read community Write community Authentication failure trap Save parameters ... ... ... > (public) (public) (public) (Off) ... ... ... ... ... > (0) (0) (172.17.92.71) (Desired Mask) (0.0.0.0) (VMUX SLOT 1) (Manager) (Yes) (No) ... ... ... ... ... > (0) (0) (192.168.5.100) (Desired Mask) (0.0.0.0) (GIG A-IO 6/1) (Manager) (Yes) (No)
1. 2. 3. 4. 5. 6. 7.
1. 2. 3. 4. 5. 6. 7.
8. Enable Telnet/SSH and SNMP access, to allow remote management. Use Configuration > System > Management > Management Access.
6-18
Gmux-2000 Ver. 4.0
Pseudowire Gateway Configuration>System>Management>Management access 1. User Access 2. Telnet/SSH access 3. SNMP access Web access 4. Radius Client > > > > >
(Enabled) (Enabled) (Disabled) (Local)
9. Save the parameters and update the database.
Configuring Physical Parameters of Voice Compression Module

1. Open Configuration > Physical Layer and select I/O 1 to configure the VCA-T1/16 module in slot 1. Pseudowire Gateway Configuration>Physical layer 1. 2. 3. 4. 5. 6. 7. 8. 9. I/O[1 - 9] T1 port voice T1 port data VT1.5 channel Signaling Profile Config Bandwidth Control SS7 Keep-Alive Suppression rate Delete all slot's bundles Disconnect all slot's bundles ... (1) > > > > > > (0%-No Suppression/Not SS7)
2. Configure voice port 1 physical parameters, using Configuration > Physical Layer > T1 port voice. ... >T1 port voice 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Pseudowire Gateway (IO 1: INT T1 VOICE PORT 1 CARD TYPE- VCA16T1-US-NE) ... (1) (Connected) ... (7F) > (Fast (1 sec)) (System A) > (B8ZS) ... (1) > (ESF) (Robbed) (64)
Channel ID[1 - 16] Admin Status Idle code[0 - ff] Restoration Time Transmit clk source Line code Profile [1 5] Assign entire port to bundle Line Type Signaling mode Data rate
3. Configure the same parameters for the other voice ports, 2 to 16. 4. Configure the data (uplink) port 1 physical parameters using Configuration > Physical Layer > T1 port data.
Gmux-2000 Ver. 4.0
6-19
...r>T1 port data 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Pseudowire Gateway (IO 1: EXT T1 DATA PORT 17 CARD TYPE- VCA16T1-US-NE) ... (1) (Connected) (Disable) ... (7F) > (Fast (1 sec)) (System A) (DSU) > (B8ZS) > (0-133 feet) [] > (ESF)
Channel ID[1 - 2] Admin Status Backup Status Idle code[0 - ff] Restoration Time Transmit clk source Interface type Line code Line length Sub channel configuration Assign entire Time Slots to port Line type
Configuring Physical Parameters of GBE Module

1. Open Configuration > Physical Layer and select I/O 6 to configure the GbE module. Pseudowire Gateway Configuration>Physical layer 1. 2. 3. 4. 5. I/O[1 - 9] Arp refresh L4 pools configuration GbE port Monitor Port ... (6) > (No Arp Refresh) > > (Auto Negotiation)
2. Leave the GbE port parameters default values. Pseudowire Gateway Configuration>Physical layer>GbE port - (IO 6: EXT PORT 1 CARD TYPE- GbE) 1. 2. 3. 4. GbE port[1 - 2] Connect state VLAN valid Auto Negotiation ... (1) (Connected) (No) (Enable)
Configuring Physical Parameters of OC-3 Module

1. Open Configuration > Physical Layer and select I/O 9 to configure the OC-3 module. Pseudowire Gateway Configuration>Physical layer 1. 2. 3. 4. I/O[1 - 9] Operation mode OC-3 port VC3 channel ... (9) > (Dual mode) > >
2. Open Configuration > Physical Layer > OC-3 port.
6-20
Gmux-2000 Ver. 4.0
Pseudowire Gateway ...n>Physical layer>OC3 channel - (IO 9: OC3 PORT 1 CARD TYPE- SONET-2) 1. 2. 3. 4. 5. 6. 7. Port ID[1 - 2] Connect state AIS on fail EED threshold SD threshold Clock mode Save parameters ... (1) (Connected) (Enable) > (3) > (6) (LBT)
Configuring System Clock

1. Configure Gmux-2000 system clock to be locked to the MSC clock. This clock will then be distributed to all Gmux-2000 ports. Open Configuration > System > Clock Source > System A > Master Clock. Pseudowire Gateway Configuration>System>Clock source>System A>Master clock 1. Master clock source 2. Master clock source ss pp 3. Save parameters > (Rx clk) ... (9/1)
Creating Bundles
Each T1 port (VT1.5) will have its own dedicated bundle, therefore, for 60 T1 trunks, it is necessary to create 60 bundles, using the same procedure as for bundle 1. 2. Open Configuration > Connection. Configuration>Connection 1. Bundle ID[1 - 2000] Pseudowire Gateway (BUNDLE 0) ... (0)
3. Press X to add the first bundle. Pseudowire Gateway Configuration>Connection - (BUNDLE 1) 1. Bundle ID[1 - 2000] ... (1) 2. Connection mode > (TDMoIP(CE)) 3. PSN type > (UDP/IP) 4. Connection configuration []> 5. Save parameters 4. Change Connection Mode to TDMoIP (CV) and the PSN type to UDP/IP.
Gmux-2000 Ver. 4.0
6-21
Configuration>Connection 1. 2. 3. 4. 5.
Pseudowire Gateway (BUNDLE 1) ... (1) > (TDMoIP(CV)) > (UDP/IP)
Bundle ID[1 - 2000] Connection mode PSN type Connection configuration Save parameters
5. Open Configuration > Connection > Connection Configuration and configure the following parameters: Pseudowire Gateway Configuration>Connection>Connection configuration 1. 2. 3. 4. 5. 6. 7. 8. Connection State Function Routing Parameters Max Bytes In Multiplexed Frame[100 - 1461] Packetizing Interval (Msec)[10 - 90] Transparent Jitter size (N*10msec) Connectivity Parameters Voice Parameters (BUNDLE 1)
(Disable) >(UDP/IP+) > ... (1400) ... (30) > (4) > >
6. Open Configuration > Connection > Connection Configuration > Routing Parameters and configure the following parameters: Pseudowire Gateway ...>Connection>Connection Configuration>Routing Parameters -BUNDLE 1) 1. 2. 3. 4. 5. 6. 7. 8. 9. Destination IP Next Hop Source CBID[1 - 8063] Dest CBID[1 - 8063] Exit Port Exit Channel[1 - 10] TOS Parameters VLAN Parameters Save parameters ... ... ... ... ... ... > > (172.17.92.71) (0.0.0.0) (1) (1) (1/17) (1)
Assigning Timeslots to Voice Ports

1. To assign timeslots to voice port 1, open Configuration > TS Assignment. Pseudowire Gateway Configuration>TS Assignment 1. 2. 3. 4. Card ss/pp TS assignment Assign TS range to bundle Assign entire port to bundle ... (1/1) []> > >
2. Associate voice port 1 to bundle number 1. 3. Connect voice port 1 to destination port 1.
6-22
Gmux-2000 Ver. 4.0
4. Configure the timeslots 1 to 31 of the voice port 1 to carry Voice traffic. 5. Connect the whole timeslot range 1 to 31 to the bundle. Pseudowire Gateway Configuration>TS Assignment>Assign TS range to bundle 1. 2. 3. 4. 5. 6. 7. 8. Bundle number[1 - 2000] ... TS type > Dest port[1 - 16] ... From TS[1 - 24] ... Num of TS[1 - 24] ... Connect the TS range to bundle Disconnect the TS range from bundle Save port assignment (1) (Voice) (1) (1) (24)
6. Check voice port 1/1 timeslot assignment. Pseudowire Gateway Configuration>TS Assignment>Ts assignment TIME SLOT NUM : ts 1 ts 2 Bundle number: 0 0 Ts type: NC NC ->> 1. Change cell [1 - 2000] ts 3 0 NC ts 4 0 NC ts 5 0 NC ts 6 0 NC ts 7 0 NC ts 8 0 NC
... (0)
7. To view the other timeslots, press CTRL + R (scroll right).
Map Voice Ports to the OC-3 Link

1. Open Configuration > Physical Layer and configure the OC3 module in I/O slot 9 as follows: Pseudowire Gateway Configuration>Physical layer 1. 2. 3. 4. IO[1 - 9] Operation mode OC3 channel VC3 channel ... (9) > (Dual mode) > >
Gmux-2000 Ver. 4.0
6-23
Pseudowire Gateway ...n>Physical layer>VC3 channel - (IO 9: VC3 PORT 1 CARD TYPE- SONET-2) 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Channel ID[1 - 6] Connect state AIS & RDI on signal label AIS & RDI on path trace J1 TX path trace J1 RX path trace J1 path trace EED threshold SD threshold Telecom assignment ... (1) (Connected) (Enable) (Enable) (Enable) (Disable) ... () > (3) > (6) []>
2. Map the T1 ports to the OC-3 link in accordance with the prescribed assignment, as follows (for example, voice port 1/1 is mapped to TUG3-1/TUG2-1/TU11-1). Pseudowire Gateway ...3 channel>Telecom assignment - (IO 9: VC3 PORT 1 CARD TYPE- SONET-2) STS1 1 TU2 TU3 0/0 0/0 NC NC NC NC STS1 2 TU2 0/0 NC NC STS1 3 TU1 TU2 0/0 0/0 NC NC NC NC
TU1 TUG2-1 1/1 add : A v drop: A
TU4 0/0 NC NC
TU1 0/0 NC NC
TU3 0/0 NC NC
TU4 0/0 NC NC
TU3 0/0 NC NC
TU4 0/0 NC NC
1. Change cell
... (0/0)
Connecting Bundles
1. Connect bundle number 1 as follows. Configuration>Connection 1. 2. 3. 4. Bundle ID[1 - 2000] Connection mode PSN type Connection configuration Pseudowire Gateway (BUNDLE 1) ... (1) > (TDMoIP(CV)) > (UDP/IP+)
Pseudowire Gateway Configuration>Connection>Connection configuration 1. 2. 3. 4. 5. 6. 7. Connection State Routing Parameters Max Bytes In Multiplexed Frame[100 - 1461] Packetizing Interval (Msec)[10 - 90] Connectivity Parameters Voice Parameters Save parameters
(BUNDLE 1)
(Enable) > ... (1400) ... (30) > >
6-24
Gmux-2000 Ver. 4.0
Configuring Voice Ports 2 to 6

1. Repeat the procedure in Creating Bundles to create another 5 bundles (bundles 2 to 6). 2. Repeat the procedure in Assigning Timeslots to Voice Ports to assign all the timeslots of the voice ports 2 to 6 of slot 1 as VOICE timeslots. 3. Repeat the procedure in Map Voice Ports to the OC-3, to map the voice ports 2 to 6 to the next TUs. 4. Repeat the procedure in Connecting Bundles to connect bundles 2 to 6.
Assigning Data Port Timeslots

1. Open all the 24 timeslots of the data port 1/17 (first data channel) using Configuration > TS Assignment, as follows: Pseudowire Gateway Configuration>TS Assignment 1. Card ss/pp 2. TS assignment 3. Assign entire TSs to port ... (1/17) []>
Pseudowire Gateway Configuration>TS Assignment>Assign entire TSs to port 1. 2. 3. 4. Sub channel number[1 - 10] Connect entire Time Slots to port Disconnect entire Time Slots from port Save port assignment ... (1)
2. View the timeslot assignment of data port 1/17 as follows: Pseudowire Gateway Configuration>TS Assignment>TS assignment TIME SLOT NUM : ts 1 ts 2 ts 3 ts 4 ts 5 ts 6 ts 7 Channel number: 1 1 1 1 1 1 1 Ts mode: Connect Connect Connect Connect Connect Connect Connect ->> 3. To view the other timeslots, press CTRL + R (scroll right)
Configuring the East Gmux-2000

Perform the tasks in the Configuring the West Gmux-2000 section again, but this time on the East Gmux-2000.
Gmux-2000 Ver. 4.0
6-25
Use the following IP addresses:

IP Address CL Interface GbE Module Port 172.17.92.71 192.168.5.71 Mask 255.255.255.0 255.255.255.0 Default Gateway 172.17.92.70 192.168.5.1
Therefore, configure the East Gmux-2000 Manager List as follows: Pseudowire Gateway Configuration>System>Management>Manager list VLAN ID[1 - 4094] ... (0) VLAN PRIORITY[0 - 7] ... (0) 1. IP ADDRESS ... (192.168.5.100) 2. SUBNET MASK ... (Desired Mask) 3. NEXT HOP ... (172.17.92.70) 4. INTERFACE > (VMUX SLOT 1) 5. TYPE (Manager) 6. TRAP(FOR MANAGER) (Yes) 7. VLAN VALID (No) For the East Gmux-2000, the destination bundle IP address is 172.17.92.70.
6.6
Inband Management of Gmux-2000 via Voice Compression TDM Links
The following procedure explains the configuration actions for enabling a network management station, connected to a central Gmux-2000 unit, to manage a remote Gmux-2000 unit inband, over a TDM link connecting between VCA-T1/16 or VCA-T1/12 modules installed in the central and remote Gmux-2000 units. The application is shown in Figure 6-4. The connection to the PSN is made through port 1 of the GbE module in the central Gmux-2000, and the network management station will connect through the PSN only to this Gmux-2000.
6-26
Gmux-2000 Ver. 4.0
Management Station
IP Address: 192.168.5.100 Default Gateway: 192.168.5.70 GbE Port IP Address: 192.168.5.70 GbE Link TDM Link Gmux-2000 with VCA-T1/16 and GbE Modules Online CL IP Address: 172.17.92.70 TDM Network TDM Link
Gmux-2000 with VCA-T1/16 and GbE Modules Online CL IP Address: 172.17.92.71 Default Gateway: 172.17.92.70
Figure 6-4. Inband Management of Gmux-2000 via Voice Compression TDM Links
Configuration Procedure
1. Use Configuration > System > Host IP to configure the central and remote Gmux-2000 CONTROL modules with IP addresses from the same IP subnet. Example: Central Gmux-2000 CONTROL module = 172.17.92.70 Remote Gmux-2000 CONTROL module = 172.17.92.71 Default gateway (must be configured as the central Gmux-2000 CONTROL module IP address) = 172.17.92.70 The following figure shows the configuration of the remote Gmux-2000.
Gmux-2000 Ver. 4.0
6-27
Pseudowire Gateway Configuration>System>Host IP INTERFACE ONLINE CL: GbE 1/IF 1: GbE 1/IF 2: GbE 2/IF 1: GbE 2/IF 2: 1. Change cell IP ADDRESS 172.17.92.71 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 IP MASK 255.255.255.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 ... (0.0.0.0) DEFAULT GATEWAY 172.17.92.70 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
> Please select item <1 to 1> ESC-prev.menu; !-main menu; &-exit; @-debug; ?-help
1 M/ 1 C
2. Configure the GbE module in the central Gmux-2000 and the network card of the manager management station with IP addresses in the same IP subnet, but in subnets different from the subnet of the Gmux-2000 CONTROL module. Example: GbE module = 192.168.5.70 Management station network card = 192.168.5.100 The following figure shows the configuration of the central Gmux-2000. Note that in this example the default gateway is left unchanged: in a real application, you need to enter here the IP address of the PSN edge router port, through which the connection to the PSN is made. Pseudowire Gateway Configuration>System>Host IP INTERFACE ONLINE CL: GbE 1/IF 1: GbE 1/IF 2: GbE 2/IF 1: GbE 2/IF 2: 1. Change cell IP ADDRESS 172.17.92.70 192.168.5.70 0.0.0.0 0.0.0.0 0.0.0.0 IP MASK 255.255.255.0 255.255.255.0 0.0.0.0 0.0.0.0 0.0.0.0 ... (0.0.0.0) DEFAULT GATEWAY 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
> Please select item <1 to 1> ESC-prev.menu; !-main menu; &-exit; @-debug; ?-help
1 M/ 1 C
3. Configure the Manager List in the central Gmux-2000 unit to include the IP addresses of the management station IP port and its exit interface, and the remote Gmux-2000 CONTROL module and exit interface. Example: 192.168.5.100 (this is the IP address of the management station), exit interface = GbE port 6/1 (or port 8/1, if the GbE module is inserted in slot 8)
6-28
Gmux-2000 Ver. 4.0
172.17.92.71 (this is the CONTROL module IP address of the remote Gmux-2000), exit interface = VCA-T1/16 or VCA-T1/12 in slot 1 The following figure shows the configuration of the central Gmux-2000. Pseudowire Gateway Configuration>System>Management>Manager list IP ADDRESS 192.168.5.100 172.17.92.71 SUBNET MASK 255.255.255.000 255.255.255.000 NEXT HOP 0.0.0.0 0.0.0.0 INTERFACE GIG A 6/1 VMUX SLOT 1
> ESC-prev.menu; !-main menu; &-exit; @-debug; ?-help
1 M/ 1 C
4. Configure the Manager List in the remote Gmux-2000 unit to include the IP address of the management station, and the next hop = CONTROL module IP address of the central Gmux-2000 and exit interface. Example: 192.168.5.100 (this is the IP address of the management station), next hop = 172.17.92.70, exit interface = VCA-T1/16 or VCA-T1/12 slot 1 The following figure shows the configuration of the remote Gmux-2000. Pseudowire Gateway Configuration>System>Management>Manager list IP ADDRESS 192.168.5.100 SUBNET MASK 255.255.255.000 NEXT HOP 172.17.92.70 INTERFACE VMUX SLOT 1
> ESC-prev.menu; !-main menu; &-exit; @-debug; ?-help
1 M/ 1 C
5. Configure the management station default gateway as the IP address of the central Gmux-2000 GbE module (192.168.5.70). This completes the basic configuration: now, when the management station looks for the CONTROL module IP address of central Gmux-2000 CONTROL module, 172.17.92.70, or the CONTROL module IP of the remote Gmux-2000, 172.17.92.71, it will use the Gmux-2000 GbE module (192.168.5.70). You can use Telnet to contact the local Gmux-2000 unit (172.17.92.70) or the remote Gmux-2000 (172.17.92.71) from the management station, and verify that you have access to the configuration menus.
Gmux-2000 Ver. 4.0
6-29
6-30
Gmux-2000 Ver. 4.0
Chapter 7 Troubleshooting and Diagnostics

This Chapter describes Gmux-2000 troubleshooting and diagnostic functions, which include: Reporting of configuration (sanity) errors Alarm and event collection, and reporting of relevant alarms by means of traps Diagnostic tests for checking transmission paths Ping for IP connectivity testing.
These functions can be used to identify problems in the network incorporating Gmux-2000 units, test the proper operation of each Gmux-2000 unit, and locate rapidly the cause of the fault: within the Gmux-2000 itself, in its connections to the network or to a users equipment unit, or in the another network component. In addition to the general Gmux-2000 functions described in this Chapter, you can find information on the module-specific diagnostic functions in the Installation and Operation Manual of each module. If you need additional support for this product, see Section 7.6 for technical support information.
7.1
Preliminary Checks
Troubleshooting
In case a problem occurs, perform the following preliminary checks: If the problem is detected the first time the Gmux-2000 is put into operation, first perform the following checks: Check for proper chassis and module installation, and correct cable connections, in accordance with the system installation plan. Check the system and module configuration parameters in accordance with the specific application requirements, as provided by the system administrator. If the Gmux-2000 nodal clock is to be locked to the clock recovered from one of the ports of a module installed in the chassis, make sure a suitable fallback clock source is configured and provides a good clock signal.
Gmux-2000 Ver. 4.0
Troubleshooting
7-1
If the FLT indicator of a module lights, replace the corresponding module. When more than one module of the same type is installed, check the ACT indicators: the ACT indicator of each active module must light. If not lit, first check the configuration. Check the displayed alarm messages and refer to Section 7.3 for their interpretation and associated corrective actions.
Troubleshooting Hardware Problems

If the problem cannot be corrected by performing the actions listed above, refer to Table 7-1. Identify the best-fitting trouble symptoms and perform the actions listed under Corrective Measures in the order given, until the problem is corrected.
Table 7-1. Hardware Troubleshooting Chart

No. 1 Trouble Symptoms Gmux-2000 does not turn on Probable Cause 1. No power Corrective Measures Check that power is available at the power outlets or power distribution panel serving the Gmux-2000. Check that both ends of all the Gmux-2000 power cables are properly connected. 2. Blown fuse For an AC-powered Gmux-2000:
1. Check and if necessary replace the fuses

located on the PI/AC module.
2. If a fuse blows again, replace the

corresponding PS module.
3. If any fuse blows again, replace Gmux-2000.

For a DC-powered Gmux-2000 using a full-width PI/DC module:
1. Check and if necessary replace the fuse(s)

located on the PI/DC module.
2. If a fuse blows again, try to identify the PS

module that may be causing the problem, by sequentially removing each PS module and checking whether the fuse stops blowing.
3. If the fuse keeps blowing, replace the

Gmux-2000 if any fuse blows again. For a DC-powered Gmux-2000 using a half-width PI/48 module:
1. Check that the PI/48 FLT indicators are off.

Replace the corresponding module if its FLT indicator lights.
2. Check that the ACT indicator of a PI/48

module lights. If not, check the DC source.
3. Replace the FILTER module, and then PI/48

modules until problem is corrected
7-2
Troubleshooting
Gmux-2000 Ver. 4.0
No.
Trouble Symptoms
Probable Cause 3. Defective PS module
Corrective Measures Replace the suspected PS module
4. Defective Gmux-2000 Replace Gmux-2000 2 The local Gmux-2000 cannot be configured through its CONTROL DCE port 1. Connection made to Check that the connection is made to the the inactive CONTROL CONTROL DCE connector of the CONTROL module module whose ACT indicator lights 2. Configuration problem Restore the default parameters using the switches located on the CONTROL modules as explained in Chapter 3, and then perform the preliminary supervision terminal configuration instructions given in Chapter 4 Check the equipment serving as a supervision terminal and the connecting cable. If data equipment provides the link between the supervision terminal and the Gmux-2000, check its proper operation 4. Software not yet Download the appropriate Gmux-2000 software loaded into CONTROL to the CONTROL modules in accordance with module, or corrupted Appendix B 5. Defective CONTROL module 3 The local Gmux-2000 cannot be managed through its CONTROL ETH port 1. Configuration problems Replace the corresponding CONTROL module Check the CONTROL ETH port configuration. Check that the ACT indicator of the CONTROL module lights Check that the LINK indicator of the CONTROL ETH port lights. If not, check for proper connection of the cable between the LAN and the CONTROL ETH port. Also check that at least one node is active on the LAN, and that the hub or Ethernet switch to which the Gmux-2000 CONTROL ETH port is connected is powered Check the external equipment (for example, the default gateway and other routers) that process the traffic coming from the local Gmux-2000 CONTROL ETH port Replace the corresponding CONTROL module
3. External problem
2. Problem in the connection between the CONTROL ETH port and the LAN
3. External problem
4. Defective CONTROL module
5. Defective Gmux-2000 Replace Gmux-2000
Gmux-2000 Ver. 4.0
Troubleshooting
7-3
No. 4
Trouble Symptoms
Probable Cause
Corrective Measures Check for proper connections of the cables to the LINK TX and RX connectors of each OC3 module port. Repeat check at the users equipment connected to the port.
The LOSS LOC indicator of 1. Cable connection an OC3 module port of the problems local Gmux-2000 lights
2. Other problem
Activate the local loopback at the local OC3 module port. If the local users equipment connected to the OC3 module port does not receive its own signal, check its operation and replace if necessary If the problem is not in the equipment connected to the OC3 module port, replace the OC3 module
The LOSS REM indicator of 1. Defective OC3 module Activate the local loopback at the local OC3 an OC3 module port of the module port. If the local users equipment local Gmux-2000 lights connected to the OC3 module port starts receiving its own signal, replace the OC3 module 2. External problem Activate the local loopback at the local OC3 module port. If the local users equipment connected to the OC3 module port does not receive its own signal, check its operation and replace if necessary If the problem is not in the equipment connected to the OC3 module port, replace the OC3 module
The status indicator of a local T1-PW-SRV/28 port lights in red
1. Loss of incoming port If there are any fault indications on the OC3 signal module served by this port, first solve the OC3 problem 2. Defective T1-PW-SRV/28 module Activate the remote loopback on the OC3 module port connected to the corresponding T1-PW-SRV/28 port. If the T1-PW-SRV/28 port status indicator turns off, check its operation and replace if necessary
3. Defective OC3 module Replace the OC3 module 4. Defective Gmux-2000 Replace Gmux-2000 7 The status indicator of a local T1-PW-SRV/28 port lights in yellow The status indicator of a local T1-PW/28 port lights in yellow External problem The remote equipment sends AIS. If problem persists, request troubleshooting of the remote equipment External problem The remote equipment sends AIS. If problem persists, request troubleshooting of the remote equipment
7-4
Troubleshooting
Gmux-2000 Ver. 4.0
No. 9
Trouble Symptoms
Probable Cause
Corrective Measures Check that the adapter cable connected to the module matches the configured T1 interface type, and then check for proper connection of the users equipment to the adapter cable connectors. Also check for proper connections at the users equipment connected to the port
The status indicator of a 1. Cable connection local T1-PW/28 port lights problem in red (loss of incoming T1 signal)
2. Other problem
Activate the local loopback at the local T1 port: If the local users equipment connected to the T1 port does not receive its own signal, check its operation and replace if necessary If the problem is not in the equipment connected to the T1 port, replace the T1-PW/28 module
10
The REM indicator of a local CT3-PW/1 T3 port lights The LOC indicator of a local CT3-PW/1 T3 port lights in red
External problem
The remote equipment reports an alarm condition (yellow alarm). If problem persists, request troubleshooting of the remote equipment Check for proper connection of the cables connecting the T3 users equipment to the local CT3-PW/1 T3 port. Activate the local loopback at the local T3 port: If the local users equipment connected to the T3 port does not receive its own signal, check its operation and replace if necessary If the problem is not in the equipment connected to the T3 port, replace the CT3-PW/1 module
11
1. Cable connection problem 2. Other problem
12
The Gmux-2000 cannot connect to the PSN network
1. Uplink configuration problems
Check the uplink port configuration, and the other parameters that affect routing. Also check the external equipment (for example, routers) that processes the traffic coming from the local Gmux-2000 GbE port
2. Problem in uplink connections
Check that the LINK indicator of the corresponding GbE port lights, and that its TX and RX indicators flash from time to time. If not, check for proper connection of the fibers to the GbE port, and to the remote equipment. Also check that the equipment to which the GbE port connects is powered and active If the PAUSE indicator lights continuously, check the remote equipment configuration
3. Congestion problem
4. Defective GbE module Replace the GbE module 5. Defective Gmux-2000 Replace Gmux-2000
Gmux-2000 Ver. 4.0
Troubleshooting
7-5
Handling Service Problems

The main tool used to analyze unsatisfactory service, or service degradation, is to use the performance statistics and status data collection tools provided by the Gmux-2000. By analyzing the performance statistics and status data, it is possible to identify the unsatisfactory performance area, and take steps to change the system configuration and enhance resources such a network bandwidth, etc., as required to improve the service quality. It is also recommended to check Section 7.5 for answers to frequently asked questions. Contact RAD Technical Support Department if you need additional help with your particular application.
7.2
Detecting Configuration (Sanity) Errors
Gmux-2000 includes an extensive subsystem that continuously checks the validity of the users configuration activities, and reports any conflicts and errors. Two types of sanity error messages are reported: Warning Minor error that does not prevent using the Gmux-2000. For example, you will get a warning when a programmed module is not physically installed in the chassis. Error that prevents proper operation of the Gmux-2000 in its intended application. For example, you will get an error as a result of invalid timeslot assignment. It is not possible to update the online database when sanity errors are present.
Error
Interpreting the Sanity Errors

Table 7-2 lists the error messages generated by Gmux-2000, and explains their interpretation.
The messages are listed in ascending order of their codes.
Table 7-2. Error Messages

Code 000 Syntax INVALID MASTER CLOCK SOURCE Meaning The selected master clock source is invalid, for example: the selected port is unconnected, the port is located on a module not installed or not configured, or it is an unmapped module port It is not allowed to select the same reference source for both the master and fallback clocks
001
MASTER AND FALLBACK CLOCKS ARE THE SAME
7-6
Gmux-2000 Ver. 4.0
Code 002
Syntax
Meaning
INVALID FALLBACK CLOCK SOURCE The selected fallback clock source is invalid, for example: the selected port is unconnected, the port is located on a module not installed or not configured, or it is an unmapped module port DEFAULT GATEWAY AND IP ARE EQUAL DEFAULT GATEWAY & IP NOT IN SAME SUBNET ILLEGAL AGENT IP ADDRESS The default gateway address is the same as the Gmux-2000 agent IP address. This is not allowed The default gateway and the Gmux-2000 agent IP addresses must be in the same subnet. Alternatively, specify 0.0.0.0 (the default gateway) The IP address specified for the Gmux-2000 agent is an invalid IP address (for example, its first byte is 000 or 224, or the last byte is 000 or 255) The default gateway IP address specified for the Gmux-2000 agent is an invalid IP address. This occurs if the address is not 0.0.0.0 and its first byte is 000 or 224, or the last byte is 000 or 255 While configuring the Manager List, you specified the same IP address already assigned to the manager as the next hop IP address. Make sure to select a different IP address, but within the same subnet The IP address specified for a management station on the Manager List is an invalid IP address (for example, its first byte is 000 or 224, or the last byte is 000 or 255) The next hop IP address specified for a management station on the Manager List is an invalid IP address (for example, its first byte is 000 or 224, or the last byte is 000 or 255) The next hop IP address for the specified management station is not within the subnet of the Gmux-2000 agent, nor within the subnet of one of the GbE interfaces The IP address specified for a management station on the Manager List is already used in the network The reporting level selected for this alarm severity is illegal The module physically installed in the specified I/O slot does not match the module type configured in the database The specified pseudowire emulation server or voice compression module is incorrectly mapped. For example, it is mapped to an invalid or non-existing GbE port, or is not yet mapped (that is, the default mapping, 0/0, has not been changed) The specified timeslot has been mapped to a bundle that has not yet been defined. The user mapped TS to bundle, which does not exist.
003 004
005
006
ILLEGAL AGENT DEFAULT GATEWAY
007
MANAGER IP AND NEXT HOP ARE THE SAME
008
ILLEGAL MANAGER IP ADDRESS
009
ILLEGAL MANAGER NEXT HOP
010
MANAGER NEXT HOP IS NOT REACHABLE MANAGER IP ADDRESS IS NOT UNIQUE ILLEGAL ALARM REPORT LEVEL MISMATCH BETWEEN HARDWARE AND DATABASE SERVER CARD MAPPED TO ILLEGAL GBETH IF
011 012 013 014
015
TIME SLOT MAPPED TO ILLEGAL BUNDLE
Gmux-2000 Ver. 4.0
7-7
Code 016
Syntax PORT NC WHILE 1 OF ITS BUNDLES ACTIVE STM TU ASSIGNED TO ILLEGAL CARD
Meaning It is not allowed to change the status of the specified port to Not Connected while one or more of the bundles configured on the port are in the Connect state and are active The specified TU of the OC3 module installed in I/O slot SS is incorrectly mapped (it is connected to a pseudowire emulation server port located on an empty I/O slot, or the I/O slot is not equipped and configured with a pseudowire emulation server module) Two TUs of the OC3 module installed in I/O slot SS are mapped to the same pseudowire emulation server module port To carry a bundle, the specified pseudowire emulation server module port must be mapped to a TU on an STM1 module
017
018 019 020
MORE THAN ONE TU MAPPED TO SAME DEST PORT IS NOT MAPPED TO STM TU
STM CARD MAPPED TO T1 SERVER The specified TU of the STM1 module installed in I/O slot SS is mapped to a T1 pseudowire emulation server port. This is not allowed (the TU can only be mapped to an E1 pseudowire emulation server port) SONET CARD MAPPED TO E1 SERVER The specified TU of the OC3 module installed in I/O slot SS is mapped to an E1 pseudowire emulation server port. This is not allowed (the TU can only be mapped to a T1 pseudowire emulation server port) The IP address defined for the specified GbE port is invalid (for example, its first byte is 000 or 224, or the last byte is 000 or 255). A GbE port must always be assigned an IP address and that IP address must be valid
021
022
ILLEGAL IP ADDRESS FOR GB PORT
023
GB PORT IP IS SAME AS AGENT IP ADDRESS ILLEGAL GATEWAY FOR GB PORT
The same IP address is assigned both to the specified GbE port and to the Gmux-2000 agent (that is, the specified GbE port has the same IP address as that of the CONTROL module) The IP address defined for the default gateway is invalid (for example, its first byte is 000 or 224, or the last byte is 000 or 255). However, the default address (0.0.0.0) is also allowed
024
025 026 027
GB PORT IP AND DEFAULT GATEWAY EQUAL GB IP AND GATEWAY NOT IN SAME SUBNET AGENT DEFAULT GATEWAY AND GB IP EQUAL AGENT IP AND GB DEFAULT GATEWAY EQUAL TWO GBs HAVE THE SAME IP ADDRESS
The same IP address is assigned both to the specified GbE port and to its default gateway The default gateway IP address and the IP address assigned to the specified GbE port must be in the same subnet The default gateway of the Gmux-2000 agent and the specified GbE port have been assigned the same IP address. This is not allowed The default gateway of the specified GbE port and the Gmux-2000 agent have been assigned the same IP address. This is not allowed The GbE ports (as specified in the alarms) have been assigned the same IP address. This is not allowed
028
029
7-8
Gmux-2000 Ver. 4.0
Code 030
Syntax CANT CHANGE PARAMETER ON ACTIVE BUNDLE
Meaning Some parameters cannot be changed while a bundle is connected. The following operations cannot be performed while a bundle is connected: Changing the IP address of the GbE port Changing the module type Changing the framing (for TDM ports) Changing the timeslot assignment. Changing the source and destination of the bundle Changing the TDM port supporting the bundle.
Before performing any of the operations listed above, disconnect the bundle 031 FRAME TYPE CONFLICTS TS ASSIGNMENT This message, which is generated only after the specified bundle is switched to the Connect state, indicates one of the following timeslot assignment errors: 032 ILLEGAL EXIT PORT For a bundle mapped to an unframed port, all the port timeslots must be chosen For a port using G.704 multiframe, timeslot 16 cannot be mapped to a bundle
This message, which is generated only after the specified bundle is switched to the Connect state, indicates that the bundle is mapped to an illegal or non-existing TDM port This message, which is generated only after the specified bundle is switched to the Connect state, indicates that the bundle is mapped to an illegal or non-existing TDM port This message, which is generated only after the specified bundle is switched to the Connect state, indicates that more than one bundle mapped to a given destination IP address has the same source CBID UDP value. The source UDP value is defined as follows: If the payload format is proprietary: Source UDP = Source CBID+1 Otherwise Source UDP = Source CBID
033
ILLEGAL TDM PORT
034
SOURCE CBID IS NOT UNIQUE
This check is made for all types of bundles (IP and MPLS) 035 GB PORT CANNOT REACH IP OF BUNDLE This message, which is generated only after the specified bundle is switched to the Connect state, indicates that the IP address of the bundle cannot be reached by the specified GbE port because the bundle IP address does not comply with at least one of the following requirements: In the same subnet with the IP address of its GbE port The next hop IP address in the same subnet with the GbE port
In the same subnet with one of the static routes
Gmux-2000 Ver. 4.0
7-9
Code 036
Syntax BUNDLE IP IS SAME AS IT'S GB PORT IP ILLEGAL IP ADDRESS
Meaning This message, which is generated only after the specified bundle is switched to the Connect state, indicates that the bundle has the same IP address as its GbE port This message, which is generated only after the specified bundle is switched to the Connect state, indicates that the IP address defined for the bundle is invalid (for example, its first byte is 000 or 224, or the last byte is 000 or 255), or that it has the default value (0.0.0.0). This is not allowed a bundle must have a valid IP address
037
038
BUNDLE GBETH PORT MISMATCH SERVER IF
The GbE port defined for a bundle must be the same as the GbE port serving the pseudowire emulation server module supporting the corresponding bundle. This message is generated only after the specified bundle is switched to the Connect state
039
ILLEGAL INTERFACE FOR STATIC ROUTE
This message, which is generated only after the specified static route is switched to the Connect state, indicates that this static route is defined on an incorrect interface number, for example, to an interface on a non-existing or not configured GbE module This message, which is generated only after the specified static route is switched to the Connect state, indicates that its defined IP address is invalid (for example, its first byte is 000 or 224, or the last byte is 000 or 255), or that it has the default value (0.0.0.0). This is not allowed a static route must have a valid IP address
040
ILLEGAL IP ADDRESS FOR STATIC ROUTE
041
ILLEGAL NEXT HOP FOR STATIC ROUTE
This message, which is generated only after the specified static route is switched to the Connect state, indicates that its next hop IP address is invalid (for example, its first byte is 000 or 224, or the last byte is 000 or 255), or that it has the default value (0.0.0.0). This is not allowed a static route must have a valid next hop IP address
042
IP AND NEXT HOP SAME FOR STATIC ROUTE
This message, which is generated only after the specified static route is switched to the Connect state, indicates that its next hop and IP addresses are the same. This is not allowed the addresses must be different This message, which is generated only after the specified static route is switched to the Connect state, indicates that its IP address is equal to the IP address of the assigned GbE port. This is not allowed the addresses must be different
043
STATIC ROUTE IP SAME AS GBETH IP
044
ILLEGAL STATIC ROUTE SUBNET MASK
This message, which is generated only after the specified static route is switched to the Connect state, indicates that its subnet mask is not 255.255.255.255
7-10
Gmux-2000 Ver. 4.0
Code 045
Syntax STATIC ROUTE NEXT HOP IS NOT REACHABLE
Meaning This message, which is generated only after the specified static route is switched to the Connect state, indicates that its next hop IP address is unreachable, because it is neither within the subnet of the CONTROL module nor within the subnet of one of the Gmux-2000 GbE interfaces This message, which is generated only after the specified static route is switched to the Connect state, indicates that its IP address is already assigned to another static route. This is not allowed only one static route may be defined for any specific IP address
046
STATIC ROUTE IP IS NOT UNIQUE
047 048
GBETH PORTS CAN'T BE ON SAME The IP addresses assigned to the two ports of a GbE module SUBNET cannot be in same subnet SAME SOURCE CBID FOR MPLS MODE BUNDLES This message, which is generated only after the specified bundles are switched to the Connect state, indicates that the source CBID value is assigned to more than one bundle using MPLS
049
SAME DEST CBID FOR MPLS MODE This message, which is generated only after the specified bundles BUNDLES are switched to the Connect state, indicates that the destination CBID value is assigned to more than one bundle using MPLS BUNDLE ALREADY MAPPED TO ANOTHER PORT SS:PP:TS The bundle being configured is already mapped to the port specified in the message. The user mapped a bundle to two different E1/T1 ports
050
051 052
MORE THAN 16 BUNDLES FOR PORT CAN'T CHANGE PARAM AFTER BUNDLE CREATED
You are trying to connect too many bundles to the specified port (the maximum is 16). Some of the parameters of a bundle can be configured only when the bundle is created. The bundle parameters that can be configured only upon creation are as follows: Encapsulation TX circuit bundle type Payload type PSN type
To change any of these parameters, first delete the bundle and then recreate the bundle with the new parameters 053 ILLEGAL NEXT HOP FOR BUNDLE This message, which is generated only after the specified bundle is switched to the Connect state, indicates that its next hop IP address is invalid (for example, its first byte is 000 or 224, or the last byte is 000 or 255). Alternatively, if the bundle destination IP address is within the subnet of the GbE port, the next hop IP address must have the default value (0.0.0.0). 054 ILLEGAL MPLS PAYLOAD FORMAT FOR BUNDLE This message, which is generated only after the specified bundle is switched to the Connect state, indicates that its payload format is invalid. For MPLS bundles, the payload format must be Standard no RTP
Gmux-2000 Ver. 4.0
7-11
Code 055
Syntax
Meaning
ILLEGAL MPLS IP TOS FOR BUNDLE This message, which is generated only after the specified bundle is switched to the Connect state, indicates that its ToS value is invalid. For MPLS bundles, the ToS is determined by the EXP bits, and must be within the range of 0 to 7
056
ILLEGAL OAM FORMAT FOR BUNDLE
This message, which is generated only after the specified bundle is switched to the Connect state, indicates that its OAM format is invalid. For MPLS bundles, the OAM format must be same as the payload format
057
ILLEGAL ADAPTIVE CLOCK MODE FOR BUNDLE
This message is generated only after the specified bundle is switched to the Connect state. When you select ADAPTIVE CLOCK = ENABLED for a bundle, the timing of the corresponding TDM port must be ADAPTIVE
058
MORE THAN 1 ADAPTIVE BUNDLE FOR PORT
This message, which is generated only after the specified bundle is switched to the Connect state, indicates that the adaptive timing mode has already been configured for another bundle using the same TDM port. This is not allowed only one bundle of any TDM port may have its timing mode configured to Adaptive
059
CARD TYPE CHANGED FOR MASTER CLOCK SRC CARD TYPE CHANGED FOR FBACK CLOCK SRC ILLEGAL TU MAPPING FOR OPERATION MODE
The type of module installed in the slot currently configured as master clock source card type has been changed. Make sure to reconfigure the master clock source The module type of module installed in the slot currently configured as fallback clock source card type has been changed. Make sure to reconfigure the fallback clock source The current Gmux-2000 version supports only the terminal mode, and therefore the only allowed selections for TU routing (performed by means of the Telecom Assignment screen) for both ADD and DROP are NC, A or B The bundle far end configuration is incompatible with the TDM port line type and payload format configured for the local bundle end. This message is generated only after the specified bundle is switched to the Connect state
060
061
062
ILLEGAL FAR END TYPE CONFIGURATION
063
SAME DEST IP SHOULD HAVE SAME VLAN ID
When two bundles have the same destination IP address, it is necessary to configure them with different VLAN numbers. This message is generated only after the specified bundle is switched to the Connect state
064
SAME TU ON OTHER MATRIX SHOULD BE BP
A TU that is bypassed between two VC-3 or STS-1 ports must remain in the same position in the frame structure (the TU number remains unchanged)
7-12
Gmux-2000 Ver. 4.0
Code 065 066 067 068
Syntax ALL EXT PORTS VC3 MUST HAVE SAME CONFIG LVC'S MUST HAVE SAME SIG LBL&PATH TRACE CL AND GIG PORT CANT BE IN SAME SUBNET DISCONNECT BUNDLES LINE TYPE CHANGE
Meaning All the STS-1 ports of a given external SONET port must have the same configuration (except for the J2 path trace string) All the low-order (VC-12 or VT-1.5) ports must have the same signal label and path trace strings. The IP addresses assigned to the GbE uplink ports cannot be in the subnet of the Gmux-2000 management IP addresses While a bundle is connected to a port, it is not allowed to change its timeslot assignment, nor change the TDM port line type to or from UNFRAMED. To make such changes, first disconnect the bundle from the I/O slot. This message is generated only after the specified bundle is switched to the Connect state
069
MANAGERS NEXT HOP IS SAME AS HOST IP MANAGERS IP IS AS SAME AS CL IP
You have configured the IP address already assigned to the Gmux-2000 management (Host IP) as the next hop IP address for a manager. This is not allowed You have configured the IP address already assigned to the Gmux-2000 management (Host IP) as the IP address of a manager. This is not allowed
070
071 072
NC VC PORT CANT BE MAPPED TO Before trying to map VC ports on an OC-3, make sure that all the SONET MATRIX ports are in the Connect state DEST CBID NOT UNIQUE FOR SAME DEST IP You have assigned the same destination CBID to two bundles mapped to same destination IP address. This is not allowed. This message is generated only after the specified bundle is switched to the Connect state
073 074 075
MPLS LABEL SHOULD BE UNIQUE MPLS LABEL SHOULD BE BIGGER THAN 15 BUNDLE'S IP IS AS SAME AS CL IP ADDRESS
You have assigned the same MPLS label to two different bundles. This is not allowed The MPLS label must be 16 or higher You have configured the IP address already assigned to the Gmux-2000 management agent as the destination IP address for a bundle. This is not allowed
076
DEST TS SHOULD BE UNIQUE FOR The bundle timeslots selected during the port timeslot PORT assignment have already been assigned for other purpose. This message is generated only after the specified bundle is switched to the Connect state
078
DEST TS FIELD CANNOT BE ZERO
You must configure a destination timeslot for each timeslot assignment. This message is generated only after the specified bundle is switched to the Connect state
079
ALL PORTS MUST BE SAME - LBT OR SYSTEM
All the Connected voice ports on the specified VCA-T1/16 or VCA-T1/12 module must use the same clock source: either LBT or SYSTEM-A
Gmux-2000 Ver. 4.0
7-13
Code 080
Syntax ASSIGN RX CLK SRC PORT TO SYSTEM A
Meaning When one of the data ports of the specified VCA-T1/16 or VCA-T1/12 module is selected as reference for the Gmux-2000 system (nodal) timing (this may occur when using the Rx Clock mode), then all the other ports (either voice or data), must be configured to the SYSTEM A mode It is not allowed to use a T1 voice port of a VCA-T1/16 or VCA-T1/12 module as TX clock source All the destination ports must be on the same system The IP address configured as next hop address must be differently from the bundle destination IP address. When using redundancy on GbE ports, it is not allowed to specify a secondary port as the exit port of a bundle When using redundancy on GbE ports, it is not allowed to specify a secondary port in a static route definition
081 082 083 084 085 086 087 088 089 090 091 092 093 094 095 096 097
CAN'T HAVE TX CLK SRC LIKE VOICE PORTS ALL PORTS MUST BE OF SAME SYSTEM STATIC ROUTE IP SAME AS BUNDLE IP SECONDARY GB PORT IN BUNDLE SECONDARY GE INTERFACE IN STATIC ROUTE
INTERFACE ALREADY EXIST IN APS You are trying to add an interface already selected for the APS group being configured APS NUMBER OF CHANNELS SHOULD BE 2 SAME PORT IN 2 APSs WRONG CHANNEL CARD TYPE FOR APS CFG MODE Make sure to configure exactly two ports as channels in an APS group You are trying to add an interface already selected for another APS group to the APS group being configured You are trying to add a channel from a module that does not support APS
CHANNELS MUST BE IN THE SAME The additional channel in the APS group being configured must be CARD taken from the same module as the first channel IP ADDRESS DEFINED ON SECONDARY GB PORT When using redundancy on GbE ports, it is not allowed to specify an IP address defined on a secondary port
TU MAPPING ON SECONDARY STM No mappings are allowed on an OC-3 port configured as PORT secondary port of an APS group 2 APSs NEEDED FOR CARD REDUNDANCY CARD REDUND PRIMARY SLOT ISN'T EQUAL CARD REDUND SECONDARY SLOT ISN'T EQUAL PORT ISN'T EQUAL IN CARD REDUNDANCY APS TU MAPPING ON APS STM INTERFACE When two OC3 modules are installed, it is necessary to configure two APS groups
When two OC3 modules are installed, it is necessary to configure two APS groups: one group must include ports 1 of each OC3 module, and the other group must include ports 2 of each OC3 module
You are trying to map TUs on an OC-3 port configured as part of an APS group. This is not allowed perform the mapping on the port intended as primary before configuring the APS group
7-14
Gmux-2000 Ver. 4.0
Code 098 099
Syntax APS INTERFACE NOT IN CONNECT STATE
Meaning Make sure the ports used as channels of an APS group are both configured as Connected
STM PORTS CAN'T BE CONNECTED You cannot bypass between two OC-3 ports (the installed TOGETHER Gmux-2000 version can only operate as a TM (terminal multiplexer) only TOO MANY BUNDLES FOR CARD IP ADDRESS NOT DEFINED FOR VMX CARD MANAGER IP IN ANOTHER INTERFACE SUBNET MODEM CANNOT BE IN RELAY WITH LBR DST PORT OF TS MUST BE 1 - 8 WITH LBR ALL VMX BUNDLES MUST HAVE SAME LBR CODER The maximum number of bundles that can be configured on a VCA-T1/16 or VCA-T1/12 module is 32 Make sure to configure the required IP address for the VCA-T1/16 or VCA-T1/12 module The IP address configured for the management station must be within the subnet of the Gmux-2000 IP interface on which it is defined It is not allowed to configure a VCA-T1/16 or VCA-T1/12 bundle to use modem relaying when using the LBRAD coder When using the LBRAD coder for one of the VCA-T1/16 or VCA-T1/12 module bundles, only the ports 1 to 8 can be in use When using the LBRAD coder for one of the VCA-T1/16 or VCA-T1/12 module bundles, all the other bundles defined on the same module must also use the LBRAD coder
100 101 102
103 104 105
106
ILLEGAL PORT(9-16) FOR BUNDLE When using the LBRAD coder for one of the VCA-T1/16 or WITH LBR VCA-T1/12 module bundles, only the ports 1 to 8 can be in use: the ports 9 to 16 cannot be used PORT SHOULD HAVE SINGLE BNDL Only one bundle with TDMoIP V2 and OAM enabled can be WITH OAM&V2 configured on each VCA-T1/16 or VCA-T1/12 module port CLOCK MODE NOT THE SAME IN BOTH STM PORTS STM PORT REDUNDANCY NOT ALLOWED When two OC-3 ports are used, you must select the same timing reference sources for both ports When two OC-3 modules are used, you must select the module redundancy mode when configuring an APS group, that is, the APS group can include only OC-3 ports from different modules (for example, port 1 of CL module A with port B of CL module B) After changing channels used by an existing TDMoIP (CV) bundle, first disconnect the bundle, and then update the database for the changes to take effect You cannot change the coder type and rate for an active TDMoIP (CV) bundle: first disconnect the bundle, and then update the database for the changes to take effect Make sure to configure a non-zero CBID value
107 108 109
110
CHANNELS CHANGE ONLY AFTER DISCNT & UPD DB CODER CANNOT CHANGE FOR ACTIVE BUNDLE VALUE OF CBID CANT BE ZERO
111
112 113 114
VALUE OF VLAN ID CANT BE ZERO After enabling VLAN tagging, you must specify a non-zero VLAN ID ILLEGAL EXIT DATA PORT TS MAPPING Make sure to assign timeslots to the exit port of the TDMoIP (CV) bundle
Gmux-2000 Ver. 4.0
7-15
Code 115 116 117 118 119 120
Syntax ILLEGAL BACKUP DATA PORT TS MAPPING ILLEGAL CARD TYPE FOR SATOP CES BUNDLE ILLEGAL FRAME TYPE FOR SATOP BUNDLE ILLEGAL FRAME TYPE FOR CES BUNDLE APS IFACES MUST BE OF SAME CARD TYPE MANAGER IFACE MUST BE PRIMARY
Meaning Make sure to assign timeslots to the backup exit port of the TDMoIP (CV) bundle SAToP and CES bundles are supported only by pseudowire emulation modules, T1-PW/28 and T1-PW-SRV/28 SAToP bundles are supported only by ports using the unframed mode CES bundles are supported only by ports using a framed mode Make sure that all the I/O slots specified as members in an APS group are equipped with the same module type When configuring a manager or a static route to use an interface (port), or an I/O module, included in an APS group, make sure to select only an interface located on the primary module. When using 1:N protection for VCA-T1/16 or VCA-T1/12 modules operating in the voice trunking mode, the VMX static route can use only interfaces located on a protected module, but not on the backup (protection) module
121
NPS PROTECTION MUST BE IN REVERT MODE
When using 1:N protection for external ports (NPS-101 protection switching device), make sure to select the revertive recovery mode. In this case, the backup (protection) module is automatically released after it is no longer needed, and thus the system is ready to protect again when another problem occurs. This is also recommended for 1:N protection for internal ports
122
TS ASSIGN NOT ALLOWED ON SECONDARY SERVER SECONDARY IFACE
It is not alowed to perform timeslot assignment for secondary ports, or for ports located on the backup (protection) module of an 1:N protection APS group It is not alowed to select a secondary GbE port (or a port located on a secondary module) of an APS group as a bundle exit port
123 124
CONFIG LINK RDN ON SECOND GE If one of the GbE ports of a GbE or GbE/2 module is already CARD configured as secondary port in an APS group, you cannot configure the other GbE port of that module as primary port in a different APS group SAME GBETH PORTS CONNECTED You are trying to include a GbE port that is already a member of an APS group in a second APS group. This is not allowed
125 126
GE PORT SHOULD BE CONNECTED Make sure that the administrative status of the GbE port you want to include in an APS group is Up (connected)
7-16
Gmux-2000 Ver. 4.0
Code 127
Syntax APS WRONG CFG MODE FOR GE CARD RDN
Meaning Make sure to select an APS configuration mode supported by the PSN module type installed in the chassis: For GbE modules: you can configure link aggregation per IEEE 802.3ad and 1:1 bidirectional port protection on the two ports of the same module, and 1:1 bidirectional module protection For GbE/2 modules: you can configure only link aggregation per IEEE 802.3ad (either on the two ports of the same module, or between the same-named ports on different modules)
128 129 130 131
NPS CHANNEL MUST BE DEFINED ONLY ONE NPS SYSTEM IN GMUX ILLEGAL RESTORE TIME FOR RDN MODE APS IFACES BUNDLES NOT WITH SAME CODER
Make sure to define the backup (protection) module as the first APS channel, and at least one protected module Gmux-2000 enables configuring a single 1:N protection group in the whole chassis The selected restore time is not valid for the selected redundancy mode When using 1:N protection, it is necessary to configure all the compressed voice bundles terminated on protected modules in the 1:N protection group to use the same coder and the same coder rate For GbE modules, it is necessary to configure the Layer 4 pools in accordance with the guidelines given in Chapter 3 of the GbE Installation and Operation Manual. If necessary, contact RAD Technical Support for additional details
132
POOLS OVERSIZE LIMIT
133 134
POOLS BLOCKSIZE ORDER AND LIMIT POOLS STRUCT FIT INTO BUNDLE STRUCT For GbE modules, the configured bundles require a Layer 4 pools memory space that exceeds the space available on the GbE module (contact RAD Technical Support for additional details). To avoid this error, the first step should be to reduce the number of bundles per destination It is not allowed to perform a remote loop on the specified link, because the link carries more than one bundle Gmux-2000 supports only two STM-1 links per chassis. Therefore, when two STM1 modules are installed in the chassis and more than two STM-1 ports are enabled (connected), it is necessary to configure APS group(s) on these ports
135 136
REMOTE LOOP TOO MANY BNDL PER LINK SDH MATRIX DEFINED IN TWO SDH SLOTS
137 138 139
VLAN ID UNDEFINED FOR CL CARD It is necessary to configure a VLAN ID for the CL (host) interface BANDWIDTH OVERHEAD HIGHER THAN PAYLOAD ILLEGAL SOURCE AND DEST CBID The selected bundle configuration parameters are not optimal When operating over MPLS PSN, the maximum allowed value of source and destionation bundles (CBID) must be less than 250
Gmux-2000 Ver. 4.0
7-17
Code 140
Syntax MORE THAN 12 DATA TS FOR PORT VC BUNDLE ILLEGAL CODING
Meaning For voice compression modules, the maximum number of data timeslots per voice port cannot exceed 12 (it is not allowed to have more than 12 HDLC timeslots) All the compressed voice bundles handled by a given voice compression module must use the same companding law (either A_law or _law) The coder selected for the compressed voice bundle is not supported by the voice port The coders selected at the two ends of the compressed voice bundle are not compatible Make sure to configure a static route to the IP address used by the syslog server Make sure to configure a static route to the IP address used by the RADIUS server Make sure to configure a static route to the IP address used by the TFTP server It is not allowed to enable OAM functionality for bundles using TDMoIP payload version V1 (OAM is supported only by payload version V2) It is not allowed to configure CES and SAToP bundles when the TDMoIP payload version is V1 (CES and SAToP bundles are supported only by payload version V2) For voice compression modules operating in the VoIP mode: you must configure a specific MEGACO media gateway (do not leave the default, an empty string) For voice compression modules operating in the VoIP mode: it is necessary to include at least one MGC IP address in the MGC list For voice compression modules operating in the VoIP mode: incorrect MGC configuration, you must assign a name string to each MGC with valid (non-zero) IP address
141
142 143 144 145 146 147
VC BUNDLE ILLEGAL CODER PER PORT VC BUNDLE ILLEGAL CODER ON JOINED PORTS SYSLOG SERVER IP IS NOT IN MANAGER LIST RADIUS SERVER IP IS NOT IN MANAGER LIST TFTP SERVER IP IS NOT IN MANAGER LIST BUNDLE V1 PAYLOAD VERSION WITH OAM BUNDLE CES SATOP WITH V1 BUNDLES MEDIA GATEWAY ID IS NOT CONFIG NO MGC IS CONFIGURED ILLEGAL MGC CONFIGURATION
148
149
150 151
152
ILLEGAL ENCODING MODE CONFIG For voice compression modules operating in the VoIP mode, incorrect encoding mode configuration: when using the text encoding mode (MEGACO parameter), it is necessary to configure at least one of the following parameters: gateway name, trunk name, or channel. ILLEGAL INTERFACE GROUP CONFIG For voice compression modules operating in the VoIP mode, it is mandatory to configure first an interface group (that is, set its Admin State to Enable) before configuring a SIGTRAN signaling link or an SCTP association For voice compression modules operating in the VoIP mode, it is mandatory to assign first signaling timeslots on the appropriate port, before configuring the SIGTRAN signaling link
153
154
ILLEGAL INVALID TS TYPE
7-18
Gmux-2000 Ver. 4.0
Code 155
Syntax DIFFER SIGN LINKS TO SAME TS
Meaning For voice compression modules operating in the VoIP mode, it is not allowed to use the same signaling timeslot for more than one signaling link with Admin State = Enable For voice compression modules operating in the VoIP mode, each SCTP association with Admin State = Enable that serves the same interface group number must be assigned a unique combination of remote IP address;remote port (unless one of them is zero). For voice compression modules operating in the VoIP mode, each SCTP association with Admin State = Enable must be assigned a unique local SCTP port For voice compression modules operating in the VoIP mode, each SCTP association with Admin State = Enable must be assigned a non-zero local SCTP port For voice compression modules operating in the VoIP mode, the total number of timeslots configured as Signaling timeslots cannot exceed the total number of signaling links with Admin State = Enable (therefore, the maximum number is 5) For voice compression modules operating in the VoIP mode, the remote IP address and port of an SCTP association operating in the client SCTP mode an SCTP association cannot be zero. However, this is allowed in server SCTP mode. For voice compression modules operating in the VoIP mode, any individual interface group can have at most 3 SCTP associations assigned to it. Remove the unneeded SCTP associations For voice compression modules operating in the VoIP mode, M2UA interface indentifier (IID) must be unique within the Gmux-2000 (each signaling link with Admin State = Enable must have a unique IID For voice compression modules operating in the VoIP mode, the total number of SCTP associations with Admin State = Enable must not exceed the configured resources (determined by the value of the Max Num of Associations parameter) For voice compression modules operating in the VoIP mode, the total number of interface groups with Admin State = Enable must not exceed the configured resources (determined by the value of the Max Num of Instances parameter)
156
DIFFER ASSOC TO SAME REM ASP
157
DIFFER INSTANCES TO SAME LOCAL PORT ILLEGAL INSTANCE LOCAL PORT
158
159
TOO MANY SIGNALING TS
160
INVALID ROUTING PARAM
161
TOO MANY SCTP ASSOC PER IG
162
DIFFER SIGN LINKS WITH SAME M2UA
163
TOO MANY SCTP ASSOC
164
TOO MANY INTERFACE GROUPS
Gmux-2000 Ver. 4.0
7-19
Code 165
Syntax TOO MANY SCTP STREAMS
Meaning For voice compression modules operating in the VoIP mode, the total number of SCTP streams must not exceed the configured resources (determined by the value of the Max Num of Streams parameter). For each existing SCTP association with Admin State = Enable, the total number of SCTP streams is given by the following values: SCTP server mode: the value of the Max Num of Incoming Streams parameter SCTP client mode: the value of the Max Num of Requested Outgoing parameter
166
VOIP THE SAME DSP PAYLOAD TYPE VCA VMX ILLEGAL MODEM RELAY OPTION VCA VMX ILLEGAL MFC OPTION T1 VOICE SAME SIGNALING MODE VOICE TS TYPE FOR ROBBED BIT
For voice compression modules operating in the VoIP mode, different payload types must be configured, using the Media Configuration menu, for the V.152, DTMF and AMR traffic Voice compression modules do not support the modem relay mode (a bundle parameter) Voice compression modules do not support the MFCR2 relay mode (a bundle parameter) All the voice ports of a given voice compression module with T1 ports must use the same signaling mode A voice compression module with T1 ports using robbed bit signaling can have only voice, or NC (not connected) timeslots (HDLC, SS7 and transparent timeslots are not allowed) For voice compression modules operating in the VoIP mode, it is necessary to enable at least one codec during Media Configuration For voice compression modules operating in the VoIP mode, it is necessary to enable at least one AMR codec rate (this is performed by means of the AMR priority table) For voice compression modules operating in the VoIP mode, it is not allowed to enable both AMR and G.729 codecs at the same time For voice compression modules operating in the voice trunking mode, make sure that the data port configured as Backup port is in the Connected state. For voice compression modules operating in the voice trunking mode, only 4 transparent timeslots are allowed in each bundle. This check is performed only after the bundle is in the Connect state
167 168 169 170
171
VOIP ALL CODECS DISABLED
172
VOIP ALL AMR RATES DISABLED
173
VOIP AMR AND G729 ENABLED
174
VMX BACKUP DATA PORT IN NC STATE MORE THAN 4 TRANS TS PER BNDL
175
176
DIFFER MULTIPLEXING AT THE SAME CARD
It is not allowed to terminate bundles using different multiplexing methods on the same pseudowire emulation module (all the pseudowires on a given module must use either source or destination multiplexing)
7-20
Gmux-2000 Ver. 4.0
Code 177 178 179 180 181
Syntax INJECT TONE TEST IN NOT VOICE TS SATOP BNDL ILLEGAL TDM BYTE IN FRAME BUNDLE AND GE SAME MAC BUNDLE AND CL HAVE SAME MAC ILLEGAL SEC PORT IN GENP CARD RDN
Meaning You are trying to inject a test tone in a timeslot which is not configured as voice timeslot. This is not allowed The number of TDM bytes per frame configured for the SAToP bundle specified by the error is not within the allowed range The destination MAC of a bundle using the Ethernet PSN type is used by one of the GbE ports. This is not allowed The destination MAC of a bundle using the Ethernet PSN type is used by the CL module. This is not allowed When configuring link aggregation for GbE/2 modules, you can select as secondary port in the APS group either the other GbE port on the same module, or the port with the same number on the other module When configuring link aggregation for GbE/2 modules, you cannot select a primary port on a module on which a port is already configured as secondary port in another APS group
182
PRIMARY RDN PORT IN SECOND GENP CARD
7.3
Handling Alarms and Traps
Overview of Alarm Collection and Reporting

Alarm Buffer
The Gmux-2000 continuously monitors critical signals and signal processing functions. In case a problem is detected, the Gmux-2000 generates time-stamped alarm messages. The time stamp is provided by an internal real-time clock.
Note
The Gmux-2000 can also monitor one external sense input, and will report its activation as any other internally-detected alarm.
The alarm messages generated by the Gmux-2000 are explained below. Internally, the Gmux-2000 stores alarms in an alarm buffer. This alarm buffer can store up to 256 alarm messages, together with their time stamps. The alarm history buffer is organized as a FIFO queue, therefore after 256 alarms are written into the buffer, new alarms overwrite the oldest alarms. The alarms can be read on-line by the network administrator using a SNMP-based network management station, a Telnet or SSH host, or a supervision terminal. The network administrator can then use the various diagnostic tests to determine the causes of the alarm messages and to return the system to normal operation. For continuous system monitoring, the following tools are available: Automatic sending of alarm messages through the supervisory port. Automatic sending of alarm traps to the user-specified network management stations.
Gmux-2000 Ver. 4.0
7-21
Automatic sending of event notifications (all traps and alarms, exceeding a user-configurable severity), to a user-specified remote syslog server.
When the Gmux-2000 is powered down, the alarm messages are erased, and therefore old alarms will not reappear after the Gmux-2000 is powered up again. When using the terminal or a Telnet/SSH host, the user also can clear (delete) the alarms stored in this buffer, after reading them.
Alarm Relays
In addition to the alarm collection and reporting facility, the Gmux-2000 has two alarm relays with floating change-over contacts: one relay for indicating the presence of major alarms and the other for minor alarms. Each relay changes state whenever the first alarm is detected, and returns to its normal state when all the alarms of the corresponding severity disappear. The relay contacts can be used to report internal system alarms to outside indicators, e.g., lights, buzzers, bells, etc., located on a bay alarm or remote monitoring panel.
Using the Event Log

The Gmux-2000 event log contains all the recorded events in accordance with their occurrence time stamp. For example, you may find in the event log the time an alarm has been detected, as well as the time at which the alarm condition disappeared. Therefore, the event log contains the alarm history of the Gmux-2000 and can be used to analyze the order of events, for example, for troubleshooting purposes. In addition to reading the event log, you may clear the whole log, or selected parts of it, as the events are no longer of importance. To permit deleting only those events that are no longer relevant Gmux-2000 provides a wide range of filtering tools, in accordance with type (history or status), or source (system, specific module, or even a specific port). Since many records may be generated after a fault occurs, or during maintenance, clearing the log after the conditions return to normal is recommended to ensure that maximum storage is available for new events.
Reading the Event Log

To display the log file: 1. Navigate to configure system event-log. 2. Type the print command. Gmux-2000 displays the current event log contents. The events appear on the screen in the order they have been recorded in the log (the last event appears at the end of the list). For each event, you can see (from left to right): the alarm code, the source, a short description of the alarm condition, the severity level, and the time stamp.
7-22
Gmux-2000 Ver. 4.0
GMUX2000>configure system event-log GMUX2000>config>system>event-log# print (097) PW 1 BUNDLE REMOTE FAIL (RDI) (018) SYS CL FLIP HAS OCCURED (002) PS-B POWER SUPPLY FAILURE (002) PS-A POWER SUPPLY FAILURE (005) SYS FAN NOT EXIST (006) PS-C TEMPERATURE IS TOO HIGH (006) PS-B TEMPERATURE IS TOO HIGH (006) PS-A TEMPERATURE IS TOO HIGH (004) SYS FAN FAIL (019) IO-1 PROGRAMMED,INSTALLED MODULE MISMATCH 07:11:40
major event major major critical warning warning warning critical major
07:447 07:086 07:076 07:076 07:076 07:076 07:076 07:076 07:076 07:076
Figure 7-1. Typical Event Log Display
Clearing the Log

To clear the desired section of the log: 1. Navigate to configure system event-log. 2. Type the clear command. Gmux-2000 clears all entries from the event log.
Displaying Alarms
To display all existing alarms: 1. Navigate to configure system. 2. Enter the alarms command. The alarms appear on the screen in the order they have been recorded in the log (the last event appears at the end of the list). For each alarm, you can see (from left to right): the source, a short description of the alarm condition, the severity level, the state (on/off), the mask (on/off). GMUX2000>configure system alarms Description Severity State Mask ----------------------------------------------------------------------------SYS FAN FAIL Critical On Off SYS FAN NOT EXIST Critical On Off PS-A POWER SUPPLY FAILURE Major On Off PS-A TEMPERATURE IS TOO HIGH Warning On Off PS-B POWER SUPPLY FAILURE Major On Off PS-B TEMPERATURE IS TOO HIGH Warning On Off PS-C TEMPERATURE IS TOO HIGH Warning On Off IO-1 PROGRAMMED,INSTALLED MODULE MISMATCH Major On Off
Figure 7-2. Typical Alarm Display
Gmux-2000 Ver. 4.0
7-23
To display port-specific alarms: 1. Navigate to configure port. 2. Select the desired port type, its slot/port number. 3. Enter the alarms command. For example: To display alarms for T1 port 1 on a module installed in slot 1: GMUX2000>configure port t1 1/1 GMUX2000>config>port>t1(1/1)# alarms Description Severity State Mask ----------------------------------------------------------------------------AIS OCCURED Major Off Off AIS SYNC LOSS Major Off Off
Interpreting Alarms
Table 7-3 lists the alarm messages generated by the Gmux-2000 and explains their interpretation. The alarm messages are listed in ascending order of their codes.
For each alarm, Table 7-3 also specifies the type (event or state), and lists the default severity level for state alarms. The severity level can be modified in accordance with the specific customers requirements using the Configuration > System > Alarm screen.
Note
A state alarm is an alarm that is in the ON state while a certain condition is present, and automatically changes to OFF when the condition is no longer present. This type of alarm cannot be cleared (removed from the alarm buffer) while it is in the ON state. An event alarm is an alarm that records the occurrence of an event. This type of alarm can be cleared at any time.
System and CONTROL Module Alarms

Table 7-3. Gmux-2000 CONTROL Alarms
Code Message 1 REAL-TIME CLOCK BATTERY FAILURE Type State Default Interpretation Severity Major The battery powering the Gmux-2000 internal real-time clock while the Gmux-2000 is not powered has failed. Replace the corresponding CONTROL module 2 POWER SUPPLY FAILURE State Major A power supply module is missing, is not turned on or failed. Install, turn on, or replace the corresponding power supply module
7-24
Gmux-2000 Ver. 4.0
Code Message 3 POWER SUPPLY DERATING
Type State
Default Interpretation Severity Major The corresponding power supply provides reduced power, in response to the activation of its internal protection circuits. 1. 2. 3. Check that all the other power supplies are not failed. Check that the fan tray operates normally. If the problem persists, replace the power supply.
FAN FAIL
State
Critical
The fan tray is not installed, or a failure has been detected in the fan tray. Install or replace the fan tray The fan tray is not installed, or a failure has been detected in the fan tray. Install or replace the fan tray The fan tray is not installed, or a failure has been detected in the fan tray. Install or replace the fan tray More than 255 alarms entries have been written in the history alarm buffer since the last clear command. Read the messages, and then clear the alarm buffer from the supervision terminal
FAN NOT EXIST
State
Critical
TEMPERATURE IS TOO HIGH ALARM BUFFER OVERFLOW
State
Warning
Event
Major
HARDWARE FAILURE
State
Major
Technical failure in the module installed in the specified slot. Replace the Gmux-2000 I/O module installed in the specified slot
FILE SYSTEM ERROR
State
Critical
Replace the corresponding CONTROL module.
Note The problem may sometimes be corrected by

formatting the flash disk, an action that should only be performed by authorized technical support personnel. 10 LOW DISK SPACE State Major The storage space left on the internal flash disk of the CONTROL module is too low. To free space, it is necessary to remove some of the files that store non-essential data, an action that should only be performed by authorized technical support personnel 11 12 13 CLOCK PIGGY CHANGED TO STANDBY State Warning Major Major Problem in CLOCK card (part of the CONTROL module). Replace the CONTROL module The module installed in the specified slot has been removed Section DB INIT of switch SW2 on the CONTROL module is set to ON. If it is no longer necessary to enforce the default database parameter values, change setting to OFF (see Chapter 3 for instructions)
MODULE WAS REMOVED Event DB INIT SWITCH IS ON Event
Gmux-2000 Ver. 4.0
7-25
Code Message 14 15 DIAL-UP OR SP SWITCH IS ON CLOCK WAS CHANGED TO FALLBACK
Type State Event
Default Interpretation Severity Major Major Reserved for future use The main clock source of the Gmux-2000 failed, and the fallback clock source has been selected. Check the port providing the master clock source: the Gmux-2000 replaces the recovered clock when the corresponding port loses frame synchronization or its input signal is missing.
16
CLOCK WAS CHANGED TO INTERNAL
Event
Major
Both the main and fallback clock sources of the Gmux-2000 failed, and the internal clock source has been selected. Check the port providing the master and fallback clock source: the Gmux-2000 replaces the recovered clock when the corresponding port loses frame synchronization or its input signal is missing.
17
CLOCK WAS CHANGED TO MASTER CL FLIP HAS OCCURRED
Event
Major
The Gmux-2000 switched back to the clock source selected as the master source. Normal state - no action required The other CONTROL module has been selected as the online module. Check the reason for flipping, and act accordingly The modules that have been read from the Gmux-2000 do not match the modules programmed in the database. Either replace the modules, or change the information appearing in the database
18
Event
Major
19
PROGRAMMED, INSTALLED MODULE MISMATCH CL-A, B DIFFERENT SOFT/HARD REVISIONS
State
Major
20
Event
Major
The CONTROL modules currently installed in the Gmux-2000 chassis have different software versions and/or hardware revisions. Use the Inventory menu to check the reason: If the hardware versions are different, one of the modules must be replaced. Contact RAD Technical Support department. If the software versions are different, reload the appropriate version in both modules in accordance with Appendix B
21
DP DIAL CYCLE FAILED
Event
Major
The current cycle of call attempts failed. Check the modem connected to the Gmux-2000 serial port. If the called numbers are often busy, you may also increase the number of call retries
22
DATABASE CHECKSUM ERROR
State
Major
Gmux-2000 technical failure (internal database error). Load the default configuration in the place of the current database (from the supervision terminal, enter the INIT DB command)
23
LOSS OF STATION
State
Minor
The station clock interface located on the CONTROL
7-26
Gmux-2000 Ver. 4.0
Code Message CLOCK EXT IN 1
Type
Default Interpretation Severity module 1 and reports that the clock signal is missing. Check connections and the equipment providing the clock signal. If problem persists, replace the CONTROL module
24
LOSS OF STATION CLOCK EXT IN 2
State
Minor
The station clock interface located on the CONTROL module 2 and reports that the clock signal is missing. Check connections and the equipment providing the clock signal. If problem persists, replace the CONTROL module The call attempts to the primary dial-out number failed. If the number is not busy, check the modem connected to the Gmux-2000. If the called number is often busy, you may also increase the number of call retries The call attempts to the alternate dial-out number failed. If the number is not busy, check the modem connected to the Gmux-2000. If the called number is often busy, you may also increase the number of call retries
25
DP PRIMARY CALL FAILED
Event
Major
26
DP ALTERNATE CALL FAILED
Event
Major
44 45 46
B.R.G FAILURE SFIFO SLIP MANAGEMENT NOT SUPPORTED IN SOFT REV DB CONTROL WAS TAKEN BY SNMP MMI
Event Event State
Major Major Major
Reserved for future use Reserved for future use You are trying to use DCC management, a function not supported by the software version currently loaded in the Gmux-2000 The Gmux-2000 database is being edited from a supervision terminal, while it is also being edited by an SNMP-based network management station. It is user's responsibility to prevent possible conflicts by stopping the editing from either the terminal or the management station The Gmux-2000 database is being edited by an SNMP-based network management station, e.g., RADview, while it is also being edited using a supervision terminal. It is user's responsibility to prevent possible conflicts by stopping the editing from either the terminal or the management station Reserved for future use Reserved for future use Reserved for future use Reserved for future use The CONTROL ETH port is not connected to an active Ethernet LAN
47
Event
Major
48
DB CONTROL WAS TAKEN BY TERM MMI
Event
Major
50 52 53 54 55
LOOP INBAND ON LOCAL LINE LOOP REMOTE LINE LOOP LOCAL LOOP TOWARD DTE LAN NOT CONNECTED
State State State State State
Minor Minor Minor Minor Minor
Gmux-2000 Ver. 4.0
7-27
Code Message 56 57
Type
Default Interpretation Severity Major Major Reserved for future use You are trying to activate I/O redundancy, a function not supported by the software version currently loaded in the Gmux-2000 The active port has been changed The internal bus capacity has been exceeded. Reduce the traffic load The optical transmitter reports a failure The optical transmitter reports a degradation fault A pointer-related fault occurred A critical alarm has been detected The Ethernet port speed is 100 Mbps The Ethernet port speed is 10 Mbps The Ethernet port operates in the full duplex mode The Ethernet port operates in the half duplex mode The Ethernet port reports that the link is up The external alarm input is active Reserved for future use The internal clock reports a problem The selected reference clock source failed A software mismatch has been detected A CRC error has been detected in bundle frames A frame alignment has been detected in bundle frames The received bundle frame exceeds the maximum length The received bundle frame is too short The received bundle frame carries an Abort indication The link is up and carries traffic A technical problem occurred The bundle is out of service Gmux-2000 MEP received a CCM with incorrect MD level (less than the MEPs own level)
I/O FLIP HAS OCCURRED Event IO REDUNDANCY NOT SUPPORTED IN SW REV PORT FLIP HAS OCCURRED BUS CAPACITY EXCEEDS TX FAIL TX DEGRADE POINTER ERROR CRITICAL ALARM PORT SPEED 100 PORT SPEED 10 PORT FULL DUPLEX PORT HALF DUPLEX PORT LINK UP INPUT ALARM RELAY 1 INPUT ALARM RELAY 2 CLOCK FAIL REFERENCE CLOCK FAIL SOFTWARE MISMATCH BUNDLE FRAME WITH CRC ERROR BUNDLE FRAME WITH ALIGNMENT ERROR BUNDLE FRAME LONGER THAN MAX BUNDLE FRAME SHORTER THAN 4 BUNDLE FRAME WITH ABORT INDICATION LINK IS ACTIVE Event
58 59 60 61 62 72 73 74 75 76 77 79 80 88 89 91 104 105 106 107 108 109 141 142 230
Event State State State Event State State State State State State State State State State State State Event vent vent vent State
Major Major Major Major Major Major Major Major Major Major Major Major Major Major Major Major Major Major Major Major Major Minor Major Major Major
DSP MEMORY TEST FAIL Event BUNDLE IS OUT OF SERVICE UNEXPECTED MD LEVEL State State
7-28
Gmux-2000 Ver. 4.0
Code Message 231 232 CONNECTIVITY OK CC MISMERGE
Type Event Event
Default Interpretation Severity Connectivity check (CC) with remote MEP has been confirmed Gmux-2000 MEP received a CCM with correct MD level (which is equal to the Gmux-2000 MEP MD level), but incorrect MA ID. This indicates that CCMs from a different service have merged with CCMs belonging to one of the Gmux-2000 MEPs. CC unexpected period for remote MEP has been detected A MEP receives no CCM frames from a peer MEP during an interval equal to 3.5 times the CCM transmission period RDI is detected in CCM received from a peer MEP Gmux-2000 MEP received a CCM with correct MD level, correct MA ID, but an incorrect MEP ID Y.1731 frame loss ratio threshold has been reached Y.1731 frame delay threshold has been reached Y.1731 frame delay variation Threshold has been reached Y.1731 unavailability ratio threshold has been reached
233 234 235 236 237 238 239 240
UNEXPECTED PERIOD LOSS OF CONTINUITY RDI DETECTED UNEXPECTED MEP FRAMES LOSS RATIO FRAMES ABOVE DELAY FRAMES ABOVE DELAY VARIATION UNAVAILABILITY RATIO
Event Event Event State State State State State
Major Major Major Major Major
GbE Module Alarms

Table 7-4. GbE Module Alarms
Code Message 8 78 81 HARDWARE FAILURE PORT LINK DOWN GBETH CAM L4 POOL1 FULL Type State State State Default Interpretation Severity Major Major Major Hardware problem. Replace the GbE module The specified GbE link is down. Check port connections Too many bundles have been defined on the specified GbE port, considering the maximum capacity of layer 4 socket pool 1. Delete unused bundles 82 GBETH CAM L4 POOL2 FULL State Major Too many bundles have been defined on the specified GbE port, considering the maximum capacity of layer 4 socket pool 2. Delete unused bundles 83 GBETH CAM L4 POOL3 FULL State Major Too many bundles have been defined on the specified GbE port, considering the maximum capacity of layer 4 socket pool 3. Delete unused bundles
Gmux-2000 Ver. 4.0
7-29
Chapter 7 Troubleshooting and Diagnostics 84 GBETH CAM L4 POOL4 FULL State Major
Installation and Operation Manual Too many bundles have been defined on the specified GbE port, considering the maximum capacity of layer 4 socket pool 4. Delete unused bundles
110
GBETH POOL BLOCK OVERFLOW
Major
OC3 Module External SONET Port Alarms

Table 7-5. External SONET Port Alarms
Code Message 8 27 HARDWARE FAILURE SIGNAL LOSS Type State State Default Interpretation Severity Major Major The OC3 module reports technical failure. Replace the OC3 module Loss of port receive signal. 1. 2. 3. 29 AIS OCCURED State Major Check cable connections to the port connector. Check line and/or other communication equipment providing the port to the remote unit. Replace the OC3 module installed in the specified slot of the Gmux-2000
Unframed all ones sequence is received in specific port data stream. 1. 2. Reset the OC3 module. Replace the OC3 module. Check cable connections to the port connector. Check line and/or other communication equipment connecting the port to the remote unit. Check frame type configuration of the remote unit.
34
LOCAL SYNC LOSS
State
Major
Loss of synchronization at the local OC-3 port. 1. 2. 3.
Note: For fiber optic interfaces, this alarm indicates also a loss of signal.
64 LOSS OF FRAME State Major A loss of frame (LOF) state exists at the specified OC-3 port. Check for problems on the SONET link, or at the remote equipment unit 65 OUT OF FRAME State Major The specified OC-3 port lost frame synchronization. Check for problems on the SONET link, or at the remote equipment unit 66 SIGNAL LABEL LOSS OF LOCK State Major The OC3 module reports that it cannot detect the signal label. Check for problems on the SONET link, or at the remote equipment unit
7-30
Gmux-2000 Ver. 4.0
Code Message 69 SIGNAL DEGRADED ERROR
Type State
Default Interpretation Severity Minor The specified port reports BER exceeding the preset signal degradation threshold. 1. 2. Check for problems on the SONET link, or at the remote equipment unit. If the problem persists, replace the module Check the Tx connection. Check the configuration. Reset the OC3 module.
86
REMOTE FAILURE INDICATION
State
Minor
Remote defect indication. 1. 2. 3.
Replace the OC3 module 87 VC/VT- RDI State Minor Remote defect indication. 1. 2. 3. 4. 90 EXCESSIVE ERROR DETECTED State Major Check the Tx connection. Check the configuration. Reset the OC3 module. Replace the OC3 module
The specified port reports BER exceeding the preset signal degradation threshold. 1. 2. Check for problems on the SONET link, or at the remote equipment unit. If the problem persists, replace the module
OC3 Module Internal STS-1 Port Alarms

Table 7-6. Internal STS-1 Port Alarms
Code Message 62 POINTER ERROR Type State Default Interpretation Severity Major The loss of pointer (LOP) state is entered when N consecutive invalid pointers are received by the specified STS-1 port (N = 8, 9 or 10). LOP state is exited when 3 equal valid pointers or 3 consecutive AIS indications are received. Check for problems on the SONET link, or at the remote equipment unit 67 SIGNAL LABEL MISMATCH State Major The specified STS-1 port detects a signal label mismatch. This may indicate incorrect routing of the corresponding VC. This alarm condition may occur while a new route is being prepared. 1. 2. Check routing of corresponding signal. Check for problems on the SONET link, or at the remote equipment unit
Gmux-2000 Ver. 4.0
7-31
Code Message 68 SIGNAL LABEL UNEQUIPPED
Type State
Default Interpretation Severity Major The specified STS-1 port receives an unequipped signal label. 1. 2. Check routing of the corresponding signal. Check for problems on the SONET link, or at the remote equipment unit
69
SIGNAL DEGRADED ERROR
State
Minor
70
PATH TRACE ID MISMATCH
State
Major
The specified STS-1 port detects a path trace mismatch. This may indicate incorrect routing of the corresponding STS-1. This alarm condition may occur while a new route is being prepared. 1. 2. Check routing of the STS-1 signal. Check for problems on the SONET link, or at the remote equipment unit
71
PATH TRACE UNEQUIPPED
State
Major
The OC3 module reports that it receives an unequipped path trace. 1. 2. Check routing of the STS-1 signal. Check for problems on the SONET link, or at the remote equipment unit Check the Tx connection. Check the configuration. Reset the OC3 module. Replace the OC3 module
86
REMOTE FAILURE INDICATION
State
Minor
Remote defect indication. 1. 2. 3. 4.
90
EXCESSIVE ERROR DETECTED
State
Major
7-32
Gmux-2000 Ver. 4.0
OC3 Module Internal VT1.5 Port Alarms

Table 7-7. Internal SONET VT1.5 Port Alarms
Code Message 30 VC/VT - AIS Type State Default Interpretation Severity Major An all 1 signal label is received by the specified port. 1. 2. 3. 4. 63 LOSS OF POINTER State Major Check configuration and routing. Check the remote equipment unit. Reset the OC3 module. Replace the OC3 module
The loss of pointer (LOP) state is entered when N consecutive invalid pointers are received by the specified VT1.5 port (N = 8, 9 or 10). LOP state is exited when 3 equal valid pointers or 3 consecutive AIS indications are received. Check for problems on the SONET link, or at the remote equipment unit
67
SIGNAL LABEL MISMATCH
State
Major
The specified VT1.5 port detects a signal label mismatch. This may indicate incorrect routing of the corresponding VT1.5. This alarm condition may occur while a new route is being prepared. 1. 2. Check routing of corresponding signal. Check for problems on the SONET link, or at the remote equipment unit
68
SIGNAL LABEL UNEQUIPPED
State
Major
The specified VT1.5 port receives an unequipped signal label. 1. 2. Check routing of the corresponding signal. Check for problems on the SONET link, or at the remote equipment unit
69
SIGNAL DEGRADED ERROR
State
Minor
70
PATH TRACE ID MISMATCH
State
Major
The specified VT1.5 port detects a path trace mismatch. This may indicate incorrect routing of the corresponding VT1.5. This alarm condition may occur while a new route is being prepared. 1. 2. Check routing of the VT1.5 signal. Check for problems on the SONET link, or at the remote equipment unit
Gmux-2000 Ver. 4.0
7-33
Code Message 71 PATH TRACE UNEQUIPPED
Type State
Default Interpretation Severity Major The OC3 module reports that it receives unequipped path trace. 1. 2. Check routing of the STS-1 signal. Check for problems on the SONET link, or at the remote equipment unit Check the Tx connection. Check the configuration. Reset the OC3 module. Replace the OC3 module
87
VC/VT - RDI
State
Minor
Remote defect indication. 1. 2. 3. 4.
90
EXCESSIVE ERROR DETECTED
State
Major
Pseudowire Emulation Server Module Alarms

Table 7-8. T1 (Internal or External) Port Alarms
Code Message 27 SIGNAL LOSS Type State Default Severity Major Interpretation Loss of receive signal. SIGNAL LOSS is also indicated when the front panel SYNC LOS LED lights up. 1. 2. 28 EXCESSIVE BPV State Major Check cable connection to the T1 link connector. Check line and/or other communication equipment connected to the link of the remote unit
The rate of bipolar violations in the port receive signal exceeds 10-6 during a measurement interval of 1000 seconds. Problem in network facilities AIS is detected on the link. Check equipment connected to the remote end of the T1 link
29
AIS OCCURED
State
Major
30
AIS RED ALM
State
Major
Red alarm on the link, caused by AIS condition. Check equipment connected to the remote end of the T1 link
32
RED ALARM
State
Major
Red alarm on T1 link. 1. 2. 3. Check cable connection to the link connector. Check line and/or other communication equipment providing the T1 link to the local server module. Replace the server module
7-34
Gmux-2000 Ver. 4.0
Code Message 37 YELLOW ALARM
Type State
Default Severity Major
Interpretation Yellow alarm on link. Check the remote equipment. Perform the following: 1. 2. 3. Check cable connection to the T1 connector of the remote device. Check line and/or other communication equipment providing the T1 link to the remote equipment. Replace the remote equipment
39
FRAME SLIP
Event
Major
T1 frame slips are detected (not displayed during local loss of frame synchronization). Updated once per second. 1. Verify the clock settings. 2. Check the far end (unstable clock source). 3. Replace the server module only if steps 1 and 2 do not correct the problem
40
BPV ERROR
Event
Major
Bipolar violations on the link receive signal. Updated once per second. 1. 2. Check the TDM equipment and cable connecting it to the T1 port. Replace the server module
41 42
EXCESSIVE ERR RATIO CRC-6 ERROR
State Event
Major Major
The bit error rate of the port receive signal exceeds 10-3. Problem in network facilities CRC-6 errors detected in the link receive signal. Updated once per second. 1. 2. Check the TDM equipment and cable connecting it to the T1 port. Replace the server module
Bundle Alarms
Table 7-9. Bundle Alarms
Code Message 92 93 BUNDLE OAM OUT OF SYNC BUNDLE OAM CONFIGURATION MISMATCH BUNDLE HW LACK OF TX BUFFERS BUNDLE LOCAL FAIL BUNDLE LINK FAIL IN REMOTE UNIT Type State State Default Interpretation Severity Major Major The OAM signaling mechanism (used to check connectivity) detected loss of connectivity Packet discarded due to mismatch in TDMoIP frame format between the received packet and the bundle configuration Packet discarded due to mismatch between received packet length and bundle configuration Bundle no longer receives packets The remote unit reports the reception of a packet with Local Fail indication (L-bit set)
94 95 96
Event State State
Major Major Major
Gmux-2000 Ver. 4.0
7-35
Code Message 97 98 99 100 101 BUNDLE REMOTE FAIL (RDI) BUNDLE RX TDMOIP VERSION MISMATCH BUNDLE RX FRAME LENGTH MISMATCH
Type State State State
Default Interpretation Severity Major Major Major Major Major The remote unit reports the reception of a packet with Remote Fail indication (R-bit set) Mismatch between local and remote bundle TDMoIP versions. Packet discarded due to mismatch between received Ethernet packet length and bundle configuration TDMoIP/MPLS packet sequence number error found within the window TDMoIP/MPLS packet sequence number error found outside the tracking window Underrun has occurred in the jitter buffer Overrun has occurred in the jitter buffer
BUNDLE SEQUENCE Event ERROR INSIDE WINDOW BUNDLE SEQUENCE ERROR OUTSIDE WINDOW BUNDLE JITTER BUFFER UNDERRUN BUNDLE JITTER BUFFER OVERRUN Event
102 103
Event Event
Major Major
VCA-T1/16, VCA-T1/12 Alarms

Table 7-10. VCA-T1/16, VCA-T1/12 Alarms
Code Message 111 to 120 121 to 130 131 to 140 142 143 to 152 CH1: TDM ML OVERFLOW to CH10: TDM ML OVERFLOW CH1: Q.50 DISABLE NEW CALLS to CH10: Q.50 DISABLE NEW CALLS CH1: DISCARD VOICE PACKETS to CH10: DISCARD VOICE PACKETS BUNDLE OUT OF SERVICE CH1: BLOCK VBD MODEM CALLS to CH10: BLOCK VBD MODEM CALLS Type Event Default Interpretation Severity Major The corresponding external port subchannel reports an overflow Reserved
Event
Major
Event
Major
The corresponding external port subchannel reports that the congestion prevention mechanism started discarding voice packets because of excessive traffic load The corresponding bundle is out-of-service The corresponding local voice port reports that the congestion prevention mechanism blocked new modem calls
Event Event
Major Major
7-36
Gmux-2000 Ver. 4.0
Code Message 153 to 162 163 to 172 173 to 182 186 187
Type
Default Interpretation Severity Major The corresponding local voice port reports that the congestion prevention mechanism blocked new modem relay calls
CH1: BLOCK RELAY MODEM Event CALLS to CH10: BLOCK RELAY MODEM CALLS CH1: REMOTE BLOCK VBD Event MODEM CALLS to CH10: REMOTE BLOCK VBD MODEM CALLS CH1: REMOTE BLOCK RELAY MODEM CALLS to CH10: REMOTE BLOCK RELAY MODEM CALLS BUNDLES WITH DIFFERENT CODER Event
Major
The corresponding remote voice port reports that the congestion prevention mechanism blocked new modem calls
Major
The corresponding remote voice port reports that the congestion prevention mechanism blocked new modem relay calls
Event
Major Event
The bundles must use the same coder type and rate The specified module hardware does not support the software version being downloaded. Contact RAD Technical Support The software version installed on the PSN interface module does not support CES and SAToP bundles. Download the most current version (contact RAD Technical Support for details) T1 link in alarm state because of the activation of a local loopback by the detection of the inband local loopback code. This disrupts traffic flow T1 link in alarm state because of the activation of a remote loopback by the detection of the remote local loopback code. This disrupts traffic flow T1 link in alarm state because of the sending of a remote loopback activation request code. This disrupts traffic flow The hardware versions of the PSN interface modules installed in the chassis have different hardware versions. Check and replace the appropriate module, or temporarily remove the module with lesser capabilities The voice compression module reports that the MTP2 link with the specified number is down
MODULE SW HW VERSIONS State MISMATCH GBETH VERSION MISMATCH State CES SATOP BUNDLE
188
Event
189
T1ALM LINK LOCAL INBAND State LOOP T1ALM LINK REMOTE REQUEST INBAND LOOP T1ALM LINK REMOTE ACTIVATE INBAND LOOP GIGA CARDS HAVE DIFFERENT HW VER Event
Minor
190
Minor
191
Event
Minor
192
State
Major
193 to 202
VOIP MTP2 LINK1 IS DOWN State to VOIP MTP2 LINK10 IS DOWN
Major
Gmux-2000 Ver. 4.0
7-37
Code Message 203 to 217 218 219 VOIP SCTP ASSOC1 IS DOWN to VOIP SCTP ASSOC15 IS DOWN VOIP SIGTRAN CONFIG FAILURE NPS CL FAILURE
Type State
Default Interpretation Severity Major The voice compression module reports that the SCTP association with the specified number is down
State State
Major Warning
The voice compression module reports that the SIGTRAN parameters could not be configured The NPS-101 attached to the Gmux-2000 reports a failure of its control subsystem (located on one of the PSCL modules) All the modules in the NPS-101 attached to the Gmux-2000 must use the same internal bus (either A or B). Check and correct One of the configured modules in the NPS-101 attached to the Gmux-2000 has been removed Gmux-2000 reports a communication failure with the attached NPS-101. First check that the Gmux-2000 serial ports use the default communication parameters, and then check for correct cable connections. If a supervision terminal is connected to the NPS-101, also check its communication parameters
220
NPS CARD IS ON WRONG BUS NPS CARD MISSING NPS COMMUNICATION FAILURE
State
Warning
221 222
State Event
Warning Warning
Traps Generated by Gmux-2000

Gmux-2000 generates several types of traps that report special events. These traps are presented in Table 7-11, together with a description of their formal object identifier (OID) and attached parameters.
Note
Trap parameters appearing in bold font in Table 7-11 do not appear in the MIB trap definition. Table 7-11. Traps List
No.
Trap
Attached Parameters General Traps
Interpretation
rfc1907.coldStart ::= { snmpTraps 1 } OID: 1.3.6.1.6.3.1.1.5.1
Reports that the Gmux-2000 has been powered up, and successfully completed the cold-start process. In response, a network management station should perform all the operations necessary to open the Gmux-2000 element manager application
7-38
Gmux-2000 Ver. 4.0
No. 2
Trap rfc1907.warmStart ::= { snmpTraps 2 } OID: 1.3.6.1.6.3.1.1.5.2
Attached Parameters
Interpretation Reports that the Gmux-2000 has been restarted (for example, by resetting the CONTROL modules), and successfully completed the warm-start process
rfc2863.linkUp ::= { snmpTraps 4 } OID: 1.3.6.1.6.3.1.1.5.4
ifIndex, ifOperStatus, openViewSeverity
Reports that the status (ifOperStatus) of the corresponding link has changed from down to any other value except notPresent. In response, a network management station should update the status color of the port. Only the minor and major openViewSeverity values are used (warning and critical are not used by Gmux-2000)
rfc2863.linkDown ::= { snmpTraps 3 } OID: 1.3.6.1.6.3.1.1.5.3
ifIndex, ifOperStatus, openViewSeverity
Reports that the status of the corresponding link (ifOperStatus) has changed to down from any other value except notPresent. In response, a network management station should update the status color of the port. Only the minor and major openViewSeverity values are used (warning and critical are not used by Gmux-2000)
rfc1907.authenticationFailure ::= { snmpTraps 5 } OID: 1.3.6.1.6.3.1.1.5.5 radGen Traps
Reports an SNMP authentication failure (this is usually the result of an attempt by a manager using an unauthorized community to access Gmux-2000)
rad.tftpStatusChangeTrap OID: 1.3.6.1.4.1.164.6.1.0.1
tftpStatus
Reports a change in the status of the TFTP protocol (used by the RADView map application SWDL function) Indicates the Gmux-2000 alarm severity associated with the reported trap or event. Only the minor and major openViewSeverity values are used (warning and critical are not used by Gmux-2000). Used by RADView HPOV map application to provide the node status indication (for example, select the node color on the map)
rad.agnStatusChangeTrap OID: 1.3.6.1.4.1.164.6.1.0.2
agnIndication, agnTestStatus, openViewSeverity (same value as agnIndication)
Gmux-2000 Ver. 4.0
7-39
No. 8
Trap cnfg.UpdateTrap OID: 1.3.6.1.4.1.164.3.3.0.6
Attached Parameters sysSSActiveCnfg, sysSSActiveCnfg, mngIP (of the manager that initiated the Update command) systemParameter
Interpretation Reports a Gmux-2000 configuration update. The mngIP parameter is non-zero only when the configuration update has been initiated by an SNMP management station Used by the Statistics Collection application
agnUploadDataTrap OID: 1.3.6.1.4.1.164.6.1.0.11
DACS Traps 10 rad.sanityCheckTrap OID: 1.3.6.1.4.1.164.3.3.0.1 sysSSanityCheckStatus, sysDbDownloadCnfgIdxC md, mngIP (of the manager that initiated the Update command) Provides information on sanity warnings and errors detected by the Gmux-2000 sanity check function. The management station that sent the update command (which has its update flag set) should open a pop-up message box after receiving a setResponse for the update command from the Gmux-2000. The update flag should be reset after receiving this trap, and also after the time-out interval, if the trap is not received within this interval Provides information on alarms detected by the Gmux-2000. Only the minor and major openViewSeverity values are used (warning and critical are not used by Gmux-2000). The relevant parameters depend on the alarm level: For system level alarms, the following parameters are not applicable (NA): sysBufferAlrSlot, sysBufferAlrPort. For card level alarms, the sysBufferAlrPort parameter is not applicable
11
rad.dacsMuxAlarmsTrap OID 1.3.6.1.4.1.164.3.3.0.2
alrGenDescription, sysBufferAlrCode, sysBufferAlrSlot, sysBufferAlrPort, sysBufferAlrState, openViewSeverity
IPmux Traps 12 bundleConnectionStatusTrap ::= {radSysWanEvents 15} OID: 1.3.6.1.4.1.164.6.1.3.0.15 ifAlias (of the bundle), ip2IfOperStatus, openViewSeverity Provides information needed to update the bundle status, following any change in the ip2IfOperStatus value. Only the minor and major openViewSeverity values are used (warning and critical are not used by Gmux-2000)
For your convenience, the RFC2863 definitions of ifOperStatus are presented below: up (1) If ifAdminStatus is changed to up(1), ifOperStatus will change to up(1) if the interface is ready to transmit and receive network traffic.
7-40
Gmux-2000 Ver. 4.0
down (2) If ifAdminStatus is down(2), ifOperStatus must be down(2). If ifAdminStatus is changed to up(1), ifOperStatus should remain in the down(2) state if and only if there is a fault that prevents it from going to the up(1) state. ifOperStatus will change from up(1) to down(2) if the interface cannot pass packets to/from the network. testing (3) A test is active on the interface. The testing(3) state indicates that no operational packets can be passed. unknown (4) Interface status cannot be determined. dormant (5) If ifAdminStatus is changed to up(1), ifOperStatus should change to dormant(5) if the interface is waiting for external actions (such as a serial line waiting for an incoming connection). notPresent (6) Some component is missing. If ifAdminStatus is changed to up(1), ifOperStatus should remain in the notPresent(6) state if the interface has missing (typically, hardware) components. lowerLayerDown (7) The interface is down due to the state of lower-layer interface(s).
7.4
Overview
Testing Gmux-2000 Operation
Diagnostics tests are available at the following levels: OC-3 port loopbacks. The loopbacks that can be activated on OC-3 ports include: Remote loopback: can be used to locate problems within the OC-3 processing sections of OC3 modules installed in the local Gmux-2000, and in the connections between a local Gmux-2000 OC-3 port and the users equipment connected to that port. Local loopback: can be used for end-to-end testing of the OC-3 signal paths from the local Gmux-2000 unit to the remote equipment, including the link through the packet-switched network and the connections to the remote OC-3 users equipment. T1 internal ports located on pseudowire emulation server modules (T1-PW-SRV/28) and modules with channelized T3 interface (CT3-PW/1). The loopbacks that can be activated at this level include: Remote loopback: can be used to locate problems along the internal signal paths serving a T1 port within the OC-3, CT3-PW/1, and T1-PW-SRV/28 modules installed in the local Gmux-2000, and in the external signal paths down to the local end users equipment connected to that T1 port. Local loopback: can be used for end-to-end testing of the T1 signal paths from the local Gmux-2000 unit to the remote equipment, including the
Gmux-2000 Ver. 4.0
7-41
local packet processor serving that T1 port, the link through the packetswitched network and the connections to the remote end users equipment connected to that T1 port. T3 and T1 external ports located on pseudowire emulation modules with T1 interfaces (T1-PW/28 and CT3-PW/1) modules. The loopbacks that can be activated at this level include: Remote loopback: can be used to locate problems within the T1 or T3 processing sections of T1-PW/28, respectively CT3-PW/1, modules installed in the local Gmux-2000, and in the connections between a local Gmux-2000 T1 port and the users equipment connected to that port. Local loopback: can be used for end-to-end testing of the T1 or T3 signal paths from the local Gmux-2000 unit to the remote equipment, including the link through the packet-switched network and the connections to the remote T1 or T3 users equipment. Voice ports located on VCA-T1/16, VCA-T1/12 modules. The loopbacks that can be activated at this level include: Remote loopback: can be used to locate problems within the T1 processing sections of the module installed in the local Gmux-2000, and in the connections between a local VCA-T1/16, VCA-T1/12 voice port and the users equipment connected to that port. Local loopback: can be used for end-to-end testing of the T1 signal paths from the local Gmux-2000 unit to the remote equipment, including the link through the transmission network and the connections to the remote users equipment. Test tone injection toward the local equipment: can be used to check the complete audio path from a timeslot of a VCA-T1/16, VCA-T1/12 voice port toward the end user connected to that port. Data ports located on VCA-T1/16, VCA-T1/12 modules operating in the voice trunking mode. At this level, only the remote loopback can be activated. This loopback can be used to check end-to-end the signal paths from the local VCA-T1/16, VCA-T1/12 data port to the remote equipment. Ping for IP connectivity testing. Ping can be used to test the uplink connections and confirm proper routing of bundles to the desired destinations. In addition, you can also enable the trace route function, to check the route taken by the pings.
The following sections describe the signal paths for each type of loopback.
Note
For convenience, all the examples shown below illustrate the signal paths when a loopback is connected on port 1. The same loopbacks can however be activated on any other port of the illustrated type, provided it is configured and connected.
7-42
Gmux-2000 Ver. 4.0
Diagnostic Tests for SONET (OC-3) Ports

Remote OC-3 Port Loopback
The remote OC-3 port loopback returns the recovered OC-3 receive signal provided by the OC-3 transceiver of the tested port toward the equipment connected to the local OC-3 port. The loopback is activated at the line side of the OC-3 framer serving the tested port.
Figure 7-3 shows the signal paths when a remote OC-3 port loopback is activated.
OC3 Module
RX TX Packet Processor RX TX OC-3 Transceiver OC-3 Framer OC-3 Transceiver OC-3 Framer
Gmux-2000
GbE Uplink
Figure 7-3. Remote Loopback on External OC-3 Port

The test signal is provided by the equipment connected to the local OC-3 port, that must receive its own transmission. While the loopback is activated, the local OC-3 port continues sending the received payload to the Gmux-2000 transmit path, for transmission through the packet network to the equipment at the remote end of the link. This test checks the connections to the local OC-3 port, including the transmission plant connecting the local equipment to the OC3 module, and the OC-3 transceiver of the OC3 module.
Local OC-3 Port Loopback

The local OC-3 port loopback connects the OC-3 transmit signal generated by the OC-3 framer of the tested port, to the receive input of the framer. This returns the OC-3 signal toward the equipment at the remote end of the link.
Figure 7-4 shows the signal paths when a local OC-3 port loopback is activated.
OC3 Module
RX TX RX TX OC-3 Transceiver OC-3 Framer Packet Processor OC-3 Transceiver OC-3 Framer
Gmux-2000
GbE Uplink
Figure 7-4. Local Loopback on External OC-3 Port
Gmux-2000 Ver. 4.0
7-43
While the loopback is activated, the local OC-3 port continues sending the transmit signal to the OC-3 line. The test signal is provided by the remote equipment whose payload is routed to the tested OC-3 port: that equipment must receive its own transmission. This test fully checks the operation of the local OC-3 port, except for the OC-3 line interface (transceiver); it also checks the Gmux-2000 signal paths that end at the corresponding OC-3 port, including the transmission through the packet network connecting the remote equipment to the Gmux-2000.
T3 and T1 Diagnostic Functions for CT3-PW/1 Modules

Remote T3 Port Loopback
The remote T3 port loopback returns the recovered T3 receive signal provided by the T3 line interface unit (LIU) of the T3 port toward the equipment connected to the local T3 port. The loopback is activated at the line side of the T3 framer.
Figure 7-5 shows the signal paths when a local T3 port loopback is activated. The
test signal is provided by the equipment connected to the local T3 port, that must receive its own transmission. While the loopback is activated, the local T3 port continues sending the received payload to the CT3-PW/1 uplink path, for transmission through the packet network to the equipment at the remote end of the link. This test checks the connections to the local T3 port, including the transmission plant connecting the local equipment to the CT3-PW/1 module, and the T3 LIU of the CT3-PW/1 module.
CT3-PW/1 Module
T1 Framer
Gmux-2000
T3 Port
T3 LIU
T3 Framer
Packet Processor
GbE Uplink
T1 Framer
Figure 7-5. Remote Loopback on External T3 Port
Local T3 Port Loopback

The local T3 port loopback connects the T3 transmit signal generated by the T3 framer of the port, to the receive input of the framer. This returns the T3 signal toward the equipment at the remote end of the link.
Figure 7-6 shows the signal paths when a local T3 port loopback is activated.
7-44
Gmux-2000 Ver. 4.0
Gmux-2000
CT3-PW/1 Module
T1 Framer PSN Interface Subsystem
T3 Port
T3 LIU
T3 Framer
Packet Processor
GbE Uplink
T1 Framer
Figure 7-6. Local Loopback on External T3 Port

While the loopback is activated, the local T3 port continues sending the transmit signal to the T3 line. The test signal is provided by the remote equipment whose payload is routed to the tested T3 port: that equipment must receive its own transmission. This test fully checks the operation of the local CT3-PW/1 port, except for the T3 line interface (transceiver); it also checks the Gmux-2000 signal paths that end at the corresponding CT3-PW/1 port, including the transmission through the packet network connecting the remote equipment to the Gmux-2000.
Remote T1 Port Loopback

Figure 7-7 shows signal paths during a remote loopback on an internal T1 port.
As shown in Figure 7-7, when a remote loopback is activated on an internal T1 port, the T1 framer of that port returns the transmit signal via the receive path of the same port. The transmit signal is received from the local end users equipment served by the tested port, through the T3 LIU and T3 framer of the CT3-PW/1 module. While the loopback is activated, the signal received from the remote T1 port is ignored. The signal received from the local end users equipment remains connected to the packet processor and it is transmitted to the remote T1 port.
CT3-PW/1 Module
T1 Framer T3 Framer/ Mapper T1 Framer
Gmux-2000
T3 Port
T3 LIU
Packet Processor
GbE Uplink
Figure 7-7. Remote Loopback on Internal T1 Port, Signal Paths
Gmux-2000 Ver. 4.0
7-45
To ensure that the users equipment is capable of providing a good signal, the remote loopback should be activated on the CT3-PW/1 internal T1 port only after checking that the local end users equipment operates normally while its own local loopback is activated. In this case, if the tested CT3-PW/1 port is synchronized, then while the remote loopback is activated on the local port, the local end users equipment must receive its own signal, and thus it must be frame-synchronized. This test checks the transmission path between the local end users equipment to the local T1 port, including the transmission plant and T3 equipment connecting the users equipment to the CT3-PW/1 module, and part of the internal CT3-PW/1 signal path that handle the routing of the signals up to the tested T1 port.
Local T1 Port Loopback

Figure 7-8 shows the signal paths during a local loopback on an internal T1 port.
As shown in Figure 7-8, when a local loopback is activated on a local internal T1 port, the receive signal of the port is connected by the port T1 framer to the input of the port transmit path. The signal is then returned toward the remote side through the port packet processor, the remaining sections of the local Gmux-2000 transmit path located on the CT3-PW/1 and GbE modules, and the link through the packet-switched network.
CT3-PW/1 Module
T1 Framer T3 Framer/ Maper T1 Framer
Gmux-2000
T3 Port
T3 LIU
Packet Processor
GbE Uplink
Figure 7-8. Local Loopback on T1 Port, Signal Paths

While the loopback is activated, the transmit signal arriving from the local end users equipment is ignored, but the local T1 port continues to send the received signal toward the local end users equipment. To ensure that the remote equipment is capable of providing a good signal, the local loopback should be activated on the local CT3-PW/1 port only after checking that the remote end users equipment connected to the tested T1 port operates normally while its own local loopback is activated. With the local loopback is activated on the local Gmux-2000 port, the remote end users equipment must receive its own signal, and thus it must be frame-synchronized. This test fully checks the operation of the local CT3-PW/1 module path serving the tested internal T1 port; it also checks the Gmux-2000 signal paths that end at the corresponding CT3-PW/1 internal T1 port, including the transmission through the packet network connecting the remote equipment to the Gmux-2000.
7-46
Gmux-2000 Ver. 4.0
T1 Port Diagnostic Functions for T1-PW-SRV/28 Modules

Remote Loopback on T1 Port (T1-PW-SRV/28 Module)
The signal paths during a remote loopback on an internal T1 port of a T1-PW-SRV/28 module are shown in Figure 7-9. As shown in Figure 7-9, when a remote loopback is activated on an internal T1 port, the T1 framer of that port returns the transmit signal via the receive path of the same port. The transmit signal is received from the local end users equipment served by the tested port, through the corresponding OC3 module and the SONET mapper of the T1-PW-SRV/28 module. While the loopback is activated, the signal received from the remote T1 port is ignored. The signal received from the local users equipment remains connected to the packet processor and it is transmitted to the remote PDH port. To ensure that the users equipment is capable of providing a good signal, the remote loopback should be activated on the Gmux-2000 port only after checking that the end users equipment operates normally while its own remote loopback is activated. In this case, if the status indicator of the tested port is off, then while the remote loopback is activated on the local Gmux-2000 port, the end users equipment must receive its own signal, and thus it must be frame-synchronized.
T1-PW-SRV/28 Module
T1 Framer
Gmux-2000
SONET Mapper
Packet Processor
GbE Uplink
T1 Framer
Figure 7-9. Remote Loopback on T1 Port (T1-PW-SRV/28 Module), Signal Paths
Local Loopback on T1 Port (T1-PW-SRV/28 Module)

The signal paths during a local loopback on an internal T1 port of a T1-PW-SRV/28 module are shown in Figure 7-10.
Gmux-2000 Ver. 4.0
7-47
T1-PW-SRV/28 Module
T1 Framer
Gmux-2000
SONET Mapper
Packet Processor
GbE Uplink
T1 Framer
Figure 7-10. Local Loopback on T1 Port (T1-PW-SRV/28 Module), Signal Paths

As shown in Figure 7-10, when a local loopback is activated on a local internal T1 port, the receive signal of the port is returned by the port framer to the input of the port transmit path, and is returned toward the remote side through the port packet processor, the remaining sections of the local Gmux-2000 transmit path located on the T1-PW-SRV/28 and GbE modules, and the link through the packet-switched network. While the loopback is activated, the transmit signal arriving from the local end users equipment is ignored. To ensure that the remote equipment is capable of providing a good signal, the local loopback should be activated on the local Gmux-2000 port only after checking that the remote end users equipment connected to the tested T1 port operates normally while its own local loopback is activated. With the local loopback is activated on the local Gmux-2000 port, the remote end users equipment must receive its own signal, and thus it must be frame-synchronized.
T1 Port Diagnostic Functions for T1-PW/28 Modules

Remote Loopback on External T1 Port (T1-PW/28 Module)
The signal paths during a remote loopback on an external T1 port of a T1-PW/28 module are shown in Figure 7-11. As shown in Figure 7-11, the signal paths are similar to the signal paths described in the Remote Loopback on T1 Port (T1-PW-SRV/28 Module) section, except that the transmit signal is received from the line interface unit (LIU) of the tested port (located on the T1-PW/28 module), not through any other Gmux-2000 module. To ensure that the users equipment connected to the tested is capable of providing a good signal, the remote loopback should be activated on the T1PW/28 port only after checking that the end users equipment operates normally while its own remote loopback is activated. In this case, if the status indicator of the tested port is off, then while the remote loopback is activated on the local T1-PW/28 port, the end users equipment must receive its own signal, and thus it must be frame-synchronized.
7-48
Gmux-2000 Ver. 4.0
T1-PW/28 Module
RX TX Packet Processor RX TX T1 Transceiver T1 Framer
Gmux-2000
GbE Uplink
T1 Transceiver
T1 Framer
Figure 7-11. Remote Loopback on External T1 Port (T1-PW/28 Module), Signal Paths
Local Loopback on External T1 Port (T1-PW/28 Module)

The signal paths during a local external T1 port loopback are shown in Figure 7-12. As shown in Figure 7-12, the signal paths are similar to the signal paths described in the Local Loopback on T1 Port (T1-PW-SRV/28 Module) section, and therefore the results are similar.
T1-PW/28 Module
RX TX Packet Processor RX TX T1 Transceiver T1 Framer
Gmux-2000
GbE Uplink
T1 Transceiver
T1 Framer
Figure 7-12. Local Loopback on External T1 Port (T1-PW/28 Module), Signal Paths
VCA-T1/16, VCA-T1/12 Voice Port Diagnostic Functions

Remote Loopback on Voice Port
The remote voice port loopback returns the T1 receive signal of the tested port toward the local equipment connected to the port. The loopback is activated at the line side of the T1 framer of the tested port, which receives the signal through the SONET mapper (for ports connected to the SONET network), or the line interface unit (LIU) of the tested port. When a remote loopback is activated on an external voice port, the T1 framer of that port returns the receive signal towards the LIU, via the transmit path
Gmux-2000 Ver. 4.0
7-49
of the same port. Figure 7-13 shows the signal paths when a remote loopback is activated on an external voice port. This test checks the connections to the local voice port, including the transmission plant connecting the local users equipment to the VCA-T1/16 voice port, and the T1 line interface of the VCA-T1/16 voice port. When the loopback is activated on a voice port connected to the SONET network (that is, connected to an SONET port located on the OC3 module via the Gmux-2000 telecom buses), the T1 framer returns the received signal to the SONET mapper, via the transmit path of the same port. Figure 7-14 shows the signal paths when a remote loopback is activated on a voice port connected to the SONET network. This test checks the transmission path to the local voice port, including the SONET transmission plant, the OC3 module, the internal Gmux-2000 paths connecting the users equipment to the local VCA-T1/16 voice port, and the T1 framer of the VCA-T1/16 voice port. In both configurations, the test signal is provided by the equipment connected to the local voice port that must receive its own transmission. Note that as long as the test is activated, that equipment cannot use loopback timing: it must use either internal timing, or lock its timing to an external clock signal. While the loopback is activated, the signal received from the remote voice port is ignored. The signal received from the local users equipment remains connected to the DSP, which continues sending the received payload for transmission through the network (T1 or SONET) to the equipment at the remote end of the link. To ensure that the users equipment connected to the tested port is capable of providing a good signal, the remote voice port loopback should be activated on the local VCA-T1/16 port only after checking that the end users equipment operates normally while its own local loopback is activated.
Gmux-2000
VCA-T1/16
TX RX Voice Compression and Timeslot Cross Connect Network Interface
Port LIU
Voice Port Framer
Figure 7-13. Remote Loopback on External Voice Port
7-50
Gmux-2000 Ver. 4.0
Gmux-2000
Telecom Buses OC3 Module To SONET Network OC3 Module SONET Mapper Voice Port Framer
VCA-T1/16
Voice Compression and Timeslot Cross Connect
Network Interface
Figure 7-14. Remote Loopback on Voice Port Connected to SONET Network
Local Loopback on Voice Port

The local voice port loopback returns the T1 signal restored from the compressed voice stream received from the remote end (through the T1 or SONET network connection), toward the equipment at the remote end of the link. The loopback is activated at the digital side of the T1 framer of the tested port. The T1 framer returns the signal restored by the receive path of the DSP serving the port towards the DSP, via the transmit path of the same port.
Note
When the tested port receives multiple bundles, each bundles signal is independently looped back.
Figure 7-15 shows the signal paths when a local loopback is activated on an
external voice port. This loopback fully checks the operation of the local VCA-T1/16 voice port, except for the T1 line interface (LIU); it also checks the internal VCA-T1/16 signal paths that end at the tested VCA-T1/16 port, including the transmission path through the network connecting the remote equipment to the local Gmux-2000, and the connections of the remote equipment to the far end Gmux-2000.
Gmux-2000
VCA-T1/16
TX RX Voice Compression and Timeslot Cross Connect
Port LIU
Voice Port Framer
Network Interface
Figure 7-15. Local Loopback on External Voice Port

When the local loopback is activated on a voice port connected to the SONET network (that is, connected to an SONET port via the Gmux-2000 telecom buses), the tested signal paths do not change. As shown in Figure 7-16, the only difference is in the paths not included with the loopback.
Gmux-2000 Ver. 4.0
7-51
This test checks the transmission path to the local voice port, including the SONET transmission plant, the OC3 module, the internal Gmux-2000 paths connecting the users equipment to the local VCA-T1/16 voice port, and the T1 framer of the VCA-T1/16 voice port.
Gmux-2000
Telecom Buses OC3 Module To SONET Network OC3 Module SONET Mapper Voice Port Framer
VCA-T1/16
Voice Compression and Timeslot Cross Connect
Network Interface
Figure 7-16. Local Loopback on Voice Port Connected to SONET Network

In both configurations, the test signal is provided by the equipment connected to the remote end, that must receive its own transmission. Note that as long as the test is activated, that equipment cannot use loopback timing: it must use either internal timing, or lock its timing to an external clock signal. While the local loopback is activated, the transmit signal arriving from the local users equipment is ignored, but the local voice port continues sending the received signal to the local equipment. To ensure that the remote equipment is capable of providing a good signal, the local loopback should be activated on the local VCA-T1/16 voice port only after checking that the remote end users equipment connected to the tested port operates normally while its own local loopback is activated. With the local loopback is activated on the local VCA-T1/16 port, the remote end users equipment must receive its own signal, and thus it must be frame-synchronized.
Test Tone Injection

The test tone is a data sequence repeating at a rate of approximately 1 kHz. This data sequence is identical to the data sequence that would have been generated if a signal at the test frequency, having a nominal level of 1 mW (0 dBm0), were applied to the input of the DSP serving the voice port.
Figure 7-17 shows the signal paths.

The test tone can be injected in any desired timeslot of a voice port, toward any desired local voice channel. When the local test tone injection is activated, the data received from the remote end in the corresponding timeslot of the local voice port is replaced by the test tone sequence. The resulting analog signal is therefore supplied to the local subscriber. As a result, a 1-kHz tone should be heard clearly and loudly in the earpiece of a telephone set connected to the corresponding voice channel. Test equipment can also be used to measure the test tone level; in this case, note that the nominal test tone level is changed in accordance with the Volume to Line parameter selected for the tested timeslot.
7-52
Gmux-2000 Ver. 4.0
The signal transmitted by the voice channel toward the other end remains connected to the corresponding transmit timeslot. At any given time, test tone injection can be activated in timeslots of only one voice port of the VCA-T1/16 module. The number of timeslots is not limited.
Gmux-2000
VCA-T1/16
TX RX Voice Compression Port LIU Voice Port Framer Test ~ Tone Timeslot Cross Connect Network Interface
Figure 7-17. Test Tone Injection Path
VCA-T1/16, VCA-T1/12 Data Port Diagnostic Functions

VCA-T1/16 and VCA-T1/12 operating in the VoIP mode do not use the data ports.
Remote Loopback on Data Port

The remote data port loopback returns the T1 receive signal of the tested port toward the network, via the network connection terminated at the tested port. The loopback is activated at the line side of the T1 framer of the tested port, which receives the signal through the SONET mapper (for ports connected to the SONET network), or the line interface unit (LIU) of the tested port. When a remote loopback is activated on an external data port, the T1 framer of that port returns the receive signal towards the LIU, via the transmit path of the same port. Figure 7-18 shows the signal paths when a remote loopback is activated on an external data port.
Gmux-2000
VCA-T1/16
Voice Port Interface Voice Compression and Timeslot Cross Connect TX RX
Data Port Framer
Data Port LIU
Figure 7-18. Remote Loopback on External Data Port

This test checks the whole transmission path between any remote users equipment that connects through the network to the local data port,
Gmux-2000 Ver. 4.0
7-53
including the interconnecting transmission and switching plant; it also tests the LIU of the VCA-T1/16 data port. When the loopback is activated on a data port connected to the SONET network (that is, connected to an SONET port via the Gmux-2000 telecom buses), the T1 framer returns the received signal to the SONET mapper, via the transmit path of the same port. Figure 7-19 shows the signal paths when a remote loopback is activated on a data port connected to the SONET network.
Gmux-2000
VCA-T1/16
Voice Compression and Timeslot Cross Connect Telecom Buses OC3 Module Data Port Framer SONET Mapper OC3 Module To SONET Network
Voice Port Interface
Figure 7-19. Remote Loopback on Data Port Connected to SONET Network

This test checks the whole transmission path between any remote users equipment that connects through the network to the local data port, including the SONET transmission plant, the OC3 module, the internal Gmux-2000 paths connecting the users equipment to the local VCA-T1/16 data port, and the T1 framer of the VCA-T1/16 data port. In both configurations, the test signal is provided by the remote equipment connected to the local VCA-T1/16 through the tested data port: any such equipment must receive its own transmission. To ensure that the users equipment connected to the tested port is capable of providing a good signal, the remote data port loopback should be activated on the local VCA-T1/16 port only after checking that the remote users equipment, and each equipment along the path, operates normally while its own local loopback is activated, and all the equipment along the path.
Ping Function
The Gmux-2000 supports the ping function, part of the ICMP protocol. This function enables checking IP connectivity between a Gmux-2000 IP port and the desired remote IP host. The user can select the destination IP address, configure the number of ping packets sent, or enable continuous pinging. In addition, the user can enable the trace route function, which collects information on the path to a remote host. Make sure that the destination IP address is included in the addresses appearing in the Managers List: if not, add a new manager with the required the destination IP address (if necessary, temporarily delete an inactive manager until you no longer need to ping that address).
7-54
Gmux-2000 Ver. 4.0
Activating Diagnostic Functions

Pinging Remote Hosts
For a description of the ping function, refer to Appendix C. To ping a remote host: 1. At the GMUX2000# prompt, enter the ping command and select the following: ping <ip-address> [number-of-packets <packets>] 2. Read the ping results. See Table 7-12. For example: To ping a host at 10.10.10.1 with 10 packets of data: GMUX2000>ping 10.10.10.1 number-of-packets 10
Table 7-12. Ping Results

Parameter Packets Sent Packets Received Packets Lost Success Min Round Trip Time (ms) Max Round Trip Time (ms) Average Round Trip Time (ms) Description Shows the total number of pings sent. The number advances until all the pings are sent, or until the specified time-out interval expires. Displays the number of ping responses received before the time-out interval expires. After all the pings have been sent or the specified time-out interval expires, displays the number of unanswered ping requests. Displays the percentage of successfully received ping responses, relative to the total number sent. Displays the minimum measured time between the transmission and reception of a ping, in milliseconds. Displays the minimum measured time between the transmission and reception of a ping, in milliseconds. Displays the average time calculated for all the successfully received ping responses, in milliseconds.
Performing Loopback Tests

Use the loopback command followed by local or remote values to perform loopbacks on the desired ports. The available tests and loopbacks depend on the specific module and port. For example: To run a local loopback on T1 port 1 of a module installed in slot 5: GMUX2000# configure port t1 1/5 GMUX2000>config>port>t1(1/5)# loopback local
Gmux-2000 Ver. 4.0
7-55
To deactivate a remote loopback on E1 port 1 of a module installed in slot 5: GMUX2000# configure port t1 1/5 GMUX2000>config>port>t1(1/5)# no loopback remote
7.5
Frequently Asked Questions
Q. How do I manage remote Vmux-2100 inband over TDM link between a central Gmux-2000 and a remote Vmux-2100?
Management Station
IP Address: 20.20.20.120 GbE Port IP Address: 20.20.20.20 GbE Link TDM Link Gmux-2000 with VCA-T1/16 and GbE Modules Online CL IP Address: 10.10.10.10 TDM Network T1 Vmux-2100
IP Address: 10.10.10.100 Default Gateway : 10.10.10.10
Figure 7-20. Inband Management of Vmux-2100

1. Check that the Gmux-2000 is running the following software versions (or higher): CONTROL module: 2.10N19 VCA-T1/16 or VCA-T1/12 module: 1.00A7 GbE module: 1.20F1 2. Connect the management station to the GbE module (directly to the MONITOR port, or through a PSN to the GbE port 1 or port 2 as shown in Figure 7-20) on the central Gmux-2000. 3. Make sure that the Gmux-2000 CONTROL module IP address and the host IP address assigned to the remote Vmux-2100 units are in the same IP subnet. Example:
7-56
Gmux-2000 Ver. 4.0
Gmux-2000 CONTROL module IP address = 10.10.10.10 Remote Vmux-2100 host IP = 10.10.10.100 Default gateway of remote Vmux-2100 (must be Gmux-2000 CONTROL module IP address) = 10.10.10.10 4. Add the IP address of the management station (20.20.20.120) to the Vmux-2100 Manager List. 5. Make sure that GbE module in Gmux-2000 and the network card of manager management station should have IP addresses from the same IP subnet, but that subnet is different from that used by the Gmux-2000 CONTROL module. Example: GbE module = 20.20.20.20 Management station network card IP address = 20.20.20.120 6. Make sure that the Manager List of the Gmux-2000 includes the IP address of the local management station and its exit interface, and the remote Vmux-2100 host IP and its exit interface. Example: 20.20.20.120 (this is the IP address of the management station), exit interface = GbE port 6/1 (or port 8/1 if the GbE module is inserted in slot 8) 10.10.10.100 (this is the host IP address of the remote Vmux-2100), exit interface = VMX slot 1 7. Make sure that the Manager List of the Vmux-2100 includes the IP address of the management station = 20.20.20.120. 8. Configure the management station default gateway as the IP address of the central Gmux-2000 GbE module (20.20.20.20) Now, when the management station looks for the IP address of the Gmux-2000 CONTROL module, 10.10.10.10, or for the host IP address of the remote Vmux-2100, 10.10.10.100, it will use the Gmux-2000 GbE module (20.20.20.20). 9. Use Telnet to contact the local Gmux-2000 (10.10.10.10) or the remote Vmux-2100 (20.20.20.120) from the management station, and verify that you have access to configuration menus. Q. What is the difference between Bundle ID and Destination/Source CBID parameters used for Gmux-2000 connection configuration? A. The Bundle ID is an internal administrative number used as a bundle name within the Gmux-2000 database. This number will not appear in the TDMoIP packets sent to the PSN. The destination CBID (Circuit Bundle Identifier) is the destination bundle number at the far end TDMoIP device. This number will be used by the Gmux-2000 to send the TDMoIP stream to the far end TDMoIP device, and it will appear in the Source Port field of the UDP header of the packets sent by the Gmux-2000.
Gmux-2000 Ver. 4.0
7-57
The Source CBID is the source bundle number at the local Gmux-2000. This number will be used by the far end TDMoIP device to send the TDMoIP stream to the Gmux-2000, and it appears in the Source Port field of the UDP header of packets sent to the Gmux-2000. The CBID will also be used within the payload of OAM packets, to validate the TDMoIP connection. Q. How does the Gmux-2000 power supply redundancy mechanism function? A. Gmux-2000 can be equipped with up to 3 PS modules (either AC or DC). The number of power supplies required depends on the Gmux-2000 card configuration and capacity. Some configurations require 1 PS module, others may require 2 PS modules. Therefore, when only 1 PS module is required, the second serves as backup. When 2 PS modules are operating, they will operate together in loadsharing mode. If one PS module fails, the remaining PS module can feed the whole Gmux-2000. For an AC powered Gmux-2000, each power inlet (PI) is connected to a separate PS module (one-to-one). In case of a power source failure in one PI, the first PS module is deactivated, but the second PI feeds the second PS module and through it the whole Gmux-2000. For the DC option, each PI is connected to all the power supply modules (allto-all). In case of a power source failure on one PI, the second PI will feed the whole Gmux-2000 via all the power supply modules. In the same way, when 2 PS modules are required and 3 modules are installed, the third module serves as backup. Q. How do I connect an E1 or T1 interface to the Gmux-2000 pseudowire emulation module with external E1 or T1 interfaces? A. Gmux-2000 pseudowire emulation module with external E1 or T1 interfaces uses a 62-pin D-type connector. To connect it to the Cat. 5 RJ-45 balanced E1 or T1 interfaces, order the following patch panel: GMUX-PPANEL-28-PW/BAL. The patch panel supports 28 balanced E1 or T1 ports. The connector on the patch panel is a Telco connector. When ordering the patch panel, it comes with an adapter cable from the 62-pin D-type connector on the Gmux-2000 side to a Telco connector. Q. Can ISDN PRA interface traffic be transmitted over the PSN using the IPmux/Gmux-2000 units? A. Transferring ISDN PRA interface traffic over the IP network using IPmux/Gmux-2000 is possible only in a point-to-point application, as the Gmux-2000 will handle the traffic as data, and will transfer it with the associated signaling. However, this it is not possible when the application is point-to-multipoint, i.e., when the Gmux-2000 must split the ISDN PRA stream, then. Q. What V5 byte code will cause the Gmux-2000 to issue a Signal Label Mismatch alarm on the VT1.5 level?
7-58
Gmux-2000 Ver. 4.0
A. Gmux-2000 expects to receive the code 010 (async) on the V5 byte of the VT1.5 signal label. Any other value will cause a Signal Label Mismatch alarm and AIS transmission on the VT1.5 level.
Note
The validation of the Signal Label by the Gmux-2000 can be disabled via the configuration menus.
Q. What is the difference between the Gmux-2000 Alarm Status and Event Log screens? A. Alarm Status is displayed under Monitoring > Alarms > Dsp All Alarms. It contains all the alarms (along with a brief description) that happened until the last device reset or the last Clear Log command. The alarm status is displayed as a table with the alarm number at the left, followed by the alarm source (slot, port or bundle), description, status of the alarm, the number of times the alarm occurred, and an indicator for special conditions. Event Log is displayed under Monitoring > Event Log > Read Log File. It contains more information than the alarm status, because each alarm has its own entry. Gmux-2000 can hold up to 256 entries in the log file, where each entry represent an alarm. The event log is cyclic, meaning after 256 alarms, the old ones are overwritten and the alarm ALARM BUFFER OVERFLOW is added (only once). Each entry (alarm) contains the following information: alarm number, alarm module (I/O number or bundle), port number, description, status (Event, Off, Critical, Major, Minor or Warning), timestamp and date. Q. How many different configuration databases can the Gmux-2000 hold? A. Up to 5 different databases are supported. Switching between databases is done on the fly, without the need for device reset. Q. I want to order a Gmux-2000 with an STM-1/OC3 module. Which modules should I order for the network and user side? A. For the network side you should order a GbE module. For the user side you should order: For STM-1: one STM-1 module and E1 pseudowire emulation server modules, where each server module will allow you to deploy 21 E1 streams out of the STM-1 payload. For a full STM-1, you need to order 3 pseudowire emulation server modules. For OC-3: one OC-3 module and T1 pseudowire emulation server modules, where each server module will allow you to deploy 28 T1 streams out of the OC-3 payload. For a full OC-3, you need to order 3 pseudowire emulation server modules. Q. What is the input range of the DC power supply for Gmux-2000? A. The input range of the DC power supply is 36 to 72 VDC. Q. How many simultaneous Telnet/SSH sessions does Gmux-2000 support? A. One.
Gmux-2000 Ver. 4.0
7-59
7.6
Technical Support
Technical support for this product can be obtained from the local distributor from whom it was purchased. For further information, please contact the RAD distributor nearest you or one of RAD's offices worldwide. This information can be found at www.rad.com (offices About RAD > Worldwide Offices; distributors Where to Buy > End Users).
7-60
Technical Support
Gmux-2000 Ver. 4.0
Appendix A Connection Data

A.1
Connector Data
The CONTROL DCE connector is a 9-pin D-type female connector with RS-232 asynchronous DCE interface, intended for direct connection to a supervision terminal. The connector is wired in accordance with Table A-1.
CONTROL DCE Connector
Table A-1. CONTROL DCE Connector Wiring

Pin 1 2 3 4 5 6 7 8 9 Function Data Carrier Detect (DCD) Receive Data (RD) Transmit Data (TD) Data Terminal Ready (DTR) Signal Ground (SIG) Data Set Ready (DSR) Request to Send (RTS) Clear to Send (CTS) Ring Indicator (RI) Direction From Gmux-2000 From Gmux-2000 To Gmux-2000 To Gmux-2000 Common reference and DC power supply ground From Gmux-2000 To Gmux-2000 From Gmux-2000 To Gmux-2000
Connection Data
The connections to the CONTROL DCE connector are made as follows: Connection to supervision terminal with 9-pin connector: by means of a straight cable (a cable wired point-to-point). Connection to supervision terminal with 25-pin connector: by means of a cable wired in accordance with Figure A-1.
Gmux-2000 Ver. 4.0
CONTROL DCE Connector
A-1
9 Pin Connector TD RD RTS To Gmux-2000 CONTROL DCE Connector CTS DSR DCD RI DTR GND
3 2 7 8 6 1 9 4 5
2 3 4 5 6 8 22 20 7
25 Pin Connector
To Terminal
Gmux-2000 Side
Terminal Side
Figure A-1. 25-Pin Terminal Cable Wiring - Connection to CONTROL DCE Connector
A.2
Connector Data
CONTROL ETH Connector
Each Gmux-2000 CONTROL ETH port has a 10/100BASE-TX Ethernet hub interface terminated in an RJ-45 connector. The port supports the MDI/MDIX crossover function, and therefore it can be connected by any type of cable (straight or crossed) to any type of 10/100BASE-TX Ethernet port. The ports also correct for polarity reversal in the 10BASE-T mode. Connector pin functions for the MDI state are listed in Table A-2. In the MDIX state, the receive and transmit pairs are interchanged.
Table A-2. CONTROL-ETH Interface Connector, Pin Functions

Pin 1 2 3 4, 5 6 7, 8 Designation RxD+ RxD TxD+ TxD Function Receive Data output, + wire Receive Data output, wire Transmit Data input, + wire Not connected Transmit Data input, wire Not connected
A-2
CONTROL ETH Connector
Gmux-2000 Ver. 4.0
Connection Data
Use a standard station cable to connect the CONTROL ETH connector to any type of 10/100BASE-TX Ethernet port.
A.3
ALARMS Connector
The ALARMS connector is a 9-pin D-type female connector which provides connections to the following functions: Major and minor alarm relay contacts +12V auxiliary supply voltage output (through 340 series resistor and protection diode) for the external alarm sense circuit External alarm sense input (to be connected to the +12V auxiliary supply voltage by external dry contacts).
Connector pin functions are listed in Table A-3.
Caution To prevent damage to alarm relay contacts, it is necessary to limit, by external

means, the maximum current that may flow through the contacts (maximum allowed current through closed contacts is 1A; load switching capacity is 60W). The maximum voltage across the open contacts must not exceed 60 VDC/30 VAC.
Table A-3. ALARMS Connector Wiring

Pin 1 2 3 4 5 6 7 8 9 Function Minor alarm relay normally-closed (NC) contact Minor alarm relay normally-open (NO) contact External alarm input IN2 Major alarm relay normally-closed (NC) contact Major alarm relay normally- open (NO) contact Minor alarm relay center contact External alarm input IN1 +12V auxiliary output (through 340 series resistor and protection diode) Major alarm relay center contact
A.4
Connector Data
STATION CLOCK Connectors
The STATION CLOCK port has three connectors:
Gmux-2000 Ver. 4.0
STATION CLOCK Connectors
A-3
One RJ-45 eight-pin connector, for the balanced interface. Connector wiring is listed in Table A-4. Two BNC female coaxial connectors, designated IN (station clock input) and OUT (nodal clock output), respectively, for the unbalanced interface.
Table A-4. STATION CLOCK Connector, Pin Functions

Pin 1 2 3 4 5 6 7 8 Direction Input Input Output Output Function AMI Clock In (ring)/Square Clock Signal In (wire +) (NOTE) AMI Clock In (tip)/Square Clock Signal In (wire ) (NOTE) Signal Ground (connection controlled by internal jumper) AMI Clock Out (ring)/Square Clock Signal Out (wire +) (NOTE) AMI Clock Out (tip)/Square Clock Signal Out (wire -) (NOTE) Frame Ground (connection controlled by internal jumper) Not connected Not connected
Note The type of clock signals (AMI per ITU-T Rec. G.703 or RS-485 squarewave) accepted and generated by these interfaces is selected by software.
Connection Data
You can connect either to the RJ-45 connector or to the coaxial connectors, in accordance with the station clock interface type selected by means of the internal settings. Never connect cables to both interfaces. When connecting cables to the coaxial connectors, pay attention to correct connection: Connect the clock input cable to the IN connector Connect the clock output cable to the OUT connector.
A.5
Power Connectors
AC Power Connector
AC-powered Gmux-2000 units have three standard IEC three-pin sockets, one for each AC power supply unit.
A-4
Power Connectors
Gmux-2000 Ver. 4.0
DC Power Connector
DC-powered Gmux-2000 units have two two-pin or three-pin DC power connectors, depending on the PI module type, for connecting two 48 VDC power sources to the DC power supply units. Each DC supply voltage is separately connected to each DC power supply unit. Connector wiring is listed in Table A-5, together with a view of the connector itself.
Table A-5. DC Connector Pin Functions

Pin 1 2 3 Function Positive DC input line Chassis (frame) ground Negative DC input line
1 2 3
Connector on Full-Width PI Module
Connector on Half-Width PI Module
Gmux-2000 Ver. 4.0
Power Connectors
A-5
A-6
Power Connectors
Gmux-2000 Ver. 4.0
Appendix B Installing New Software Releases

This appendix explains how to upgrade Gmux-2000 to version 4.0. Software upgrade is required to fix product limitations, enable new features, or to make the unit compatible with other devices that are already running the new software version. The information includes the following: Detailed conditions required for the upgrade Any impact the upgrade may have on the system Overview of downloading options Upgrade via the CLI Upgrade via the Boot menu.
B.1
Impact
Gmux-2000 resets automatically after the software upgrade, resulting in up to five minutes of downtime.
B.2
Software Upgrade Options
Application software can be downloaded to Gmux-2000 using the copy command over TFTP, or via the Boot menu, using XMODEM or TFTP.
B.3
Prerequisites
This section details the the software file names and outlines system requirements needed for the upgrade procedure.
Software Files
Version 4.0 releases are distributed as software files named GMUXCL.img. The I/O modules updates are supplied as image files as well. The files can be obtained from the local RAD business partner from whom the device was purchased.
Gmux-2000 Ver. 4.0 Prerequisites B-1
System Requirements
Before starting the upgrade, verify that you have the following: For upgrade via TFTP: Gmux-2000 unit with operational CONTROL module (CL-2) with a router interface bound to it and a static route defined to a PC with a TFTP server application (such as 3Cdaemon or PumpKIN), and a valid IP address. T Software file stored on the PC
Note
Gmux-2000 communicates with TFTP server via the Fast Ethernet port on the CONTROL module (out-of-band) or via Gigabit Ethernet port on the PSN module (inband).
For upgrade via XMODEM: Operational Gmux-2000 unit Connection to a PC with a terminal emulation application (such as HyperTerminal) Software file stored on the PC.
B.4
Upgrading Software using the CLI
The recommended software downloading method is downloading by means of the TFTP, using the copy command. Network administrators can use this procedure to distribute new software releases to all the managed Gmux-2000 units in the network from a central location.
Figure B-1. Downloading a Software Application File to Gmux-2000 via TFTP

Use the following procedure to download software release 4.0 to Gmux-2000 using the copy command. 1. Verify that the required image file is stored on the PC with the TFTP server application. 2. Verify that the Gmux-2000 CONTROL module has a router interface assigned to it. 3. Verify that a static route is configured to the PC. 4. Ping the PC to verify the connection. 5. Activate the TFTP server application.
B-2
Gmux-2000 Ver. 4.0
6. Download the image file(s) from the PC to the flash disk on the CONTROL module. 7. Download the image file(s) to the CONTROL module or to the I/O modules, using the internal download procedure.
Note
Configuration values shown in this chapter are examples only.
Verifying the CONTROL Module IP Parameters

The Gmux-2000 CONTROL module must be bound to a router interface with IP parameters configured according to your network requirements. Also, a static route must exist to the TFTP server. Otherwise you will not be able to establish a proper communication session with the server. Static routes can be established via the Fast Ethernet port on the CONTROL module (out-of-band) or via Gigabit Ethernet port on the PSN module (inband). Refer to the following manual section for additional information:
Working with Supervision Terminal in Chapter 4 Adding and Configuring Router Interfaces and Defining Static Routes in
Chapter 5.
To verify the CONTROL module IP parameters: At the router# prompt, enter the info command. The router interface configuration information is displayed. GMUX2000>config>router(1)# info interface 1 address 172.17.151.65/24 bind ethernet no vlan management-access store exit static-route 172.17.151.1/24 no default-gateway no arp-refresh store
address
0.0.0.0 static-if
cl-interface
To verify the GbE/2 module IP parameters: At the router# prompt, enter the info command. The router interface configuration information is displayed.
Gmux-2000 Ver. 4.0
B-3
GMUX2000>config>router(1)# info interface 1 address 172.17.151.65/24 bind giga-ethernet 6/1 no vlan management-access store exit static-route 172.17.151.1/24 no default-gateway no arp-refresh store
address
0.0.0.0 static-if
giga-a-port-1
Pinging the PC
Check the integrity of the communication link between Gmux-2000 and the PC by sending a ping from the unit to the PC. To ping the PC: 1. At any level, start pinging the desired host specifying its IP address and the number of packets being sent: GMUX2000>config>router(1)# ping 172.17.151.1 number-of-packets 25 2. If the ping request is timed out, check the link between Gmux-2000 and the PC (physical path, configuration parameters etc).
Activating the TFTP Server

Once the TFTP server is activated on the PC, it waits for any TFTP file transfer request originating from the product, and carries out the received request automatically. Downloading/Uploading by TFTP section in Chapter 5 explains how to prepare your PC for the TFTP file transfer. To run the TFTP server: Activate a TFTP server application, such as 3Cdaemon (available from www.3com.com) or PumpKIN (available from http://kin.klever.net/pumpkin/).
Downloading the New Software Release File to the Unit

This procedure is used to download the new software release to the flash disk of the CONTROL module. To download a file via TFTP: At the file# prompt, enter the copy command, as follows:
GMUX2000>file# copy tftp://172.17.151.1/GMUXCL.img GMUXCL.img The application file is downloaded and saved on the flash disk.
B-4
Gmux-2000 Ver. 4.0
Downloading the New Software Release File to a Module

Once a file is saved on the CONTROL module flash disk it must be downloaded to the CONTROL or I/O module itself to replace the current software. At the file# prompt, enter the copy command, as follows:
GMUX2000>file# copy GMUXCL.img main-sw GMUX2000>file# copy STM1.img io-5-sw
B.5
Upgrading Software via the Boot Menu
Software downloading may also be performed using the Boot menu. The Boot menu can be reached while Gmux-2000 performs initialization, for example, after power-up. You may need to start the loading from the Boot menu when it is not possible to activate TFTP using the CLI (for example, because the Gmux-2000 software has not yet been downloaded or is corrupted).
Caution The Boot menu procedures are recommended only for use by authorized
personnel, because this menu provides many additional options that are intended for use only by technical support personnel. Two software downloading options are available from the Boot menu: Downloading using the XMODEM protocol. This is usually performed by downloading from a PC directly connected to the CONTROL port of the CONTROL module.
Figure B-2. Downloading a Software Application File to Gmux-2000 via XMODEM

Downloading using the TFTP. This is usually performed by downloading from a remote location that provides an IP communication path to an Ethernet port of the CONTROL module.
Note
All the screens shown in this section are given for illustration purposes only: your Gmux-2000 may display different software versions.
Using the XMODEM Protocol

Use the following procedure to download software release 4.0 to Gmux-2000 via XMODEM. 1. Verify that the GMUXCL.img is stored on the PC with the terminal application.
Gmux-2000 Ver. 4.0
B-5
2. Configure the communication parameters of the selected PC serial port for asynchronous communication for 115.2 kbps, no parity, one start bit, eight data bits and one stop bit. Turn all types of flow control off. 3. Turn off Gmux-2000. 4. Activate the terminal application. 5. Turn on Gmux-2000 and immediately start pressing the <Enter> key several times in sequence until you see the Boot screen. A typical screen is shown below (the exact version and date displayed by your Gmux-2000 may be different).
Note
If you miss the timing, Gmux-2000 performs a regular reboot process (this process starts with Loading and ends with a message to press <Enter> a few times to display the log in screen).
GMUX_CL Boot Version 1.50 (Oct 26 2004) Boot Manager Version 6.07 (Oct 16 2004) 0 - Exit Boot-Manager 1 - Dir 2 - Set Active Software Copy 3 - Delete Software Copy 4 - Download Files or an Application by XMODEM 5 - Format flash 6 - Show basic hardware information 7 - Perform Reset to the board 8 - System Configuration. 9 - Download an Application by TFTP Press the ESC key to go back to the Main Menu. Select: 6. Type 4 to select Download Files or an Application by XMODEM. You will see a message that requests the partition number to which the new software is to be downloaded, and offers a recommended value. 7. If there is no special reason to select a different value, type the recommended number and then press <Enter>. A typical display is shown below: Select Copy number for download ( 1 ) Select: 1 8. The process starts, and you will see: Erasing Partition please wait .... Please start the XMODEM download. 9. Start the transfer in accordance with the program you are using. For example, if you are using the Windows HyperTerminal utility: Select Transfer in the HyperTerminal menu bar, and then select Send File on the Transfer menu. You will see the Send File window:
B-6
Gmux-2000 Ver. 4.0
Select the prescribed Gmux-2000 software file name (you may use the Browse function to find it). In the Protocol field, select Xmodem. When ready, press Send in the Send File window. You can now monitor the progress of the downloading in the Send File window.
Note
If downloading fails, repeat the whole procedure.

10. When the downloading process is successfully completed, you will see a sequence of messages similar to the following:
Loading ... Decompressing to RAM. Processing archive: FLASH Extracting GMUXCL.BIN .......................................................... .................................................................... CRC OK Running ... ******************************************************************* * In order to start working - press the ENTER button for few times* ******************************************************************* 11. At this stage, press the <Enter> key several times to go to the log in screen. 12. If necessary, repeat the process for the second CONTROL module.
Note
If after downloading a new software version you cannot establish again communication with the Gmux-2000, you must initialize the database using section 2 (DB INIT) of the internal switch SW2 of the active CONTROL module. See detailed procedure in Chapter 3.
Using the TFTP

Use the following procedure to download software release 4.0 to Gmux-2000 via TFTP. 1. Verify that the GMUXCL.img is stored on the PC with the TFTP server application. 2. Define IP parameters via the Boot Manager menu. 3. Activate the TFTP server application. 4. Download the GMUXCL.img from the PC to Gmux-2000.
Preparations for Using TFTP Protocol

The preparations needed for using the TFTP protocol from the boot menu are similar to the preparations needed to download software using the CLI, except that you must connect to the CONTROL ETH connector of the desired CONTROL module.
Gmux-2000 Ver. 4.0
B-7
The main difference is that you need to define the IP communication parameters for the corresponding CONTROL module (IP addresses and the associated subnet mask and a default gateway IP address).
Note
The IP parameters used for TFTP transfers from the boot menu should be different from those you intend to use during normal operation.
To define management IP parameters from the boot menu: 1. Connect the Ethernet cable from the TFTP server to the CONTROL ETH connector of the desired Gmux-2000 CONTROL module. 2. Display the boot menu. 3. Select System Configuration to start the configuration of the CONTROL module IP communication parameters, as needed for TFTP transfer.
GMUX_CL Boot Version 1.50 (Oct 26 2004) Boot Manager Version 6.07 (Oct 16 2004) 0 - Exit Boot-Manager 1 - Dir 2 - Set Active Software Copy 3 - Delete Software Copy 4 - Download Files or an Application by XMODEM 5 - format flash 6 - Show basic hardware information 7 - Perform Reset to the board 8 - System Configuration. 9 - Download an Application by TFTP Press the ESC key to go back to the Main Menu. Select:8 IP Address [172.17.171.139]: 168.119.10.101 IP Mask [255.255.255.0]: 255.255.255.0 Default Gateway Address [172.17.171.1]: 168.119.10.1
4. The parameters are displayed in consecutive lines. For each parameter, you can accept the current values by simply pressing <Enter> to continue, or type a new value: IP Address: used to select the IP address of the CONTROL module. To change the current value, type the desired IP address in the dotted quad format, and then <Enter> to continue. IP Mask: used to select the IP subnet mask of the CONTROL module. To change the current value, type the IP subnet mask address in the dotted quad format, and then <Enter> to continue. Default Gateway Address: when the TFTP server is located on a different LAN, you must define the IP address of the default gateway to be used by the CONTROL module. Make sure to select an IP address within the subnet of the assigned CONTROL module IP address. To change the current value, type the desired IP address in the dotted quad format, and then <Enter> to end the configuration.
B-8
Gmux-2000 Ver. 4.0
If no default gateway is needed, for example, because the TFTP server is attached to the same LAN as the CONTROL module being loaded, enter 0.0.0.0. 5. After pressing <Enter>, you will see again the boot menu. 6. Select Perform Reset to the board to reset the CONTROL module. The new parameters take effect only after the resetting is completed.
Downloading Procedure
To download software from the boot menu using TFTP: 1. On the boot menu, select Download an Application by TFTP and then press <Enter> to start the TFTP transfer. 2. After you see Please Enter the Target File Name, enter the name of the desired software distribution file (make sure to include the path, when necessary). When done, press <Enter> to continue. 3. You will see Please Enter the Server IP address: enter the IP address of the server that will download the software distribution file, using the dotted quad format, and then <Enter> to continue. GMUX_CL Boot Version 1.50 (Oct 26 2004) Boot Manager Version 6.07 (Oct 16 2004) 0 - Exit Boot-Manager 1 - Dir 2 - Set Active Software Copy 3 - Delete Software Copy 4 - Download Files or an Application by XMODEM 5 - format flash 6 - Show basic hardware information 7 - Perform Reset to the board 8 - System Configuration. 9 - Download an Application by TFTP Press the ESC key to go back to the Main Menu. Select:9 Please Enter the Target File Name: C:\bin\GMUXCL.IMG IP Mask [255.255.255.0]: 255.255.255.0 Default Gateway Address [172.17.171.1]: 168.119.10.1 4. If no errors are detected, the downloading process starts, and the screen displays its relative progress. 5. After the transfer is successfully completed, return to the boot menu and select Exit Boot-Manager. 6. When the Gmux-2000 initialization is ended, the CONTROL module loads the new software.
Note
If downloading failed, repeat the whole procedure.

7. If necessary, repeat the process for the second CONTROL module.
Gmux-2000 Ver. 4.0
B-9
Note
If after downloading a new software version you cannot establish again communication with the Gmux-2000, you must initialize the database, using section 2 (DB INIT) of the internal switch SW2 of the active CONTROL module. See detailed procedure in Chapter 3.
B-10
Gmux-2000 Ver. 4.0
Appendix C Operating Environment

C.1 Overview
This Appendix presents a concise description of the Gmux-2000 operating environment, to provide the background information required for understanding the Gmux-2000 configuration and performance monitoring parameters. This Appendix covers the following issues: PDH environment Section C.2 SDH environment Sections C.3 through C.7 SONET Environment Section C.8 Ethernet transmission technology Section C.9 IP environment Section C.10 Pseudowire emulation Section C.11 Management using SNMP Section C.12
C.2
PDH Environment
This section presents information on the main characteristics of the Plesiochronous Digital Hierarchy (PDH) signals. Table C-1 shows the PDH multiplexing hierarchies used in the main geographical areas.
Table C-1. PDH Multiplexing Hierarchy

Multiplex Level 1 2 3 4 Europe E1 2.048 Mbps E2 8.448 Mbps E3 34.368 Mbps E4 139.264 Mbps North America (USA) DS1 1.544 Mbps DS2 6.312 Mbps DS3 44.736 Mbps DS4NA 139.264 Mbps Japan J1 1.544 Mbps 6.312 Mbps 32.064 Mbps 97.729 Mbps
Gmux-2000 Ver. 4.0
PDH Environment
C-1
E1 Environment
E1 Line Signal Characteristics
E1 signal characteristics are specified in ITU-T Rec. G.703. The nominal data rate of the E1 signal is 2.048 Mbps. The E1 line signal is encoded in the High-Density Bipolar 3 (HDB3) code. HDB3 is based on the alternate mark inversion (AMI) code. In the AMI code, 1s are alternately transmitted as positive and negative pulses, whereas 0s are transmitted as a zero voltage level. To prevent the transmission of long strings of 0s, which do not carry timing information, the HDB3 coding rules restrict the maximum length of a 0 string that can be transmitted through the line to three pulse intervals. Longer strings of 0s are encoded at the transmit end to introduce non-zero pulses. To allow the receiving end to detect the artificially-introduced pulses and enable their removal to restore the original data string, the encoding introduces intentional coding violations in the sequence transmitted to the line. The receiving end detects these violations and when they appear to be part of an encoded 0 string it removes them. Coding violations may also be caused by transmission errors. Therefore, any coding violations that cannot be interpreted as intentional coding violations can be counted, to obtain information on the quality of the transmission link.
E1 Signal Structure
The E1 line operates at a nominal rate of 2.048 Mbps. The data transferred over the E1 line is organized in frames. Each E1 frame includes 256 bits. The E1 frame format, as defined in ITU-T Rec. G.704, is shown in Figure C-1.
Time Slot 0 a. Even Frames (0,2,4-14) 1 0 0 1 1 0 1 1 FAS b. Odd Frames (1,3,5-15) I 1 A N N N N N Time Slot 16 a. Frame 0 0 0 0 0 X Y X X MAS Channel Data b. Frames 1-15 A B C D A B C D 1 2 3 4 5 6 7 8 Time Slots 1-15, 17-31
8 Bits per Time Slot
32 Time Slots/Frame
TS 0
TS 1
TS 2
TS 3
TS 4
TS 5
TS 6
TS 7
TS 8
TS 9
TS 10
TS 11
TS 12
TS 13
TS 14
TS 15
TS 16
TS 17
TS 18
TS 19
TS 20
TS 21
TS 22
TS TS 23 24
TS 25
TS 26
TS 27
TS 28
TS 29
TS 30
TS 31
16 Frames/Multiframe Notes I N A FAS
FR 0
FR 1
FR 2
FR 3
FR 4
FR 5
FR 6
FR 7
FR 8
FR 9
FR 10
FR 11
FR 12
FR 13
FR 14
FR 15
International Bit National Bits (Sa4 through Sa8) Alarm Indication Signal (Loss of Frame Alignment - Red Alarm) Frame Alignment Signal, occupies alternate (but not necessarily even) frames
ABCD X Y MAS
ABCD Signaling Bits Extra Bit Loss of Multiframe Alignment Multiframe Alignment Signal
Figure C-1. E1 Frame Format

The 256 bits included in a frame are organized of 32 timeslots of eight bits each. The frame repetition rate is 8,000 per second, therefore the data rate supported by each timeslot is 64 kbps.
C-2
PDH Environment
Gmux-2000 Ver. 4.0
Timeslot 0
Timeslot 0 of E1 frames is used for two main purposes: Delineation of frame boundaries. For this purpose, in every second frame, timeslot 0 carries a fixed pattern, called frame alignment signal (FAS). Frames carrying the FAS are defined as even frames, because they are assigned the numbers 0, 2, 4, etc. when larger structures (multiframes) are used. The receiving equipment searches for the fixed FAS pattern in the data stream using a special algorithm, a process called frame synchronization. Once this process is successfully completed, the equipment can identify each bit in the received frames. Interchange of housekeeping information. In every frame without FAS (odd frames), timeslot 0 carries housekeeping information. This information is carried as follows: Bit 1 this bit is called the international (I) bit. Its main use is for error detection using the optional CRC-4 function (CRC-4 stands for Cyclic Redundancy Check, using a fourth-degree polynomial). This function is described below. Bit 2 is always set to 1, a fact used by the frame alignment algorithm. Bit 3 is used as a remote alarm indication (RAI), to notify the equipment at the other end that the local equipment lost frame alignment, or does not receive an input signal. The other bits, identified as Sa4 through Sa8, are designated national bits, and are actually available to the users, provided agreement is reached as to their use. The total data rate that can be carried by each national bit is 4 kbps.
Multiframes
To increase the information carrying capacity without wasting bandwidth, the frames are organized in larger patterns, called multiframes. ITU-T Rec. G.704 recommendations define the following types of multiframes: Basic G.704 framing G.704 framing with timeslot 16 multiframe.
Basic G.704 Multiframe

The basic G.704 structure consists of two frames, which are identified by means of the information included in timeslot 0: The even frame of the pair includes the frame alignment signal (FAS). The odd frame includes an 1 in bit position 2, and housekeeping information in the other bits.
The number of timeslots available for users data is 31, and therefore the maximum payload rate is 1984 kbps. To enable the transmission of network management information, a separate timeslot may have to be assigned within the frame. This procedure is called common channel signaling (CCS). The CCS information is often transmitted in timeslot 16.
Gmux-2000 Ver. 4.0 PDH Environment C-3
G.704 Framing with Timeslot 16 Multiframe (G.704 Multiframe)

The G.704 multiframe structure includes 16 frames, which are identified by means of a separate multiframe alignment signal (MAS) contained in timeslot 16 of each frame. The G.704 multiframe structure is generally used when timeslot 16 serves for the end-to-end transmission of channel-associated signaling (CAS). A typical application in which timeslot 16 serves for the transmission of signaling is the transfer of voice channels by means of voice modules, which use channel-associated signaling. Since timeslot 16 must be reserved for the transmission of the MAS and system signaling, only 30 timeslots are available for the users payload, and the maximum payload rate is 1920 kbps. When using the G.704 multiframe format, timeslot 16 of each of the 16 frames in each multiframe carry the following information: The first four bits of timeslot 16 in multiframe 16 always carry the multiframe alignment sequence, 0000. Bit 6 in timeslot 16 in multiframe 0 is used to notify the equipment at the other end of the link that the local equipment lost multiframe alignment. The other bits of this timeslot are not assigned mandatory functions.
Channel Associated Signaling

When using the G.704 multiframe format, timeslots 16 in frames 1 through 15 of each multiframe are available for carrying users information. In general, this information is the signaling information for the 30 payload timeslots (channels). As shown in Figure C-1, four signaling bits, designated A, B, C, and D, are available for each channel, thereby enabling end-to-end transmission of four signaling states. Note that each frame in the multiframe carries the signaling information of two channels.
CRC-4 Error Detection

The Gmux-2000 system supports the CRC-4 function in accordance with ITU-T Rec. G.704 and G.706. The CRC-4 function is used to detect errors in the received data, and therefore can be used to evaluate data transmission quality over E1 links. This function can be enabled or disabled by the user, independently for each link. To enable error detection, additional information must be provided to the receiving equipment. The additional information is transmitted to the receiving equipment by using a multiframe structure called CRC-4 multiframes. A CRC-4 multiframe is an arbitrary group of 16 frames. This group is not related in any way to the G.704 16-frame multiframe structures explained above. A CRC-4 multiframe always starts with an even frame (a frame that carries the frame alignment signal). The CRC-4 multiframe structure is identified by a six-bit CRC-4 multiframe alignment signal, which is multiplexed into bit 1 of timeslot 0 of each odd-numbered (1, 3, 5, etc.) frame of the CRC-4 multiframe (i.e., in frames 1 through 11 of the CRC-4 multiframe).
C-4
PDH Environment
Gmux-2000 Ver. 4.0
Each CRC-4 multiframe is divided into two submultiframes of 8 frames (2048 bits) each. The detection of errors is achieved by calculating a four-bit checksum on each 2048-bit block (submultiframe). The four checksum bits calculated on a given submultiframe are multiplexed, bit by bit, in bit 1 of timeslot 0 of each even-numbered frame of the next submultiframe. At the receiving end, the checksum is calculated again on each submultiframe and then compared against the original checksum (sent by the transmitting end in the next submultiframe). The results are reported by two bits multiplexed in bit 1 of timeslot 0 in frames 13, 15 of the CRC-4 multiframe, respectively. Errors are counted and used to prepare statistic data on transmission performance.
E1 Alarm Conditions
Excessive bit error rate. The bit error rate is measured on the frame -3 alignment signal. The alarm threshold is an error rate higher than 10 that persists for 4 to 5 seconds. The alarm condition is canceled when the error -4 rate decreases below 10 for 4 to 5 consecutive seconds. Loss of frame alignment (also called loss of synchronization). This condition is declared when too many errors are detected in the frame alignment signal (FAS), e.g., when 3 or 4 FAS errors are detected in the last 5 frames. Loss of frame alignment is cleared after no FAS errors are detected in two consecutive frames. The loss of frame alignment is reported by means of the A bit (Figure C-1). Loss of multiframe alignment (applicable only when the G.704 multiframe structure is used). This condition is declared when too many errors are detected in the multiframe alignment signal (MAS) (same conditions as for loss of frame alignment). The loss of multiframe alignment is reported by means of the Y bit (Figure C-1). Alarm indication signal (AIS). The AIS signal is an unframed all-ones signal, and is used to maintain line signal synchronization in case of loss of input signal, e.g., because an alarm condition occurred in the equipment that supplies the line signal. Note that the equipment receiving an AIS signal loses frame synchronization.
T1 Environment
T1 Line Signal
The basic T1 line signal is coded using the alternate mark inversion (AMI) rules, explained in Section C.2. The AMI format cannot transmit long strings of zeros, because such strings do not carry timing information. Therefore, the AMI signal source must generate a signal with guaranteed minimum 1 density. The minimum average 1 density required by the applicable standards is 1:8. Therefore, when a T1 signal is transmitted over an AMI line, each frame timeslot must include at least one 1
Gmux-2000 Ver. 4.0
PDH Environment
C-5
bit. This effectively reduces user data rate to 56 kbps per timeslot, and precludes the provision of clear channel capability (CCC). To circumvent this problem, modified line codes are used, that perform zero suppression by substituting special codes for long 0 strings. The generally accepted zero suppression methods are B7 and B8ZS. With B7, the maximum length of 0 strings in the user data must not exceed seven zeros (when a longer string is detected, the seventh bit is changed to one, to meet the minimum 1 density requirement and thus ensure that the remote end can properly recover the clock signal). Although this requirement can be fulfilled in many applications, it does not provide 64 kbps clear channel capability. Therefore, when the B7 line code is used, inband management is not supported. Only the B8ZS zero suppression method provides clear channel capability, and the 1 density requirement no longer restricts user data characteristics. This means that each T1 frame timeslot can support the full 64 kbps.
Since the AMI coding does not affect the signal transmitted to the line, it is also called transparent coding. This emphasizes the fact that although the other methods are also transparent to users data, perfect transparency is achieved only when the zero-string substitution sequences are correctly recognized. Thus, the other methods are more sensitive to transmission errors (transmission errors may affect the decoding of zero-string substitution sequences).
T1 Signal Structure
The T1 line operates at a nominal rate of 1.544 Mbps. The data transferred over the T1 line is organized in frames. The T1 frame format is shown in Figure C-2.
8 Bits/Channel Byte Organization (D4 Frame - See NOTE)
8 A B
Other Frames Frame 6 Frame 12
Bit B Conveys Signaling Information
Frame Organization
Ft C H C H 24 Channels/Frame or 1 2 Frame = 193 Bits Fs
CH 13
CH 24
Multiframe Organization
FR FR 1 2
FR 7 Multiframe SF (D4) 12 Frames ESF: 24 Frames
FR FR 11 12
NOTE: In addition, ESF has a C-bit in frame 18 and a D-bit in frame 24
Figure C-2. T1 Frame Format

Each T1 frame includes 193 bits. 192 bits are organized in 24 timeslots of eight bits each that carry the payload data. An additional timeslot, including one bit (the F-bit) carries framing and supervision information. As a result, the data rate supported by each payload timeslot is 64 kbps. The data rate of the framing slot is 8 kbps. The T1 frame does not include a dedicated timeslot for the transfer of channel signaling. When end-to-end transfer of signaling is necessary, a technique called
C-6
PDH Environment
Gmux-2000 Ver. 4.0
robbed-bit signaling is used. The robbed-bit is the least significant bit (bit 8) of the channel byte, and is actually robbed only once in every six frames. In order to enhance link/system supervision capabilities, the frames are organized in larger patterns, called super-frames. Two types of super-frames are used: SF (also called D4), consists of 12 T1 frames. Extended SF (ESF), consists of 24 T1 frames
The SF format provides limited supervision capabilities, such as end-to-end reporting of local loss-of-signal (yellow alarm), and line loopback. The ESF format provides improved supervision capabilities, and allows better utilization of the 8 kbps framing timeslots. The major advantage of the ESF format is that it supports on-line link performance monitoring (by means of a 2 kbps Cyclic Redundancy Check (CRC) channel) and in addition provides a 4 kbps end-to-end supervision and control data link. The data link can be used for performance monitoring and failure reporting, for activation of maintenance loopbacks, and for transmission of various commands to the far end equipment. The implementation of the multiframing format is based on the use of various F-bit patterns. The F-bit pattern is used to perform three functions: Framing Pattern Sequence (FPS), defines frame and multiframe boundaries. Facility Data Link (FDL), allows transfer of supervisory data, e.g. alarms, error performance, test loop commands, etc. to be passed through the T1 link. Cyclic Redundancy Check (CRC), allows the measurement of the bit error rate and enhances the reliability of the framing algorithm.
The F-bit pattern defines the structure of frames and multiframes. In the D4 (SF) frame format, the F-bit of consecutive frames is alternately interpreted as an Ft bit (terminal framing bit) or Fs bit (frame signaling bit). Ft pattern: alternating 0's and 1's, defines the frame boundaries. Fs pattern: fixed 001110 pattern, defines the multiframe boundaries, so that one frame may be distinguished from another. In particular, the Fs pattern is needed so that frames 6 and 12 may be identified for the recovery of signaling bits. In the ESF frame format, the multiframe structure is extended to 24 frames, but the frame and channel structure are the same as in the D4 (SF) format.
T1 Alarm Conditions
The basic alarm conditions are the red alarm and the yellow alarm. Note that with the ESF format, the FDL link can be used for more sophisticated status transmissions, in accordance with the ANSI Standard T1.403-1989 and AT&T Pub. 54016. Red Alarm. A red alarm is generated when the local unit has lost frame synchronization for more than 2.5 consecutive seconds, or the bit error rate -2 exceeds 10 for 2.5 consecutive seconds. Loss of frame synchronization may be caused either by Fs or Ft errors, by the reception of an AIS signal, or by the loss of the input signal (receive data remains zero for 31 consecutive bits). In accordance with AT&T TR-62411, a system automatically recovers
Gmux-2000 Ver. 4.0
PDH Environment
C-7
synchronization when there has been a period of 10 to 20 consecutive seconds free of the loss of sync condition. Since in many system applications this is an overly conservative specification, the Gmux-2000 system offers faster frame synchronization algorithms, which allow the user to select a fast mode. In the fast mode, the time necessary to declare synchronization is reduced to approximately one second free of the loss of sync condition. Yellow Alarm. A yellow alarm is sent from the remote unit to inform the local unit that a red alarm exists at the remote end. Alarm Indication Signal (AIS). The AIS signal is an unframed all-ones signal, and is used to maintain line signal synchronization when an alarm condition occurs in the equipment that supplies the line signal.
T3 Environment
T3 Line Signal
The T3 line signal is coded using the B3ZS rules (for other zero suppression codes, see E1 Line Signal Characteristics section), that limits the maximum length of zero runs to 2.
T3 Signal Structure
The T3 line operates at a nominal rate of 44.736 Mbps. The data transferred over the T3 line is organized in frames. The general structure of a T3 frame (also called M-frame) is shown in Figure C-3.
M Subframe 1
M Subframe 7
X1 679 bits X2 679 bits P1 679 bits P2 679 bits M1 679 bits M2 679 bits M3 679 bits
M-Frame (4760 bits)
Figure C-3. T3 Frame Structure

Each T3 frame includes 4760 bits. The 4760 bits consist of seven M-subframes of 680 bits each, that carry the data payload, framing, and supervision information.
M-Subframe Organization
Figure C-4 shows the organization of the seven M-subframes.
C-8
PDH Environment
Gmux-2000 Ver. 4.0

M Subframe Block 1 X1 1
. Block 8
Info Info Info Info Info Info Info Info F1 C F0 C F0 C F1 (84 bits) (84 bits) 1,1 (84 bits) (84 bits) 1,2 (84 bits) (84 bits) 1,3 (84 bits) (84 bits) Info Info Info Info Info Info Info Info F1 C F0 C F0 C F1 (84 bits) (84 bits) 2,1 (84 bits) (84 bits) 2,2 (84 bits) (84 bits) 2,3 (84 bits) (84 bits) Info Info Info Info Info Info Info Info F1 C F0 C F0 C F1 (84 bits) (84 bits) 3,1 (84 bits) (84 bits) 3,2 (84 bits) (84 bits) 3,3 (84 bits) (84 bits) Info Info Info Info Info Info Info Info F1 C F0 C F0 C F1 (84 bits) (84 bits) 4,1 (84 bits) (84 bits) 4,2 (84 bits) (84 bits) 4,3 (84 bits) (84 bits) Info Info Info Info Info Info Info Info F1 C F0 C F0 C F1 (84 bits) (84 bits) 5,1 (84 bits) (84 bits) 5,2 (84 bits) (84 bits) 5,3 (84 bits) (84 bits) Info Info Info Info Info Info Info Info F1 C F0 C F0 C F1 (84 bits) (84 bits) 6,1 (84 bits) (84 bits) 6,2 (84 bits) (84 bits) 6,3 (84 bits) (84 bits) Info Info Info Info Info Info Info Info F1 C F0 C F0 C F1 (84 bits) (84 bits) 7,1 (84 bits) (84 bits) 7,2 (84 bits) (84 bits) 7,3 (84 bits) (84 bits) Stuff Blocks
X2
P1
P2
M0
M1
M0
Legend
Xn = Status Pn = Parity Mn = M-Frame Alignment Fn = Subframe Alignment Cn,m = Control
Figure C-4. M-Subframe Organization in DS3 Signal

An M-subframe consists of eight 85-bit blocks. The blocks designated 1 through 7 always have the same structure, whereas the structure of block 8 changes in accordance with the M-subframe. Each block comprises one overhead (OH) bit, followed by 84 information bits, resulting in a total of 56 overhead bits per frame. The functions of the overhead bits are as follows: M-Frame Alignment Channel. The M-frame alignment channel signal (bits M1=0, M2=1, and M3=0) is used to identify each of the seven M-subframes. M-Subframe Alignment Channel. The M-subframe alignment channel signal (bits F1=1, F2=0, F3=0, and F4=1) is used to identify the frame overhead bit positions. P-Bit Channel. The P-bit channel (bits P1 and P2) is used for performance monitoring. X-Bit Channel. The X-bit channel (bits X1 and X2) is used as an alarm channel. C-Bit Channel. The C-bit channel (bits C1, C2, and C3) are reserved for application-specific uses. The application type of a DS3 data stream is identified by means of the first C-bit in M-subframe 1: this bit serves as an application identification channel (AIC) signal: For SYNTRAN (M13) applications, the AIC signal is a repeating 100,100... pattern that is used to identify the start of an M-frame triad. For C-bit parity applications, the AIC signal is a continuous 1.
Gmux-2000 Ver. 4.0
PDH Environment
C-9
Block Organization
Figure C-5 shows the structure of the eight types of blocks contained in M-subframes.
The first seven blocks, 1 through 7, are used to carry DS2 tributary data and overhead data. The overhead bit of these blocks is shared among the five channels described above. The eighth block is used for stuffing, to implement positive justification. For this purpose, one bit of each block can serve as a stuffing bit for the corresponding DS2 tributary (the bit is identified as Sj, where j is the tributary number (1 to 7). For applications that use stuffing, the type of bit (stuffing or data) is indicated by means of the justification control bits in that subframe (these bits are designated Cj1, Cj2, Cj3, where j is the tributary number). The overhead bit of the eighth block is always part of the subframe alignment channel.
................ Blocks 1 to 7 in All M Subframes OH D1 D2 D3 D4 D5 D6 D7 D1 ................ D6 D7
Block 8 M Subframe 1 F1 S1 D2 D3 D4 D5 D6 D7 D1
................ ................ ................ D6 D7
M Subframe 2
F1
D1
S2
D3
D4
D5
D6
D7
D1
................ ................
D6
D7
M Subframe 3
F1
D1
D2
S3
D4
D5
D6
D7
D1
................ ................
D6
D7
M Subframe 4
F1
D1
D2
D3
S4
D5
D6
D7
D1
................ ................
D6
D7
M Subframe 5
F1
D1
D2
D3
D4
S5
D6
D7
D1
................ ................
D6
D7
M Subframe 6
F1
D1
D2
D3
D4
D5
S6
D7
D1
................ ................
D6
D7
M Subframe 7
F1
D1
D2
D3
D4
D5
D6
S7
D1
................
D6
D7
OH = Xn, Pn, M1, M0, F1, F0, or Cn,m Dn = Information Bit from DS2n : n = 1,2....7 Sn = Stuff Opportunity for DS2n : n =1,2....7
Figure C-5. Block Organization in DS3 Signal
Structure of Standard DS2 Tributary Data

Figure C-6 shows the structure of the DS2 frames, which are carried as payload in the T3 (DS3) signal. The DS3 signal carries seven DS2 streams, where each DS2
C-10
PDH Environment
Gmux-2000 Ver. 4.0
stream, having a nominal data rate of 6.312 Mbps, carries four DS1 (1.544 Mbps) signals. The multiplexing method is positive justification. This arrangement ensures compatibility with the DSX-3 cross-connect requirements of ANSI T1.107. The DS2 signal is organized using principles similar to those used for the DS3 signal: The DS2 frame (also called M-frame) contains 1176 bits. The 1176 bits are organized as four 294-bit M subframes. Each M subframe comprises six 49-bit blocks.
The DS2 signal structure includes M-frame and M-subframe alignment channels, an X-bit status channel, and a C-bit control channel. The control channel is used, among other functions, to control the justification at the DS2 level.
M-Frame (1176 bits) M Subframe 1
. . . . . . . . . M Subframe 4
X 293 bits
M1 293 bits M2 293 bits M3 293 bits
M Subframe 1
Block 1
. . . . . . . . . . . . . . . . . . . . .
Block 6
Info Info Info Info Info Info M1 C1 F1 C2 C3 F2 (48 bits) (48 bits) (48 bits) (48 bits) (48 bits) (48 bits) Info Info Info Info Info Info C1 F1 C2 C3 F2 (48 bits) (48 bits) (48 bits) (48 bits) (48 bits) (48 bits) Info Info Info Info Info Info C1 F1 C2 C3 F2 (48 bits) (48 bits) (48 bits) (48 bits) (48 bits) (48 bits) Info Info Info Info Info Info C1 F1 C2 C3 F2 (48 bits) (48 bits) (48 bits) (48 bits) (48 bits) (48 bits) Stuff Blocks
M2
M3
Legend
X Mn Fn C = Status = M-Frame Alignment = Subframe Alignment = Control
Figure C-6. Structure of Standard DS2 Tributary Data
M13 Multiplex Signal Characteristics

This section describes the synchronous DS3 M13 multiplex application (SYNTRAN), where 28 DS1 channels are multiplexed directly to the DS3 level. The M13 multiplex signal preserves the M, F, P, and X bits for compatibility with the DSX-3 cross-connect requirements of ANSI T1.107 (as well as for network elements and transmission facilities which recognize these overhead bits). The M13 application performs multiplexing of signals having a common timing source,
Gmux-2000 Ver. 4.0
PDH Environment
C-11
and therefore stuffing is not necessary. As a result, the C-bit (C1, C2, and C3) positions in the M-subframes are not needed for stuff indication and are available for network operations and maintenance functions. The payload bits are organized into 588 eight-bit octets (timeslots), which are used to directly multiplex 28 DS1 signals. An additional subframe is embedded inside the asynchronous DS3 frame structure to define a synchronous superframe of 699 M-frames that contains 595 synchronous subframes.
SYNTRAN Maintenance Features

DS3 Signal Performance Monitoring. An error detection cyclical redundancy check code (CRC-9) is used to monitor SYNTRAN signal performance via a 9-bit code. FEBE Indicator. Bit C2 in the first M-frame in a triad is designated as a Far End Block Error (FEBE) bit. It is used to indicate CRC-9 errors detected at the receive side (by returning the FEBE bit to the transmitting side). Alarm Channel. Bit C3 of the M-frame in a triad designated as an alarm and control channel. Loopbacks. The alarm and control channel also supports the transmission of code words to activate and deactivate the line loopback.
Asynchronous DS3 C-Bit Parity Application

This section describes the asynchronous DS3 C-bit parity signal structure that is used to multiplex asynchronous 28 DS1 signals to the DS3 signal level. The asynchronous DS3 C-bit parity signal preserves the M, F, P, X, and C-bits, to assure compatibility with DS3 equipment and transmission facilities.
C-Bit Maintenance Features

X-Bit Channel. The X-bit channel is used to transmit failure conditions from the far end to the near end of the system in the same manner as the yellow alarm. Far-End Alarm and Control Signals. The third C-bit in M-subframe 1 is used as a Far-End Alarm and Control (FEAC) signal. This signal is used for two purposes: To send alarm and status information from the far-end terminal back to the near-end terminal. To initiate DS3 and DS1 loopbacks at the far-end terminal from the near-end terminal. DS3-Path Parity Bits. The three C-bits in M-subframe 3, designated CP-bits, are used to carry DS3 path parity information. The receiver uses these bits to determine if an error has occurred in M-frame, by computing the parity based on the contents of M-frame n and comparing this parity value with the parity received in the CP-bits in M-frame n+1. Terminal-to-Terminal Path Maintenance Data Link. The three C-bits in M-subframe 5 (designated as DL-bits) are used as a 28.2 kbps terminal-to-terminal path maintenance data link.
C-12
PDH Environment
Gmux-2000 Ver. 4.0
The data link uses the Link Access Procedure on the D-channel (LAPD). The LAPD messages carry DS3 path identification, DS3 idle signal identification, and DS3 test signal identification information.
DS3 Alarm Conditions

DS3 Alarm Indication Signal (AIS). The DS3 AIS is a signal with a valid M-frame alignment channel, M-subframe alignment channel, and valid P-bits. The information bits are a 10... sequence, starting with a one (1) after each M-frame alignment bit, M-subframe alignment bit, X-bit, P-bit, and C-bit channel. In addition, the C-bits are set to zero (C1=0, C2=0, and C3=0), and the X-bits are set to one (X1=1 and X2=1). DS3 Yellow Alarm. The yellow alarm is declared when the DS3 receive path cannot detect the framing, or detects AIS reception. The yellow alarm is indicated by setting the X-bits to zero (X1=0 and X2=0) in the DS3 signal returned. In the non-alarm condition, the X bits are set to one (X1=1 and X2=1). Idle Signal. The idle signal is a signal with a valid M-frame alignment channel, M-subframe alignment channel, and P-bit channel. The information bits are set to a 1100... sequence, starting with a one-one (11) after each M-frame alignment, M-subframe alignment, X-bit, P-bit, and C-bit channels. In addition, the C-bits in M-subframe 3 are set to zero.
C.3
SDH Implementation Principles
This section describes the implementation principles for the Synchronous Digital Hierarchy (SDH), as a background for the detailed presentation of the SDH signal structures. In the following explanations, the following terms are used to describe SDH networks: Network node. The SDH network node is a facility at which signals built in accordance with the SDH frame structure are generated and/or terminated. Therefore, a network node provides a convenient access point to add or drop payload signals, e.g., PDH tributary signals, for transmission over the SDH network. SDH transport system. An SDH transport system provides the technical means to transfer SDH signals between two network nodes. SDH network. An SDH network is formed by interconnecting the required number of network nodes by means of SDH transport systems.
Basic SDH Principles

The Synchronous Digital Hierarchy (SDH) is implemented on the basis of two principles: 1. Direct synchronous multiplexing of individual tributary signals within the structure of the higher-rate multiplexed signal.
Gmux-2000 Ver. 4.0
C-13
2. Transparent transporting of each individual tributary signal through the network, without any disassembly except at the two network nodes that exchange information through that particular signal. To enable synchronous multiplexing, SDH equipment is designed to permit efficient and reliable synchronization of the whole network to a single timing reference.
Direct Multiplexing Approach

Direct multiplexing means that individual tributary signals can be inserted and removed into the SDH multiplexed signal without intermediate multiplexing and demultiplexing steps. This capability results in the following characteristics: Efficient signal transport, as the same SDH transport system can carry various types of payloads (tributary signals). Flexible routing, because any tributary can be inserted and removed into the SDH signal as a single unit, without affecting in any way the other tributary signals carried by the same SDH signal. This permits to build cost-effective add/drop multiplexers, the key component of flexible networks, instead of implementing digital cross-connect systems as entities separated from multiplexing equipment.
In addition, the SDH signal structure includes sufficient overhead for management and maintenance purposes, and therefore provides the network operator full control over all the operational aspects of SDH networks and equipment units. This overhead permits the integration of the network management and maintenance functions within the transport network itself.
General Structure of SDH Signals

The SDH signal is a serial signal stream with a frame structure. Figure C-7 shows the general structure of SDH signals. The SDH frame structure is formed by byte-interleaving the various signals carried within its structure. Each SDH frame starts with framing bytes, which enable equipment receiving the SDH data stream to identify the beginning of each frame. The location of the other bytes within this frame structure is determined by its position relative to the framing byte. The organization of the frame can be easily understood by representing the frame structure as a rectangle comprising boxes arranged in N rows and M columns, where each box carries one byte. In accordance with this representation, the framing byte appears in the top left-hand box (the byte located in row 1, column 1), which by convention is referred to as byte 1 of the SDH frame.
C-14
Gmux-2000 Ver. 4.0

N x M Bytes
Order of Transmission
F B B B
B B
N x M Bytes
N Rows
1 2
Order of Transmission
B B
M Columns
Legend
B Signal Byte F Framing Byte
Figure C-7. General Structure of SDH Signals

The frame bytes are transmitted bit by bit, sequentially, starting with those in the first row (see arrow in Figure C-7). After the transmission of a row is completed, the bits in the next lower row are transmitted. The order of transmission within each row is from left to right. After transmission of the last byte in the frame (the byte located in row N, column M), the whole sequence repeats - starting with the framing byte of the following frame.
SDH Frame Organization

As shown in Figure C-8, an SDH frame comprises two distinct parts: Section Overhead (SOH) Virtual Container (VC).
F F F F
N Rows
Section Overhead
Path Overhead (One Column)
Virtual Container (VC)
M Columns
Figure C-8. SDH Frame Organization
Gmux-2000 Ver. 4.0
C-15
Section Overhead
In SDH networks, the term section refers to the link between two consecutive SDH equipment units of the same type. Some signal carrying capacity is allocated in each SDH frame for the section overhead. This provides the facilities (alarm monitoring, bit error monitoring, data communications channels, etc.) required to support and maintain the transportation of a VC between nodes in an SDH network. The section overhead pertains only to an individual SDH transport system. This means that the section overhead is generated by the transmit side of a network node, and is terminated at the receive side of the next network node. Therefore, when several SDH transport systems are connected in tandem, the section overhead is not transferred together with the payload (VC) between the interconnected transport systems.
Virtual Container (VC)

The VC is an envelope (i.e., a special type of signal structure, or frame) that is used to transport a tributary signal across the SDH network. The path followed by a VC within the network may include any number of nodes, therefore the VC may be transferred from one SDH transport system to another, many times on its path through the network. Nevertheless, in most cases the VC is assembled at the point of entry to the SDH network and disassembled only at the point of exit. Since the VC is handled as an envelope that is opened only at the path end points, some of its signal carrying capacity is dedicated to path overhead. The path overhead provides the facilities (e.g., alarm and performance monitoring), required to support and maintain the transportation of the VC between the end points.
VC Assembly/Disassembly Process
The concept of a tributary signal being inserted into a virtual container, to be transported end-to-end across a SDH network, is fundamental to the operation of SDH networks. This process of inserting the tributary signal into the proper locations of a VC is referred to as mapping. In all the SDH signal structures, the carrying capacity provided for each individual tributary signal is always slightly greater than that required by the tributary rate. Thus, the mapping process must compensate for this difference. This is achieved by adding stuffing bytes, e.g., path overhead bytes, to the signal stream as part of the mapping process. This increases the bit rate of the composite signal to the rate provided for tributary transport in the SDH structure. At the point of exit from the SDH network, the tributary signal must be recovered from the virtual container, by removing the path overhead and stuffing bits. This process is referred to as demapping. After demapping, it is necessary to restore the original data rate of the recovered tributary data stream.
C-16
Gmux-2000 Ver. 4.0
C.4
STM-1 Frame Structure
Gmux-2000 handles the base-level SDH signal, which is called Synchronous Transport Mode Level 1 (STM-1).
Description of STM-1 Frame

Figure C-9 shows the STM-1 frame structure.
2430 Bytes/Frame
Serial Signal Stream 155.52 Mbps
Path Overhead (9 Bytes)
STM-1 Virtual Container (VC-4)
9 Rows
Section Overhead
Container Capacity = 150.34 Mbps Payload Capacity = 149.76 Mbps
9 Columns 1 Column
260 Columns
2430 Bytes/Frame x 8 Bits/Byte x 8000 Frames/sec = 155.52 Mbps
Figure C-9. STM-1 Frame Structure

STM-1 frames are transmitted at a fixed rate of 8000 frames per second.
Note
At a transmission rate of 8000 frames per second, each byte supports a data rate of 64 kbps.
The STM-1 signal frame comprises 9 rows by 270 columns, resulting in a total signal capacity of 2430 bytes (19440 bits per frame). Considering the STM-1 frame repetition rate, 8000 frames per second, this yields a bit rate of 155.520 Mbps. The STM-1 frame comprises the following parts: Section Overhead. The STM-1 section overhead occupies the first nine columns of the STM-1 frame, for total of 81 bytes. Virtual Container. The remaining 261 columns of the STM-1 frame, which contain a total of 2349 bytes, are allocated to the virtual container. The virtual container itself comprises a container for the payload signal (260 columns), preceded by one column of path overhead. The virtual container carried in an STM-1 frame is referred to as a Virtual Container Level 4, or VC-4. VC-4, which is transported unchanged across the SDH network, provides a channel capacity of 150.34 Mbps. The VC-4 structure includes one column (9 bytes) for the VC-4 path overhead, leaving 260 columns of signal carrying capacity (149.76 Mbps). This carrying
Gmux-2000 Ver. 4.0
C-17
capacity is sufficient for transporting a 139.264 Mbps tributary signal (the fourth level in the PDH signal hierarchy). The VC-4 signal carrying capacity can also be subdivided, to permit the transport of multiple lower-level PDH signals.
Pointers
In Figure C-9, the VC-4 appears to start immediately after the section overhead part of the STM-1 frame. Actually, to facilitate efficient multiplexing and cross-connection of signals in the SDH network, VC-4 structures are allowed to float within the payload part of STM-1 frames. This means that the VC-4 may begin anywhere within the STM-1 payload part. The result is that in most cases, a given VC-4 begins in one STM-1 frame and ends in the next. Were the VC-4 not allowed to float, buffers would be required to store the VC-4 data up to the instant it can be inserted in the STM-1 frame. These buffers (called slip buffers), which are often used in PDH multiplex equipment, introduce long delays. Moreover, they also cause disruptions in case a slip occurs.
Identifying VC-4 Beginning in the STM-1 Frame

When a VC-4 is assembled into the STM-1 frame, a pointer (byte) located in the section overhead of the STM-1 frame indicates the location of the first byte (J1) of the VC-4 that starts in that STM-1 frame.
Using Pointers to Correct Timing Differences

SDH network are intended to operate as synchronous networks. Ideally, this means that all SDH network nodes should derive their timing signals from a single master network clock. However, in practical applications, network implementation must accommodate timing differences (clock offsets). These may be the result of an SDH node losing network timing reference and operating on its standby clock, or it may be caused by timing differences at the boundary between two separate SDH networks. The VC-4 is allowed to float freely within the space made available for it in the STM-1 frame, therefore phase adjustments can be made as required between the VC-4 and the STM-1 frame. To accommodate timing differences, the VC-4 can be moved (justified), positively or negatively three bytes at time, with respect to the STM-1 frame. This is achieved by simply recalculating and updating the pointer value at each SDH network node. In addition to clock offsets, updating the pointer will also accommodate any other adjustment required between the input SDH signal rate and the timing reference of the SDH mode. Pointer adjustments introduce jitter. Excessive jitter on a tributary signal degrades signal quality and may cause errors. Therefore, SDH networks must be designed to permit reliable distribution of timing to minimize the number of pointer adjustments.
C-18
Gmux-2000 Ver. 4.0
C.5
SDH Overhead Data
SDH Overhead Data Types

In SDH networks, a transmission path can include three equipment functions: SDH terminal multiplexer which performs the insertion/removal of tributary signals into SDH frames SDH cross-connect switch permits to change the routing of tributary signals carried in SDH frames Regenerator used to increase the physical range of the transmission path.
The resulting structure of an SDH transmission path is shown in Figure C-10.

Multiplexer Section Multiplexer Section
Regenerator Section Regenerator Section Regenerator Section
Tributary Signals
. . .
SDH Terminal Multiplexer SDH Cross-Connect
SDH Terminal Multiplexer
Tributary Signals
. . .
VC Assembly
Path
VC Disassembly
Figure C-10. Structure of Transmission Path in SDH Network

As shown in Figure C-10, a transmission path can comprise three types of segments: Multiplexer section a part of a transmission path located between a terminal multiplexer and an adjacent SDH cross-connect equipment, or between two adjacent SDH terminal multiplexers. Regenerator section a part of a transmission path located between a terminal multiplexer or SDH cross-connect equipment and the adjacent regenerator, or between two adjacent regenerators. A multiplexer section can include up to three regenerator sections. Path the logical connection between the point at which a tributary signal is assembled into its virtual container, and the point at which it is disassembled from the virtual container.
To provide the support and maintenance signals associated with transmission across each segment, each of these segments is provided with its own overhead data, hence three types of overhead data: Section overhead, carried in the first nine columns of the STM-1 frame: Multiplexer section (MS) overhead carried in overhead rows 5 to 9 Regenerator section (RS) overhead carried in overhead rows 1 to 3 AU pointers carried in overhead row 4.
Gmux-2000 Ver. 4.0
SDH Overhead Data
C-19
Path overhead, carried in the first column of a VC-4. The path overhead carried in the VC-4 is called high-order path overhead; see Section C.6 for a description of the low-order path overhead.
Figure C-11 shows the detailed structure of the overhead data in STM-1 frames.
Section Overhead
Framing A1 Framing A1 Framing A1 Framing A2 Framing A2 Framing A2 ID C1
Path Overhead
Path Trace J1 BIP-8 B3 Signal Label C2
Pointer H3 Pointer H3
Regenerator Section Overhead (Rows 1 - 3)
BIP-8 B1
Orderwire E1
User F1
DCC D1
DCC D2
DCC D3
AU Pointers (Row 4)
Pointer H1 BIP-24 B2 DCC D4 B2 B2
Pointer H2 APS K1 DCC D5
Pointer H3 APS K2 DCC D6
Path Status G1 User Channel F2 Multiframe H4
Multiplex Section Overhead (Rows 5 - 9)
DCC D7
DCC D8
DCC D9
Z3
DCC D10
DCC D11
DCC D12
Z4
Z1
Z1
Z1
Z2
Z2
Z2
Orderwire E2
Z5
Bytes reserved for future use
Figure C-11. Organization of STM-1 Overhead Data
Regenerator Section Overhead (RSOH)

A regenerator section of an SDH network comprises the transmission medium and associated equipment between a network element and the adjacent regenerator, or between two adjacent regenerators. The associated equipment includes the aggregate interfaces and SDH processing equipment which either originates or terminates the regenerator section overhead. The functions of the various bytes carried in the STM-1 regenerator section overhead are described below.
Framing (A1, A2 Bytes)

The six framing bytes carry the framing pattern, and are used to indicate the start of an STM-1 frame.
Channel Identifier (C1 Byte)

The C1 byte is used to identify STM-1 frames within a higher-level SDH frame (STM-N, where the standardized values of N are 4, 16, etc.). The byte carries the binary representation of the STM-1 frame number in the STM-N frame.
C-20
SDH Overhead Data
Gmux-2000 Ver. 4.0
Parity Check (B1 Byte)

A 8-bit wide bit-interleaved parity (BIP-8) checksum is calculated over all the bits in the STM-1 frame, to permit error monitoring over the regenerator section. The computed even-parity checksum is placed in the RSOH of the following STM-1 frame.
Data Communication Channel (D1, D2, D3 Bytes)

The 192 kbps Data Communication Channel (DCC) provides the capability to transfer network management and maintenance information between regenerator section terminating equipment.
Orderwire Channel (E1 Byte)

The E1 byte is used to provide a local orderwire channel for voice communications between regenerators and remote terminal locations.
User Communication Channel (F1 byte)

The F1 byte is intended to provide the network operator with a channel that is terminated at each regenerator location, and can carry proprietary communications. The information transmitted on this channel can be passed unmodified through a regenerator, or can be overwritten by data generated by the regenerator.
AU Pointers (H1, H2, H3 bytes)

The AU (Administration Unit) pointer bytes are used to enable the transfer of STM-1 frames within STM-N frames, and therefore are processed by multiplexer section terminating equipment. Separate pointers are provided for each STM-1 frame in an STM-N frame. AU pointer function is to link between the section overhead and the associated virtual container(s).
Multiplexer Section Overhead (MSOH)

A multiplexer section of an SDH network comprises the transmission medium, together with the associated equipment (including regenerators) that provide the means of transporting information between two consecutive network nodes (e.g., SDH multiplexers). One of the network nodes originates the multiplexer section overhead (MSOH) and the other terminates this overhead. The functions of the various bytes carried in the STM-1 multiplexer section overhead are described below.
Parity Check (B2 Bytes)

A 24-bit wide bit-interleaved parity (BIP) checksum is calculated over all the bits in the STM-1 frame (except those in the regenerator section overhead). The computed checksum is placed in the MSOH of the following STM-1 frame.
Gmux-2000 Ver. 4.0
SDH Overhead Data
C-21
Protection Switching (K1, K2 Bytes)

The K1 and K2 bytes carry the information needed to activate/deactivate the switching between the main and protection paths on a multiplexer section.
Data Communication Channel (D4 to D12 Bytes)

Bytes D4 to D12 provide a 576 kbps data communication channel (DCC) between multiplexer section termination equipment. This channel is used to carry network administration and maintenance information.
Orderwire Channel (E2 Byte)

The E2 byte is used to provide a local orderwire channel for voice communications between multiplexer section terminating equipment.
Alarm Signals
Alarm information is included as part of the MSOH. These functions are explained in Section C.7.
VC-4 Path Overhead Functions

The path overhead (POH) is contained within the virtual container portion of the STM-1 frame. The POH data of the VC-4 occupies all the 9 bytes of the first column. The functions of the various bytes carried in the VC-4 path overhead are described below.
Path Trace Message (J1 Byte)

The J1 byte is used to repetitively transmit a 64-byte string (message). The message is transmitted one byte per VC-4 frame. A unique message is assigned to each path in an SDH network. Therefore, the path trace message can be used to check continuity between any location on a transmission path and the path source.
Parity Check (B3 Byte)

An 8-bit wide bit-interleaved parity even checksum, used for error performance monitoring on the path, is calculated over all the bits of the previous VC-4. The computed value is placed in the B3 byte.
Signal Label (C2 Byte)

The signal label byte, C2, indicates the structure of the VC-4 container. The signal label can assume 256 values, however two of these values are of particular importance: The all 0s code represents the VC-4 unequipped state (i.e., the VC-4 does not carry any tributary signals) The code 00000001 represents the VC-4 equipped state.
C-22
SDH Overhead Data
Gmux-2000 Ver. 4.0
Path Status (G1 Byte)

The G1 byte is used to send status and performance monitoring information from the receive side of the path terminating equipment to the path originating equipment. This allows the status and performance of a path to be monitored from either end, or at any point along the path.
Multiframe Indication (H4 byte)

The H4 byte is used as a payload multiframe indicator, to provide support for complex payload structures, for example payload structures carrying multiple tributary units (TUs see Section C.6). If, for example, the TU overhead is distributed over four TU frames, these four frames form a TU multiframe structure. The H4 byte then indicates which frame of the TU multiframe is present in the current VC-4.
User Communication Channel (F2 Byte)

The F2 byte supports a user channel that enables proprietary network operator communications between path terminating equipment.
Alarm Signals
Alarm and performance information is included as part of the path overhead. These functions are explained in Section C.7.
C.6
SDH Tributary Units
The VC-4 channel capacity, 149.76 Mbps, has been defined specifically for the transport of a fourth level (139.264 Mbps) PDH multiplex signal. To enable the transport and switching of lower-rate tributary signals within the VC-4, several special structures, called Tributary Units (TUs), have been defined. The characteristics of each TU type have been specifically selected to carry one of the standardized PDH signal rates. In addition, a fixed number of whole TUs may be mapped within the container area of a VC-4.
Tributary Unit Frame Structure

The structure of the tributary unit frame is rather similar to the SDH frame structure, described in Section C.3. With reference to Figure C-8, the tributary unit frame also includes a section overhead part and a virtual container part, which comprises a container and path overhead. In general, the tributary unit frame is generated in three steps: A low rate tributary signal is mapped into the TU container Low-path path overhead is added before the container, to form the corresponding virtual container (VC-11, VC-12, VC-2 or VC-3, depending on the TU type)
Gmux-2000 Ver. 4.0
SDH Tributary Units
C-23
A TU pointer is added to indicate the beginning of the VC within the TU frame. This is the only element of TU section overhead.
The TU frame is then multiplexed into a fixed location within the VC-4. Because of the byte interleaving method, a TU frame structure is distributed over four consecutive VC-4 frames. It is therefore more accurate to refer to the structure as a TU multiframe. The phase of the multiframe structure is indicated by the H4 byte contained in the VC-4 path overhead.
Tributary Unit Types

As mentioned above, specific containers (C), virtual containers (VC) and associated TU structures have been defined for each standard PDH multiplex signal level. These structures are explained below: TU-11: Each TU-11 frame consists of 27 bytes, structured as 3 columns of 9 bytes. At a frame rate of 8000 Hz, these bytes provide a transport capacity of 1.728 Mbps and will accommodate the mapping of a North American DS1 signal (1.544 Mbps). 84 TU-11s may be multiplexed into the STM-1 VC-4. TU-12: Each TU-12 frame consists of 36 bytes, structured as 4 columns of 9 bytes. At a frame rate of 8000 Hz, these bytes provide a transport capacity of 2.304 Mbps and will accommodate the mapping of a CEPT 2.048 Mbps signal. 63 TU-12s may be multiplexed into the STM-1 VC-4. TU-2: Each TU-2 frame consists of 108 bytes, structured as 12 columns of 9 bytes. At a frame rate of 8000 Hz, these bytes provide a transport capacity of 6.912 Mbps and will accommodate the mapping of a North American DS2 signal. 21 TU-2s may be multiplexed into the STM-1 VC-4. TU-3: Each TU-3 frame consists of 774 bytes, structured as 86 columns of 9 bytes. At a frame rate of 8000 Hz, these bytes provide a transport capacity of 49.54 Mbps and will accommodate the mapping of a CEPT 34.368 Mbps signal or a North American 44.768 DS3 signal. Three TU-3s may be multiplexed into the STM-1 VC-4.
Figure C-12 illustrates the assembly (multiplexing) of TUs in the VC-4 structure,
for the specific case of the TU-12. For other multiplexing options, see
Figure C-13.
C-24
SDH Tributary Units
Gmux-2000 Ver. 4.0

2430 Bytes/Frame
Serial Signal Stream 155.52 Mbps
VC-4 Path Overhead
9 Rows
Section Overhead
TU-12 No. 1
TU-12 No.2 to TU-12 No.62
TU-12 No. 63
9 Columns 1 Column
260 Columns
Figure C-12. VC-4 Carrying TU-12 Payload

As shown in Figure C-12, 63 TU-12s can be packed into the 260 columns of payload capacity (i.e., the C-4 container) provided by a VC-4. This leaves 8 columns in the C-4 container unused. These unused columns result from intermediate stages in the TU-12 to VC-4 multiplexing process, and are filled by fixed stuffing bytes.
SDH Multiplexing Hierarchy

Figure C-13 shows a general view of the SDH multiplexing hierarchy. The
hierarchy illustrates all the both the European and North American PDH multiplex levels (see Table C-1 for details on the PDH multiplexing hierarchy).
Figure C-13 also shows the utilization of additional SDH signal structures:
TUG: tributary unit group, is the structure generated by combining several lower level tributaries into the next higher level tributary. For example, TUG-2 is generated by combining 3 TU-12 or 4 TU-11, and TUG-3 is generated by combining 7 TUG-2. AU: administrative unit, is a structure that includes a VC and a pointer to the beginning of the VC. For example, AU-3 contains one VC-3 and includes a pointer to the beginning of the VC. AUG: administrative unit group, is the structure generated by combining several lower level administrative units into the next higher level administrative unit. For example, AUG for the STM-1 level is generated by combining 3 AU-3 (several AUG can be combined for generating STM-N (N = 4, 16, etc.) structures).
Note
For simplicity, reference is made only to VCs (the actual structure needed to transport a VC can be found from the SDH or SONET multiplexing hierarchy).
Gmux-2000 Ver. 4.0
SDH Tributary Units
C-25

1 AUG 3 AU-3 VC-3 1 AU-4 VC-4 1

C-4
STM-1 (155.520 Mbps)
139.264 Mbps (E4)
44.736 Mbps (DS3)

3 7 1 TU-3 VC-3 C-3
34.368 Mbps (E3)
TUG3 1 7 TUG2 Pointer Processing 3 Mapping TU-12 VC-12 C-12 2 TU-2 VC-2 C-2
6.312 Mbps (DS2) 3.152 Mbps (DS1C)
VT3
Legend
TU-11
VC-11
C-11
1.544 Mbps (DS1) 2.048 Mbps (E1)
Figure C-13. SDH Multiplexing Hierarchy

The flexibility of the SDH multiplexing approach is illustrated by the many paths that can be used to build the various signal structures. For example, Figure C-13 shows that the STM-1 signal can be generated by the following multiplexing paths: Each E1 signal is mapped into a VC-12, which is then encapsulated in a TU-12. Each group of 3 TU-12 is combined to obtain a TUG-2 (3 E1 signals per TUG-2.) Seven TUG-2 are combined to obtain one TUG-3 (21 E1 signals per TUG-3). TUG-3 is carried in a VC-3. Three VC-3 are combined to generate one VC-4 (63 E1 signals per VC-4). The STM-1 signal carries one VC-4.
C.7
SDH Maintenance Signals

The maintenance signals transmitted within the SDH signal structure are explained in Table C-2.
Table C-2. SDH Maintenance Signal Definitions

Signal Loss of Signal (LOS) Description LOS state entered when received signal level drops below the value at which an error ratio of 10 is predicted.
-3
LOS state exited when 2 consecutive valid framing patterns are received, provided that during this time no new LOS condition has been detected
C-26
Gmux-2000 Ver. 4.0
Signal Out of Frame (OOF)
Description OOF state entered when 4 or 5 consecutive SDH frames are received with invalid (errored) framing patterns. Maximum OOF detection time is therefore 625 s. OOF state exited when 2 consecutive SDH frames are received with valid framing patterns
Loss of Frame (LOF)
LOF state entered when OOF state exists for up to 3 ms. If OOFs are intermittent, the timer is not reset to zero until an in-frame state persists continuously for 0.25 ms. LOF state exited when an in-frame state exists continuously for 1 to 3 ms
Loss of Pointer (LOP)
LOP state entered when N consecutive invalid pointers are received where N = 8, 9 or 10. LOP state exited when 3 equal valid pointers or 3 consecutive AIS indications are received.
Note
Multiplexer Section AIS
The AIS indication is an all 1s pattern in pointer bytes.
Sent by regenerator section terminating equipment (RSTE) to alert downstream MSTE of detected LOS or LOF state. Indicated by STM signal containing valid RSOH and a scrambled all 1s pattern in the rest of the frame. Detected by MSTE when bits 6 to 8 of the received K2 byte are set to 111 for 3 consecutive frames. Removal is detected by MSTE when 3 consecutive frames are received with a pattern other than 111 in bits 6 to 8 of K2.
Far End Receive Failure (FERF or MS-FERF)
Sent upstream by multiplexer section terminating equipment (MSTE) within 250 s of detecting LOS, LOF or MS-AIS on incoming signal. Optionally transmitted upon detection of excessive BER defect (equivalent BER, based on B2 bytes, exceeds 10 ). Indicated by setting bits 6 to 8 of transmitted K2 byte to 110.
-3
Detected by MSTE when bits 6 to 8 of received K2 byte are set to 110 for 3 consecutive frames. Removal is detected by MSTE when 3 consecutive frames are received with a pattern other than 110 in bits 6 to 8 of K2. Transmission of MS-AIS overrides MS-FERF AU Path AIS Sent by MSTE to alert downstream high order path terminating equipment (HO PTE) of detected LOP state or received AU Path AIS. Indicated by transmitting all 1s pattern in the H1, H2, H3 pointer bytes plus all bytes of associated VC-3 and VC-4). Detected by HO PTE when all 1s pattern is received in bytes H1 and H2 for 3 consecutive frames. Removal is detected when 3 consecutive valid AU pointers are received High Order Path Remote Alarm Indication (HO Path RAI, also known as HO Path FERF) Generated by high order path terminating equipment (HO PTE) in response to received AU path AIS. Sent upstream to peer HO PTE. Indicated by setting bit 5 of POH G1 byte to 1. Detected by peer HO PTE when bit 5 of received G1 byte is set to 1 for 10 consecutive frames. Removal detected when peer HO PTE receives 10 consecutive frames with bit 5 of G1 byte set to 0
Gmux-2000 Ver. 4.0
C-27
Signal TU Path AIS
Description Sent downstream to alert low order path terminating equipment (LO PTE) of detected TU LOP state or received TU path AIS. Indicated by transmitting all 1s pattern in entire TU-1, TU-2 and TU-3 (i.e., pointer bytes V1-V3, V4 byte, plus all bytes of associated VC-1, VC-2 and VC-3 loaded by all 1s pattern). Detected by LO PTE when all 1s pattern received in bytes V1 and V2 for 3 consecutive multiframes. Removal is detected when 3 consecutive valid TU pointers are received.
Note
TU Path AIS is only available when generating and/or receiving floating mode tributary unit payload structures.
Low Order Path Remote Alarm Indication (LO Path RAI, also known as LO Path FERF)
Generated by low order path terminating equipment (LO FTE) in response to received TU Path AIS. Sent upstream to peer LO PTE. Indicated by setting bit 8 of LO POH V5 byte to 1. Detected by peer LO PTE when bit 8 of received V5 byte is set to 1 or 10 consecutive multiframes. Removal detected when peer LO PTE receives 10 consecutive multiframes with bit 8 of V5 byte set to 0.
Note
LO Path RAI is only available when generating and/or receiving floating mode tributary unit payload structures.
Response to Abnormal Conditions

This section describes the response to the wide range of conditions that can be detected by the maintenance means built into the SDH frames, and the flow of alarm and indication signals.
Figure C-14 provides a graphical representation of the flow of alarm and

indication signals through an SDH transmission path.
C-28
Gmux-2000 Ver. 4.0

Low Order Path
High Order Path Multiplexer Section Regenerator Section Regenerator Section
LO PTE
HO PTE
MS TE
RS TE
LOP LOS LOF LOS LOF AIS (X2)
MS TE
LOP
HO PTE
LOP
LO PTE
AIS (H1H2)
AIS (V1V2)
Tributary AIS
FERF (X2) RAI (G1) RAI (G1)
RAI (VS)
RAI (VS)
B1(BIP-8)
B1(BIP-8)
B2(BIP-24)
B3(BIP-8)
FEBE (G1)
FEBE (G1)
BIP-2 (VS) FEBE (VS) FEBE (VS)
Legend
Collection Transmission Generation LO HO Low Order High Low Order PTE RS TE MS TE Path Terminating Equipment Regenerator Section Terminating Equipment Multiplexer Section Terminating Equipment
Figure C-14. Flow of Alarm and Indication Signals through an SDH Transmission Path
Flow of Alarm and Response Signals

The major alarm conditions such as Loss of Signal (LOS), Loss of Frame (LOF), and Loss of Pointer (LOP) cause various types of Alarm Indication Signals (AIS) to be transmitted downstream. In response to the detection of an AIS signals, and detection of major receiver alarm conditions, other alarm signals are sent upstream to warn of trouble downstream: Far End Receive Failure (FERF) is sent upstream in the multiplexer overhead after multiplexer section AIS, or LOS, or LOF has been detected by equipment terminating in a multiplexer section span A Remote Alarm Indication (RAI) for a high order path is sent upstream after a path AIS or LOP condition has been detected by equipment terminating a path
Gmux-2000 Ver. 4.0
C-29
A Remote Alarm Indication (RAI) for a low order path is sent upstream after low order path AIS or LOP condition has been detected by equipment terminating a low order path.
Performance Monitoring
Performance monitoring at each level in the maintenance hierarchy is based on the use of the byte interleaved parity (BIP) checksums calculated on a frame by frame basis. These BIP checksums are sent downstream in the overhead associated with the regenerator section, multiplexer section and path maintenance spans. In response to the detection of errors using the BIP checksums, the equipment terminating the corresponding path sends upstream Far End Block Error (FEBE) signals.
C.8
SONET Environment
SONET (Synchronous Optical Network) is an alternative standard to SDH, widely used in North America and other parts of the world. SONET uses similar implementation principles, and even the frame structures are quite similar to those used by SDH. Therefore, the following description is based on the information already presented for SDH in Sections C.3 through C.7.
Figure C-15 shows the SONET multiplexing hierarchy.

STS-3 (155.520 Mbps) 1 STS-3 STS-3c 1 STS-3c SPE
139.264 Mbps (E4)
44.736 Mbps (DS3)
1 2
VT6
VT6 SPE VT3 SPE VT1.5 SPE VT2 SPE
6.312 Mbps (DS2) 3.152 Mbps (DS1C) 1.544 Mbps (DS1) 2.048 Mbps (E1)
Legend
Pointer Processing
STS-1
STS-1 SPE
VT3
VT Group
4 3
VT1.5
Mapping
VT2
Figure C-15. SONET Multiplexing Hierarchy
C-30
SONET Environment
Gmux-2000 Ver. 4.0
The designations of the main signal structures in the SONET hierarchy are as follows: Containers are replaced by Synchronous Payload Envelopes (SPE) for the various virtual tributaries (VTs) Virtual containers (VCs) are replaced by virtual tributaries (VTs), however the rates are similar to those used in the SDH hierarchy Tributary unit groups (TUGs) are replaced by virtual tributary groups The VC-3 level is replaced by the Synchronous Transport Signal level 1 (STS-1), and has the same rate (51.840 Mbps). 3 STS-1 can be combined to obtain one Synchronous Transport Signal level 3 (STS-3) at the same rate as STM-1 (155.520 Mbps). The corresponding optical line signal is designated OC-3.
C.9
Ethernet Transmission Technology
Introduction to Ethernet Transmission

One of the most successful digital transmission technologies is referred to by the generic term Ethernet. The Ethernet technology is suitable for a wide range of physical media: coaxial cable, twisted pairs and optical fibers. The current standards for Ethernet transmission cover rates from 10 Mbps to 10 Gbps. In many office LANs, Ethernet runs at 10 Mbps and 100 Mbps (Fast Ethernet); 1000 Mbps (1 Gbps, also called Gigabit Ethernet, or GbE) is rapidly becoming commonplace. The basic standards covering Ethernet LANs are included in the IEEE 802.3 family. In addition to the aspects covered by the IEEE 802.3 standards, there is a wide range of LAN standards (the IEEE 802 family) that cover other aspects of LAN transmission, for example, bridging, with particular emphasis on Ethernet LANs. Ethernet standards (in their broadest interpretation) cover the physical and data link control layers (layers 1 and 2 in the OSI model; IP is a layer 3 protocol). The data link control layer is split into two sublayers: media access control (MAC) and logical link control (LLC).
Ethernet LAN Topologies

Ethernet LANs use a multidrop topology. The LANs can be implemented either in bus or star (hub-based) topology. For the Gmux-2000, only the star (hub-based) topology is relevant.
Figure C-16 shows the general structure of a LAN using the star topology.
In the star topology, all the nodes on the LAN are connected to a common unit, which serves as the hub of the LAN. The hub can be implemented in two ways:
Gmux-2000 Ver. 4.0
C-31
Simple Ethernet hub, which detects the transmitting node and transparently distributes its signal to all the other nodes. A hub supports only half-duplex communication (the same as in a bus topology). Ethernet switch: the switch includes more sophisticated circuits that enable both half-duplex and full-duplex operation and prevent collisions.
In a star topology, the LAN cables are usually made of two twisted pairs (one transmit pair and one receive pair). The standard connector type is RJ-45, and its pin assignment has also been standardized. However, because of the need to use separate transmit and receive pairs, two types of port pin assignments have developed: station ports and hub ports (the difference is interchanging of the transmit and receive pins in the connector). This permits to interconnect connectors of different types by a cable wired pin-to-pin (straight cable). A fixed assignment of pin functions in the connectors requires using a crossed cable (a cable wired to interconnect the transmit pair at one end to the receive pair at the other end) to interconnect ports of same type. To avoid the need for using two types of cables (straight and crossed), special methods have been developed to enable automatic detection of pairs by the Ethernet interface, thus enabling the interface to select the correct connection irrespective of the type of cable. Interfaces operating on twisted pairs are designated in accordance with data rate: 10BASE-T (10 Mbps), 100BASE-TX (100 Mbps, where X is the number of pairs) and 1000BASE-T (1000 Mbps, which always uses 2 twisted pairs). 100 Mbps fiber optic interfaces are identified as 100BASE-FX (where X is the number of fibers, and 1000 Mbps fiber optic interfaces carry a label that indicates the range (SX for short range, etc.). Interfaces that support multiple rates are identified as 10/100BASET, 10/100/1000BASET, etc.
10/100BaseT Ethernet Hub
SD
TX Pair RX Pair
Figure C-16. Star (Hub-Based) Ethernet LAN Topology
Ethernet Communication Protocol

Today, Ethernet is used as a generic term for a LAN transmission technology that uses Carrier Sense and Multiple Access with Collision Detection (CSMA/CD) to enable the transmission of short bursts of data (called frames) between two or more stations (nodes). All the users have permanent access to the full bandwidth of the transmission medium but can only use it for short times, by transmitting short data bursts.
C-32
Gmux-2000 Ver. 4.0
Each data burst has a fixed structure, called a frame. The frame structure is explained below. The connection point of each user to the transmission media is called a node. For identification purposes, each LAN node has its own unique number, called MAC address.
Media Access Method

Media access is performed by means of the carrier sense, multiple access protocol (CSMA) with collision detection (CD), defined by IEEE Standard 802.3. The protocol defines three basic steps: A node that wants to transmit checks that the LAN is free. If another node is already transmitting, the node waits until the LAN is free. When the LAN is free, the node starts transmission and sends its frame. Each node has equal access rights, therefore the first node that starts transmitting is the one that seizes the LAN. When two nodes start transmitting at the same instant, a collision occurs. In this case, the transmitting nodes will continue to transmit for some time, in order to ensure that all transmitting nodes detected the collision (this is called jamming). After the jamming period, all transmitting nodes stop the transmission and wait for a random period of time before trying again. The delay times are a function of collision numbers and random time delay, therefore there is a good chance that an additional collision between these nodes will be avoided, and the nodes will be able to transmit their messages. The basic procedure described above has been developed for half-duplex communication, because it declares a collision whenever data is received during a local transmission. However, when using twisted pairs, separate pairs are used for the transmit and receive directions. Therefore, each node is capable of simultaneously transmitting and receiving (full-duplex operation), thereby doubling the effective data rate on the LAN.
Autonegotiation
As mentioned above, modern Ethernet interfaces are often capable of operation at the two basic rates, 10 Mbps and 100 Mbps, or even at three rates (10/100/1000 Mbps). Therefore, the rate and operating mode (half-duplex or full-duplex) are user-configurable options. When connecting equipment from different vendors to a common LAN, several operating modes are possible, depending on the specific characteristics of the equipment interconnected by means of the LAN . These modes are listed below, in ascending order of capabilities: Half-duplex operation at 10 Mbps. Full-duplex operation at 10 Mbps. Half-duplex operation at 100 Mbps. Full-duplex operation at 100 Mbps. Half-duplex operation at 1000 Mbps. Full-duplex operation at 1000 Mbps.
Gmux-2000 Ver. 4.0
C-33
To ensure interoperability (which practically means to select the highest transport capability supported by all the equipment connected to the LAN), two approaches can be used: manual configuration of each equipment interface, or automatic negotiation (autonegotiation) in accordance with IEEE Standard 802.3. The autonegotiation procedure enables automatic selection of the operating mode on a LAN, and also enables equipment connecting to an operating LAN to automatically adopt the LAN operating mode (if it is capable of supporting that mode). When autonegotiation is enabled on all the nodes attached (or trying to attach) to a LAN, the process is always successful. However, even if the nodes on an operating LAN are manually configured for operation in a fixed mode, a late-comer node with autonegotiation capability can still resolve the LAN operating rate can be resolved, thereby enabling it to adopt the LAN rate. Under these conditions, an autonegotiating node cannot detect the operating mode (half or full duplex), and therefore they will default to half-duplex. Therefore, as a practical configuration rule, do not enable the full-duplex mode without enabling autonegotiation, except when all the nodes have been manually configured for the desired operating mode (which may of course be full duplex).
Basic Ethernet Frame Structure

The frame transmitted by each node contains routing, management and error correction information. For Ethernet LANs, the characteristics of frames are defined by IEEE Standard 802.3. Basic frame lengths can vary from 72 to 1526 bytes and have the typical structure shown in Figure C-17.
72 to 1526 Bytes
Preamble (7 Bytes)
SFD (1 Byte)
MAC Destination Address (6 Bytes)
MAC Source Address (6 Bytes)
Length/ Type (2 Bytes)
MAC Client Data (0 To 1500 Bytes)
Padding Bytes
Frame Check Sequence (4 Bytes)
Start Frame Delimiter
Figure C-17. Basic Ethernet Frame Structure

Preamble. Each frame starts with a preamble of seven bytes. The preamble is used as a synchronizing sequence for the interface circuits, and helps bit decoding. Start-Frame Delimiter (SFD) field consists of one byte. The SFD field indicates where the useful information starts. Medium-Access (MAC) Destination Address (DA) field consists of six bytes. The MAC DA field carries the address of the destination node. Medium-Access (MAC) Source Address (SA) field consists of six bytes. The MAC SA field carries the address of the source node.
Note
In conventional notation MAC addresses are represented as 6 pairs of hexadecimal digits, separated by dashes, for example, 08-10-39-03-2F-C3.
C-34
Gmux-2000 Ver. 4.0
Length/Type field consists of two bytes that indicate the number of bytes contained in the logical link control (LLC) data field. In most Ethernet protocol versions, this field contains a constant indicating the protocol type (in this case, this field is designated EtherType). MAC Client Data field. The MAC client data field can contain 0 to 1500 bytes of user-supplied data. Padding field. The optional padding field contains dummy data, that is used to increase the length of short frames to at least 64 bytes. Frame Check Sequence (FCS) field contains four check bytes generated by a cyclic redundancy check (CRC) code. The FCS field is used to detect errors in the data carried in the frame.
Bridging
Communication between Nodes on Same LAN
A MAC address is unique and identifies a single physical port. Therefore, two Ethernet nodes attached to the same LAN exchange frame directly, by specifying the desired MAC destination address, together with the source MAC address. The node that identifies its MAC address in the destination field can send a response by copying the source address of the frame to the destination address field.
Communication between Nodes on Different LANs

To enable nodes on different LANs to communicate, it is necessary to transfer frames between the two LANs. The device used for this purpose is called MAC bridge, or just bridge. Two types of bridges are used: Local bridges, which have Ethernet ports attached to the two LANs. The bridge control mechanism learns the nodes attached to each LAN by reading the source MAC addresses of the frames generated by the nodes. When the destination address of a frame is not on the LAN from which it was received, the bridge transfers it to the other LAN. Remote bridges, which are used in pairs. A basic remote bridge has one LAN port and one WAN port. The WAN port communicates through a link with the WAN port of the remote bridge connected to the desired remote LAN. In this case, the traffic addressed to destinations not located on the local LAN is transferred through the WAN link to the remote bridge.
Using Virtual Bridged LANs

VLAN can be used to provide separation between traffic from different sources sharing the same physical transmission facilities, and provide information on the relative priority the user assigns to each frame. The characteristics and use of virtual LANs (VLANs) and of the MAC bridges capable of handling tagged frames are defined in IEEE Standard 802.1Q. VLANs are made possible by a slight modification to the Ethernet frame structure shown in Figure C-17. The structure of an Ethernet frame with VLAN support is shown in Figure C-18 (for simplicity, the figure does not include the preamble and SFD fields).
Gmux-2000 Ver. 4.0
C-35
Ethernet frames with VLAN support include a tag header immediately after the source MAC address (therefore, such frames are also referred to as tagged frames). The tag header comprises 4 bytes:
0
Two bytes for the tag protocol identifier. For Ethernet-encoded tags in accordance with IEEE802.1Q, these bytes carry the equivalent of 8100. Priority (PRI) specified by the user (3 bits: 7 is the highest priority and 0 is the lowest priority). One bit for the canonical format indicator (always 0 as shown in Figure C-18). VLAN ID (12 bits), used to indicate the VLAN to which the frame belongs.
4 8 12 16 20 24 28 31
Destination MAC Address (DA) Destination MAC Address (DA) Source MAC Address (SA)
Source MAC Address (SA) Tag Protocol Identifier (8100) EtherType (IP = 0800) PRI 0 VLAN ID
Ethernet Payload (42 to 1500 Bytes) Ethernet Payload . . . CRC
Figure C-18. Structure of Ethernet Frame with VLAN Support
C.10 IP Environment
This section provides background information on the IP environment. The information presented in this section refers to Version 4 of the IP protocol (IP4), currently the most widely used protocol version.
Introduction to IP
IP means Internet Protocol. The term IP protocol is often used to indicate a standardized set of rules and procedures that enable data exchange through a packet-switched network. Accordingly, the term Internet indicates the set of networks that use the IP protocol and are interconnected in a way that, at least in principle, permits any entity on one network to communicate with any entity on another network.
C-36
IP Environment
Gmux-2000 Ver. 4.0
Note
The term suite of IP protocols is also often used, in recognition of the fact that the operation of the Internet is actually defined by many related protocols.
IP Networks, IP Hosts and IP Ports

Any entity that can communicate using the IP protocol is called an IP host. The connection point between an IP host and an IP network is called IP port. An IP network forms when a number of IP ports can communicate directly (peer to peer) using the IP protocol, without any intermediaries. An IP host can have any number of IP ports. Moreover, the ports may be located on different IP networks.
IP Addresses
To enable IP communication between two IP hosts, it is necessary to find a route between their IP ports. For this purpose, each IP port is assigned an IP address. The only purpose of an IP address is to permit unambiguous identification of an IP port. Therefore, each IP port must be assigned a distinct and unique IP address. The IP protocol does not require the IP port to be related in an unambiguous way to a physical (communication) port. This has two main implications: Since the IP port is actually a connection to an IP network, any number of IP ports can share a given physical port. An IP port may be reached through several physical ports.
Note
By convention, the scope of IP addresses has been extended in two ways:

To permit identification of IP networks To permit simultaneous addressing of all the ports connected to a IP network
(this operation is called broadcasting).
IP Packet Structure
The information exchanged through IP networks is organized in packets. The structure of an IP packet, as specified by IP protocol Version 4, is as follows (the numbers are bit numbers):
Gmux-2000 Ver. 4.0
IP Environment
C-37
Appendix C Operating Environment 0 IP Version (4) 4 IP Header Length 8

12
Installation and Operation Manual 16 20 24 28 31
IP Type of Service (IP TOS)
Total IP Packet Length (total number of octets in header + payload) Flags (3 bits) Fragment Offset (13 bits)
Fragment Identification (16 bits)
(These fields are used for IP packet fragmentation) Time to Live (Range: 0 to 255; when 0, packet is discarded) Number of Upper-Layer Protocol Carried in Payload (IGMP = 2) (UDP = 17) Source IP Address Destination IP Address Options (when used) Padding (as required) IP Header Checksum
Payload (maximum bytes: 65535 header length)
IP Address Structure
An IP address is a 32-bit number, represented as four 8-bit bytes. Each byte represents a decimal number in the range of 0 through 255. The address is written in decimal format, with the bytes separated by decimal points, e.g., 164.90.70.47. This format is called dotted quad notation. An IP address is logically divided into two main portions: Network portion Host portion.
Network Portion
In general, the network portion is assigned by the Internet Assigned Numbers Authority (IANA), and its main purpose is to identify a specific IP network. There are five IP address classes: A, B, C, D, and E. However, only the A, B and C classes are used for IP addressing. Consult your network manager with respect to the class of IP addresses used on your network. The network portion of an IP address can be one, two, or three bytes long, in accordance with the IP address class. This arrangement is illustrated below:
C-38
IP Environment
Gmux-2000 Ver. 4.0
Installation and Operation Manual IP Address Byte 1 Byte 2
Byte 3
Byte 4
Class A
Network Portion
Host Portion
Class B
Network Portion
Host Portion
Class C
Network Portion
Host Portion
The class of each IP address can be determined from its leftmost byte, in accordance with the following chart:
Address Class Class A Class B Class C First Byte 0 through 127 128 through 191 192 through 223 Address Range 0.H.H.H through 127.H.H.H 128.N.H.H through 191.N.H.H 192.N.N.H through 223.N.N.H
where: N indicates bytes that are part of the network portion H indicates bytes that are part of the host portion.
Host Portion
In general, the host portion is used to identify an individual host connected to an IP network. After obtaining an IP network address, the using organization is free to assign host identifiers in accordance with its specific needs.
Note
The following host identifiers have special meanings, and must not be assigned to an actual host:
The all-zeros host identifier is interpreted as a network identifier. The all-ones host identifier is interpreted as a broadcast address. Therefore,
a message with an all-ones host identifier is accepted by all the hosts in the network.
Subnetting
Given the scarcity of IP network addresses, for organizations operating several relatively small, physically separated, IP networks, e.g., several departmental networks, it is advantageous to enable several physical networks to share a common IP network address. Small in this context means that the number of IP ports connected to each of these networks is small relative to the host address space for the corresponding IP address class. The approach taken to enable the sharing of an IP network address by two or more networks is called subnetting, which means use of subnets. The subnetting
Gmux-2000 Ver. 4.0
IP Environment
C-39
is relevant only within the using organization, and therefore can be freely selected to meet its specific needs. To enable subnetting, the meaning of the bits in the host portion of the IP address is further sub-divided into two portions: Subnet number. For example, subnet numbers can be used to identify departmental subnets. The subnet number follows the network identifier. Host number the last bits of the IP address.
This subdivision is illustrated below:

Net Number Subnet Number Host Number
For example, when the subnet includes 16 IP hosts, only the last four bits need to be reserved for the host number. For an organization which obtained one global Class C network address, this means that four bits are available to identify subnets. Therefore, this organization can implement 16 IP subnets, each comprising up to 16 hosts (except for two subnets that are limited to 15 hosts).
Subnet Masks
Subnet masks are used to indicate the division of the IP address bits between the net and subnet portion and the host portion. The mask is a 32-bit word that includes ones in the positions used for net and subnet identification, followed by zeros up to the end of the IP address. For example, the default subnet mask for any Class C address (i.e., all the eight bits in the host address space are used for hosts in the same net) is 255.255.255.000. However, if the same address is used in a subnet comprising up to 16 hosts and for which the host numbers range is 00 to 15, the subnet mask changes as follows:
IP Address (Dotted-Quad) IP Address (Binary) Subnet Mask (Binary) Subnet Mask (Dotted-Quad) 192 1011 1111 1111 1111 255 70 0100 0110 1111 1111 255 55 0011 0111 1111 1111 255 13 0000 0111 1111 0000 240
In most applications, the binary subnet mask is built as a contiguous string of ones, followed by a number of zeros (the number of zeros is selected as needed, to complete the number of subnet mask bits to 32). Therefore, when this conventional approach is used, the subnet mask can also be specified simply by stating the number of ones in the mask. For example, the subnet mask shown above is specified by stating that it comprises 28 bits.
C-40
IP Environment
Gmux-2000 Ver. 4.0
IP Routing Principles
The exchange of information between IP hosts is made in packets using the structure specified by the IP protocol. As explained in the IP Packet Structure section above, IP frames carry, within their header, the IP addresses of the destination and source hosts. In accordance with the IP protocol, an IP host checks the addresses of all the received frames, and accepts only frames carrying its own IP address as the destination. The source address is then used to enable the destination to respond to the source. An IP host will also respond to broadcasts (frames whose destination host identifier is all-ones).
Note
IP hosts support additional protocols within the IP suite, e.g., protocols used for connectivity checking, maintenance, etc. Therefore, IP hosts will accept additional types of messages, which are beyond the scope of this description.
When checking the destination address of an IP frame, an IP host starts by checking the network identifier. If the network identifier is different, the host will immediately reject the frame. Therefore, IP hosts can communicate only if they have the same network identifier. For example, this means that when a management station managing Gmux-2000 is connected directly, through a LAN, to the Gmux-2000 Ethernet management port, the network identifier part of the IP address assigned to the Gmux-2000 Ethernet port must be identical to the network identifier of the management station. To enable hosts located on different IP networks to communicate, IP routers are needed. The routers monitor the flowing traffic and identify the IP addresses of the local hosts connected to them, and then communicate this information to the other routers which are known to it using special protocols. Therefore, a router can determine to which other router to send a packet with a foreign IP address. The user can increase the routing efficiency by specifying a default gateway to handle IP traffic to other networks (this is always an IP router). When a default gateway address is specified, packets with IP destinations located on other networks are sent to the default gateway for processing: the router serving as default gateway then sends them to their destination. The default gateway must always be in the same IP subnet as the port sending traffic to the gateway.
Note
As an alternative, static IP routing may also be used. To define a static route, the user must specify the next hop, that is, IP address of the next port to which IP packets are to be forwarded.
Gmux-2000 Ver. 4.0
IP Environment
C-41
Tools for Checking IP Connectivity

Ping Function
The IP protocol is referred to as an unreliable connectionless packet delivery protocol, because each packet transmitted by an IP host travels on its own through the network until it eventually reaches its destination. To ensure reliable delivery, higher layer protocols are used, for example, the widely-used TCP protocol. However, using higher layer protocols cannot provide an answer to the need to check that it is indeed possible to reach the desired IP destination address, because configuration errors or a network fault, for example, temporary congestion or failure of critical communication links, may still prevent the establishment of an IP connection. Therefore, it is often necessary to check for IP connectivity. The IP protocol suite includes a special protocol, the Internet Control Message Protocol (ICMP), that enables IP hosts connected to the Internet to report a wide range of errors and provide information about the conditions that caused the errors. Support for this protocol is mandatory on every IP host. ICMP includes a dedicated connectivity test procedure, implemented by means of two types of ICMP messages: echo request and echo reply. This procedure is often referred to as pinging: the host wanting to check IP connectivity to a destination sends one or more ping (echo request) messages, and the destination returns an echo reply message for each request. By comparing the number of pings sent to the number received and the time needed for each reply to reach the ping source, the source host can obtain useful information regarding the transmission conditions.
Trace Route
The trace route function is used to find the intermediate IP hosts (routers) that forward IP packets to a desired destination. The basic operation method of the trace route function is to sequentially send ICMP echo request (ping) packets with increasing TTL (time-to-live) values: The first set of packets have a TTL of 1 (when TTL is set to 1, an IP host will not forward packets). Thus, only the first host on the route will respond The next set of packets have a TTL of 2, and therefore they will pass the first host, but not the second one. This permits identifying the IP address of the second IP host on the route. The process continues until the destination responds to the ICMP packets.
The round trip time of each group of packets can also be measured, to detect excessive delays that may point to congestion on the route.
C-42
IP Environment
Gmux-2000 Ver. 4.0
C.11 Pseudowire Emulation

Pseudowire Emulation Techniques
Pseudo Wire Emulation Edge-to-Edge (for short, pseudowire emulation), is a mechanism that emulates the essential attributes of a telecommunications service (such as an E1 or T1 leased line) over a packet-switched network. From the perspective of customers edge equipment, using pseudowire emulation provides the characteristics of an unshared link or circuit of the chosen telecommunications service. Pseudowire emulation is intended to provide only the minimum necessary functionality to emulate the wire, and therefore the functions required of pseudowires include encapsulating the service-specific payload into packets (for example, bit streams, etc.) arriving at some ingress port and carrying them across the packet-switched network over an IP path. In some cases, it is necessary to perform additional operations to emulate the behavior and characteristics of the service with the required degree of faithfulness. Gmux-2000 supports pseudowire emulation services for efficiently carrying TDM traffic through packet-switched networks as multiple, independently routed packet streams (internally, each packet stream carries a user-defined bundle). Packet formats can be selected on a per-stream basis for optimal transmission over IP-based networks. To optimally match the requirements of each application, the following protocols are supported: TDMoIP (TDM over IP) in accordance with RFC5087. HDLCoPSN (HDLC over PSN) in accordance with RFC5087 and RFC4618 (except Clause 5.3 PPP) CESoPSN (structure-aware TDM circuit emulation over PSN) in accordance with RFC5086 SAToPSN (structure-agnostic TDM over PSN) in accordance with RFC4553
Pseudowire Emulation over UDP/IP

The User Datagram Protocol (UDP) is a transport protocol (that is, a Layer 4 protocol in the OSI model) that provides an unreliable connectionless delivery service. UDP uses IP to transport messages among host machines. One of the main characteristics of UDP is support for multiple destinations within a given host machine, which means that it enables the multiplexing of traffic from multiple sources, for example, different software processes running on the host machine, over the same IP link. The term used to refer to a UDP source (or destination) is port. UDP messages are called user datagrams. A datagram consists of two parts: User datagram header. The UDP datagram header is divided into four 16-bit fields that specify the port from which them was sent, the port to which the message is destined, the message length, and a UDP checksum.
Figure C-19 shows the structure of a UDP datagram header.

Gmux-2000 Ver. 4.0 Pseudowire Emulation C-43
Appendix C Operating Environment 0 4 8 12 16
Installation and Operation Manual 20 24 28 31
Source UDP Port (2 Bytes) Datagram Length (2 Bytes)
Destination UDP Port (2 Bytes) UDP Checksum (2 Bytes)
Figure C-19. Structure of UDP Datagram Header

The source and destination fields carry the 16-bit UDP protocol port numbers used to demultiplex datagrams. In UDP, the source port is optional: when used, it specifies the port to which replies should be sent; if not used, it should be zero. The length field carries the number of bytes in the complete UDP datagram (UDP header and user data). The UDP checksum is optional; 0 in the checksum field means that the checksum has not been computed and the field must be ignored at the receive side. User datagram data field. The datagram data field can include up to 65527 bytes. This field is usually used to carry payload such as IP packets, generated using one of the above-mentioned pseudowire emulation protocols.
TDMoIP
TDMoIP is a pseudowire technology for emulating TDM circuits over packet switched networks, with particular emphasis on IP networks, although it is often used as a generic term equivalent to TDMoPSN. TDMoIP (and for that matter TDMoPSN as well) transport capabilities include E1, fractional E1, T1 and fractional T1 data streams, with and without channel-associated signaling. Voice can also be transported. The TDMoIP technology enables transmitting the continuous data stream generated by TDM equipment as a stream of discrete packets, having a structure suitable for transmission over packet-switched networks. The data stream consists of individual timeslots retrieved from the E1 or T1 frame structure; each independent set of timeslots is referred to as a bundle. The TDMoIP packets are encapsulated in UDP packets and transported using IP (this is referred to as UDP over IP, or UDP/IP). In many applications, the TDMoIP technology must transfer not only the data stream, but also the original timing (clock rate).
Structure of TDMoIP Packets

Figure C-20 shows the structure of a basic TDMoIP packet. The packet includes
the standard IP packet header, followed by the UDP datagram carrying the payload, which is encapsulated in the IP packet. However, the UDP datagram header is slightly modified relative to the standard header: The UDP source port field is divided into two sections: Three bits that identify the TDMoIP protocol version
C-44
Pseudowire Emulation
Gmux-2000 Ver. 4.0
The source port number field, comprising 13 bits, is used to identify the TDMoIP bundle number. The bundle number serves as a pseudowire label. The available range of pseudowire labels is 1 to 8063; 0 is not allowed, the range of ports 8064 to 8190 is reserved, and 8191 is used for OAM control messages.
0
The destination UDP port number is 085E. The checksum is 0 (not calculated).
4 8 12 16 20 24 28 31
IP Version IP Header IP Type of Service (4) Length (IP TOS) Fragment Identification Time to Live Upper-Layer Protocol (UDP=17)
Total IP Packet Length (total number of octets in header + payload) Flags Fragment Offset IP Header Checksum
Source IP Address Destination IP Address TDMoIP Version TDMoIP Bundle Number (Pseudowire Label) UDP Datagram Length Destination UDP Port (085E) UDP Checksum (always 0 for TDMoIP) TDMoIP Payload . . .
Figure C-20. Structure of Basic TDMoIP Packets

The TDMoIP payload section of the packet starts with a control word having the structure shown in Figure C-21.
Byte 1 0 1 2 3 4 L 5 R 6 M 7 0 1 2 Byte 2 3 4 5 6 7 0 1 2 Byte 3 3 4 5 6 7 0 1 2 Byte 4 3 4 5 6 7
FORMID
Res
Length
Sequence Number
Figure C-21. TDMoIP Control Word Structure
Gmux-2000 Ver. 4.0
C-45
FORMID
Format identifier, comprises 4 bits, used to specify the payload format: 0000 unspecified payload format 1100 AAL1 unstructured payload 1101 AAL1 structured payload 1110 AAL1 structured with CAS payload 1001 AAL2 payload 1111 HDLC payload
Local TDM failure indicator: can be set to 1 to indicate physical layer loss of signal at the sending gateway, that should trigger AIS generation towards the destination. Remote PSN failure indicator: can be set to 1 to indicate that the sending gateway does not receive packets from the PSN, for example, because of a failure of the reverse direction of the bidirectional connection, as a result of congestion or other network-related fault. May be used to generate RDI. Defect modifier indicator (optional). Reserved. 6-bit field used to indicate the length of the TDMoIP packet, in case padding is needed to meet the minimum transmission unit requirements of the PSN. Must always be used when the total packet length is less than 64 bytes. The TDMoIP sequence number (16 bits) provides the common pseudowire sequencing function, and enables detection of lost and misordered packets.
M RES Length
Sequence Number
Structure of Ethernet Frame Carrying TDMoIP Payload

When the TDMoIP traffic is carried over Ethernet, the basic TDMoIP packet shown in Figure C-20 is encapsulated in the frame shown in Figure C-17 (without using VLANs) or Figure C-18 (when using VLANs). Essentially, this encapsulation adds the corresponding frame header before the TDMoIP packet, and the CRC field after the packet.
TDMoIP Packetizing Process

This section describes the process used to build TDMoIP packets. A simplified diagram of this process, which identifies the main steps of the process, is shown in Figure C-22. The packetizing process (illustrated here for Ethernet frames) comprises the following main steps: 1. Splitting the continuous TDM data stream into discrete slices of appropriate size. The slice size is always an integer number of bytes. For example, in Figure C-22, the number of TDM bytes per slice, K, is 2.
C-46
Gmux-2000 Ver. 4.0
2. Adding the overhead necessary to transmit each slice over the packet network and enable reaching the desired destination. Basically, this process includes the following steps: 1. Inserting the TDM bytes into the payload field of a UDP packet, and adding the overhead data needed to build a UDP packet. 2. Inserting the UDP packet into the payload field of an IP packet, and adding the overhead data needed to build an IP packet for transmission to the desired IP destination. 3. Inserting the IP packet into the payload field of an Ethernet frame, and adding the MAC overhead needed to build an Ethernet frame for transmission to the destination MAC address (the MAC address needed to reach the desired IP destination is determined using the ARP protocol). For example, in Figure C-22 the resultant overhead comprises a total of 54 bytes.
Note
The actual overhead depends on several factors, one of them being the encoding method used to transmit CAS information. Figure C-22 also ignores the minimum interpacket gap, which further increases the overhead.
Frame 1 Frame 2 Frame 48N K
TDM Frames (8000/sec)
....
... .. ...
... .. ... ............................

K=2
... .. ... ....

Closing of Frame
Opening of New Frame
Ethernet Frames
....
Overhead
..........................
1 2 3 4 . . . . . . . . . . . . . . . . . . . . . N48 Payload
F C S
....
4 bytes
42 bytes 52 bytes
Figure C-22. Building an Ethernet Frame with TDMoIP Payload

The receiving end performs the steps necessary to reconstruct the original TDM data stream from the received frames, in the best possible way, where best means meeting a set of criteria that describe a compromise among several conflicting requirements. A simplified diagram of this process, which identifies the main steps of the process, is shown in Figure C-23.
Gmux-2000 Ver. 4.0
C-47

Payload 1 2 3 4 .....................
N4 8 F C S
....
Ethernet Frames
Overhead
..........................
....
Start of New Frame
End of Frame
K=2
TDM Frames (8000/sec)
....
... .. ...
Frame 1
... .. ... ............................

Frame 2
... .. ... ....

Frame 48N K
Figure C-23. Retrieving the Payload from an Ethernet Frame with TDMoIP Payload
The number of TDM bytes inserted in each Ethernet frame sent to the network, which is actually the size of the UDP packet payload field, affects two important performance parameters: Bandwidth utilization: because of the relatively short TDMoIP payload, the bandwidth utilization efficiency depends on the overhead that must be transmitted to the PSN in order to support the transmission of a certain amount of payload. Packetizing delay and the associated delay variance. Bandwidth utilization efficiency increases when using a large payload size per frame. However, there are additional aspects that must be considered when selecting the size of the TDMoIP payload: Filling time: the filling time, which is the time needed to load the payload into am Ethernet frame, increases in direct proportion to the number of bytes in the TDMoIP payload. This is particularly significant for bundles with few timeslots; for example, a voice channel could be carried by a single-timeslot bundle. Considering the nominal filling rate (approximately one byte every 0.125 msec), for E1 streams the time needed to fill a single-timeslot bundle is as follows: At 48 TDM bytes per frame: 5.5 msec with CAS support and 5.9 msec without CAS support At 384 TDM bytes per frame: 44 msec with CAS support and 47 msec without CAS support. For T1 streams, only 24 timeslots are available, but the filling rate is similar (approximately one byte every 0.125 msec). Therefore, before considering any other delays encountered along the end-to-end transmission path, the round-trip (or echo) delay for the voice channel example presented above is 92 msec at 384 TDM bytes per frame (including the additional intrinsic delay of module see below).
C-48
Gmux-2000 Ver. 4.0
Such long delays may also cause time-out in certain data transmission protocols. Intrinsic jitter: the transmission of packets to the network is performed at nominally equal intervals (usually, the interval is 1 msec). This means that every 1 msec the TDMoIP packet processor sends to the network (through the appropriate Ethernet interface) all the frames ready for transmission. As a result, the actual payload transmission intervals vary in an apparently random way whose peak value depends on the bundle size, an effect called delay variance (or jitter). For example, a bundle with 6 timeslots will fill a 48-byte payload field of an Ethernet frame every 1 msec. If the sending instants are not perfectly synchronized with the filling instants, the sending time will sometimes occur just in time and sometimes will be delayed by 1 msec relative to the ideal, creating a peak delay variance of 1 msec at the transmitting side. The intrinsic jitter in other cases is lower, therefore the delay variance generated by the Gmux-2000 TDMoIP modules will not exceed 2 msec.
HDLCoPSN Payload Format

The HDLCoPSN payload format is intended to enable efficient transport of HDLC payload embedded in a TDM (E1 or T1) stream over a separate pseudowire connection. This format is not intended for general HDLC payloads, and assumes that the HDLC messages are always shorter than the maximum packet size. The HDLC mode should only be used when the majority of the bandwidth of the input HDLC stream is expected to be occupied by idle flags. A typical application is carrying CCS (common channel signaling, for example, Signaling System 7 SS7), which is carried in specific timeslots of E1 and T1 streams, or ISDN PEI signaling. The HDLC format is intended to operate in the port mode, transparently passing all HDLC data and control messages. To transport HDLC, the sending gateway monitors the HDLC flags, until a meaningful frame is detected. The contents of the frame are then transferred to the receiving gateway, which reconstructs the original HDLC frame.
CESoPSN Payload Format

The CESoPSN payload format is a structure-aware format that enables encapsulating structured (nDS0) TDM streams with or without CAS for transport over packet-switched networks (PSN). The CESoPSN payload format is designed to include a fixed (user-configurable) amount of TDM data in each packet. Gmux-2000 implementation supports a range of 1 to 45 frames of payload per CESoPSN packet: this ensures that packets do not have to be fragmented for transmission over PSN.
Gmux-2000 Ver. 4.0
C-49
SAToPSN Payload Format

The SAToPSN payload format is a structure-agnostic format that enables encapsulating TDM bit streams for transport over packet-switched networks (PSN). The SAToPSN payload format is designed to ignore any structure included in the bit stream, and thus can transport unframed streams, as well as any stream with proprietary or standard framing.
Using Jitter Buffers

Background
Ideally, since frames are transmitted at regular intervals, they should reach the destination after some fixed delay. If the transmission delay through the network were indeed constant, the frames would be received at regular intervals and in their original transmission order. In practice, the transmission delay varies because of several factors: Intrinsic jitter at the transmit side, described in the TDMoIP Packetizing Process section above Variations in the transmission time through the network, caused by the frame handling method: frames pass through many switches and routers, and in each of them the frame (or the packet encapsulated in the frame) is first stored in a queue with frames or packets from other sources, and is then forwarded to the next link when its time arrives. Intrinsic jitter at the receive side, due to the variation in the time needed to extract the payload from the received packets.
Jitter Buffer Functions

Any network designed for reliable data transmission must have a negligibly low rate of data loss. Therefore, it is reasonable to assume that essentially all the transmitted frames reach their destination. Under these circumstances, the rate at which frames are received from the network is equal to the rate at which frames are transmitted by their source (provided that the measurement is made over a sufficiently long time). As a result, it is possible to compensate for transmission delay variations by using a large enough temporary storage. This storage, called jitter buffer, serves as a first-in, first-out buffer. The buffer has two clock signals: Write clock, used to load packets into the buffer. Since each packet is loaded immediately after being successfully received from the network, packets are written into the buffer at irregular intervals. Read clock, used to transfer packets to the packet processor at a fixed rate.
The jitter buffer operates as follows:
C-50
Gmux-2000 Ver. 4.0
At the beginning of a session, the buffer is loaded with a conditioning pattern until it is half full. No bits are read from the buffer at this time. Therefore, a delay is introduced in the data path. After the buffer reaches the half-full mark, the read-out process is started. The data bits are read out at an essentially constant rate. To prevent the buffer from either overflowing or becoming empty (underflow), the read-out rate must be equal to the average rate at which frames are received from the network. Therefore, the buffer occupancy remains near the half-full mark.
The buffer stores the frames in accordance with their arrival order.
Selecting an Optimal Jitter Buffer Size

For reliable operation, the jitter buffer must be large enough to ensure that it is not emptied when the transmission delay increases temporarily (an effect called underflow, or underrun), nor fills up to the point that it can no longer accept new frames when the transmission delay decreases temporarily (an effect called overflow). The minimum size of a jitter buffer depends on the intrinsic jitter: usually, the minimum value is 3 msec. The maximum size is 300 msec. The theoretically correct value for the size of the jitter buffer of any given bundle is slightly more than the maximum variation in the transmission delay through the network, as observed on the particular link between the bundle source and the destination. For practical reasons, it is sufficient to select a value that is not exceeded for any desired percentage of time: for example, a value of 99.93% means that the jitter buffer will overflow or underflow for an accumulated total of only one minute per day. Jitter buffers are located at both ends of a link, therefore the delay added by the buffers is twice the selected value. The resultant increase in the round-trip delay of a connection may cause problems ranging from inconvenience because of long echo delays on audio circuits (similar to those encountered on satellite links) to time-out of data transmission protocols. Therefore, the size of each jitter buffer must be minimized, to reduce the round-trip delay of each connection in as far as possible, while still maintaining the link availability at a level consistent with the application requirements.
Adaptive Timing
Because of the transmission characteristics of packet switching networks, which use statistical multiplexing, the average rate must be measured over a sufficiently long interval. The optimal measurement interval is equal to the difference between the maximum and minimum transmission delays expected in the network. As explained above, the buffer is used to store packets for an interval equal to the maximum expected delay variation. Therefore, this buffer can be used by the adaptive timing mechanism, to recover a clock having a frequency equal to the average transmit rate. The method used to recover the payload clock of a bundle is based on monitoring the fill level of the jitter buffer: the clock recovery mechanism monitors the buffer
Gmux-2000 Ver. 4.0
C-51
fill level, and generates a read-out clock signal with adjustable frequency. The frequency of this clock signal is adjusted so as to read frames out of the buffer at a rate that keeps the jitter buffer as near as possible to the half-full mark. This condition can be maintained only when the rate at which frames are loaded into the buffer is equal to the rate at which frames are removed. Assuming that the IP network does not lose data, the average rate at which payload arrives will be equal to the rate at which payload is transmitted by the source. Therefore, the adaptive clock recovery mechanism actually recovers the original payload transmit clock. This mechanism described above also generates a clock signal having the frequency necessary to read-out frames at the rate that keeps the jitter buffer as near as possible to the half-full mark. The bundle used as the basis for recovering the adaptive clock can be selected by the user.
C.12 SNMP Environment

The SNMP management functions of the Gmux-2000 are provided by an internal SNMP agent. The SNMP management communication uses the User Datagram Protocol (UDP), a connectionless-mode transport protocol, part of the suite of protocols of the Internet Protocol (IP). This section covers the information related to the SNMP environment.
SNMP Principles
The SNMP management protocol is an asynchronous command/response polling protocol: all the management traffic is initiated by the SNMP-based network management station, which addresses the managed entities in its management domain. Only the addressed managed entity answers the polling of the management station. The only exception to the rule are trap messages, which are sent by a managed entity asynchronously, to inform the management station of a significant event. The managed entities include a function called an SNMP agent, which is responsible for interpretation and handling of the management station requests to the managed entity, and the generation of properly-formatted responses to the management station. SNMP has evolved to include three main versions: SNMPv1 basic SNMP version SNMPv2 basic SNMP version, provides additional operations and enhanced trap features SNMPv3 adds security capabilities to be used with SNMPv1 and SNMPv2
C-52
SNMP Environment
Gmux-2000 Ver. 4.0
SNMP Operations
The SNMPv1 protocol includes four types of operations: getRequest Command initiated by the management station for retrieving specific management information from the managed entity. The managed entity responds with a getResponse message. Command initiated by the management station for retrieving sequentially specific management information from the managed entity. The managed entity responds with a getResponse message. Command initiated by the management station for manipulating specific management information within the managed entity. The managed entity responds with a setResponse message. Message (alert) sent by the managed entity, carrying unsolicited information on significant events (e.g., startup, alarms) reported by the managed entity.
getNextRequest
setRequest
trap
The SNMPv2 protocol includes the following additional types of operations: getBulk Inform Command initiated by the management station for efficiently retrieving large blocks of data. Trap (alert) sent by a management station to another management information, which then sends a response
SNMP Traps
The Gmux-2000 SNMP agent supports the MIB-II authentication trap, and in addition generates enterprise-specific traps for each alarm message. Traps are also sent to notify the management station of the following events: Resetting (warm start trap) Change in status of the management link (up or down) Authentication failure (use of wrong community).
Management Information Base

The management information base (MIB) includes a collection of managed objects. A managed object is defined as a parameter that can be managed, such as a configuration parameter, a performance statistics value, etc. The MIB includes the definitions of relevant managed objects. Various MIBs can be defined for various management purposes, types of equipment, etc. An object's definition includes the range of values and the access rights: Read-only Read-write Object value can be read, but cannot be set. Object value can be read or set.
Gmux-2000 Ver. 4.0
SNMP Environment
C-53
Write-only Not accessible
Object value can be set, but cannot be read. Object value cannot be read, nor set.
MIB Structure
The MIB has an inverted tree-like structure, with each definition of a managed object forming one leaf, located at the end of a branch of that tree. Each leaf in the MIB is reached by a unique path, therefore by numbering the branching points, starting with the top, each leaf can be uniquely defined by a sequence of numbers. The formal description of the managed objects and the MIB structure is provided in a special standardized format, called Abstract Syntax Notation 1 (ASN.1). Since the general collection of MIBs can also be organized in a similar structure, under the supervision of the Internet Activities Board (IAB), any parameter included in a MIB that is recognized by the IAB is uniquely defined. To provide the flexibility necessary in a global structure, MIBs are classified in various classes (branches), one of them being the experimental branch, and another the group of private (enterprise-specific) branch. Under the private enterprise-specific branch of MIBs, each enterprise (manufacturer) can be assigned a number, which is its enterprise number. The assigned number designates the top of an enterprise-specific sub-tree of non-standard MIBs. Within this context, RAD has been assigned the enterprise number 164. Therefore, enterprise MIBs published by RAD can be found under 1.3.6.1.4.1.164. MIBs of general interest are published by the IAB in the form of a Request for Comment (RFC) document. In addition, MIBs are also often assigned informal names that reflect their primary purpose. Enterprise-specific MIBs are published and distributed by their originator, which is responsible for their contents. Enterprise-specific MIBs supported by RAD equipment, including the Gmux-2000, are available in ASN.1 format from the RAD Technical Support Department.
Management Domains under SNMPv1 and SNMPv2

SNMPv1 and SNMPv2 enable, in principle, each management station that knows the MIBs supported by a device to perform all the management operations available on that device. However, this is not desirable in practical situations, so it is necessary to provide a means to delimit management domains.
SNMP Communities
To enable the delimitation of management domains, SNMPv1 and SNMPv2 use communities. Each community is identified by a name, which is a case-sensitive alphanumeric string defined by the user. Any SNMP entity (this term includes both managed entities and management stations) can be assigned by its user community names.
Access Restriction Using SNMP Communities

In general, SNMPv1 and SNMPv2 agents support two types of access rights:
C-54
SNMP Environment
Gmux-2000 Ver. 4.0
Read-only: the SNMP agent accepts and processes only SNMP getRequest and getNextRequest commands from management stations which have the same read-only community name. Read-write: the SNMP agent accepts and processes all the SNMP commands received from a management station with the same write community name.
For each SNMP entity it is possible to define a list of the communities which are authorized to communicate with it, and the access rights associated with each community (this is the SNMP community name table of the entity). For example, the SNMP community name table of the Gmux-2000 SNMP agent can include three community names. In accordance with the SNMP protocol, the SNMP community of the originating entity is sent in each message. When an SNMP message is received by the addressed entity, first it checks the originator's community: if the community name of the message originator differs from the community name specified for that type of message in the agent, the message it discarded (SNMP agents of managed entities report this event by means of an authentication failure trap).
Gmux-2000 Communities
When using SNMPv1 and SNMPv2 without SNMPv3 security features, the SNMP agent of the Gmux-2000 is programmed to recognize the following community types: Read SNMP community that has read-only authorization, i.e., the SNMP agent will accept only getRequest and getNextRequest commands from management stations using that community. SNMP community that has read-write authorization, i.e., the SNMP agent will also accept setRequest commands from management stations using that community. SNMP community which the SNMP agent will send within trap messages.
Write
Trap
SNMPv3 Capabilities
SNMPv1 and SNMPv2 can neither authenticate the source of a management message, nor provide privacy (encryption). To overcome these shortcomings, SNMPv3 provides a security framework for SNMPv1 and SNMPv2 that adds the following main capabilities: Security features: Authentication checks the integrity of management data and verifies its origin, and thus ensures that unauthorized users cannot masquerade as authorized users Privacy ensures that unauthorized users cannot monitor the management information passing from managed systems to the management system
Gmux-2000 Ver. 4.0
SNMP Environment
C-55
Authorization and access control ensures that only authorized users can perform SNMP network management functions and contact the managed entities. Administrative features: Naming of entities People and policies Usernames and key management Notification destinations Proxy relationships Remote dynamic configuration of agents via SNMP operations.
SNMP Engine ID
An important parameter defined in relation with SNMPv3 is the SNMP engine ID, a unique and unambiguous identifier of the function that processes SNMP messages (it thus also identifies the SNMP entity that corresponds to that engine). The SNMP engine ID is a string that has three components: An automatically-generated, fixed part A part that identifies the configuration type (method) used to derive the user-defined part is selectable. A user-defined part, which must be unique within the SNMP-managed network. The method used to configure this part depends on the configuration type.
The automatically-generated part of the SNMP engine ID changes after each restart (reboot) of the SNMPv3 protocol. For reasons explained below in the SNMPv3 Administrative Features section, the SNMP engine ID is the first parameter to be set whenever SNMPv3 is used and the configuration data and authorized users must be reconfigured.
SNMPv3 Message Processing

SNMPv3 message processing requires two mechanisms (models): the message processing model, and a specific security model. The message processing model performs the following tasks: In the transmit direction: accepts SNMP protocol data units (PDUs) from the SNMP agent central processor, encapsulates them in messages, and then subjects the message to the security model, to insert security-related parameters in the message header In the receive direction: accepts incoming messages, uses the security model to process the security-related parameters in the message header, and delivers the encapsulated PDU to the SNMP agent central processor
The message processing models supported by Gmux-2000 are as follows: SNMPv1
C-56
SNMP Environment
Gmux-2000 Ver. 4.0
SNMPv2c: SNMPv2 with community-based security model SNMPv2u: SNMPv2 with user-based security model (USM) SNMPv3 The security models available for Gmux-2000 are as follows: SNMPv1 SNMPv2c: SNMPv2 with community-based security model User-based security model (USM) The user can also enable using any of the above-mentioned models, to match different management station capabilities: the appropriate model is automatically selected, in accordance with the model used in the incoming SNMP message.
User-Based Security Model (USM)

The USM, defined in RFC2272, provides authentication and privacy services for SNMP, to protect against modification of information in transit from an authorized entity (including modification of message order, delaying or replaying of valid messages to change their effect, etc.), prevent an unauthorized entity from performing management operations by assuming the identity of an authorized entity, and prevent disclosure of the contents of the messages exchanged between a management station and an agent. To achieve these goals, USM uses authentication to check the integrity of transmitted messages, and encryption to prevent disclosure: Authentication mechanisms. Mechanisms that provide integrity checks based on a secret key are usually called message authentication codes (MAC). Typically, message authentication codes are used between two parties that share a secret key in order to validate the information transmitted between these parties. Therefore, an SNMP engine requires an authentication key and a privacy key. Separate values of these two keys are maintained for each local and remote user, and their values must be stored by each user, because the keys are not accessible via SNMP. USM authentication protocol is based on the key-Hashing Message Authentication Code (HMAC), described in RFC2104. HMAC uses a userselected secure hash function and a secret key to produce a message authentication code. USM allows the use of one of two alternative authentication protocols, where both generate a 96-bit output that is used to check message integrity: HMAC-MD5-96: HMAC is used with MD5 (Message Digest algorithm 5) as the underlying hash function. HMAC-SHA-96: HMAC is used with SHA-1 (Secure Hashing Algorithm 1). Encryption mechanism. USM uses the cipher block chaining (CBC) mode of the Data Encryption Standard (DES) for encryption, with a key length of 56 bits.
View-Based Access Control Model (VACM)

SNMP manager authorizations are defined by means of the view-based access security model (the name of the model is derived from the method used to
Gmux-2000 Ver. 4.0
SNMP Environment
C-57
define the authorizations: control over the MIB parts that can be viewed by each manager). VACM makes it possible to configure each SNMPv3 agent to allow different levels of access to different managers: for example, the Gmux-2000 SNMPv3 agent may restrict some managers to view only the Gmux-2000 performance statistics, and allow others to view and update Gmux-2000 configuration parameters. Moreover, the SNMPv3 agent can also limit what a manager can do by accepting only commands that invoke parameters included in certain parts of the relevant MIBs (for example, read-only access to the configuration parameters part of a MIB, and read-write access to the diagnostics part). The access control policy used by the agent for each manager must be preconfigured (the policy essentially consists of a table that details the access privileges of each authorized manager). For Gmux-2000, the configuration of the VACM parameters can only be made by means of a MIB browser, and/or by SNMP commands.
SNMP Security Level

The USM capabilities enable the user to select the level of security at which SNMP messages can be sent or with which operations are being processed. The available options are as follows: No authentication and no privacy (encryption) the lowest protection. With authentication, but without privacy With authentication and with privacy the best protection level.
SNMPv3 Administrative Features

The administrative features of SNMPv3 enable determining the entities that are allowed to manage an entity, for example, the Gmux-2000. There are two administrative aspects: User management. During SNMPv3 configuration, it is necessary to define allowed users and their security attributes. For each user, it is possible to select the security level, and the passwords used for each type of protection (authentication and/or privacy) needed at the selected level. Target and notification management. As part of the SNMPv3 configuration, you can also define the notification capabilities for a list of entities referred to as targets (of notification messages). For each target, you can specify a message processing model, a security model, and the required security level. You can also define a list of notifications that can be sent to the corresponding target.
Note
Gmux-2000 supports only the sending of traps for notification purposes.
C-58
SNMP Environment
Gmux-2000 Ver. 4.0
24 Raoul Wallenberg Street, Tel Aviv 69719, Israel Tel: +972-3-6458181, Fax +972-3-6483331, +972-3-6498250 E-mail: erika_y@rad.com, Web site: http://www.rad.com
Customer Response Form

RAD Data Communications would like your help in improving its product documentation. Please complete and return this form by mail or by fax or send us an e-mail with your comments. Thank you for your assistance!
Manual Name: Publication Number:
Gmux-2000 (SONET) Ver. 4.0 358-201-08/10
Please grade the manual according to the following factors:
Excellent
Installation instructions Operating instructions Manual organization Illustrations The manual as a whole
Good
Fair
Poor
Very Poor
What did you like about the manual?
Error Report
Type of error(s) or problem(s): Incompatibility with product Difficulty in understanding text Regulatory information (Safety, Compliance, Warnings, etc.) Difficulty in finding needed information Missing information Illogical flow of information Style (spelling, grammar, references, etc.) Appearance Other Please list the exact page numbers with the error(s), detail the errors you found (information missing, unclear or inadequately explained, etc.) and attach the page to your fax, if necessary.
Please add any comments or suggestions you may have.
You are:
Distributor End user VAR Other
Who is your distributor? Your name and company: Job title: Address: Direct telephone number and extension: Fax number: E-mail:
Publication No. 358-201-08/10
Order this publication by Catalog No. 803606
International Headquarters
24 Raoul Wallenberg Street Tel Aviv 69719, Israel Tel. 972-3-6458181 Fax 972-3-6498250, 6474436 E-mail market@rad.com
North America Headquarters

900 Corporate Drive Mahwah, NJ 07430, USA Tel. 201-5291100 Toll free 1-800-4447234 Fax 201-5295777 E-mail market@rad.com
www.rad.com
The Access Company

Gmux-2000

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Gmux-2000

Uploaded by

Copyright:

Available Formats

INSTALLATION AND OPERATION MANUAL

The Access Company

Installation and Operation Manual Notice

19952010 RAD Data Communications Ltd.

Publication No. 358-201-08/10

General Safety Instructions

Handling Energized Products

Connecting Data and Telecommunications Cables

FXS (Foreign Exchange Subscriber)

Electromagnetic Compatibility (EMC)

FCC-15 User Information

Canadian Emission Requirements

Warning per EN 55022 (CISPR-22)

Mise au rebut du produit

Instructions gnrales de scurit

Manipuler des produits sous tension

Connexion au courant du secteur

Haim Karshen VP Quality

RAD Data Communications GmbH, Otto-Hahn-Str. 28-30, 85521 Ottobrunn-Riemerling, Germany

Quick Start Guide

OC3 Module or C.OC3 Module or T1-PW/28 Module or T1-PW-SRV/28 Module

Slot Utilization for TDM Traffic Transport Services

Gmux-2000 Ver. 4.0

Quick Start Guide

Installation and Operation Manual

Power Inlet (PI) Module

ALA RM S PW R T ST M AJ . ALARM M IN . ALA RM

GE 2 PAUSE RX LINK TX PAUSE RX ACT FLT

REM ACT FLT I/O-4

REM ACT FLT I/O-3

REM ACT FLT I/O-2

S TAT ION CLOCK 1 3 5 7 9 11 13 15 LOC ACT FLT REM 2 4 6 8 10 12 14 16

REM ACT FLT I/O-1

Gmux-2000 Ver. 4.0

Installation and Operation Manual

Quick Start Guide

GMUX2000>admin# update-card-types GMUX2000>config>card# card-type

10. 11. 12.

Gmux-2000 Ver. 4.0

Quick Start Guide

Installation and Operation Manual

13. 14. 15. 16. 17. 18.

GMUX2000>config>port# GMUX2000>config>system>clock# GMUX2000>config>protection# GMUX2000>config#>cross-connect GMUX2000>config>pwe#

Gmux-2000 Ver. 4.0

Installation and Operation Manual

Installation and Operation Manual

Installation and Operation Manual

Installation and Operation Manual

Installation and Operation Manual

Installation and Operation Manual

Installation and Operation Manual

Gmux-2000 Ver. 4.0B

Gmux-2000 Ver. 4.0

Installation and Operation Manual

Gmux-2000 Ver. 4.0

Installation and Operation Manual

Gmux-2000 Ver. 4.0

Installation and Operation Manual

Gmux-2000 Ver. 4.0

Installation and Operation Manual

Channelized OC-3 Modules

Gmux-2000 Ver. 4.0